VOTE: Revised Identity Web Payments Workshop Use Cases

Please +1/+0/-1 each identity use case below in order to show whether or
not you agree that we should try and attempt addressing the use case in
the first iteration of the Web Payments work. If you +0 or -1 the use
case, please specify why as well as changes that could be made that
would result in you +1'ing the use case.

----------------------------------------------------------------------

Use Case: Store basic identity credentials and payment provider
information on the Web in a way that is easy to share with various
merchants given authorization by the owner of the identity, and that is
easy to synchronize between devices.
Notes: This includes the ability for the identity owner to manage the
identity information. It does not include the ability for the identity
owner to automatically sell their identity information.

Use Case: A customer visits a website and authorizes the transmission of
one or more pieces of information (such as proof-of-age, shipping
address, etc.) previously stored with an identity provider to the
website to enable access or fulfillment of a transaction.

Use Case: Using metadata that is the result of a transaction, discover
attributes associated with the identity of participants in the transaction.

Use Case: Digitally verifiable credentials such that a merchant and
payment processor in a transaction can prove that they have done due
diligence in verifying the customer's identity (KYC).

Use Case: A customer 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: Enable anonymous transactions such that the identity of the
customer is not discoverable by merchants or payment processors.

Use Case: Jack wants to send Jill 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.

Use Case: A person pays a merchant using a short identifier. Prior to
sending the payment, some information associated with the short
identifier indicates to them that the short identifier is a verified
short identifier for the merchant.

Design Criteria: A person sets a second identity as a backup for
accessing their first identity, should they lose the ability to use the
first identity.

-- manu

-- 
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 Wednesday, 16 July 2014 01:29:49 UTC