Wallet Requests

From MgmtWiki
Jump to: navigation, search

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 this proposal has deliberately been formatted as an explainer and not in any existing group's format as it is not clear which standards group is best suited to address the issue. The need for an explainer will exist even after a standard is created.

The primary deliverable is a message that can be created by any verifier independent of media used to transmit the query to the user's device or the format of credentials in the user's possession. The primary objective is to provide the holder of the device with a single screen information display that can be acted on by the user without referencing any other source.

As used here a wallet is any app on a holder's portable device that can protect a subject's private data and perform secure creation of holder's intent to be returned to the Verifier.

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. The web deployments need to handle large numbers of requests, potentially with different end-points. Strong context session cookies need good protection, possibly with encryption.

Use Cases

  1. 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.
  2. 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.
  3. 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.

  1. 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.
  2. 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 include the purpose.

Changes needed from the Device or Browser

There is currently a proposal to address Digital Identifiers in the W3C WICG. This particular proposal is focused on getting an app in the browser to select the right wallet. What is still missing is a means to instantiate this "metawallet" that could expose any choice to the user. The best user experience is to just select the wallet and let the wallet ask the user to express their intent. The one corner case is where the user has two credentials which address the query from the Verifier. Perhaps user could be given the ability to configure this "metawallet" to make the choice for them.

Contents of Query

These are proposed data for the query from the Verifier to the wallet.

The security for this message has yet to be formalized. It could be be the inclusion of federation Metadata or a cert from a trust registry or as part of a signing key.

Name Req Status Examples Details
Name of Verifier Required Joe's bar and Grill This is the dba name that the user should recognize
Data Processor Optional Stripe The legal name of the entity retaining user data
Contact If data retained Remove data URL or mailto: link
T&C Discouraged 25 pages of legalese terms for legal purpose
Authentication Option PoP IAL level of security
DateTime  ? Trackable May need for version or context
Reference Option Trackable nonce
Jurisdiction Option EU US-CA FHIR legal or trust zone or federation
Purpose and scope structures over 21

None of these ideas or names originated with the paper. Some of the sources include:

Purpose Structure

There are a large number of reasons why a Verifier might ask the user for verified claims of one sort or another. In some cases the purpose can easily determine the data field to supply. For example the requirement for a minimum age for COPPA is 13. In that case the purpose could be age over 12 which could be coded as "ao.12".

The purpose will be coded as rurl?code. Where rurl is a URL in reversed order and code is any ASCII string the registry desires. The rurl "0?" means the purpose code table described below. The optional data element (claim) list would be a json string similar to that proposed in other standards organizations. For example {eu.purpose?code) could be a table created by the eu and put at the location https://purpose.eu.

Purpose Registries

The purposes that the Verifier can select can be simple, in which case a list from this document could be used. In others they are part of a federation that determine which user attributes are needed to meet a given purpose. For example in medicine if the purpose is "create a prescription" attributes like allergies must be provided to avoid selection of a medicine that could cause harm.

The follow are a few of the common purposes that could be included in a standard:

code Name Examples Details
ao.xx age over ao.12 the minimum age to avoid regulation like COPPA rules

References

Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Wallet_Requests&oldid=20195"