Re: Proof of Concept: Identity Credentials Login

On 6/10/14 9:52 AM, Tim Holborn wrote:
> I agree about decentralisation, etc.
>
> see: https://github.com/digitalbazaar/opencred-idp and (or so it 
> appears) https://github.com/digitalbazaar/opencred-verifier
>
> I think the fact the solution is available on Github, significantly 
> influences the rational surrounding whether or not it’s starting out 
> to be a workable solution…

Being on Github doesn't make something an open standard. Basically, Open 
Source != Open Standard.

>
> (does you.id have a github repo?)

YouID [1] is a utility for generating:

1. Identifiers -- WebIDs
2. Public and Private keys
3. Public and Private Identity Cards -- the private part is an X.509 
cert and the public part is stored at a location of your choosing
4. Identity Card Content in a variety of formats -- TURTLE, JSON-LD, 
HTML+RDFa, HTML+Microdata .

1-4 can be done by hand using any collection of tool e.g., those that 
bundled with all modern operating systems (desktop to mobile). All YouID 
does is save you time while negating the distracting politics around RDF 
document content formats etc.. Basically, we are using our knowledge of 
this subject matter to produce a solution for end-users and developers 
alike.

To answer your question, YouID isn't open source, its available on iOS 
or Android.

I don't see YouID being mutually exclusive with anything i.e., saving 
time (re., public and private identity claims docs generation) is 
compatible with any collection of standards that loosely couple: 
identity, identifiers, identification, authentication, and authorization :-)

Links:

[1] http://youid.openlinksw.com
[2] http://bit.ly/1tkOWv1 -- Blog post that walks you through what YouID 
is about.


Kingsley




> And: http://manu.sporny.org/2014/identity-credentials/ notes the need 
> to complete the decentralisation of the method.
>
> And i absolutely agree that it needs to be RWW compatible (rww.io / 
> data.fm are json-ld compliant).  How it deal with the URI For an 
> x509v3 cert (subjectAltName) is another function of what’s already 
> outlined https://credential.club/ - however applied to a machine 
> (resulting in one TLS Cert per Machine Account for desktop devices; 
> perhaps only one on mobile devices… or perhaps one for each 
> persona/agent? i’d prefer one per machine…)
>
> Similarly; the ability to create an AUTH link - which relates back to 
> a post authored earlier today…
>
> Along those lines; another form of ‘credential’ might be taking a pic 
> with a phone of a QR Code shown on a desktop interface, then tracking 
> the two device ID’s, etc.  eg: using something like; 
> http://davidshimjs.github.io/qrcodejs/
> or - is that not a credential?
>
> anyhow. really stoked.  I think it’s a great start to a POC; 
> infinitely capable of being applied to the roles required surrounding 
> WebID’s roles with RWW / LDP - in addition to linking to institutional 
> credential providers (KYC, etc.); providing 'anon persona’,  creating 
> auth sequence that can then support the use of FOAF (where 
> appropriate) for things like social-web; all sorts of options: when 
> earlier - i was entirely frustrated by the somewhat opaque terminology 
> of ‘agent’.
>
> This way; i’m not just me; but i’m me, as defined by my license, my 
> passport - and last time i checked a company doesn’t have a passport 
> or a drivers license ;)
>
> nite...
>
>
> On 10 Jun 2014, at 11:35 pm, Kingsley Idehen <kidehen@openlinksw.com 
> <mailto:kidehen@openlinksw.com>> wrote:
>
>> On 6/10/14 8:05 AM, Tim Holborn wrote:
>>> I wouldn’t worry about it too much.  I assume you’ve tested the demo?
>>
>> When I am presented with a dialog asking me to abdicate control of my 
>> identity via a 3rd party hosted identity card service and 
>> verification provider, I balk.
>>>
>>> Looks like a great URI Structure.
>>
>> What is a great URI structure? URIs denote things. HTTP URIs denote 
>> things in ways that unveil what they connote e.g., via the HTML 
>> rendered in the users browser.
>>
>>
>> My fundamental point is this:
>>
>> 1. mutual inclusion is good
>> 2. using open standards (actual or de facto)  is good
>> 3. decentralization is non negotiable -- nobody should be forced to 
>> abdicate self-hosting of identity credentials to a 3rd party (G+, 
>> Dropbox, OneDrive etc.. are options on the table for storage too, 
>> alongside other Read-Write HTTP servers).
>>
>> A solution that embraces the above, at its core, will be adopted at 
>> Web-scale. Alternatives will fail. Of that, I am 100% certain.
>>
>>
>> Kingsley
>>
>>>
>>> Timh.
>>> On 10 Jun 2014, at 10:00 pm, Kingsley Idehen <kidehen@openlinksw.com 
>>> <mailto:kidehen@openlinksw.com>> wrote:
>>>
>>>> On 6/10/14 12:25 AM, Manu Sporny wrote:
>>>>> TL;DR: There is now an open source demo of credential-based login
>>>>> for the Web. We think it’s better than Persona, WebID+TLS, and
>>>>> OpenID Connect. If we can build enough support for Identity
>>>>> Credentials over the next year, we’d like to standardize it via
>>>>> the W3C.
>>>>>
>>>>> This is a text-only version of the original blog post, which can 
>>>>> be found here:
>>>>>
>>>>> http://manu.sporny.org/2014/identity-credentials/
>>>>>
>>>>> Identity Credentials and Web Login
>>>>>
>>>>>   In a [1]previous blog post, I outlined the need for a better login
>>>>>   solution for the Web and why Mozilla Persona, WebID+TLS, and
>>>>>   OpenID Connect currently don’t address important use cases that
>>>>>   we’re considering in the Web Payments Community Group. The blog
>>>>>   post contained a proposal for a new login mechanism for the Web
>>>>>   that was simultaneously more decentralized, more extensible,
>>>>>   enabled a level playing field, and was more privacy-aware than the
>>>>>   previously mentioned solutions.
>>>> Manu,
>>>>
>>>> I've provided a comment on your blog post. At the same time, my 
>>>> history with Wordpress blogs is that comments are 100% guaranteed 
>>>> to make it to the public, for a variety of reasons. Anyway, since I 
>>>> want to express my opinions on this matter in public, here's a copy 
>>>> of what I pasted to your blog, in regards to your assertions about 
>>>> WebID-TLS:
>>>>
>>>> The World Wide Web is inherently architected to accommodate 
>>>> multiple ways of providing services driven by Linked Open Data 
>>>> (i.e., open standards based structured data) and HTTP URIs. I don't 
>>>> believe in OpenID vs Persona vs WebID-TLS vs OAuth etc. These 
>>>> authentication protocols can co-exist.
>>>>
>>>> In regards to WebID-TLS, you make the following assertion that I 
>>>> disagree with:
>>>> WebID+TLS also depends on the use of client-side certificates that 
>>>> are managed by the browser, which are difficult to use for most 
>>>> non-technologists.
>>>>
>>>> Issues with your assertions:
>>>>
>>>> [1] They are too generic -- dependency of Client Certification 
>>>> Authentication (CCA) isn't a bad thing bearing in mind only a 
>>>> minority of Browser (circa. 2104) have this problem.
>>>>
>>>> [2] Too subjective -- "difficult to use for most non-technologists" 
>>>> isn't a defensible position.
>>>>
>>>> The Client Certificate Authentication (CCA) Problem Status:
>>>>
>>>> As of the time of writing this reply, the only browsers with this 
>>>> problem i.e, an inability to disconnect and start new TLS sessions 
>>>> are as follows: Chrome and Opera. The aforementioned problem is no 
>>>> longer an issue across Firefox, Safari, and IE.  I can prove this 
>>>> with a simple WebID-TLS authentication service [1].
>>>>
>>>> I don't see how Opera and Chrome can continue to be deficient re. 
>>>> CCA bearing in mind the current state of implementations from IE, 
>>>> Safari, and Firefox. Thus, I wouldn't count on a fixable problem on 
>>>> the part of browser vendors as the basis for undermining a truly 
>>>> open solution for Identity Claims authentication such as WebID-TLS.
>>>>
>>>> End-users do not need programmers thinking or speaking for them. 
>>>> That's broken. What end-users need is the ability to control their 
>>>> identity and privacy online via solutions that leverage Web & 
>>>> Internet architecture such that the following are loosely coupled 
>>>> (no 3rd party .com, .org, .cc etc.. in the way):
>>>>
>>>> 1. Identity - perceived entity (actually nebulous since none of us 
>>>> can accurately claim full perception of the aspects of any entity)
>>>>
>>>> 2. Identifiers - HTTP URIs that denote Agents (no different to the 
>>>> role of a Passport Number, SSN, Credit Card Number etc..)
>>>>
>>>> 3. Identity Claims Documents -- Identity Cards or Profile Documents 
>>>> or Certificate (basically what your Passport, Driver's License, 
>>>> Credit Card, Club Membership Card etc.. provide)
>>>>
>>>> 4. Identity Claims Authentication Protocols -- variety of protocols 
>>>> that verify claims made in Identity Claims Documents
>>>>
>>>> 5. Protected Resource Access Authorization -- how verified 
>>>> Identities are tested against ACLs (Access Control Lists) or Data 
>>>> Access Policies (this may be Role Based [RBAC] or Attributed Based 
>>>> [ABAC]).
>>>>
>>>> Links:
>>>>
>>>> [1] http://id.myopenlink.net/ods/webid_demo.html -- WebID-TLS demo 
>>>> that proves TLS session login and logout can occur without 
>>>> restarting Safari (this is based on a timeout), Firefox (this uses 
>>>> crypto.logout), and IE (this uses the "new session" feature under 
>>>> the standard menu)
>>>>
>>>> [2] http://csrc.nist.gov/groups/SNS/rbac/ -- Role Based Access 
>>>> Control (RBAC)
>>>>
>>>> [3] http://csrc.nist.gov/projects/abac/ -- Attribute Based Access 
>>>> Control (ABAC).
>>>>
>>>> -- 
>>>>
>>>> Regards,
>>>>
>>>> Kingsley Idehen
>>>> Founder & CEO
>>>> OpenLink Software
>>>> Company Web: http://www.openlinksw.com
>>>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen 
>>>> <http://www.openlinksw.com/blog/%7Ekidehen>
>>>> Twitter Profile: https://twitter.com/kidehen
>>>> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
>>>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>> -- 
>>
>> Regards,
>>
>> Kingsley Idehen
>> Founder & CEO
>> OpenLink Software
>> Company Web: http://www.openlinksw.com
>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen 
>> <http://www.openlinksw.com/blog/%7Ekidehen>
>> Twitter Profile: https://twitter.com/kidehen
>> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>
>>
>>
>>
>>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen