- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Mon, 25 Aug 2014 10:09:58 +0200
- To: Manu Sporny <msporny@digitalbazaar.com>, W3C Credentials Community Group <public-credentials@w3.org>
> Use Case: Store basic credentials and payment provider information on > the Web in a way that is easy to share with various payees/merchants > given authorization by the owner (payee) of the credential, and that is > easy to synchronize between devices. I don't fully understand this. Either you publish information on the web for access by other parties OR you keep information in [preferably synchronized] devices and only provide information *through* the devices. Which one is it? Anders On 2014-08-24 22:08, Manu Sporny wrote: > Hi all, > > W3C Community Groups are supposed to get a wiki, but ours isn't showing > up yet. I was going to transfer over the identity/credentials use cases > that we have in the Web Payments CG to this CG, but can't yet. As a > temporary alternative, they're listed below. > > For those that may not have been tracking the Web Payments CG work, > these use cases came out of a workshop[1] that W3C put together on > payments (held in Paris, March 2014). They've been refined over the last > couple of months to meet the needs of the payments work. Clearly, we're > going to have more use cases added in this group. These are just a > starting point. We're also going to have to modify the language a bit to > make them more generic. For example, we will probably want to replace > the 'payer', 'payee', 'merchant' language to something more akin to > 'sender', 'receiver', etc. > > Web Payments Identity/Credential Use Cases > ------------------------------------------ > > === Glossary === > > There are a number of roles assigned to entities in each use case below: > > payer - the entity sending value in a transaction. > payee - the entity receiving value in a transaction. > buyer - an entity that is performing a purchase. > merchant - an entity that is offering a product or service for sale. > payment processor - an entity that is responsible for transferring value > between entities and generating verifiable digital receipts. > > There is terminology that is common to all use cases: > > credentials - attributes such as name, shipping address, government > issued ID, or proof-of-age associated with a particular entity that may > be exchanged before, during, or after a transaction. > > === Version 1.0 Use Cases === > > Use Case: Store basic credentials and payment provider information on > the Web in a way that is easy to share with various payees/merchants > given authorization by the owner (payee) of the credential, and that is > easy to synchronize between devices. > > Use Case: Steve (buyer) visits a website (merchant) and authorizes the > transmission of one or more credentials (such as proof-of-age, shipping > address, etc.) previously stored with a credential storage service to > the website to enable access or fulfillment of a transaction. > > Use Case: Given the permission of the participants (payer, payee, buyer, > merchant) of a transaction, the transaction metadata can be used to > discover additional attributes associated with those participants. For > example, given the buyer's authorization, a merchant could query the > identity URL for the buyer contained in a digital receipt and obtain an > up-to-date email address. > > Use Case: Digitally verifiable credentials such that a merchant and > payment processor involved in a transaction can prove that they have > performed the proper due diligence when identifying the payer and the > payee (Know Your Customer). > > Use Case: A payer executes a transaction without revealing secrets that > are not vital to the transaction (i.e. identity, passwords, PINs or > other information that the merchant does not need to know). > > Use Case: Use an existing, widely deployed identity provider mechanism > (i.e. OpenID Connect) to integrate with the digital credentials sharing > and payments initiation process. > > Use Case: Transact with a merchant without revealing any identifying > information. Identifying information is available to the payment processor. > > Use Case: Gunther (payer) enters a short-identifier that he believes > identifies The Widget Store (merchant) into a UI. The UI displays a > certificate of authenticity that indicates the short identifier is in > fact for The Widget Store. Gunther uses the short identifier to make a > payment to the store. > > Use Case: Jack (payer) wants to send Jill (payee) some money and asks > Jill for a short, memorable payment identifier. Jill sends the payment > identifier to Jack via an SMS message. Jack makes a payment using the > short payment identifier; the payment processor translates the short > payment identifier into a destination financial account for Jill. > > === Out of Scope or Future Use Cases === > > Use Case: Enable truly anonymous transactions such that the identity of > the payee is not discoverable by payees, merchants, or payment processors. > > Design Criteria: A primary entity (buyer, merchant, etc.) with access to > a credential service sets a second entity (buyer, merchant, etc.) as a > backup for accessing their credentials should they inadvertently lose > their ability to access the credential service (accidental loss of > password or 2-factor authentication device). > > -- manu > > [1] http://www.w3.org/2013/10/payments/minutes/ >
Received on Monday, 25 August 2014 08:10:52 UTC