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

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/

Received on Thursday, 19 June 2014 04:33:22 UTC