Consent for Mobile Credentials

From MgmtWiki
Revision as of 13:43, 28 July 2022 by Tom (talk | contribs) (User Journeys)

Jump to: navigation, search

Consent for Mobile Credentials Introduction


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

Author: Tom Jones


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.


  • The mobile driver’s license or state-issued ID is more likely to be used than the card in the wallet.
  • This paper makes the assumption that paper versions continue to be available for the foreseeable future.
  • This paper makes the assumption that the only way the holder is likely to adopt a mobile credential if it is:
  1. Required for access by a verifier that has a resource the user requires, or
  2. For all other use cases, the credential must be easy to acquire and convenient to display to the verifier.
  3. In all cases the holder must determine that the digital form does not compromise their expectations to privacy, safety and incremental cost.


  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.
  5. The transaction is a process that requires the user data for the purpose given. In cases where there is some warrantee or guaranty of return, the transaction will continue until that expires.


  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 displayed by 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?


  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.)
  9. The user agent will always display to the user the name of the legal entity that will retain user data beyond the duration of the transaction.

Use Context

  • It is difficult to make generalizations about what a user needs to see to make a consent decision other that the broad categories of:
  1. Who is asking
  2. Why are they asking for my data (what is their specific purpose in asking)
  3. What data do that really need and what is above and beyond what they need
  4. What will happen to my data that they retain
  5. Where is the request being made (to the extent that this is important to my decision.)

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.)