Difference between revisions of "Presentation from a Wallet"
From MgmtWiki
(→User Journey) |
m (→References) |
||
| (8 intermediate revisions by the same user not shown) | |||
| Line 13: | Line 13: | ||
# The computing device, whether mobile phone or laptop, will need to provide secure storage and collect user inputs for transmission in the bundle to the RP. | # The computing device, whether mobile phone or laptop, will need to provide secure storage and collect user inputs for transmission in the bundle to the RP. | ||
# The [[Relying Party]] aka the [[Verifier]] of the bundle sent by the [[Wallet]]. | # The [[Relying Party]] aka the [[Verifier]] of the bundle sent by the [[Wallet]]. | ||
| + | |||
| + | ===Requirements=== | ||
| + | |||
| + | There were subsections to PEMC with my comments | ||
| + | {|border="1" padding="2" width="999px" | ||
| + | | Original || comments | ||
| + | |- | ||
| + | | In order to foster adoption, it is essential that we create a trusted experience for all participants. During presentment, this consists of elevating awareness around what data is being requested, by whom, whether the relying party intends on storing this data and if so, what are they planning on doing with the stored data. The Wallet provider should incorporate these elements into their presentment UI in order to create a transparent presentment experience.|| It all must fit on one screen with the OK button at the bottom - if it takes more than one screen the button would not be visible until the user scrolled to the bottom | ||
| + | |- | ||
| + | |1) All data elements that are being requested by the relying party should be clearly outlined and visible ||. This places too much detail to the user in many cases. For those cases we need some way to abstract the data requirements into purposes | ||
| + | |- | ||
| + | |2) The mDL holder should be clearly aware of who is requesting the mDL information. This should be done via displaying the name and icon for the relying party in the presentment sheet in a way that is clear and legible. || The logo is required, but might be a default logo provided by the software vendor | ||
| + | |- | ||
| + | |3) The intent to retain variable per data element should be displayed clearly to the user for increased transparency. ||. Again we must be able to shorten the request into something the user can understand. | ||
| + | |- | ||
| + | |4) The intent to retain variable should be supported by an up to date identity data privacy policy. This identity specific data use policy should be accessible from within the mDL holder's Wallet. The data use policy should offer simple explanations outlining why the relying party plans on storing the data and for how long.|| This is desirable but we need some UX to test | ||
| + | |} | ||
==Problems== | ==Problems== | ||
| Line 48: | Line 65: | ||
==References== | ==References== | ||
| + | ===Other Material=== | ||
| + | * Generic information is available on the wiki page [[Presentation]]. | ||
[[Category: User Agent]] | [[Category: User Agent]] | ||
| + | [[Category: Use Case]] | ||
| + | [[Category: Attestation]] | ||
Latest revision as of 11:24, 25 October 2023
Contents
Full Title or Meme
This represents a bundle of claims and credentials in a Presentation from a Wallet.
Context
- This was generated as the high-level view of a Mobile Driver's License Presentation.
- Wallets are now (in 2021-07) being asked to accumulate a variety of user private information and credentials. Here-to-fore not common request to a wallet has been proposed.
- See the wiki page Direct Presentation for Microsoft's take on the same topic.
Actors
The issuer of the credential is not included in this list but is essential to the entire Ecosystem.
- The human user of a computing device with a means to securely store secrets.
- The application running as a User Agent on the computing device with access to a secure, hardware enabled wallet containing user credentials and other secrets.
- The computing device, whether mobile phone or laptop, will need to provide secure storage and collect user inputs for transmission in the bundle to the RP.
- The Relying Party aka the Verifier of the bundle sent by the Wallet.
Requirements
There were subsections to PEMC with my comments
| Original | comments |
| In order to foster adoption, it is essential that we create a trusted experience for all participants. During presentment, this consists of elevating awareness around what data is being requested, by whom, whether the relying party intends on storing this data and if so, what are they planning on doing with the stored data. The Wallet provider should incorporate these elements into their presentment UI in order to create a transparent presentment experience. | It all must fit on one screen with the OK button at the bottom - if it takes more than one screen the button would not be visible until the user scrolled to the bottom |
| 1) All data elements that are being requested by the relying party should be clearly outlined and visible | . This places too much detail to the user in many cases. For those cases we need some way to abstract the data requirements into purposes |
| 2) The mDL holder should be clearly aware of who is requesting the mDL information. This should be done via displaying the name and icon for the relying party in the presentment sheet in a way that is clear and legible. | The logo is required, but might be a default logo provided by the software vendor |
| 3) The intent to retain variable per data element should be displayed clearly to the user for increased transparency. | . Again we must be able to shorten the request into something the user can understand. |
| 4) The intent to retain variable should be supported by an up to date identity data privacy policy. This identity specific data use policy should be accessible from within the mDL holder's Wallet. The data use policy should offer simple explanations outlining why the relying party plans on storing the data and for how long. | This is desirable but we need some UX to test |
Problems
Standards and other guidance have been created for requesting private information from users. There is little coordination between these efforts. A partial list follows:
- W3C Verifiable Credentials
- OpenID Connect
- IETF GNAP
- Open ID SIOP
- ISO 18013-5 on the Mobile Driver's License
Solution
The following is both a collection and a proposal for a unified solutions to the problems.
Policy
- Policies are expressed as a purpose
Request
- Collection of needs sent to the wallet by the verifier.
- Each request is for a collection of data elements that will be called a purpose.
Response
Bundled set of credentials presentations and user information from the Wallet.
User Journey
- User is at a place where some form of ID is required.
- User taps wallet to verification device
- Verification Device sends a request to the user
- Uwe Wallet interprets the verifier request into a SINGLE SCREEN UX
- If there are optional requirements the user can disable them.
- The user clicks OK
- The presentation response returns to the verifier
- If the verifier is happy the user gains access
References
Other Material
- Generic information is available on the wiki page Presentation.
