Re: Proof of Concept: Identity Credentials Login

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

Received on Tuesday, 17 June 2014 13:47:47 UTC