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

On 19 June 2014 19:51, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:

> CC the group (replied direct to Melvin by mistake):
>
> I have to disagree with your interpretation of the normalisation process
> in OpenID Connect Discovery.
> Identifiers can take a LARGE variety of forms, mostly IRIs but if they
> take the form userpart@host they are assumed to be acct: identifiers.
>

No you are confused.

You are overloading strings to mean

1. A memorable identifier
2. An identity string
3. A message delivery system (email)

You are taking the worst of all worlds to cut corners.  It does not scale.


>
> Normalisation simply uses rules to determine the host and resource parts
> from the identifier so that the RP can do the initial WebFinger request to
> find out where the IdP is hosted.
>
> If my email address is adrian@hopebailie.com I have 2 options:
> 1. Host a resource at hopebailie.com/.well-known/webfinger that tells the
> RP wehere to find my idP. The resource for the webfinger request will be
> adrian@hopebailie.com
> 2. Use my email address as PART of my identifier where the JRD document
> pointing to my IdP is hosted on another domain. eg: openpayee.org. In
> this case my identifier could beadrian%20hopebailie.com@openpayee.org or
> even http://openpayee.org/adrian%20hopebailie.com
>
> Use of the acct: URI scheme is optional. The standard says it can be
> assumed if it's left out and the identifer takes the form userpart@host.
>

-1,000,000 we dont want to be promoting a new URI scheme in this group.  In
the massively unlikely event that it takes off in scale it could be
considered.  This is almost certain not to happen.  Let's not make bad bets
on bad tech for no reason.


>
> Finally, I want to reiterate again that I don't think this is important
> anyway.
> If our objective is for a payer to get information about how to pay a
> payee then it's the payee handing our identifers NOT the payer.
>
> I still contend that payee's getting information about a payer is an edge
> case that a payments specification does not need to handle explicitly. It
> should be sufficient to be aware of the need for this and cater for it.
>
>
> On 19 June 2014 15:31, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>
>>
>>
>>
>> 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.
>>>
>>
>>
>> This is not actually correct.  You only URL encode the identifier (which
>> can be any URI) when giving it as a parameter to the .well-known/webfinger
>> HTTPS URI.
>>
>> So the identifier is actually acct:adrian.baille@gmail.com
>>
>> What you may type into a form could be the memorable name
>> adrian.baille@gmail.com which for some very odd reasons gets translated
>> to an acct: URI, rather than, the expected mailto: URI.
>>
>> It's not clear to me whether this new acct: URI scheme will take off, in
>> the same way that mailto: and http: have.  We need several years to find
>> out, maybe even a decade, and my bet is that it will *not* become
>> ubiquitous, and maybe even will not even be around then.  The words of Eran
>> who actually created this concept:
>>
>> "Getting consensus for new URI schemes is often more difficult than
>> solving American healthcare"
>>
>> We dont want to bite off more than we can chew.  We should simply
>> standardize around the widely adopted http:, mailto: and perhaps tel:
>> schemes, while leaving the door open for those that want to use others.
>>
>> It would be a non starter, imho, for web payments to standardize around
>> an acct: URI scheme.
>>
>>
>>
>>
>>>
>>> > * 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/
>>>
>>>
>>
>