Re: Proof of Concept: Identity Credentials Login

Hey,

As a general comment, great to see that I'm not crazy and as a whole we are
in agreement!
Some comments inline:


On 24 June 2014 03:11, Manu Sporny <msporny@digitalbazaar.com> wrote:

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

Indeed :)


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

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

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

Again, yay!
That said, I haven't noticed it as prominently as I would expect in the
specs I have read on webpayments.org.
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.
All of the conversation I have seen on the list so far APPEARS to be
forgetting this.
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.

I suspect that this difference of opinion may come from our different
perspectives/approaches to the problem.
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.
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?

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?

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.

An important difference between the two, which may also be part of why we
are not 100% in agreement yet, is that in the brick 'n mortar world there
is usually a vast chasm between shopping and paying.
The basket of goods (what you are paying for) and any business rules around
that are entirely irrelevant to the processing of the payment for those
goods.
I'm not convinced that we should try to push them together which APPEARS to
be the approach of the webpayments.org standards I have looked at.

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.


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


Yes, it's encouraging :)


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


As far as I know real-time ACH is not possible in the US.
To make a real-time  payment you have to use a card.

In contrast UK consumers can send money to one another via push payment
that clears in real-time.
The PayM project means they can do it by simply knowing the receivers
mobile number.
The Zapp project will ultimately mean paying at stores with your phone via
a push payment.

To me this is the ideal, and a standardisation of this model sets the stage
perfectly to start using push payments for all of the use cases you have
looked at so far.


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


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.

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?

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.

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.

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.


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


I believe this is just a difference of opinion on approach and what these
smaller pieces should constitute.
As I mentioned before I think this comes from viewing payments from the
eCommerce side first.

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.
   2. Discovery
   The payer uses the identifier to discover the available channels on
   which the payee is able to receive payments.
   3. Channel Selection
   The payer selects one or more payment channels from those that are
   available and for which payer accepts the terms.
   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.
   5. Payment
   The payer 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).
   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.
   8. Confirmation
   The payee confirms that the payment is complete.

Notice that all of this can be achieved without the payer doing any
identity exchange.
One could certainly add that step in somewhere around the invoice request
step but it's not essential and so I see it as a massive distraction.

I think that the work done so far to categorise the various use cases is
excellent and a step in right direction.

I want to propose 2 things:

   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.
   2. That the other steps above be considered for inclusion as categories.



> Everything that we're
> discussing here should be a spec that stands on its own.


+1


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


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

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


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

+1 million :)


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

The spec assumes that all of the information about the transaction will be
bundled together.
In many scenarios this is not the case.
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.

A completely seperate specification can deal with digital contracts,
defining the basket of goods (assets) etc.
The channel selection or other specifications should allow for this and
provide extension points for this explicitly.
i.e. If the payee requires X info or the for the payer to accept Y terms
provide these now in this form and only proceed if they do Z.


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

My wording is misleading sorry, I agree with your approach 100%.
Once the payer knows how they can make the payment they pick one (and
optionally request an invoice specifying the terms they have selected so
there can be no debate later about the 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?
>
> 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).


Happy for this to be an extension to the v1 standard. 100% agree with this
approach.


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

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

We can produce a v1 set of payments standards that handles 80% of use cases
without needing this.
Just like currency conversion or other "terms negotiation" bits this can be
an extension to the basic payment process.


> > 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 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.
Deploying an Open ID Connect provider today is pretty straight-forward
(maybe not to a layman but we are talking about people who will be
deploying this as a node in a complex payment network. Banks, payment
gateways etc.)
The advantage of using what is already out there is obviously saving time
and leverage existing deployment footprint and skills (not to be
underestimated).

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

In the same way as programmers try to define interfaces so that the base
library can be swapped out if the callers abide by the interface I am
proposing that it is possible to define a high level standard (without
implementation detail) that describes process flows and information and
then to provide implementation specific details that describes how those
flows are done on top of a specific base (Open ID Connect, SAML, etc)


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


Yes, I think we all want the same thing. I have come at the problem
slightly differently (it seems) and so we will have to talk through the
differences and see where we end up.

Now, lunch break's over, back to the day job :)


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