Re: Proof of Concept: Identity Credentials Login

On 06/23/2014 03:20 PM, Adrian Hope-Bailie wrote:
> /"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 openpayee.org <http://openpayee.org> 
> Unfortunately this has been a lone effort and I do have a day-job :)

:) pesky day-jobs.

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

I read through most of the website last night and finished the rest of
it up this afternoon. The blog post was particularly helpful, so thanks
for that. From what I can tell, there is a huge amount of alignment
between what you're proposing and what we've created thus far. We agree
on the whole 'push payments' thing.

> 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 :)

No, don't worry about it. We can spot healthy debate when we see it. :)

I think you're jumping in /after/ we had already come to the conclusion
that 'push payments' were the way forward. We came to this conclusion
around 3-4 years ago, so you're probably not going to get much pushback
on that part of your idea. :)

> As such, OpenPayee started as an intention to simply promote the
> idea of "push payments".

That's where most of this group is right now as well. It's a good sign
that you were not familiar with the work we've been doing here, but
still came to more-or-less the same conclusion.

> (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!)

No, that's not true. The vast majority of non-card network inter-bank
payments in the US are ACH payments (which are electronic). ACH payments
also account for 61% of all monetary movement (by amount) in the US:

http://www.frbservices.org/files/communications/pdf/research/2013_payments_study_summary.pdf

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

So, the goals of OpenPayee and the work we're doing here are aligned at
this most fundamental level.

> /"The identity problem is separate from payments for the most 
> part."/
> 
> I realise you want to come up with a solution that supports the large
> group of use cases on the wiki.

No, that's not what we're doing here.

We have a set of use cases. We want to achieve as many of those use
cases as possible w/o over-complicating the solution. So, we will throw
out use cases if it results in a solution that's too complex.

In general, many of the active participants on this mailing list aren't
just working on "problems related to payments", we're working on
"problems related to information technology", of which payments is a subset.

JSON-LD is a good example. We created it because it was part of the
solution when it came to exchanging payment information (offers for
sale, digital receipts, etc.). When we started the work on it here, we
got push back of this sort: "We already have JSON, let's just use that,
no need to boil the oceans."

Hindsight is always 20/20, but if we had caved in on that problem area
those many years ago, we wouldn't have JSON-LD today. We view identity
in the same way, we're not trying to find a solution for identity that
works for payments. We're trying to find an identity solution that works
really well for the Web, and it just so happens to also work really well
for payments.

> Unless... you break the problem into smaller pieces and solve these 
> one-by-one.

I agree. Why do you think we're not doing that? Everything that we're
discussing here should be a spec that stands on its own. These specs can
be used to solve /other/ problems on the Web. Going down the list of
technologies we have so far that stand on their own:

JSON-LD
JSON-LD Normalization (for digital signatures)
HTTP Signatures
Secure Messaging
Identity Credentials

Each of those technologies can be used for a myriad of different things
other than Web Payments. We really only have three specs so far that are
specific to payments:

Web Payments (peer-to-peer payments)
Web Commerce (offers and digital receipts)
Web Commerce API (payment initiation and digital receipt delivery)

> Lets break the end-to-end payments process into stages and try to 
> standardize these individually?

+1, although that's already the approach we're using here. :)

> That way we can avoid needing to standardise for edge case scenarios
>  with a large and complex standard.

+1, we don't want 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 what this spec does:

https://web-payments.org/specs/source/web-commerce/

> The next piece that needs to be standardised is the negotiation of 
> terms.

The Web Commerce spec doesn't require negotiation. The "Offer" of sale
provides the terms that a merchant is willing to accept and the payer
either accepts them or doesn't.

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

I get the gist, but we've marked that sort of stuff as "version 2"
stuff. I don't know how much you know about the ForEx market but it's
complicated to say the least and is something that should probably not
be in the standard (that negotiation is between you and your payment
provider).

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

That's what the Identity Credentials spec does.


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

Agreed, but doing stuff like that typically kills standards. The more
options you have, the more fragmentation. Re-use is good, we just need
to make sure that the stuff being re-used isn't pulling in a ton of
cruft that the Web doesn't need. I'd argue that OpenID Connect pulls in
more cruft than is necessary and creates big privacy/usability problems,
but that's up for debate and we need to continue to have that debate.

> 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 webpayments.org
> <http://webpayments.org> specs that could help here.

Yes, there are. We're more or less working on the same set of problems
and have the same design requirements and goals in mind. The devil is in
the details, but the fact that there doesn't seem to be a big
philosophical divide is a good sign that we should be able to
collaborate closely on this stuff.

Thanks for the continued interest and discussion, Adrian. :)

-- 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 Tuesday, 24 June 2014 01:12:22 UTC