W3C home > Mailing lists > Public > public-webid@w3.org > May 2014

Re: Releasing RWW.IO

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Mon, 05 May 2014 09:33:53 -0400
Message-ID: <53679341.7000901@openlinksw.com>
To: public-webid@w3.org
On 5/5/14 8:55 AM, Tim Holborn wrote:
>
> Firstly,
>
> It’s taken several years to develop WebID already. Whilst new 
> solutions may exist, i’m not sure what existed at the time…

No, it has taken years to establish the fact that an HTTP URI can denote 
an Agent. That's fundamental to the actual architecture of the World 
Wide Web.

WebID was simply introduced (term wise) as a conflation of identity, 
identity card, and authentication protocol. That marketing and 
architecture related bug has been fixed in the recent specs.

>
> Perhaps the capacity for the WebID spec to accept/consider 
> alternatives to WebID-TLS could be considered. 

WebID doesn't mandate anything, bar the use of an HTTP URI to denote an 
Agent.

The WebID-TLS protocol is a totally different thing that's loosely 
associated with a WebID i.e., an open protocol for authenticating 
identity claims constructed around an WebID.

>  Additionally, perhaps the WebID Spec could also include a WebID 
> ontology, which can enhance what can currently be referenced as a 
> holder of credentials beyond the capabilities of FOAF specifically.

The WebID-TLS protocol does include an ontology.

>
> In considering the mail on this topic of late (not just in the WebID 
> Community) I see two issues.
>
> 1. The WebID ontological reference points at FOAF specifically.  I 
> think perhaps this might best be considered by looking at a WebID 
> Ontology (that can then include both ‘things’, ‘agents’ and ‘legal 
> entities’, using different ontologies if needed, and a set of terms 
> that cater for the needs of WebID Specifically, as a specification).

A WebID doesn't need to resolve to a FOAF document.

The WebID-TLS protocol is based on an ontology and it will look for 
relations defined by said ontology en route to authenticating identity 
claims gleaned from identity cards/ profile documents.

>
> 2. The AUTH method should probably specify the requirements in 
> relation to an AUTH standard.  Whether that’s specifically TLS, i 
> think isn’t what the spec actually attempts to accomplish - other than 
> having some sort of solution available…

I believe that's what WebID-TLS does.

>
> I’ve spent some time today reviewing the U2F solution [1,2,3]
>
> Obviously, as is exhibited on the list - the ever passionate Anders, 
> has as a solution [4] he is particularly interested in progressing, 
> and honestly - it looks like an enormous piece of work, so to me, i 
> wonder how we can help him conform to a standard, rather than having 
> an isolated approach.  so long as methods conform to a standard, isn’t 
> that what we’re seeking to achieve?
>
> Then a company i’ve had some knowledge of for sometime just obtained 
> some press for a different type of proprietary standard [5] and; 
> whilst the KYC elements (which [5] also caters for) have an array of 
> other issues, it appears even within web-payments group - their 
> “identity credentials” spec [6] has an array of related requirements, 
> which should ideally be served through WebID specifications (whether 
> complimentary or standalone).
>
> ISSUES:
>
> 1. Perhaps if this form of concept were adopted, we might end-up with 
> services that understand one type of authentication and the WebID 
> doesn’t support that particular form of identification.
> 2. Perhaps some forms of Authentication are better than others. 
>  Perhaps issues come-up and some means of notifying users is 
> beneficial, around how to resolve any such new issues (heartbleed[7] 
> bug for example)
> 3. Perhaps some authentication methods might comply with the standard, 
> but be proprietary.
>
> <rant>As of a few(?) months ago (even quite some time earlier, first 
> testing with ODS in-fact), the functionality of WebID in terms of 
> Cimba.co <http://Cimba.co>, rww.io, data.fm, webcredits.org 
> <http://webcredits.org> and other related works has shown me a 
> functional AUTH / ID capability that i’m finding quite useful for dev, 
> and consistent with objectives outlined, discussed and broadly 
> collaboratively working upon for sometime.   I do not see the benefit 
> of simply putting the WebID/WebID-TLS function - down to the act of 
> providing a URI - the AUTH association is important IMHO - however, i 
> do see room for development and improvement, and perhaps ontologically 
> providing room for alternatives might be the answer, not sure. 
>  Perhaps most noticeably, i see that people seem frustrated with the 
> specificity of the specification, and perhaps that is what could use 
> some work.


The specifications need to be more emphatic, via supplementary 
narratives in regards to clarifying the loose coupling of:

1. WebID -- for denotation
2. WebID-Profile Documements -- for profile representation
3. WebID-TLS for authenticating identity claims.


Kingsley

> I think most people agree that the concept of a distributed 
> authentication and identity solution is required, and i’m relatively 
> sure no-one has a particular issue with WebID as a term, or an 
> underlying initiative and undertaking to achieve something, that 
> people seem to understand, but disagree about the technicalities of 
> how its achieved.  the approach i’ve suggested attempts to provide a 
> practical solution, that might be capable of providing the necessary 
> flexibility required by interested parties. </rant>
>
> That’s all for now.  it’s taken a while to churn through this 
> diligently, and i’m still going.  “in good faith"
>
> Timh.
>
> [1] https://sites.google.com/site/oauthgoog/gnubby
> [2] https://fidoalliance.org
> [3] https://github.com/Yubico/python-u2flib-server
> [4] http://webpki.org/papers/PKI/webauth.pdf
> [5] 
> http://www.smh.com.au/it-pro/business-it/australian-online-security-startup-wins-singapore-backing-20140505-zr4ow.html 
>
> [6] https://web-payments.org/specs/source/identity-credentials/
> [7] http://heartbleed.com/
>
> On 5 May 2014, at 10:13 pm, Kingsley Idehen <kidehen@openlinksw.com 
> <mailto:kidehen@openlinksw.com>> wrote:
>
>> On 5/4/14 11:39 PM, Tim Holborn wrote:
>>>
>>> On 5 May 2014, at 7:29 am, Kingsley Idehen <kidehen@openlinksw.com 
>>> <mailto:kidehen@openlinksw.com>> wrote:
>>>
>>>> On 5/3/14 7:42 AM, Anders Rundgren wrote:
>>>>> On 2014-05-03 13:19, Melvin Carvalho wrote:
>>>>>>
>>>>>>
>>>>>> On 3 May 2014 10:08, Anders Rundgren 
>>>>>> <anders.rundgren.net@gmail.com 
>>>>>> <mailto:anders.rundgren.net@gmail.com> 
>>>>>> <mailto:anders.rundgren.net@gmail.com>> wrote:
>>>>>>
>>>>>>     Now I have tried it out as well including the micro-blogging.
>>>>>>
>>>>>>
>>>>>> Awesome.  I typed your name "A n d e r" into the channel finder 
>>>>>> and your webid came up after about 3 letters.  I'm now following you.
>>>>>>
>>>>>>     It was cool with one exception, TLS CCA (Client Certificate 
>>>>>> Authentication)
>>>>>>
>>>>>>     Logging in to http://cimba.co <http://cimba.co/> required me 
>>>>>> to select certificate twice and
>>>>>>     from a pretty long list of non-WebID certificates.
>>>>>>
>>>>>>     Unless W3C gets their act together and creates a 
>>>>>> web-compliant replacement
>>>>>>     for TLS CCA, WebID won't ever catch on.  I have no faith in 
>>>>>> W3C for taking
>>>>>>     any action on this since not even the requirements have ever 
>>>>>> been discussed.
>>>>>>     TLS is a sacred cow.
>>>>>>
>>>>>>
>>>>>> I think there's a slight distinction between WebID and WebID+TLS.
>>>>>>
>>>>>> WebID itself is independent of the auth mechanism.
>>>>> Yes, this enhancement was introduced as a "workaround".
>>>>
>>>> Not a workaround, a point of fundamental clarity.
>>>>
>>>> Conflating things never works. WebID as the moniker for WebID-TLS 
>>>> protocol was a piece of poor marketing and technology evangelism. 
>>>> This bug has been fixed, and we just need to make this crystal 
>>>> clear to everyone.
>>>>
>>>
>>> WebID-TLS was the single most important entry-point to my work with 
>>> W3 Community groups - through a rather significant amount of time 
>>> with Henry Story helping me get my head around the basics of the 
>>> groups, no-less…
>>>
>>> Not suggesting my ’linked-data’ story doesn’t go back further than 
>>> that - started in 2000 - but i saw the merit in the practical 
>>> solution WebID-TLS Provided then, and i still do now.  If there are 
>>> alternatives, i think we should encourage them also.
>>
>> Yes, WebID-TLS is one of many authentication protocols. My point is 
>> that we don't conflate that with WebID (an HTTP URI that denotes an 
>> Agent).
>>
>> Separating Identity, Identification, and authentication is vital, 
>> otherwise all efforts will remain susceptible to all the confusion 
>> that arises from concerns conflation. In my experience, confusion is 
>> the biggest impediment adoption as it makes concept comprehension 
>> artificially difficult.
>>
>>
>>>
>>>
>>>> A WebID is simply an HTTP URI that denotes an Agent. That's it.
>>>>
>>>
>>> i think that’s certainly an interpretation - but not the only one 
>>> that’s dictated by technology eco-systems, yet, perhaps…
>>
>> It isn't an interpretation, that's the definition in the spec.
>>
>> WebID != WebID-TLS .
>>
>>>
>>> Web of Trust is an important element to many meritorious concepts - 
>>> i see the work carried out within WebID as an important constituent 
>>> of this undertaking, still in its infancy.
>>>
>>> IMHO
>>>
>> Building a Web of Trust requires loose coupling of:
>>
>> 1. identity -- this is denotation comes into play
>>
>> 2. identification -- handled by documents comprised of verifiable 
>> identity claims (represented using entity relationship statements 
>> endowed with human and machine discernible entity relation semantics)
>>
>> 3. authentication -- actual protocols used to verify identity claims.
>>
>>
>> Kingsley
>>
>>>>
>>>>>
>>>>>> One hope was that mozilla labs would help with the UX, as below.
>>>>>>
>>>>>> http://www.azarask.in/blog/post/identity-in-the-browser-firefox/<http://www.azarask.in/blog/post/identity-in-the-browser-firefox/>
>>>>> That's where it gets wrong, there is no UX problem to solve. It is the
>>>>> underpinning TLS CCA scheme that is the sole culprit which is why 
>>>>> Google,
>>>>> Microsoft, Paypal, RSA, ARM (!), etc. abandoned it in favor of U2F.
>>>>
>>>> Yes, and all this really means is simply this: incorporate as much 
>>>> of WebID-TLS into U2F as possible. That's what we will do, as our 
>>>> natural instinct, at OpenLink Software.
>>>>
>>>>
>>>>>
>>>>> Your best option at this stage is probably defining a WebID-U2F 
>>>>> profile.
>>>>
>>>> Yep! As per my comments above.
>>>>>
>>>>> Personally, I'm not overly interested in U2F, it is much simpler 
>>>>> making
>>>>> client-side X.509 "web-compatible" by building on the already 
>>>>> established
>>>>> schemes out there.
>>>>
>>>> Yes, but that's a problem due to the manner in which Browsers have 
>>>> been implemented and the impossible politics that swirls around 
>>>> getting them to fix this flaw.
>>>>
>>>>
>>>> Kingsley
>>>>>
>>>>> Anders
>>>>>
>>>>>>
>>>>>>     Fortunately Google hadn't any problems slaughtering this poor 
>>>>>> creature
>>>>>>     when they started their U2F project which have created a hype 
>>>>>> I haven't
>>>>>>     seen before during my 15Y+ in the "id-business".  It didn't 
>>>>>> take an
>>>>>>     eternity either.
>>>>>>
>>>>>>     Anders
>>>>>>     grumpy old fart with a mission
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Regards,
>>>>
>>>> Kingsley Idehen
>>>> Founder & CEO
>>>> OpenLink Software
>>>> Company Web:http://www.openlinksw.com <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
>>
>>
>>
>>
>


-- 

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 Monday, 5 May 2014 13:34:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:55 UTC