Consent for Mobile Credentials
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
There are two times where a user is asked to make a decision which can impact their privacy and convenience.
- The user is asked to load or active a mobile application which will act as their agent for secrets that they hold.
- The holder can understand a request for information and make a very quick decision about proceeding. The Verifier can be held responsible for meeting the terms granted by the consent.
- The user is comfortable using their phone application as a secure place for their secrets.
- 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:
- Required for access by a verifier that has a resource the user requires, or
- For all other use cases, the credential must be easy to acquire and convenient to display to the verifier.
- In all cases the holder must determine that the digital form does not compromise their expectations to privacy, safety and incremental cost.
- The holder is a human being with a mobile device that is capable of holding credentials and other user private data and is requesting access to some resource.
- The user agent is a collection of the device operating system and applications that can display a request to the holder.
- The verifier is some collection of devices, relying parties and service providers that requests user private data.
- The purpose expresses the reason that user private data is requested.
- 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.
- The Subject of the credential is typically the holder except when the holder is acting as a delegate or guardian for the Subject.
- User proofing – typically this is by comparing the user physical attributes in some form, for example facial recognition.
- Verifier proofing – this is the information carried from the verifier device to the user agent on the user device, for example a smartphone.
- Will the verifier be required to be registered before it can request data from a mobile credential?
- 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.
- 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.
- 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.
- 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.
- Can the issuer track the progress of the user?
- The holder has an agent running in a mobile device that is trusted to represent the holder’s interest.
- 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.)
- 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.)
- 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.
- Beside information required by the verifier for the purpose stated, the verifier can request additional information at the option of the holder.
- 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.)
- 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.
- 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.)
- 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.
- It is difficult to make generalizations about what a user needs to see to make a consent decision other than the broad categories of:
- Who is asking for my data?
- Why are they asking for my data (what is their specific purpose in asking)?
- What data do that really need and what is above and beyond what they need?
- When and where will my retained data be used?
- Where is the request being made (to the extent that this location contains any information important to my decision)?
- How will they determine who is requesting access and will that process result in biometric data leakage?
- There are many shown in great detail at this link. The paradigmatic edge use cases are:
- 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.
- Who is the airline as agent for the government security checks.
- Why the data is needed (purpose) is to prevent hijacking attacks.
- What data is needed is dependent to some extent on the holder, who needs to prove that they are not a risk.
- When will the data be collected is at least 24 hours before the plane leaves and retention is variable but does trend towards complete erasure eventually. See the wiki page on Passenger Name Record for details.
- Where the data is collected is likewise variable, but typically begins when the airline creates a flight record(s). The holder should be able to trust the airline collecting that data.
- How can the holder know who sees the data? That can be determined, but only by diligent inspection of the rules and regulations, or the holder can trust the governing authority to protect their data.
- Getting a glass of wine at the locally owned restaurant will typically involve showing the mobile credential to some checker at the restaurant.
- Who is the local restaurant, but if the solution is well-constructed, this ID is just to let the user agent know that the verifier is trustworthy.
- Why (purpose) is because the holder wants access to a substance that is controlled by a state that sets the rules?
- What data is needed is determined by the local liquor board but is being standardized by the ISO 18015 standards processes?
- When should be limited to the access point and retention should be limited to meeting state reporting requirements?
- Where the data is collected should be clear by proximate location of the liqueur dispenser. Note that is also possible to acquire some sort of token, like a plastic armband to use at the dispenser.
- How this happens in being addressed in 18013-7, but potentially with guidance created by local standardization efforts like PEMC in North America.