W3C home > Mailing lists > Public > public-webpayments@w3.org > June 2014

Re: Proof of Concept: Identity Credentials Login

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Tue, 10 Jun 2014 15:42:17 +0200
Message-ID: <CAKaEYhJcGfkC1EUkTPbWejynRBMiqEk0p0GbrhvR6VQTt8E4pQ@mail.gmail.com>
To: Kingsley Idehen <kidehen@openlinksw.com>
Cc: Web Payments <public-webpayments@w3.org>
On 10 June 2014 15:35, Kingsley Idehen <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.
>

+1


>
>
> Kingsley
>
>
>
>> Timh.
>> On 10 Jun 2014, at 10:00 pm, Kingsley Idehen <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
>>> 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
>
>
>
>
>
>
Received on Tuesday, 10 June 2014 13:42:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:31 UTC