What should a request to the wallet look like to achieve the purpose of the Verifier <https://tcwiki.azurewebsites.net/index.php?title=Verifier> and the privacy of the Subject <https://tcwiki.azurewebsites.net/index.php?title=Subject>. 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 <https://tcwiki.azurewebsites.net/index.php?title=Verifier> in any jurisdiction can make a request that all digital Wallets <https://tcwiki.azurewebsites.net/index.php?title=Wallet> 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 <https://tcwiki.azurewebsites.net/index.php?title=Ecosystem> are important to the person that selects which wallet to use. Problems 1. Users will not select Wallets <https://tcwiki.azurewebsites.net/index.php?title=Wallet> 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 from the Verifier <https://tcwiki.azurewebsites.net/index.php?title=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. 3. Many states in the US are issuing Mobile Driver's License <https://tcwiki.azurewebsites.net/index.php?title=Mobile_Driver%27s_License> wallets that can only hold their own State Issued Identifiers <https://tcwiki.azurewebsites.net/index.php?title=State_Issued_Identifier>. Thus using that Wallet <https://tcwiki.azurewebsites.net/index.php?title=Wallet> for other purposes of the Verifier <https://tcwiki.azurewebsites.net/index.php?title=Verifier> will force the user to select different wallets to gain access the the desired resource. A solution that many user will avoid. 4. 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. 5. Use Cases 1. A wallet that holds a California Mobile Driver's License <https://tcwiki.azurewebsites.net/index.php?title=Mobile_Driver%27s_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 <https://tcwiki.azurewebsites.net/index.php?title=Loyalty_ID> in order to take advantage of selective discounts available to loyal customers. 3. A sovereign state needs State Mandated Identification <https://tcwiki.azurewebsites.net/index.php?title=State_Mandated_Identification> in order to have a consistent Identifier <https://tcwiki.azurewebsites.net/index.php?title=Identifier> for any of the several hundred licenses and other uses. Solutions This page describes two ways to handle requests from wallets that need to server 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 purposew 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.