W3C home > Mailing lists > Public > public-webid@w3.org > September 2012

Re: Perceived issues with TLS Client Auth

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Thu, 27 Sep 2012 08:57:42 -0400
Message-ID: <50644D46.7090506@openlinksw.com>
To: Ben Laurie <benl@google.com>
CC: Henry Story <henry.story@bblfish.net>, Melvin Carvalho <melvincarvalho@gmail.com>, public-webid <public-webid@w3.org>
On 9/27/12 5:54 AM, Ben Laurie wrote:
>> Because the new certificate I received from my server, contains the same
>> >WebID as the old certificate. The public key changed (and so  the
>> >certificate too of course )  but the WebID remains the same:-)
> OK, but that still leaves open the question of how joe.name gets hold
> of this WebID in the first place.

I think you mean, how does the owner of joe.name lookup WebIDs to which 
ACLs apply. If my interpretation is correct, you've triangulated to the 
value of signed emails. Basically, I lookup WebIDs from signed emails. 
If that doesn't work, I use Linked Data lookups, SPARQL queries etc., to 
perform lookups across many of the data spaces at my disposal; many of 
which are vast in size and publicly accessible. In the absolute worst 
case,  an email, tweet, skype ping, IRC etc.. are all options for 
obtaining a WebID from some entity.

> Also for the WebID to remain the same, I have to remember what it is,
> right? If I visit joe.name and cannot log in because I have no cert, I
> have to somehow get a new cert issued with the right WebID (i.e. the
> one joe.name is expecting). How do I do that?
>> >So for a same id, what remains the same across each certificate, in whatever
>> >device it happens to be, is the Subject Alternative Name, the URI that
>> >refers to me: the WebID.
> Well, hang on. For that to be secure, either the WebID profile must be
> updated to include the new public key, or joe.name has to check that
> it comes from the same issuer, and believe that this issuer has a
> secure issuance policy.

No, the issuer policy isn't so important in this context. What matters 
is the proof of identity. Simple example, I want to share a photo with 
some old college buddies, there are many characteristics known to the 
group such as our nicknames, stuff we like and dislike etc.. All of 
these identity splices can be factored into an ACL based on WebIDs. 
Similar approaches apply to families, no issuance policy can match 
what's only known to the family :-)

They most important point here is that key and linked data graphs are 
composites. The resource owner determines access policies by leveraging 
a powerful graph at her/his/its disposal.




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

Received on Thursday, 27 September 2012 12:58:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:35 UTC