Credential Aggregation

From MgmtWiki
Revision as of 14:41, 24 November 2021 by Tom (talk | contribs) (Consent)

Jump to: navigation, search

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.

Principles

  • The user will provide no data that is not required for the purpose desired for this access.

Taxonomy

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 broad 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. In some cases the shc is stored in a health app rather than in the wallet.
  • When credentials needed at one site (like the gym in this case) it is likely that the user 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.

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.

References