The 3 stack layers of BrowserID and WebID

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. ;-)

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! 

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! 

> 
> [...]
> 
>> Well WebId does not have any notion of longer or shorter lived keys.
>> The certificate says how long they are valid for, full stop. They can 
>> be longer or shorter.
> 
> Right. We want to specifically rule out longer-lived certs for our
> application, because otherwise we have to build in revocation. Now, of
> course our data formats don't rule it out. But our logic certainly will
> for the time being.

Ok, so it would be nice if the base logic ruled it out for people who only
have an e-mail address in their certificate, but for servers that understood
the point of the WebID in the JSON certificate, that those could work with longer
lasting certificates. 

At least this would allow us to experiment with some interesting ideas 
there too.

> 
>> Well yes, that ok. But you do seem to empasize the non-collaboration all
>> the time.
> 
> Because I'm hearing comments that sound like "obviously we should
> collaborate." It's not obvious, and in fact it may hurt both efforts.
> There are a dozen ways of slicing the authentication pie. We're trying
> one way, and we want to see how far it goes before we complicate.

agree, I am also very keen to keep WebID simple. (I don't really fancy
writing specs that much)

I think there are two things that are imporant in a discussion we
can have:

 1. to make sure we are extensible
 2. to allow us to explore what could be done with the webid auth method. 
    We can then build some demos that use the JSON certificate format that
   tie into webids.


> 
>> Could it also be the other way around that we should perhaps also
>> accept the conclusion that we might benefit from collaboration, were it to
>> be justified?
> 
> Of course, but so far I'm seeing lots of conflicting approaches.

The only piece we are looking for is to be able to add a WebID in the JSON
and experiment with that on the Relying Party side. I think the Browser part
would be exactly the same.

> 
>> What are the different sets of requirements?
> 
> We can start with the two very important ones:
> 
> (a) we think TLS is wrong for RPs, you think it should be leveraged.

  We have leveraged it because that is all we have available. But we 
are happy to use other tools that lead us to the same place. 

> (b) we think relying parties should always get an email address (or at
> least we're not trying to address the use cases where they don't need
> one), you think it's optional.

yes, but we can work with the use case where they get an e-mail and get WebID 
benefits.  It's a simple relation after all between the two

   <http://bblfish.net/#hjs> --- mailbox ---> <mailto:henry.story@bblfish.net>

I completely agree that e-mail identifiers are widely understood and are the
right thing to show people when asking them to choose a identity.

So I hope this helps reduce the understandable confusion. When we described WebID
we could have described it in very abstract terms without making reference to any
technology. We even have an open issue for that ISSUE-42 also known as "the meaning of life".
But I think it is better to be practical, and to generalise as the need arises. So
I am very much with you as far as simplicity goes. But it is worth allowing people 
to explore the next stage of where you will be wanting to go, and that need not be
that complex a place as is thought.

Henry


> 
> -Ben


Social Web Architect
http://bblfish.net/

Received on Tuesday, 19 July 2011 12:49:01 UTC