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

No, I'm not confused. I am describing the Open ID Connect Discovery
specification as it stands.
(http://openid.net/specs/openid-connect-discovery-1_0.html - see Section 2)

The specification DOES NOT require that Open ID Connect identifiers use a
custom URI scheme.
It only requires that whatever string you use as your identifier can be
normalised, using the rules described in the specification, to determine a
resource and host.
The host portion is essential in order to move onto the next step of IdP
discovery through the WebFinger queries.

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


Can you quantify this statement? Why does it not scale? Why is the worst of
what worlds? I can't respond to a purely emotive statement like that.

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

Two responses to this statement:

1. Not sure where this statement comes from? I am providing illustrative
examples above of how I may use my email address as my identifier in
various ways. I am disputing Manu's assertion above that users will always
use their email address as their OpenID Connect identifier. Nothing I have
said infers promotion of a new URI scheme? (In any case the acct: scheme is
not new, it is already in the IETF standards track).

2. Let's ignore the use of a custom URI scheme for the purpose of
indicating the identity scheme for a minute and focus on custom URI schemes
in general.

You are a making a sweeping statement about custom URI schemes without
considering the fact that this has become the most common way to bridge the
Web with non-browser applications (the likes of which are almost certainly
going to be responsible for performing payments in future).

All of the major mobile and PC OSes support the registration of custom URI
schemes as a means to identify that a resource must be handled by a
specific application or set of applications that are registered to handle
that URI scheme. This is achieved without the URI schemes being registered
in any way via the IETF.

I am interested to hear how you propose payments will be initiated without
a custom URI scheme? How will this be achieved in brick-and-mortar stores
where the payer wishes to pay via their internet connected mobile phone and
the initiation is done via QR code or NFC tap? What will the information be
that is passed to the mobile device that will provide it with the context
that the user is wishing to make a payment?

Again, I must stress, that debating this is a waste of time. An payment
standard should be agnostic of identity protocol used.
They are two different things and if payments are done well identity
becomes less important (or even irrelevant).


On 20 June 2014 03:09, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

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