Consent for Mobile Credentials

From MgmtWiki
Jump to: navigation, search

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

There are three times where a user is asked to make a decision which can impact their privacy and convenience.

  1. The user is asked to load or activate a mobile application which will act as their agent for secrets that they hold.
  2. 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.
  3. The holder seeks out and acquires credentials that can be held on their personal device (with perhaps some assist from a cloud service). This has not considered in existing credentials which are supplied by governments or Fiduciary institutions like banks and employers, but may become more of a concern with Digital Assets and Web3 Digital Identifiers,

Goal

  • 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:
  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.
  • In no case is any definition or other input used that is not publicly accessible. (Like from ISO 18013-5 or 27560)
  • Existing legal language like opt-in or opt-out that was written before the existence of Smartphones is not included.

Taxonomy

  1. 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.
  2. The user agent is a collection of the device operating system and applications (like the Wallet) that can display a request to the holder and solicit a response.
  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.
  6. The Subject of the credential is typically the holder except when the holder is acting as a delegate or guardian for the Subject.

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

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.)
  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 than the broad categories of:
  1. Who is asking for my data? (typically this will be a verifier and a verifier provider. (aka Data Controller and Data Processor)
  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. When and where will my retained data be used?
  5. Where is the request being made (to the extent that this location contains any information important to my decision)?
  6. 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:
  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.
    1. Who is the airline as agent for the government security checks.
    2. Why the data is needed (purpose) is to prevent hijacking attacks.
    3. What data is needed is dependent to some extent on the holder, who needs to prove that they are not a risk.
    4. 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.
    5. 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.
    6. 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.
  2. Getting a glass of wine at the locally owned restaurant will typically involve showing the mobile credential to some checker at the restaurant.
    1. 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.
    2. Why (purpose) is because the holder wants access to a substance that is controlled by a state that sets the rules?
    3. What data is needed is determined by the local liquor board but is being standardized by the ISO 18015 standards processes?
    4. When should be limited to the access point and retention should be limited to meeting state reporting requirements?
    5. 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.
    6. How this happens in being addressed in 18013-7, but potentially with guidance created by local standardization efforts like PEMC in North America.
  3. Medical impairment use where the user cannot be expected to be able to give meaningful consent:
    1. The major case of interest to this broad category is the holder's mobile device may have explicit consent indicated.
    2. Also, it is a requirement that general purpose wallets support subjects that are not able to use a Smartphone for whatever reason.
  • Implied Consent = Implied consent arises where consent may reasonably be inferred from the action or inaction of the individual[1]. None of these cases appear to be applicable to Consent for Mobile Credentials although they may apply to use cases where a mobile credential is used, such as the airport pre-check with biometric verification.
    • In particular, a user gesture on the consent screen of the Smartphone is considered to be explicit consent.
    • Impairment to operate where the user is reasonable expected to have lost the physical ability to meet license requirements:
    • There is this implied consent case in (for example) the United States[2] allows implied consent if the driver of a motor vehicle appears impaired. Although in this case the license can be viewed as a contract between the state and the driver.

Solutions

Situational Consent

There are cases, like emergency medical or others where the time to get consent can result in life threatening situations. An example is taken from WA state, but other jurisdictions will have similar regulations. If there is time, judicial review is required, for example in mental illness confinement. While these rules apply in other cases, it is only the Consent for Mobile Credentials case that is included here:

  • Many states have "Good Samaritan" laws that allow licensed medical personal to make decisions within their area of expertise.
  • The State of WA grants licenses to EMT personnel and vehicles so that they can make limited medical decisions.[3]
    The secretary licenses ambulance and aid services and vehicles to provide service that is consistent with the state plan and approved regional plans.
  • Note that is a licensed EMT on duty and in an approved vehicle, the only situation where that is permitted.
  • Similar rules apply in a licensed hospital emergency environment.
  • The Smartphone may include information on the lock-screen on how to access medical history information that can be accessed in these situations.

Apple Wallet

Request for consent from a state-issued ID like a Mobile Driver's License requires face-id or touch-id which gives some element of Proof of Presence.

Consent Apple Wallet.png

References

  1. ↑ iapp resource center https://iapp.org/resources/article/consent-2/
  2. ↑ US DoJ INTERPRETATION OF IMPLIED CONSENT LAWS BY THE COURTS (1972) https://www.ojp.gov/ncjrs/virtual-library/abstracts/interpretation-implied-consent-laws-courts#:~:text=ALL%20FIFTY%20STATES%20HAVE%20ENACTED,ALCOHOLIC%20CONTENT%20OF%20HIS%20BLOOD
  3. ↑ WAC 246-976-260 http://app.leg.wa.gov/WAC/default.aspx?cite=246-976-260&pdf=true

Other Material

  • See also the wiki on Mobile Privacy Experience for information on the user experience of this type of transaction.
  • See also the wiki on Consent Management for information on the protocols that are used to carry consent request and response information.

Input from the following individuals are acknowledged. It is not to be presumed that these individuals agree with anything in this paper.

  • Heather Flanagan
Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Consent_for_Mobile_Credentials&oldid=21826"