Difference between revisions of "Credential Aggregation"
From MgmtWiki
(→Taxonomy) |
(→Problems) |
||
| (17 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
==Context== | ==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. | * 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. | ||
| − | |||
# Driver's license - to provide a biometric image for verification. | # Driver's license - to provide a biometric image for verification. | ||
# Smart Health Card - to prove vaccination or current testing. | # Smart Health Card - to prove vaccination or current testing. | ||
| + | # Gym membership card - typically will include an expiration date. This card is entirely local, and is optional to this use case. | ||
* 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 | * 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=== | ===Principles=== | ||
* The user will provide no data that is not required for the purpose desired for this access. | * 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 | + | * Before the user is asked to consent to the transaction, they will see the full cost in money and in lost privacy to complete any transaction. |
| + | * Digital access to credentials cannot be more difficult than stuffing a bunch of cards into a wallet. | ||
===Taxonomy=== | ===Taxonomy=== | ||
| Line 21: | Line 22: | ||
* [[Digital Presentation]] is a data minimized collection of user attributes from one or more credentials. | * [[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. | * [[User Experience]] or presentation of options to the user for their consent. | ||
| + | * [[OpenID_Connect#Identity_Token|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== | ==Problems== | ||
| + | * Browsers only understand a small set of "login credentials", primarily user-name and password. | ||
* 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 real world only a few sites ask to make copies of your credentials and collect more data than they need in the process. | ||
| + | ** This is changing now that scanners can capture a driver's license card and turn it into a digital representation. | ||
| + | ** Still the [[Relying Party]] needs to take physical possession of the card which smart people are increasingly resisting. | ||
* In the digital world collecting the full credential exposes the user to signification loss of [[Privacy]]. | * 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. | * 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. | + | * 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 [[Smartphone]]s. In some cases the shc is stored in a health app rather than in the wallet. | + | * Other credentials, like the [[Smart Health Card]] (shc:) are completely independent of the wallet and are accepted by existing [[Smartphone]]s updates as of 2021-11-24. 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. | + | * 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. |
| + | * There are already examples of attackers tying unrelated attributes to mobile Driver's Licenses<ref>Noah Farmer ''ServiceNSW’s Digital Drivers Licence Security appears to be Super Bad'' (2022-05-17) Dvuln https://blog.dvuln.com/blogs/servicensw-digital-superbad</ref>, so we must assume that this will become a favorite identity spoofing technique. | ||
==Solutions== | ==Solutions== | ||
| Line 36: | Line 43: | ||
* 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]]. | * 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 App]]s. 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. | * 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 App]]s. 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. | + | * 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=== | ===Consent=== | ||
| Line 45: | Line 52: | ||
# 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. | # 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. | * 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. | ||
| + | |||
| + | ===REAL ID=== | ||
| + | The REAL ID is a program of the US DHS to enable certificates, like Driver's Licenses, to be accepted for access to travel modes, like airplanes, at TSA check points. | ||
| + | * The REAL ID is issued as a [[Credential Aggregation]] indicator. These the REAL ID process can be viewed as a prototype of a [[Policy-Based Access Control]] method. | ||
| + | * The following is an example of the aggregation template use by the State of Washington. | ||
| + | [[File:WaStatRealIdDocsjpeg.jpeg]] | ||
==References== | ==References== | ||
Revision as of 20:47, 25 May 2022
Contents
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.
- Driver's license - to provide a biometric image for verification.
- Smart Health Card - to prove vaccination or current testing.
- Gym membership card - typically will include an expiration date. This card is entirely local, and is optional to this use case.
- 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.
- Before the user is asked to consent to the transaction, they will see the full cost in money and in lost privacy to complete any transaction.
- 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
- Browsers only understand a small set of "login credentials", primarily user-name and password.
- 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.
- This is changing now that scanners can capture a driver's license card and turn it into a digital representation.
- Still the Relying Party needs to take physical possession of the card which smart people are increasingly resisting.
- 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.
- There are already examples of attackers tying unrelated attributes to mobile Driver's Licenses[1], so we must assume that this will become a favorite identity spoofing technique.
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.
- The user can see the purpose of use display on a consent screen.
- There maybe a list of data elements displayed to the user, but this in not a good User Experience.
- 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.
- 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.
REAL ID
The REAL ID is a program of the US DHS to enable certificates, like Driver's Licenses, to be accepted for access to travel modes, like airplanes, at TSA check points.
- The REAL ID is issued as a Credential Aggregation indicator. These the REAL ID process can be viewed as a prototype of a Policy-Based Access Control method.
- The following is an example of the aggregation template use by the State of Washington.
References
- ↑ Noah Farmer ServiceNSW’s Digital Drivers Licence Security appears to be Super Bad (2022-05-17) Dvuln https://blog.dvuln.com/blogs/servicensw-digital-superbad
