Re: VOTE: Revised Identity Web Payments Workshop Use Cases

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

+1 to all

Note: In crypto currency payments, generally a payment is from one public
key to another (ie URI to URI), and may not include either a customer or
merchant.



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