Preliminary Credentials Use Cases

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/

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/

Received on Sunday, 24 August 2014 20:08:58 UTC