Re: Proof of Concept: Identity Credentials Login

How scalable is it?  

What solution (apart from WebID) can plausibly create an independant, decentralised, IdP for every legal entity...

Needs to support 5 star linked data, and the h/w resource footprint is important too...

Internet of things "participants" will have Auth Requirements too, but let's leave that to one side...  Legal entities are the ones setting the rules overall...

Timh.

Sent from my iPad

> On 17 Jun 2014, at 11:24 pm, 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.
> 
> 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.
> 
> 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/
>>>> 
>>> 
>> 
>