Re: Proof of Concept: Identity Credentials Login

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