Re: Proof of Concept: Identity Credentials Login

On 17 June 2014 16:09, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:

> "OpenID connect relies on webfinger, which in turn relies on JRD, JSON
> Resource Descriptors, in the discovery piece."
> Thanks for the clarification.
>
> Suggestion:
> Why not use an Accept header in the WebFinger requests to ask for
> application/ld+json instead of application/jrd+json?
> One could specify JSON-LD documents that define the same contexts as
> OpenID Connect expects such as the Open ID Provider Metadata described in
> Section 3 of the discovery protocol (
> http://openid.net/specs/openid-connect-discovery-1_0.html)?
>
> i.e. All the benefits of Open ID Connect AND JSON-LD.
>
> I don't dispute the work that has gone into this and think JSON-LD is
> excellent and worth using.
> Unfortunately standards that become ubiquitous are not always the ones
> that have been under development the longest or been the most work.
>
> My issue is with throwing out Open ID Connect entirely instead of finding
> a way to extend it or even collaborate with the OpenID foundation.
> I would love the work of the Web Payments WG to succeed and am simply
> warning against us possibly swimming upstream on this issue.
>

I agree with you, and I have suggested supporting JSON LD a few times.  But
my impression is that we're a long way from that becoming a reality, if
ever.  Having said that, the activity streams community is moving towards
JSON LD, so there's always hope.


>
>
> On 17 June 2014 15:47, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>
>>
>>
>>
>> On 17 June 2014 15:24, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
>>
>>> Hi Melvin,
>>>
>>> I am not sure what you are referring to when you say JRD? Do you mean
>>> JWS (JSON Web Signatures) or JWT (JSON Web Tokens)?
>>> In any event, Open ID Connect is not a payments protocol. So the
>>> suitability of "JRD" for a payments protocol is irrelevant.
>>>
>>
>> OpenID connect relies on webfinger, which in turn relies on JRD, JSON
>> Resource Descriptors, in the discovery piece.
>>
>> It's not very standards compliant and as far as I can tell it was a break
>> away group from the w3c standards process independently trying to build a
>> linked data type serialization with signatures (initially over XML).
>>
>> But now, thanks to Manu and Dave, we have first class serializations in
>> JSON (and HTML) and also signing in JSON, all voted for and approved by the
>> wide ranging W3C member list.  About 5-10 years of prep work has gone in to
>> getting us to this stage.
>>
>>
>>>
>>> Open ID Connect provides a means for one party to take an identifier and
>>> discover information about the other party.
>>> My suggestion is that this would be a payer using the protocol to
>>> discover payment info about the payee.
>>>
>>> What one builds on top of this is up to the implementor of the extension.
>>> As an example: Open ID Connect defines a UserInfo endpoint where one can
>>> get info about the user.
>>>
>>> Why not simply provide a specification for a PaymentInfo endpoint and
>>> dictate that this endpoint returns JSON-RD?
>>> i.e. Once I have your Open ID Connect identifer I can discover the
>>> various channels you support to accept payment, pick the one I want to use
>>> and process the payment.
>>>
>>> Hopefully the standard also specifies how I can get a digital invoice
>>> from you (or your payment processor) and a digitally signed receipt as
>>> proof of payment.
>>>
>>> I'm afraid I still see no value in inventing another new federated
>>> identity protocol if you are doing it simply to facilitate payments. The
>>> ones we have offer enough to solve the payments initiation problem.
>>>
>>
>> There's nothing new about this.  It predates OpenID, in fact the very
>> first OpenID implementation (codename Yadis) was based on Linked Data.
>>
>>
>>>
>>> Adrian
>>>
>>>
>>>
>>>
>>>
>>> On 17 June 2014 14:53, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On 17 June 2014 14:42, Adrian Hope-Bailie <adrian@hopebailie.com>
>>>> 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.
>>>>>
>>>>>
>>>>> * 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?
>>>>>
>>>>
>>>> OpenID Connect does not support JSON LD.  It has its own language,
>>>> JRD.  JRD is not as powerful as linked data, and is incompatible.  For
>>>> example, JRD is unable to handle numbers, only strings.  This makes it
>>>> particularly unsuitable for a payments protocol.
>>>>
>>>> It's very unlikely imho that OpenID Connect will support linked data in
>>>> the near future.  If that were the case, there would be a good argument to
>>>> combine efforts.
>>>>
>>>>
>>>>>
>>>>> * 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 and I choose to select 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.
>>>>>
>>>>> * 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.
>>>>>
>>>>> * 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.
>>>>>
>>>>> * Less complex than the OpenID Connect technology stack.
>>>>>
>>>>> I would debate this :)
>>>>> 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. Proposing a standard that
>>>>> ignores the current status quo makes the standard a non-starter.
>>>>>
>>>>>
>>>>>
>>>>> 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. Developing internet standards is hard and time
>>>>> consuming. If you have managed to create a decent standard it far better
>>>>> for the world-in-general to get on board and use it and extend it and
>>>>> improve it than start again.
>>>>>
>>>>> I think JSON-LD is great and I would definitely support it's use in
>>>>> extending Open ID Connect to cater for specific scenarios, like payments.
>>>>>
>>>>> Open ID Connect solves most of the tough challenges in initiating a
>>>>> payment, the stage of the payment processing where there is the most
>>>>> friction and least standardisation today. It handles taking an identifier
>>>>> (in a variety of forms) and discovering the identity provider for that
>>>>> identifier. It handles dynamic registration of a relying party when
>>>>> required/allowed and most importantly it is built on OAuth2.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>> On 16 June 2014 03:54, Manu Sporny <msporny@digitalbazaar.com> wrote:
>>>>>
>>>>>> On 06/11/2014 07:38 PM, Adrian Hope-Bailie wrote:
>>>>>> > I read your blog post about this and I was wondering... Can you
>>>>>> > explain why you think this is better than Open ID Connect or what is
>>>>>> > missing/broken from OpenID Connect that this provides/fixes?
>>>>>>
>>>>>> Here are the advantages over OpenID Connect:
>>>>>>
>>>>>> * Based on an extensible data model (RDF/Linked Data) that doesn't
>>>>>>   require coordination to extend what can be placed in the messages.
>>>>>> * Based on a extensible syntax that supports Linked Data (JSON-LD).
>>>>>> * Does not require you to use your email provider as you identity
>>>>>>   provider (enabling better competition / level playing field).
>>>>>> * Privacy-aware, protecting you from organizations that would like
>>>>>>   to track who you send your credential information to.
>>>>>> * Provides a framework to exchange 3rd party proofs-of-identity
>>>>>>   beyond the simple examples in the OpenID Connect spec.
>>>>>> * Less complex than the OpenID Connect technology stack.
>>>>>>
>>>>>> There are a few more, but those are the highlights. That's not to say
>>>>>> that OpenID Connect is bad, just that it doesn't go far enough wrt.
>>>>>> data
>>>>>> model flexibility, protecting your privacy, and simplicity.
>>>>>>
>>>>>> -- 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/
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>