Re: Releasing RWW.IO

Firstly, 

It’s taken several years to develop WebID already. Whilst new solutions may exist, i’m not sure what existed at the time… 

Perhaps the capacity for the WebID spec to accept/consider alternatives to WebID-TLS could be considered.  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. 

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).

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’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, rww.io, data.fm, 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.  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> wrote:

> On 5/4/14 11:39 PM, Tim Holborn wrote:
>> 
>> On 5 May 2014, at 7:29 am, Kingsley Idehen <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>> 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 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
>>> 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
> 
> 
> 
>