Re: Preliminary Credentials 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.

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