Difference between revisions of "Wallet User Experience"
From MgmtWiki
(→Goals) |
(→Provide Creds to a Website) |
||
| (32 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title== | ==Full Title== | ||
| − | The [[User Experience]] of get a user to | + | The [[User Experience]] of get a user to select the appropriate piece of mobile code as a user agent for a particular [[Relying Party]] on the user's identifier. |
==Context== | ==Context== | ||
| − | * The context is giving | + | * The context is giving users control over the identifiers that they use |
* The primary context is the user's mobile smartphone. A secondary context is the user on a laptop computer connected to the internet. | * The primary context is the user's mobile smartphone. A secondary context is the user on a laptop computer connected to the internet. | ||
* The operating assumption is that the user has contacted the RP with a browser and that the identity security code is a separate native or web application that will be referred to below as the '''[[Wallet]]'''. | * The operating assumption is that the user has contacted the RP with a browser and that the identity security code is a separate native or web application that will be referred to below as the '''[[Wallet]]'''. | ||
* For convenience of this list a wallet can include references other wallets. | * For convenience of this list a wallet can include references other wallets. | ||
| + | * Nothing in these requirements should be construed to require that all of the wallet code is resident on a device in the user's physical possession. | ||
| + | * 2021-09-20 Bloomberg reported = Robinhood Markets is testing a new crypto wallet and cryptocurrency transfer feature for its app, a long-awaited move that will make it easier for customers to send and receive digital currencies like Bitcoin. With crypto wallets, consumers can use virtual currencies without having to convert them to dollars. They also provide a single place for customers to store all of their virtual currencies, protected by a private key. Robinhood shares jumped as much as 2.1% on the news. —David E. Rovella | ||
==Goals== | ==Goals== | ||
| − | The following are the required success criteria for both the user and the RP in establishing and maintaining an enduring relationship. Wallets supporting ephemeral | + | The following are the required '''success criteria''' for both the user and the RP in establishing and maintaining an enduring relationship. Wallets supporting ephemeral relationships are possible and may be addressed in a subsequent list as needed. The high level goal is to minimize the cognitive load on the user. The '''success metric''' of this effort is (1) the percentage of users that successfully create and maintain their own usefull identifiers under their own control and (2) the number of RPs that accept SIOP identifiers. |
| − | # A user of common | + | # RPs will have the means to test if they meet the criteria for giving users control of their own identifiers. |
| − | install one or more wallets and | + | # RPs will provide a well-known endpoint displaying their acceptance criteria for wallets. (the need for this is TBD) |
| + | # SIOP will provide a well-known endpoint API for determining their identifier functionality that contains no user personal information and minimal correlation information. | ||
| + | # A user of common ability will be able to install one or more wallets and create zero or more identifiers on each wallet. | ||
# The user can add or remove wallets at any time. | # The user can add or remove wallets at any time. | ||
# The RP can display for the user's selection on the user's browser a small number of choices that are created entirely by browser code and information from the DOM provided by the user's browser. | # The RP can display for the user's selection on the user's browser a small number of choices that are created entirely by browser code and information from the DOM provided by the user's browser. | ||
# Upon selection of one of those options, the user will be able to access a wallet previously provisioned with an identifier or a wallet with a list of other wallets. | # Upon selection of one of those options, the user will be able to access a wallet previously provisioned with an identifier or a wallet with a list of other wallets. | ||
# The user will have full and effective control of the selection of an identifier that meets the RP criteria. | # The user will have full and effective control of the selection of an identifier that meets the RP criteria. | ||
| − | # If such a identifier does not exist, the user | + | ## If such a identifier does not exist, the user will get simple and effective instructions on creating such an identifier that does meet the criteria. |
| + | # Working together the user, the device, the browser, the wallet and the RP will establish means for the user to easily restore connectivity to the RP using the user selected identifier. | ||
| + | |||
| + | ==Problems== | ||
| + | David Chadwick reported on the EIC Thursday (2021-09-19) afternoon session Decentralized Identity for the Enterprise from Esatus. Attendees were able to download the '''Esatus Wallet''', and then install a VC and use it to access a Wordpress web site. Esatus uses the Sovrin permissioned blockchain with public read access to store issuer DIDs, schemas and VC types. The demo system allows anyone to register as an issuer and does not have a proper functioning trust regime (but this can be added). There was a demo of SOWL, a web based system for creating new VC schemas and VC types and storing these on the Sovrin test blockchain. He then created a new Applications in SOWL that will use VCs for access, through defining Entitlements and Rules. We were shown how you can build a Wordpress web site using the SAML protocol for login, but instead of un/pws, VCs are sent from the user's wallet. SOWL supports OIDC, SAML, LDAP and SCIM. One negative feature is that the wallet has to be configured with the correct Sovrin blockchain to talk to, as there are many of them in the wild. If the wrong one is chosen the demo will not work. '''This shows a weakness of the current blockchain based system'''. Why not publish the VC meta data on the web instead of in a blockchain, and then wallets would not need to choose between blockchains. A member of the audience said the current system would not pass the Granny test. The performance was also dire. | ||
| + | |||
| + | ==Solutions== | ||
| + | # A specification meeting these criteria will be published. | ||
| + | # That specification may well require new means of support from the device and browser provisioned on that device. | ||
| + | ===FHIR Smart App Launch=== | ||
| + | * [http://www.hl7.org/fhir/smart-app-launch/ Smart App Launch] web site | ||
| + | ===Provide Creds to a Website=== | ||
| + | in response to a request for an actual message flow - we consider openID Connect as a paradigm, when user is at a RP website, the site shows one or more buttons - like google - the user clicks, lots of magic happens and the OpenID Provider (OP) sends an id_token bounce off user to RP which retains browser session context. The SIOP is like that but the OP is user and under user control. — SO here we go: | ||
| + | * User is at the RP web site - sees a button labeled “personal” or some such - user click button - now we need some non-existant magic - the browser understand the protocol - say sellfissued:// or did: and finds a wallet and sends the request to the wallet (this is ta problem we need help with) | ||
| + | * The SIOP wallet finds the creds it needs to respond to the request - we understand that part well - no hard issues, but now the hard part - the wallet sends the id_token back to the browser session that sent the request | ||
| + | *I have been able to create a wallet that will do all of that using localhost:// - but that can be hijacked - a protocol can be registered by the app - but that can be redirected by any other app loaded on the device. - so we are stuck - several choices are: protocol handler or cred manager or password manager extension - nothing has worked out yet. | ||
| + | *now an apple wallet has super powers by virtual of being owned by the platform and can deal with some of these issues and has some sort of solution for the mobile Driver’s license, but even apple puts the health cred in the health app, not the wallet, so we still have a problem that i call credential aggregation. https://tcwiki.azurewebsites.net/index.php?title=Credential_Aggregation | ||
| + | * here is a demo of an employer getting creds, like a green card, from an applicants wallet. Just change the wording to a covid cred being acquired by a web app and it would apply directly to COVID Cred: https://www.youtube.com/watch?v=Tq4hw7X5SW0&t=20s | ||
==References== | ==References== | ||
| + | * See wik page on [[Patient Experience]] | ||
| + | * See wik page on [[Self-issued_OpenID_Picker#User_Experience| Self-issued ID chooser UX]] | ||
| + | |||
| + | |||
| + | [[Category: User Experience]] | ||
Revision as of 12:45, 20 December 2021
Contents
Full Title
The User Experience of get a user to select the appropriate piece of mobile code as a user agent for a particular Relying Party on the user's identifier.
Context
- The context is giving users control over the identifiers that they use
- The primary context is the user's mobile smartphone. A secondary context is the user on a laptop computer connected to the internet.
- The operating assumption is that the user has contacted the RP with a browser and that the identity security code is a separate native or web application that will be referred to below as the Wallet.
- For convenience of this list a wallet can include references other wallets.
- Nothing in these requirements should be construed to require that all of the wallet code is resident on a device in the user's physical possession.
- 2021-09-20 Bloomberg reported = Robinhood Markets is testing a new crypto wallet and cryptocurrency transfer feature for its app, a long-awaited move that will make it easier for customers to send and receive digital currencies like Bitcoin. With crypto wallets, consumers can use virtual currencies without having to convert them to dollars. They also provide a single place for customers to store all of their virtual currencies, protected by a private key. Robinhood shares jumped as much as 2.1% on the news. —David E. Rovella
Goals
The following are the required success criteria for both the user and the RP in establishing and maintaining an enduring relationship. Wallets supporting ephemeral relationships are possible and may be addressed in a subsequent list as needed. The high level goal is to minimize the cognitive load on the user. The success metric of this effort is (1) the percentage of users that successfully create and maintain their own usefull identifiers under their own control and (2) the number of RPs that accept SIOP identifiers.
- RPs will have the means to test if they meet the criteria for giving users control of their own identifiers.
- RPs will provide a well-known endpoint displaying their acceptance criteria for wallets. (the need for this is TBD)
- SIOP will provide a well-known endpoint API for determining their identifier functionality that contains no user personal information and minimal correlation information.
- A user of common ability will be able to install one or more wallets and create zero or more identifiers on each wallet.
- The user can add or remove wallets at any time.
- The RP can display for the user's selection on the user's browser a small number of choices that are created entirely by browser code and information from the DOM provided by the user's browser.
- Upon selection of one of those options, the user will be able to access a wallet previously provisioned with an identifier or a wallet with a list of other wallets.
- The user will have full and effective control of the selection of an identifier that meets the RP criteria.
- If such a identifier does not exist, the user will get simple and effective instructions on creating such an identifier that does meet the criteria.
- Working together the user, the device, the browser, the wallet and the RP will establish means for the user to easily restore connectivity to the RP using the user selected identifier.
Problems
David Chadwick reported on the EIC Thursday (2021-09-19) afternoon session Decentralized Identity for the Enterprise from Esatus. Attendees were able to download the Esatus Wallet, and then install a VC and use it to access a Wordpress web site. Esatus uses the Sovrin permissioned blockchain with public read access to store issuer DIDs, schemas and VC types. The demo system allows anyone to register as an issuer and does not have a proper functioning trust regime (but this can be added). There was a demo of SOWL, a web based system for creating new VC schemas and VC types and storing these on the Sovrin test blockchain. He then created a new Applications in SOWL that will use VCs for access, through defining Entitlements and Rules. We were shown how you can build a Wordpress web site using the SAML protocol for login, but instead of un/pws, VCs are sent from the user's wallet. SOWL supports OIDC, SAML, LDAP and SCIM. One negative feature is that the wallet has to be configured with the correct Sovrin blockchain to talk to, as there are many of them in the wild. If the wrong one is chosen the demo will not work. This shows a weakness of the current blockchain based system. Why not publish the VC meta data on the web instead of in a blockchain, and then wallets would not need to choose between blockchains. A member of the audience said the current system would not pass the Granny test. The performance was also dire.
Solutions
- A specification meeting these criteria will be published.
- That specification may well require new means of support from the device and browser provisioned on that device.
FHIR Smart App Launch
- Smart App Launch web site
Provide Creds to a Website
in response to a request for an actual message flow - we consider openID Connect as a paradigm, when user is at a RP website, the site shows one or more buttons - like google - the user clicks, lots of magic happens and the OpenID Provider (OP) sends an id_token bounce off user to RP which retains browser session context. The SIOP is like that but the OP is user and under user control. — SO here we go:
- User is at the RP web site - sees a button labeled “personal” or some such - user click button - now we need some non-existant magic - the browser understand the protocol - say sellfissued:// or did: and finds a wallet and sends the request to the wallet (this is ta problem we need help with)
- The SIOP wallet finds the creds it needs to respond to the request - we understand that part well - no hard issues, but now the hard part - the wallet sends the id_token back to the browser session that sent the request
- I have been able to create a wallet that will do all of that using localhost:// - but that can be hijacked - a protocol can be registered by the app - but that can be redirected by any other app loaded on the device. - so we are stuck - several choices are: protocol handler or cred manager or password manager extension - nothing has worked out yet.
- now an apple wallet has super powers by virtual of being owned by the platform and can deal with some of these issues and has some sort of solution for the mobile Driver’s license, but even apple puts the health cred in the health app, not the wallet, so we still have a problem that i call credential aggregation. https://tcwiki.azurewebsites.net/index.php?title=Credential_Aggregation
- here is a demo of an employer getting creds, like a green card, from an applicants wallet. Just change the wording to a covid cred being acquired by a web app and it would apply directly to COVID Cred: https://www.youtube.com/watch?v=Tq4hw7X5SW0&t=20s
References
- See wik page on Patient Experience
- See wik page on Self-issued ID chooser UX
