Re: Proof of Concept: Identity Credentials Login

* 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?

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