Re: Proof of Concept: Identity Credentials Login

On 06/24/2014 07:03 AM, Adrian Hope-Bailie wrote:
> As a general comment, great to see that I'm not crazy and as a whole we
> are in agreement!

Just because the group agrees doesn't mean we're not crazy. :P

> Great! I see this as fundamental, push payments is the only way we can
> ultimately migrate to a system where payments are initiated and
> concluded on the Web (even if they are processed, cleared and settled
> out of band).

+1

>     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. :)
> 
> Again, yay!
> That said, I haven't noticed it as prominently as I would expect in the
> specs I have read on webpayments.org <http://webpayments.org>.

Unfortunately, the specs are half-baked, poorly written, and not up to
date with current thinking. They don't quite reflect where we are as a
group due to lack of time to update the specs.

> My experience in dealing with payments industry stakeholders is that
> they have gotten so used to cards as the only way to do B2C payments
> that they haven't even considered alternatives.

For some stakeholders that's true, for others not so much. We've found
that many know about the alternatives, but think that implementation of
those alternatives are at least a decade or two off (this tends to be
the common line wrt. most banks, large and small, that I've spoken with
over the years).

> If what we are doing presupposes that we will use a push payments model,
> why so much focus on protecting the payer's identity?
> As I have said before, sharing the payer's identity or proving some
> payer credential is an edge case.

Sharing an email address and shipping information is not an edge case.
Those two pieces of information are regularly exchanged as a part of an
online payment.

> I see this standard as a means to use the internet to change existing
> payments, most of which occur in the real world, not online.

That could be one thing that the standard affects, yes. That said, we
can't make that our solitary focus. If we're successful, we won't have
to make a distinction between online and offline payments, or mobile and
non-mobile payments. We're creating a set of modern standards for
payments, full stop.

> i.e. People are already making card payments at a POS today, how can we
> change this so they use their mobile but not in a way that simply puts
> their card on their mobile?

+1, that's exactly the right question to ask (and one of the questions
that we're attempting to address in this group).

> My impression is that the work of the group thus far has been to take an
> Internet payments first approach and that pulling in "brick 'n mortar"
> use cases is a something that came after.
> i.e. CNP eCommerce sucks, how can we make it better?
> Am I wrong?

No, we want the solution to work on the Internet and Brick and Mortar
(BaM) as well. The issue with leading with Brick and Mortar first is
that the BaM industry moves at a snails pace and the cost of upgrading
POS terminals are quite large. There are large players (like Verifone,
for example) in that industry that control access to what technologies
are used and when they're deployed. We can't deploy and iterate quickly
in BaM, but we can deploy and iterate quickly on the Web.

> I see both as valid problems to solve but I see the brick 'n mortar
> scenario as the one that should be solved first.
> If you can solve that, entirely online payments can be solved easily.

I strongly disagree. Why do you think it'll be easier to deploy in a BaM
environment than an online one? Retailers are among the most
conservative when it comes to new payment rails.

> The payments process should a be simple one.
> 1. Establish who is paying who and how.
> 2. Process the payment
> 3. Provide both parties with proof of the completed payment
> 
> Other services like verifying the age of the payer, getting the shipping
> address of the payer, generating a full invoice including the basket of
> goods can all be bolted-on.
> If we try to make them integral to the payment process then things get
> way too complicated.

I understand the point you're making, but I see your proposal as just
digitizing the current payment flow we have today and paying with an
electronic cheque equivalent.

Keep in mind that there is nothing preventing organizations from simply
doing what you state above with the current spec. You're talking about a
simple transfer of money w/ a memo field (an electronic cheque). That's
the easy problem to solve, and that what this spec is for:

https://web-payments.org/specs/source/web-payments#the-transaction-process

That approach also ignores much of the input that we've gotten from
large retailers, banks, and governments. The fact is that identity is a
big problem on the Web and in payments. The use case that you want to
solve is just a minor part of the bigger problems with payments on the
Web. You may want to review the input we got from major banks/retailers
and financial technology companies here:

http://www.w3.org/2013/10/payments/final_report.html#output

This may also help:

http://www.w3.org/2013/10/payments/minutes/

While I agree that what you're proposing we do is a good first cut, it
won't address the many other concerns that the world wide payments
community has. Again, this is about striking a balance between boiling
the oceans and spec'ing a toy payments protocol. If we go too far in
either direction, adoption will fail. I expect that we'll be debating
whether we're straying too far in either direction for the duration of
the work we do here. :)

> As far as I know real-time ACH is not possible in the US.

It is, it's called FedWire, but it's only accessible to the banks. :)

> To make a real-time payment you have to use a card.

A card payment isn't real-time, the money can still take days to settle.

... but I get what you're saying. We want instantaneous
customer-to-customer clearing. That said, what you've proposed doesn't
lead to instantaneous customer-to-customer clearing.

The banks have been able to do instantaneous customer-to-customer
clearing for years now. However, when the time comes to vote for
instantaneous customer-to-customer clearing, it's voted down each and
every time because if it's allowed, the float goes away and banks lose
that revenue stream on which they depend.

>     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.
> 
> I applaud this work and I really like JSON-LD.
> You may argue that it brings us closer to a payments standard by an
> essential providing a piece of the puzzle that you considered to be
> missing. 
> My contention is that it wasn't really essential to developing a
> payments standard which is what I believe is the mission of this group.

We'll have to agree to disagree that JSON-LD wasn't required for a
Web-based, scalable payment standard. :)

> Why not take this work into the appropriate forum and from the
> perspective of developing a payments standard we can consider it just
> another arrow in the quiver?

It will eventually move to the appropriate forum. The unfortunate
reality is that forum doesn't exist right now. If it did, the identity
work would already live there. This is the same thing that happened with
JSON-LD. It was incubated in this group until the JSON-LD CG was formed
and then the RDF WG adopted and standardized the work.

Where do you think the identity work we're doing here should go? Which
forum should it move to?

> My concern is that by developing an identity exchange standard under the
> name of a web payments group you have effectively labelled it as a
> standard for payments.
> The assumption from anyone outside the group will always be that it is
> designed for this purpose because the group felt the existing solutions
> weren't good enough.

That didn't happen for JSON-LD, why do you think it'll happen to the
identity work?

> I think there needs to be clear messaging that the Identity Credentials
> work is, as you have said before, an experiment being done "on the
> sidelines" to test some theories.

Where would you like to see that messaging?

> I need to do a deeper dive but from my first impressions, a lot of what
> is laid out in the 3 payments focused specs could be done without any of
> the stand-alone standards.
> How you exchange credentials, sign messages, represent linked data are
> all implementation details that can be achieved a number of ways.

Yes, but the point of standards is to nail down the implementation
details wrt. interoperability. You can't just say "and then you
digitally sign a message and send it to the payer". Interoperability and
standards are about /how/ you do that.

> My approach has been to break payments down to the following steps:
> 
>  1. Initiation
>     The payee provides the payer with an identifier and optionally a set
>     of transaction meta-data such as the payment amount and currency.

+1

What sort of identifier is this? Is it a URL? Is there machine-readable
data at that URL?

>  2. Discovery
>     The payer uses the identifier to discover the available channels on
>     which the payee is able to receive payments.

+1

How does the payer extract the information in an interoperable way?

>  3. Channel Selection
>     The payer selects one or more payment channels from those that are
>     available and for which payer accepts the terms.

+1

>  4. Invoice (optional)
>     The payer requests a digital invoice from the payee confirming the
>     transaction details including the amount, currency,  channel(s) and
>     terms that will be used to make the payment.

Why is this step optional? If you make it optional, where is the
consumer protection? What happens if the payer changes their mind? "Oh,
no, I never said pay me $1 for access... I said pay me $10! - the $1 was
for the preview that I showed you". Remember, this stuff is going to be
used for peer-to-peer payments as well. It's not just customer-to-merchant.

>  5. Payment
>     The payer processes the payment.

+1, if you mean the payer's payment processor processes the payment.

>  6. Receipt
>     The payer requests a digital receipt from a trusted entity
>     participating in the payment (dictated by the channel used, usually
>     the payee's provider).

+1

>  7. Notification
>     The payer notifies the payee that the payment has been completed by
>     posting a copy of the receipt to the payee. Alternatively the payee
>     may receive the receipt directly from their provider.

+1

>  8. Confirmation
>     The payee confirms that the payment is complete.

+1

> Notice that all of this can be achieved without the payer doing any
> identity exchange.

Sure, it can happen w/o the payer doing any identity exchange, but that
only covers a small-ish portion of the number of use cases that we have
to cover if this payment mechanism is going to achieve what you can do
online today.

Let's take the example of a movie rental where you have to be over the
age of 15 to rent the movie.

How do you prove that you're over a certain age? What happens when the
buyer returns to the website to say, view the rental on the second day?
How do you prevent the digital receipt from being pirated and used by
1,000 different people?

>  1. That the Identity classification is split (or a new category added:
>     Discovery) so there is a clear distinction between the payer
>     discovering the channels available to pay the merchant and the
>     merchant discovering information about the payee.

It's already split out:

https://web-payments.org/specs/#identity

Where else would you like to see the clear distinction?

>  2. That the other steps above be considered for inclusion as categories.

Categories where? I think we've been considering those categories for a
while and, while it may not be obvious from the website, that's the
operational model we've been assuming for a number of years now. So,
this sounds like a documentation problem. Where do you think we should
document those steps?

>     These specs can be used to solve /other/ problems on the Web.
> 
> A bonus if it happens but surely a distraction and likely to cause
> delays? :)

In some cases yes, in others no. You'll have to be more specific about
what you think is a distraction. :)

Keep in mind that when Web standards go out there, their life span is
10+ years. So, we should be very careful to craft a solution that's
extensible and that is capable of changing with the times. The worst
case isn't that the technology isn't adopted, it's that it /is/ adopted
and it isn't flexible enough to keep pace with innovation or it doesn't
scale appropriately to billions of people.

To put it bluntly: This is the Web, we don't half-ass solutions just
because we want to make rapid progress. :

Bolting things on after-the-fact is far more difficult than designing
them correctly from the start.

> Although I'd also propose a standard for each stage and name them as
> such maybe?
> 
> Some ideas:
> 
> Web Payments Initiation (OpenPayee was heading down this road, elements
> of Web Commerce API)
> - How to normailse an identifer and optional meta-data into a resource
> address(es) where the channel discovery, id exchange etc services can be
> found
> - Should probably include a means to verify the payee in some way
> 
> Web Payments Channel Discovery (some stuff from Web Commerce)
> - Standardised way to represent available payment channels and basic
> requirements for channels to plug into this system
> 
> Web Payments Payer Identity Exchange (Identity Credentials?)
> - Standardised way to request payer credentials etc
> 
> Web Payments Terms Core (+ extensions for specifying how specific terms
> would be represented: currency, fees, clearing requirements etc )
> - Standardised way to represent what terms are understood by both
> parties, elegant fallback for those that aren't and a means to describe
> the terms.
> 
> Web Payments Invoicing 
> - Standardised way to request a digital invoice in which the final terms
> are described (and calculations done so this only contains final
> amounts) that is signed by the payee.
> - Standard format(s) for the invoice, signature etc
> - Should include a mechanism to reject a request if the terms have been
> misrepresented or misinterpeted by the payer
> 
> Web Payments Receipts (stuff from Web Commerce and Web Commerce API)
> - Standard way to request a signed receipt after the payment is complete.
> - Standard format(s) for the receipt, signature etc
> - Standardised means to conclude the payment by sharing the receipt or
> confirming it's signature or similar

I think these are good suggestions. It feels a bit like premature
re-arranging, but perhaps we should start a separate thread to discuss
this proposal. Do you mind starting that thread?

>     > 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/
> 
> Yes and no.
> I think this spec is the perfect place to start but it highlights what I
> mentioned before about coming at this from the Web angle first.
> I know that this the original intention of PaySwarm (as I understand it)
> was a web based payments system solving problems specifically around
> digital assets, micropayments and licenses so this is expected.

No, PaySwarm was already intended as a mechanism to make both Internet
and "physical retail" payments.

> The spec assumes that all of the information about the transaction will
> be bundled together.

Hmm, why do you say that?

> All the payer wants to know is how much and how do I make the payment.
> That's all I think the channel discovery standard should solve.

That may be all the payer wants to know, but the regulatory environment
requires much more to be collected during the sale. Same for the
retailer and the payment processor. A retail transaction isn't as simple
as "I want $5, give it to me."

> A completely seperate specification can deal with digital contracts,
> defining the basket of goods (assets) etc.

Maybe... open to discussion on which spec each of these things go in.
It's all good as long as the narrative is clear.

> The channel selection or other specifications should allow for this and
> provide extension points for this explicitly.

+1

> True. But again, I see this as an optional step that doesn't justify
> thee amount of airtime it's getting.
> (Maybe my timing in joining the group is just unlucky?)

Your timing in joining the group is exceptionally unlucky... we hadn't
been discussing identity much until just a few weeks ago. :)

> I see your point but I would counter that by saying, if the major
> players are adopting that standard the cruft get's quickly hidden from
> the implementer by being core to whatever library they build on.

Cruft has a fantastically huge cost when you're talking about Internet
and Web infrastructure. We aren't designing a software library here,
we're designing part of an infrastructure that 3.4 billion people are
going to be using by the year 2025. We don't want 70% of that
infrastructure to consist of cruft.

> Call it simplistic but I see this process as similar to software
> development.
> You either find a base library that does most of what you need and
> extend it or you start from scratch.
> History tells us that most engineers will always want to go with option
> 2 but the pragmatic programmer usually goes with option 1 for good reason.
> - No need to become intimately familiar with the internals of the base
> library
> - Leverage the hard work and many eyes of the people that contributed to
> the base library
> - Benefit from the constant improvements and updates to the base library

IMHO, looking at Web and Internet architecture design in those
simplistic terms is a recipe for disaster. :)

Designing technology and protocols for the Web is a different beast than
standard software development and engineering.

I understand the analogy that you're making, but having participated in
the standards-making process for a while now, software engineering and
Web standards engineering only share a few things in common.

You build on top of standards that are useful, that much is true.
However, building on top of standards that contain 70% cruft is a good
indicator that what you're building on top of is probably not a good fit
for what you're doing.

Again, I'm not saying that OpenID Connect is 70% cruft, or that OAuth2
is not useful. I'm saying that from what we've experienced to date, they
didn't drop in as easily as some of the other technologies we've decided
to build on top of (like RDF, JSON, JSON-LD, AES, HTTP Signatures, HTTP,
URLs, etc).

-- 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 Thursday, 26 June 2014 02:10:44 UTC