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

Re: WebID questions -- was: [dane] Call for Adoption: "Using Secure DNS to Associate Certificates with Domain Names For S/MIME"

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 26 Sep 2012 09:08:27 -0400
Message-ID: <5062FE4B.8030607@openlinksw.com>
To: Ben Laurie <benl@google.com>
CC: Henry Story <henry.story@bblfish.net>, "public-webid@w3.org" <public-webid@w3.org>, Andrei Sambra <andrei@fcns.eu>
On 9/26/12 5:30 AM, Ben Laurie wrote:
>> >The last thing I remember you stating is that authenticating with one ID across multiple sites is in your view a horrendous thing. Is that the fundamental problem?
> One of them. And not just my view - the view of many. Here's a
> presentation from a colleague that illustrates our thinking on the use
> of client certs for authn:
> http://tools.ietf.org/agenda/81/slides/tls-1.pdf.
If that's such a horrendous problem, and you don't want to mint a WebID 
per nym (pseudonym, aptonym, mononym etc..). what's the practical solution?

You have the option to export and import PKCS#12 documents, if you want 
to stick with a single WebID. You can repeat the Cert. generation loop 
using apps that trivialize Certificate generation circa. 2012.

Identity is a very abstract concept. A WebID is at best a condition 
splice of one's identity that's ultimately aligned to conditional 
resource access via constrained URI de-reference. I can operate 
confidently as 'Peter Parker' of 'Spiderman' without compromising these 
identities, via WebID (verifiable agent identifiers), the WebID 
protocol, and Linked Data resources. The only limit is our imagination.



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 Wednesday, 26 September 2012 13:08:50 UTC

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