Re: VOTE: Revised Identity Web Payments Workshop Use Cases

General Comments:


   - Refer to "payers" and "payees" rather than "customers" and "merchants"
   unless the use case is specifically limited to these actors.
   - Be specific when talking about identities, or identity attributes
   (claims), whether the use case refers to the payer's or the payee's
   identity or both.
   - My suggestion would be to focus the first iteration on payment
   processing without a need to exchange/verify the payer identity and add
   this in iteration 2.
   In terms of discussion within the IG, I think both are appropriate.


I made some suggested edits to the use cases which I have put in quotes.

Use Case: Store basic identity credentials and payment provider
information "of payers" on the Web in a way that is easy to share with
"payees" given authorization by the payer, and that is
easy to synchronize between devices.
Notes: This includes the ability for the identity owner "(payer)" to manage
the
identity information. It does not include the ability for the identity
owner to automatically sell their identity information.
+0: Not required for first iteration. It is not ESSENTIAL for the payer to
exchange identity credentials to complete a basic transaction. Think this
should be the focus of 2nd iteration.

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 fulfilment of a transaction.
+0: Not required for first iteration. It is not ESSENTIAL for the payer to
exchange identity credentials to complete a basic transaction. Think this
should be the focus of 2nd iteration.

Use Case: Using metadata that is the result of a transaction, discover
attributes associated with the identity of participants in the transaction.
+0: Not sure that I understand the need for this use case.


Use Case: Digitally verifiable credentials such that a "payee" and
"payee’s" payment processor in a transaction can prove that they have done
due
diligence in verifying the customer's identity (KYC).
+0: Not required for first iteration. It is not ESSENTIAL for the payer to
exchange identity credentials to complete a basic transaction. Think this
should be the focus of 2nd iteration.

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).
+1

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.
+1: Assuming we are referring to sharing digital credentials of the payee
for first iteration and extend this to the payer for later iterations.


Use Case: Transact with a merchant without revealing any identifying
information. Identifying information is available to the payment processor.
+1

Use Case: Enable anonymous transactions such that the identity of the
""payer" is not discoverable by "payees" or the "payees’" payment
processors.
+1


Use Case: "Payer" wants to send "payee" some money and asks "payee" for a
short,
memorable payment identifier. "Payee" sends the payment identifier to
"payer"
via an SMS message. "Payer" makes a payment using the short payment
identifier; the payment processor translates the short payment
identifier into a destination financial account for the "payee".
+1

Use Case: A "payer" pays a "payee" 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 "payee. i.e. The payee’s identity can be verified
by the payer."
+1


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.



On 16 July 2014 03:29, Manu Sporny <msporny@digitalbazaar.com> wrote:

> 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/
>
>