Credential Aggregation

Full Title or Meme

In the real-world a person is likely to need to produce more than one certificate from the wallet to get access to high value locations. This use case looks at how that effort might be addressed when Credentials are held in digital format.

Context

• To reify this abstract concept we will use a Smartphone to digitize John's common practice of actually using his gym membership. The following credentials are displayed to the desk attendant today.

1. Gym membership card - typically will include an expiration date.
2. Driver's license - to provide a biometric image for verification.
3. Smart Health Card - to prove vaccination or current testing.

• In the physical world presentation of the three credentials there is no necessity for the issuer to know when and where the credential was presented, aside from the obvious recording by the gym. Which is implicit in swiping the membership card for entry into the gym. In the Digital presentation it is possible for the issuer of the COVID certification and mDL to collect info about the presentation - which would be an infringement on Privacy as the disclosure to the mDL or COVID issuer of any attributes related to the presentation is not necessary for the purpose of the transaction

Principles

• The user will provide no data that is not required for the purpose desired for this access.
• Digital access to credentials cannot be more difficult than stuffing a bunch of cards into a wallet.

Taxonomy

• Credential is a collection of user attributes attested by the issuer.
• Attribute or Identifier are terms used in Identity Management for Authentication information.
• Data element can represent an attribute, identifier or details of the digital world.
• Claim as defined in NIST or SAML publications is just a statement the user makes about themselves. Sometimes this is confused with attribute.
• Verified can applied to Credentials, Presentations or Attributes.
• Digital Presentation is a data minimized collection of user attributes from one or more credentials.
• User Experience or presentation of options to the user for their consent.
• Identity Token is generated by an Authentication process like OpenID Connect.
• Access Token is generated by an Authorization process. A future use case, Ball Park Ticket Acquisition, will describe the process.

Problems

• In the real world only a few sites ask to make copies of your credentials and collect more data than they need in the process.
• In the digital world collecting the full credential exposes the user to signification loss of Privacy.
• Many issuers of credentials are very specific about which wallet can be used to store their credential with adequate security.
• The Verifiable Credential spec comes with a very specific presentation format which is both exclusive to its use and very broad in the the range that be be request and delivered.
• Other credentials, like the Smart Health Card (shc:) are completely independent of the wallet and are accepted by existing Smartphones updates as of 2021-11-24. In some cases the shc is stored in a health app rather than in the wallet.
• When multiple credentials are needed at one site (like the gym in this case) it is likely that the user (in 2021) will need to open separate web apps or wallets for each credential. Not a very user-friendly process when trying to carry your gym bag and get past the receptionist.

Solutions

• Any successful solution cannot make life more difficult for the user. Credential Aggregation is proposed for the gym access use case.
• As a general rule the user's entire credential data contents should not be passed to any Relying Party whether in-person or on-line.
• Data minimization requires that most presentations of user data be extracted from the credential depending on the purpose of use.
• Presentation apps are likely to exist based on the needs of the Relying Party and will need to be able to acquire data from all sorts of credentials. In some cases these will be delivered to the user with the Smartphone.
• Since many of the wallets are not configurable to talk to other apps on the Smartphone, it is expected that most presentation apps will be provided as Progressive Web Apps. In many cases these apps will be from the Relying Party or a Federation of Relying Parties. This solution allows the Relying Party to ensure that the data provided is sufficient to act as an access token, perhaps with some biometric evaluation, which could be performed within the Smartphone itself.
• Once a user has an access token on the Smartphone, it is very helpful for the user to be able to verify that the access token will work before travelling to the gym. Such a verification endpoint should always be available to the holder of the credential and/or the Access Token.

Consent

• To meet the principle that user's must be aware that data is only to be used for the purpose intended several conditions will be crucial.

1. The user can see the purpose of use display on a consent screen.
2. There maybe a list of data elements displayed to the user, but this in not a good User Experience.
3. In cases like healthcare it is not likely that the user would even understand what most of the data elements were and the list would be very long.
4. One possible solution is a government approved list of purposes. It is likely that industry groups would be tasked to create the lists for approval.

• A Consent receipt is recommended at least the first time that consent is granted. It would like pretty much the same as that provided by existing authenticators. Some notification channel will need to exist to the user, such as email or sms. This channel could also be used for other notification like breaches.