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

Kingsley
>> [...]
>>
>>> 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/
>
>
>


-- 

Regards,

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:21:37 UTC