- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 27 Sep 2012 08:57:42 -0400
- To: Ben Laurie <benl@google.com>
- CC: Henry Story <henry.story@bblfish.net>, Melvin Carvalho <melvincarvalho@gmail.com>, public-webid <public-webid@w3.org>
- Message-ID: <50644D46.7090506@openlinksw.com>
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. > -- Regards, 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 27 September 2012 12:58:09 UTC