Re: Proof of Concept: Identity Credentials Login

On 06/17/2014 09:24 AM, Adrian Hope-Bailie wrote:
> Why not simply provide a specification for a PaymentInfo endpoint
> and dictate that this endpoint returns JSON-RD? i.e. Once I have your
>  Open ID Connect identifer I can discover the various channels you 
> support to accept payment, pick the one I want to use and process the
> payment.

Can you show us what an example of this would look like? Just a simple
blog post or outline of the data going back and forth would be helpful.

> I'm afraid I still see no value in inventing another new federated 
> identity protocol if you are doing it simply to facilitate payments.
>  The ones we have offer enough to solve the payments initiation 
> problem.

Just to be clear, we're not doing it "simply to facilitate payments".

The identity problem is separate from payments for the most part. There
is an area of overlap, and that's when additional details are required
to do a payment, most notably when a customer needs to:

1. Transmit which payment processor should be used for a payment.
2. Transmit any high-stakes credential information (such as the
   transmission of proof of age, or license to purchase a controlled
   substance (chemicals, fertilizer, alcohol, etc.), KYC information,
   etc.)
3. Transmit any low-stakes information (such as shipping address).
4. Do all 3 above in a loosely coupled way that allows market
   verticals to extend the information exchanged w/o having to
   go through the W3C/IETF standardization process.

Basically, when the customer needs to provide any information in an easy
to use way to the merchant. In many cases, the customer should only have
to transmit the payment processor to use for most digital goods.
However, there are many cases where extra information is required to be
transmitted as a part of the transaction. A set of technologies that
intend to be a world standard can't ignore those set of use cases.

Ideally, we'd be able to extend OpenID Connect to address the use cases
above, but our initial attempt at doing so led to a technology stack
that was far too complicated while still not addressing many of the use
cases that we need to address. Again, we'd love to see an example of
OpenID Connect meeting all of the use cases we need to address:

https://www.w3.org/community/webpayments/wiki/CategorizedWebPaymentsUseCases#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 Monday, 23 June 2014 15:52:31 UTC