Re: Browser ID, WebID & URLs

On 19 Jul 2011, at 04:56, Ben Adida wrote:

> On 7/17/11 9:37 PM, Henry Story wrote:
>> 
>> The goal of both is to have global and distributed authentication. As 
>> far as that goes the goals are the same. 
> 
> Right, the difference is that we're trying to start with the simplest
> layer, you're trying to build the distributed social network up front.

I am trying to design it so that I can build the distributed social network afterwards. The distributed social network is not part of the WebID specification. You will see that here: http://webid.info/spec/ -- there is no mention of foaf there or anything else.

>> Btw. for BrowserId to function in a distributed way it will require browser 
>> support, right? Or can it already function that way?
> 
> To be *truly* distributed, it will require browser support. But it will
> be pretty close to fully distributed with just browserid.org as a
> passthrough domain for certificates.
> 
>> There is a problem with javascript being able to access only one site at a 
>> time if I understand correctly.
> 
> Right, but with postMessage() and browserid.org doing coordination,
> we're in good shape. Also, the relying parties will *not* have to change
> their code to inherit browser support. The JS library turns itself off
> once it detects that the browser natively supports the API.

So currently centralised, but no API change needed to decentralise. ok.


>> I am all for keeping things simple, btw. But this is a big browser change that
>> it being put through, with security implications, and so I imagine that being
>> able to enable one more use case may be a good thing for adoption.
> 
> Actually, it's exactly the opposite. Simple, targeted changes are *much*
> easier to deploy than larger changes with bigger attack surfaces.
> 
>>> User profiles are great, but I don't think they should be required,
>> 
>> They are not required in WebId. 
> 
> Hmmm, don't you have to have a public URI? Isn't that what Kingsley was
> saying?

If you mean by profile, anything with additional information above the relation
of the public key to the id, then no: no such additional information is required.

Otherwise I could claim that BrowserId also makes such information available since
a service could be built that relates an e-mail address to a person private life.

> 
>> Services that don't control the e-mail, such a Social Web services - including
>> Facebook, and others - won't find this very helpful then.
> 
> Ah, because you're thinking that we want Facebook to certify your
> bblfish.net address. That's not really it. Facebook is already doing
> email. You can claim your @facebook.com email address now. So we hope
> that Facebook will eventually certify their users for @facebook.com,
> over which they, of course, have authority.

But what about other services that are not so gargantuan that they can offer
anything and everything. Take even large services such as Identi.ca, for example. 
Why should they have to provide e-mail as a service in order to provide an identity
for a user? E-mail is well known to be very problematic in many ways.
Spam is rampant: I heard that 99% of mail is spam. It is mostly sent in plain text
ready for all to read. And it is channeled around different servers on the internet,
visible to a lot more people that the intended recipient and sender. 

e-mail is such an issue that many businesses - who don't hesitate to run their own web 
site - outsource it to Google.  So that basing yourself on e-mail is not going
to be very appealing to social networking services.

Luckily if we get together that we can cover those use cases too. And I don't think
that this need come at a large cost in complexity. It could even be done in such
a way as to be something that can be selected for: if a Relying Party does not want
to have WebID addition, it could request certificates that don't offer that as an option.

>> sending e-mail addresses out can be a spam problem.
> 
> Users are sharing email addresses with web sites *anyways*.

but should they have to do this with each one they want to try out some fun gadget with?

> 
>> A URL which verifies
>> a public key and has a bit of optional metadata - name for example - allows
>> protection from that type of spam.
> 
> Ah, so now we're back to a public profile?

That information is completely optional. It could consist of just one link for example
to a form where someone can POST a comment - the equivalent of e-mail but done in a
webby way.

> 
>> It is not a baseline to WebID either. It just enables it. 
> 
> Now I'm really confused. Is there a public URI or not?

There is a public URL, but it need contain no more information than the public key.

> 
>> You seem to have made short lasting keys a necessary part of your protocol.
>> Why is that? I am pointing out one can enable longer lasting ones too.
> 
> Because long-lasting keys require adding revocation to the protocol, and
> we don't want to go there because it's gnarly.

It is not gnarly with WebId. Of course if you ignore WebID then you loose revocation, 
and things seem gnarly. A lot of things will seem complicated if you decide
a priori to ignore the easy solutions to them.

> 
>> I don't think it says anywhere that BrowserId is not meant to have browser support.
>> It just says that implementing security correctly is  a lot of work and that the TLS
>> layer in the browser has been there for a while. So BrowserID support in the browser will
>> have to be implemented very carefully.
> 
> Which is why we're keeping things extremely simple for now.
> 
> We don't think we can effectively reuse TLS while meeting our
> requirement that relying parties should have a very easy job.

Who says you need to re-use TLS? What I like about BrowserID
is that you don't use TLS or X509 certificates, and yet you are doing 
what WebID is all about! The fact that WebId has been using TLS and X509
certificates is because that is what works in all browsers now. We
did not  want to go and change the browsers themselves. If Mozilla
decides to change the browser then of course new things become possible.

I'll send the response to the next part of your mail in another
install, as this is getting a bit long. Also this distinction between BrowserId and
WebID is what is causing a lot of misunderstanding.

Henry

Social Web Architect
http://bblfish.net/

Received on Tuesday, 19 July 2011 11:38:15 UTC