Re: The 3 stack layers of BrowserID and WebID

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


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen