Consent for Mobile Credentials

Consent for Mobile Credentials Introduction

Abstract

This paper specifies the requirements for meaningful consent between the holder and the verifier of a mobile credential.

Author: Tom Jones

Context

The holder can understand the request and make a very quick decision about proceeding. The Verifier can be held responsible for meeting the terms granted by the consent.

Goal

• The mobile driver’s license or state-issued ID is more likely to be used than the card in the wallet.

Taxonomy

1. The holder is a human being with a mobile device that is capable of holding credentials and other user private data.
2. The user agent is a collection of the device operating system and applications that can display a request to the holder.
3. The verifier is some collection of devices, relying parties and service providers that requests user private data.
4. The purpose expresses the reason that user private data is requested.

Problems

1. User proofing – typically this is by comparing the user physical attributes in some form, for example facial recognition.
2. Verifier proofing – this is the information carried from the verifier device to the user agent on the user device, for example a smartphone.
3. Will the verifier be required to be registered before it can request data from a mobile credential?
4. Data retention – in most cases, like the GDPR, the only concern is whether the user is required to supply user information to the verifier. In cases like user proofing, the comparison may be made by either the user device or the verifier device, but the assumption should be that in the latter case that the data is not retained by the verifier.
5. The consent page on mobile devices is small and the best UI would allow the user to decide on a single screen of data with the “OK” button at the bottom.
6. Besides the proofing of the user the mobile credential will typically contain a license or grant to use or access some resource, like driving or fishing. These licenses can be suspended or revoked which the use of the credential for identification remains. This will typically require either on-line access to the licenses, or for better user data protection, a frequent update of the credential on the user device. For best security this should be a push model, but that creates some privacy concerns.
7. The verifier will likely be more than one legal entity, how much detail is appropriate to display on the consent page seen by the user and how much data should be relegated to other screens that the user most likely will not visit.
8. Can the issuer track the progress of the user?

Requirements

1. The holder has an agent running in a mobile device that is trusted to represent the holder’s interest.
2. The agent may accumulate holder policy over time that will allow faster decisions in the future. The holder can always see and modify that policy. (Often these are call settings.)
3. The agent can express that holder’s intent and personal information to the verifier in a statement that the verifier can accept. (i.e., It meets the policy of the verifier.)
4. The Verifier has a requirement for information about the holder that can be specified as a purpose to the holder’s agent in a format known to both the agent and verifier.
5. Beside information required by the verifier for the purpose stated, the verifier can request additional information at the option of the holder.
6. The request from the verifier must indicate which information is retained by the verifier for longer than the completion of the current transaction. (This allows for biometric data to be used to verify the binding of the holder to information supplied.)
7. The holder’s agent can and will create a single screen that gives the holder the information needed to make the choice to release data. (Note that the single screen is allowed to reference other information that is made accessible to the holder from that screen.) Optional information must be separated from required information in the request for consent displayed to the holder.
8. The verifier will present entity IDs for all of the parties that will participate in the verification process. In particular the requesting party and the processing party (GDPR calls these the data controller and data processor.)

User Journeys

There are many shown in great detail at this link https://kantara.atlassian.net/wiki/spaces/PEMCP/pages/2097325/User+Stories The paradigmatic edge cases are:

1. Going through the security line at the airport will typically involve some sovereign entity which is obligated to proof the user before access to the planes.
2. Getting a glass of wine at the locally owned restaurant will typically involve showing the mobile credential to some checker at the restaurant. Can we define a paradigmatic consent screen where age proofing is the only action accessible? (Purpose specific screening.)