Re: Proof of Concept: Identity Credentials Login

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

This is/was my intention with
Unfortunately this has been a lone effort and I do have a day-job :)

I was hoping to combine my work on OpenPayee with what you are all doing in
the CG and add it to the efforts you have already made.
Having developed my ideas independently I have the benefit of an entirely
fresh perspective on your work so far so excuse me if it seems like I am
attacking everything you say :)
It's obviously not the case, I simply have a lot of content and ideas to
share and debate.

I arrived at the idea for OpenPayee from my analysis of the current state
of payments networks and my conclusion that the idea of handing any form of
credential to a payee that allows them to debit money from your account is
just wrong and outdated. i.e. Card payments are bad in principal. The
system is expensive, loaded with risk and only really serves to protect the
oligopoly of the existing big networks.
As such, OpenPayee started as an intention to simply promote the idea of
"push payments".
I.e. payments should be controlled by the payer and pushed (in the form of
a credit) from the payer's account to the payee.

Obviously the world is not ready to up and abandon card payments entirely
however it's worth noting that in many countries real-time ACH payments or
EFTs (the terminology differs in different territories) is already a
(The UK, Singapore and one or more of the Scandanavian countries that I am
aware of, the elephant in the room is the US where inter-bank payments that
don't run on the card networks are still done with paper checks!)

For this reason, the process needs to fall back elegantly to support card
payments and I believe this is easy to do without entirely compromising the
integrity of the push payments architecture.
The approach would be for the payment to still be initiated by the payer
through their agent/bank/wallet provider but that provider would simply
pass the payer's card details onto the payee's agent/payment

It is that the payer chooses who to trust with their payment details.
They select a provider that they believe is secure but also has existing
trust relationships with other key stakeholders in the payments ecosystem.
i.e. If I live in South Africa I probabaly want a provider that can, at a
minimum, make direct payments into any South African bank account.

The choice will be a balance between convenience (many supported payments
channels) and security but what is key is that the choice is with the payer.

OpenPayee is based on two fundamental goals:
1. Use push payments and put the payer in control.
2. Standardise the way the payee's details are shared with the payer so
that the payer can make a payment through a channel supported by both the
payer and payee.

I would suggest you look at what I have put up on thus far
(it's rough and could use some critique) and give me your feedback.
Particularly, the use cases may be illustrative of the idea.

*"The identity problem is separate from payments for the most part."*

This is fundamental to my approach.

I realise you want to come up with a solution that supports the large group
of use cases on the wiki.
This is the ideal but likely to be very difficult to achieve without
defining the whole stack from end-to-end as I think you have already
Unless... you break the problem into smaller pieces and solve these

Lets break the end-to-end payments process into stages and try to
standardize these individually?
That way we can avoid needing to standardise for edge case scenarios with a
large and complex standard.

Off the top of my head we should start by defining a standard way for the
payee to advertise the channels that they will accept payments on (either
with a specific transaction context or in a general context).
That's the purpose of OpenPayee.

The next piece that needs to be standardised is the negotiation of terms.
i.e. Now that I know you accept payments via a card gateway that can
process VISA cards, via bitcoin, via UK bank transfers and via SWIFT what
are the terms of using each channel.
If I want to pay by card via your card gateway what currencies do you
support and what is the conversion rate from the base currency you quoted
my original transaction in?
If I pay via UK bank transfer what is the maximum and minimum amount you'll
accept on that channel and how long will it take for the payment to clear
so I can can get a digitally signed receipt?
I think you get the gist?

One could then standardise an additional information exchange process
whereby the payer must supply the payee with information (perhaps depending
on the channel used?):
i.e. Now I know that you accept payments via X channels what additional
information do you need from me to complete the payment (age, delivery
address etc)

The advantage of this is that each channel is then free to define how the
payment is actually processed.
This may not even happen over the public Internet if the two agents have an
existing relationship on a proprietary network such as two banks that are
members of SWIFT.

To me, that is sufficient to handle almost all payment scenarios and is
loosely coupled enough so that it can be overlaid on existing channels and
leverage existing standards that provide the other services required, such
as identity exchange. By the way, the standard for exchanging payee info
should define how this can be done on top of as many existing identity
exchange protocols as possible to ensure it's easy to adopt. Right now I am
using Open ID Connect as a starting point.

I am focusing, initially, on the payee info exchange with OpenPayee but
that would need to be followed quickly with the terms negotiation piece.
I haven't dug into it in detail but I think there is a great deal of stuff
in the specs that could help here.

On 23 June 2014 17:52, Manu Sporny <> wrote:

> 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:
> -- manu
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: The Marathonic Dawn of Web Payments

Received on Monday, 23 June 2014 19:21:28 UTC