Re: OpenID Connect vs. Identity Credentials (was Re: Proof of Concept: Identity Credentials Login)

Hi Manu,

Thanks for the feedback.
I think my next job is to flesh out my ideas for OpenPayee (extension to
OpenID Connect) and then for us to perform a proper comparison.

A few comments:

Devil's Advocate

Playing devil's advocate is essential. A standardisation working group
without a few of these invariably ends up losing touch with reality and
ultimately wondering why their proposed standard goes nowhere when it is
released on the world. In many respects this is the hat I am wearing as I
get my head around the work you have all done to date. Please see it in
that light and not as a direct criticism of any of the work you have done.

*"Developing a standard that describes both how to exchange data and what*
*data should be exchanged specifically for payments would be a mistake.*
*:) It would be a layering violation."*


I agree. OpenPayee is an effort to extend Open ID Connect (the standard for
identity and data exchange) to add the next layer that is payments
specific. I concede that you are raising issues with OpenID Connect that
hadn't occurred to me and perhaps those need to be addressed for OpenPayee
to work. A deeper dive is required.

*"Keep in mind that many industries do payments and the requirements for*

*what data is exchanged to initiate or complete a payment varies,*
*sometimes greatly, from industry to industry. So, the decision of what*
*data is required should be up to each industry, not the Web Payments**group
(although, we can help them craft the type of credentials their*
*industry would find useful)."*


Again I agree. My approach with OpenPayee is to simply fill the gap between
initiation and negotiation of terms. This dramatically reduces the number
of use cases one must handle.

In other words, let's just standardise a mechanism for the payee to pass an
identifier (and possibly some transaction meta-data) to the payer and for
the payer to use that to discover all of the "channels" that the payee will
accept payment on. Finally we need to standardise a way for the payee to
get a proof-of-payment that they trust. Everything that hapens in-between
can be channel specific including what data is exchanged.

There is scope to add logic to the channel selection protocol that allows
the payer to make automated selections based on standardised
representations of fee calculations and currency exchange rates  etc but
are those essential to get this off the ground?

WRT OpenID identifers, being your own provider, privacy and IdP
centralisation...

I think this issue is constantly clouded by that fact that we always fall
back to the default assumption that it is the consumer sharing their
identity. It's not. It absolutely shouldn't be. To make a payment the payee
(merchant) must pass identity over to the payer (customer) who controls the
process. There is no reason, in the simplest case where the merchant
doesn't require a delivery address or age verification or similar, for the
payee to know anything other than the fact that they were paid.

My view of the future is that I will trust my bank to be my payment
provider. When I wish to make a payment to someone they will share their
OpenPayee identifier with me and using a channel I trust (my bank's
internet banking site, their app or some other mechanism) I will pay them
directly out of my account.

The channel I use (direct EFT, payment card, bitcoin) will be negotiated
between my bank and the payee's payment provider. If there is a need for me
to make a choice then I will be prompted to do so. When the payment is
complete the payee will get a digital receipt signed by my bank (and
possibly counter-signed by the payee's bank or a trusted entity that
manages the channel they ultimately used to make the payment). If I choose,
they don't even know my name.

So now my bank knows who I spend money with. Not very different to how it
is today.

TL;DR

I contest that identity (specifically protection and de-centralisation of
identity and privacy) is not as important to standardising payments as the
amount of effort going into it would suggest. If this is done right the
payer (customer) should be in absolute control of the process and the only
party that necessarily has to give away their identity is the payee (so
that this identity can be used to discover the channels available to pay
them).

I also contest that it is not the role of the payments standard to specify
means by which payer info get's passed to the payee. This could happen
entirely out of band or not at all. The fact that kids can buy alcohol
using prepaid debit cards today won't change because there is a new way to
process the payment. That is not so say that the standard should allow for
this by having a step in the process that says "If the payer needs to
verify some element of their identity do that now".

Adrian




On 19 June 2014 06:32, Manu Sporny <msporny@digitalbazaar.com> wrote:

> Adrian,
>
> Responses to your email below. Keep in mind that I do think you have a
> number of fair points. I'm playing devil's advocate and outlining why
> we've done what we have to date. OpenID Connect is the 800lb gorilla, we
> can't ignore it and we'd be foolish to not try and propose a set of
> extensions to OpenID Connect that would bring it up to feature parity
> with the Identity Credentials stuff.
>
> On 06/17/2014 08:42 AM, Adrian Hope-Bailie wrote:
> >> * Based on an extensible data model (RDF/Linked Data) that doesn't
> >>  require coordination to extend what can be placed in the
> >> messages.
> >
> > If we are trying to create a standard then at some point one must
> > prescribe some elements of the data model. Why not take Open ID
> > Connect and extend it by prescribing the elements that are required
> > for it to support exchange of payment details between parties to a
> > payment?
> >
> > I don't see the value in developing standard that simply describes
> > how to get data without ever prescribing what data must be provided
> > by which parties.
>
> There are two points you're making. The first has to do with extending
> OpenID Connect, the second has to do with the design of a login
> standard. Let's address the second point you're making first.
>
> Developing a standard that describes both how to exchange data and what
> data should be exchanged specifically for payments would be a mistake.
> :) It would be a layering violation.
>
> The correct way to design such a mechanism is to write a specification
> that describes how to exchange data in a generic manner (which is what
> the Identity Credentials specification does). What data gets exchanged
> is for a different specification, and we do intend to write that
> specification.
>
> Keep in mind that many industries do payments and the requirements for
> what data is exchanged to initiate or complete a payment varies,
> sometimes greatly, from industry to industry. So, the decision of what
> data is required should be up to each industry, not the Web Payments
> group (although, we can help them craft the type of credentials their
> industry would find useful).
>
> To your first point, we could try to extend OpenID Connect. I think
> that's still on the table and we do need to explore it. One of the
> things we wanted to do before exploring extending OpenID is to see how
> much of the technology stack we could cut away. OpenID Connect sits on
> top of 13-17 specifications (depending on how you're counting). Identity
> Credentials sits on top of around 5-7 (depending on how you're
> counting). The comparison isn't as easy as counting the number of
> specifications, but I stand by the assertion that the Identity
> Credentials stuff is simpler (less specs) and more flexible (based on
> Linked Data), and protects your privacy (login masking) than the OpenID
> Connect stack.
>
> To be fair, we should do a thorough analysis of both approaches, and we
> can now do that since the proof of concept exists and we've worked out
> how most of the Identity Credentials stuff would work.
>
> > * Based on a extensible syntax that supports Linked Data (JSON-LD).
> >
> > I don't see why an extension to Open ID Connect couldn't simply
> > prescribe an additional endpoint service that is required and serves
> >  JSON-LD documents for the purposes of whatever you are trying to
> > achieve?
>
> It could, but JSON-LD is just a part of the set of problems we're trying
> to address. Even if you put the JSON-LD endpoint in, you'd still have
> the privacy and IdP centralization issues. We're trying to increase
> competition, not minimize it.
>
> I'm curious about your proposal, though. Could you flesh out what this
> would look like via an OpenID Connect response? An simple example would
> help me understand what you mean by "additional endpoint service".
>
> > * Does not require you to use your email provider as you identity
> > provider (enabling better competition / level playing field).
> >
> > Neither does Open ID Connect. Anyone can be an Open ID Connect
> > provider and issue identifiers to their users. If my email address is
> > adrian@hopebailie.com <mailto:adrian@hopebailie.com> and I choose to
> > select openpayee.org <http://openpayee.org> as my id provider then my
> > identity is simply "acct:adrian%40hopebailie.com@openpayee.org".
> > There are also myriad ways to delegate Open ID provision to third
> > parties.
>
> Do you think the general public would be comfortable with this experience?
>
> Website: What is your OpenID?
> Customer: adrian%40hopebailie.com@openpayee.org
>
> I'm asserting that most people will just put in their free email
> provider's address - adrian.baille@gmail.com. This is one of the biggest
> reasons that large email providers are big supporters of the OpenID
> Connect specifications. It provides them with not only an oligopoly in
> email services, but an automatic one wrt. identity/login services.
>
> > * Privacy-aware, protecting you from organizations that would like
> > to track who you send your credential information to.
> >
> > You can be your own Open ID Provider if you really want to protect
> > your privacy and issue yourself dynamic identities for each use. I
> > expect Open ID Connect providers to offer this as a default
> > configuration option.
>
> Becoming your own OpenID Provider is not easy for the vast number of
> people that are on the Web. Making that assumption as the mechanism that
> protects your privacy, for any online identity solution, is a bad
> assumption to make.
>
> I doubt large OpenID Connect providers will offer this as the default
> configuration option because the incentives will be completely
> mis-aligned with what you predict. The choices are "do the right thing"
> and "make a ton of money collecting and using customer browsing data".
> The latter business model is the one that pays the bills for most
> Internet companies.
>
> > * Provides a framework to exchange 3rd party proofs-of-identity
> > beyond the simple examples in the OpenID Connect spec.
> >
> > Claims based authentication is a fundamental piece of every federated
> > identity system in use today. This simple means of issuing signed
> > claims is the simplest and easiest way to federate identity. Just
> > because there aren't examples doesn't mean Open ID Connect can't
> > handle the use case.
>
> Is there an example of digitally signed 3rd party claims for OpenID
> Connect? If not, what would they look like?
>
> > * Less complex than the OpenID Connect technology stack.
> >
> > I would debate this :)
>
> It is debatable. :)
>
> > Open ID Connect is built on OAuth2. If you don't like OAuth2 then go
> > and complain to pretty much everyone on the internet because it's
> > the way SSO works online today, ask Facebook, Google etc.
>
> Just because that's the way the Internet works doesn't mean it's a good
> thing. :)
>
> > Proposing a standard that ignores the current status quo makes the
> > standard a non-starter.
>
> That's true, but no one is saying that we're going to ignore OpenID
> Connect. We're going to do these things:
>
> 1) Analyze the benefits/drawbacks of OpenID Connect vs. Identity
>    Credentials.
> 2) Attempt to extend OpenID Connect w/ functionality that the
>    Identity Credentials specification has.
> 3a) Go forward with Identity Credentials only if the OpenID Connect
>     extensions are too complex or we can't get adoption via the
>     OpenID Foundation for the extensions, or
> 3b) Add OpenID Connect as an option for the Identity Credentials work.
>
> I don't know if you've read the spec yet or not, but we have had an
> OpenID issue in there for a while now:
>
>
> https://web-payments.org/specs/source/identity-credentials/#integration-with-openid-oauth1-and-oauth2
>
> > As a general comment, and I will admit to only having a high level
> > perspective of your proposal, it feels like you are throwing the baby
> > out with the bath water.
>
> I admit that we might be doing that. This is an experiment, and like all
> experiments, we can't go into it thinking that the state of the world is
> just fine. We have to ask question like: Is the JOSE stack easy for
> developers to use and debug? Is OpenID Connect what's best for the
> citizens of the Web? Is there a better way?
>
> > Finally, and to me most importantly, identity is only important in as
> > much as the payer needs to discover the identity of the payee so that
> > they can get paid. If accept your motivation that in some cases the
> > payer's identity (or some element of it such as age) must be verified
> > by the payee but that is an edge case that should be solved outside
> > the payments process.
>
> That's oversimplifying the problem. Keep in mind that the credentials
> that you transmit are not just age, but email address, payment provider,
> and shipping address. These are not edge cases. They are a frequent part
> of an online payment.
>
> > How do merchants verify the age of consumers today when they are
> > buying things online? They don't. If they do, they do so by assuming
> > that if the customer has a credit card then they are old enough. So
> > actually this is a channel-level data exchange. i.e. As the payer I
> > have identified the payee and the available channels to pay them
> > already. It just so happens that all of the available channels are
> > only usable to payers of a certain age.
>
> Except that this is no longer true. Most anyone can get their hands on a
> pre-paid card these days. You can make no assumptions on the age of your
> customer just because they have access to a credit card. This is exactly
> what's broken with the current system today.
>
> Want to know how underage kids buy beer and liquor in America now?
>
> Step 1: Get a pre-paid debit card.
> Step 2: Go to an online liquor store and place your order.
> Step 3: Deliver to beer-drop-friendly address.
>
> Just because this is the way the world works today does not mean that we
> should accept it. Especially when it wouldn't be that much work to fix
> it on a global scale. :)
>
> So, all of this said, what changes do you think we'd need to make to
> OpenID Connect to reach feature parity with the Identity Credentials stuff?
>
> -- 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/
>
>