Wallet Requests
Contents
Full Title or Meme
What should a request to the wallet look like to achieve the purpose of the Verifier and the privacy of the Subject.
Also known as a Generic Wallet Query Language.
Context
Today it is possible to use a driver's license issued in California to enter a bar in Thailand. The question arises about how a request from a Verifier in any jurisdiction can make a request that all digital Wallets could meaningfully handle to allow existing purposes. The use cases listed below include cases were interoperability of wallets with disparate requirements in diverse identity Ecosystems are important to the person that selects which wallet to use.
Problems
- Users will not select Wallets that cannot get them access to resources that they depend upon. This page focuses on the way to create a request from a verifier such that it can be handled by the wallets that the user is likely to have in their possession.
- When the request comes to the user's device, the means for routing that request to an appropriate wallet will be a challenge that is not further addressed in the paper. Any solution will require some support from the device's OS.
- When the request from the Verifier includes multiple purposes it is not likely that the user can be expected to switch from one wallet to another. Nor is it clear that the user ID will be the same in two different wallets.
- Many states in the US are issuing Mobile Driver's License wallets that can only hold their own State Issued Identifiers. Thus using that Wallet for other purposes of the Verifier will force the user to select different wallets to gain access the the desired resource. A solution that many users will avoid.
- Technologies, including cryptographic methods, are changing rapidly. If these changes are not accommodated by users with existing mobile devices, the user will not be able to use them until they upgrade their device.
Use Cases
- A wallet that holds a California Mobile Driver's License can be used to enter a bar in a different country with different legal requirements.
- A shopper at a grocery store wants to give the store their Loyalty ID in order to take advantage of selective discounts available to loyal customers as they pay for their goods with a payment card also in their wallet.
- A sovereign state needs State Mandated Identification in order to have a consistent Identifier for any of the several hundred licenses and other uses of that State.
Solutions
This page describes two ways to handle requests from wallets that need to serve multiple purposes in a single request to the wallet. While it is possible that a wallet could handle both types of request, interoperability would be improved if only one of these methods were selected.
- Allow the request to contain both optional and required claims and list multiple purpose as advisory and not directly connected to the list of claims required.
- Allow the request to contain multiple purposes and let the holder make a choice on which purpose to consent. In many cases the purpose should be sufficient to determine the claims provided by the wallet. This has also been called the collection of transaction sets, where each transaction was related to one purpose. It is also possible for each purpose to list the specific data elements (claims) that are needed, but the long term goal would be for the purposes to be sufficient for that purpose. Each purpose could be required or optional, but any data element listed in the purpose would be required.
Note that the word scope in OAuth or OIDC could contain the purpose.
Contents of Query
These are proposed data for the query to the wallet.
| Name | Req Status | Example | Details |
| Name of Verifier | Required | Joe's bar and Grill | This is the dba name that the user should recognize |
| Data Controler | Optional | Stripe | The legal name of the entity retaining user data |
| Contact | If data retained | Commerce | Url or mailto link |
| T&C | Discouraged | . | terms for legal purpose |
| Security | Option | PoP | level of security |
| DateTime | ? | Trackable | May need for context |
| Reference | Option | Trackable | nonce |
| Jurisdiction | Option | EU US-CA | legal or trust zone or federation |
| Purpose and scope | structures | over 21 |
