W3C home > Mailing lists > Public > public-xg-webid@w3.org > July 2011

Re: The 3 stack layers of BrowserID and WebID

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Tue, 19 Jul 2011 20:22:45 +0100
Message-ID: <4E25D985.5080205@openlinksw.com>
To: WebID XG <public-xg-webid@w3.org>
CC: dev-identity@lists.mozilla.org, Ben Adida <ben@adida.net>
On 7/19/11 1:48 PM, Henry Story wrote:
> On 19 Jul 2011, at 04:56, Ben Adida wrote:
>>>> We have different requirements.
>>> Not sure we do.
>> At the very least we have different sub-requirements. You want to
>> leverage TLS client-side certs. We specifically don't.
> Good so this is a big misunderstanding - and a very understandable one 
> of course. WebID leverages TLS and X509 certificates because that is  
> what is available in all current browsers and because it works, not  
> because we love TLS or X509.  Mozilla labs can change the technologies 
> in one browser, so you can of course change what is available and so 
> change what WebId needs to run.
> I think it is important to distinguish the different layers of 
> technology  that are being used by the current BrowserId and the 
> current WebID, as I argued on stackexchange article comparing WebID 
> and BrowserID http://bit.ly/na7vsA
> a. Transport:             TLS            vs      unencrypted tcp/ip
> b. Cert formats:         X509            vs        signed JSON
> c. Auth method: Subject PK verification  vs    Issuer PK verification
>  From the above table we can see that WebID/foaf+ssl is described by 
> the first column of the table (X509, Subject PK verification) whereas 
> BrowserId is described by the second column of the table (Signed JSON, 
> Issuer PK verification).
> So that is where we are now. From that perspective it looks like both 
> protocols are like oil and vinegar: they can't mix -- even though they 
> are destined to always be mixed, and then be used to make a good 
> tasting salad. ;-)

Mixing depends on details of the email verification protocol. Basically, 
how they associate public keys and email addresses (maito: URIs).

> So consider each layer:
> a. Transport: Does WebID really require TLS (other than for securing 
> the transport)? Not really, what is required is that the browser sign 
> a token with the users private key and for that be the basis of the 
> verification of his identity.
> b. Cert formats:  WebId is designed at the semantic layer, not the 
> syntactic one. So we don't really care if a new certificate format 
> comes along. The same logic applies. So WebID can work very well with 
> signed JSON certificates too.
> c. Auth method: WebID was going to look at some point at issuer 
> certification verification. Now you have presented a good use case - 
> with the proof that you cared enough to implement something, not just 
> waffle about how useful it could be - we have something to work on.
> The point is that each element of the stack is orthogonal. Each auth 
> method can be used with either transport layer and with each 
> certification format. Furthermore the authentication methods can be 
> combined!

Yes, and this will happen (more than likely) if the email authentication 
protocol is clear about the relation that connects a mailto: scheme URI 
to a public key, ultimately this is the key to the matter. Even if they 
opt not to use or recommend Webfinger.

> So why am I really excited about the combination of layers currently 
> called BrowserId that you have developed? Well because first you 
> Mozilla *can* change those layers, and secondly you have shown that 
> adoption is then very quick: if services don't need to add TLS they 
> can add distributed identity in an instant. They are less secure than 
> if they did, but one must fight one micro battle at a time. [ So I am 
> assuming here that there are no blocking security issues in what you 
> have built ].
> Once this is seen, then I think you will understand that allowing us 
> to explore the WebID auth method as part of your experiment, will not 
> tie you into X509 or TLS. With a bit of thinking we should even be 
> able to work things out so that there is a base protocol that works 
> along the lines of what you have call it  - BrowserId 1 - and then a 
> way to enable extensions that would take advantage of WebID 
> authentication - WebId without TLS or X509 let me be very clear!

Yep too, but we'll see when the details re. mailto scheme and public key 
association are clear :-)



Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
Received on Tuesday, 19 July 2011 19:23:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:25 UTC