Re: Browser ID

On 7/16/11 3:16 AM, Ben Adida wrote:
> On 7/15/11 11:56 AM, Danny Ayers wrote:
>> Nice work Ben, but...
> Thanks Danny. It's a team effort, of course, I only joined Mozilla 3
> months ago.
>
>> Ok, email seems fine as a lowest common denominator, but that does
>> seem rather to neglect the huge advantage that the Web offers - a HTTP
>> URI can effectively provide any information you like (including email
>> address in, say, a FOAF or XFN profile).
> Three things:
>
> (a) I'm a big fan of linked data, but when it comes to the simple act of
> logging into a web site, I'm worried about what it means to force users
> to have a profile reachable publicly. That seems inherently at odds with
> privacy.

But everyone has a public profile courtesy of Twitter, Facebook, Google, 
Microsoft etc.. All of that before we get to FOAF.

Privacy is about self calibration of one's vulnerabilities. A sparse 
profile (structured document at an address) that basically boils down to 
delivering URI associated with a Public key (via a relation) where 
access occurs over TLS doesn't strike me as being at odds with privacy. 
Especially, when it doesn't even have to route this through a 3rd party 
service to work.

> (b) I don't think users think of themselves as URIs.

Nothing about WebID implies people see themselves as URIs.

People have Identifiers. They always had them, and now we have the 
ability to replicate what already exists in the new medium delivered by 
the InterWeb. A WebID is a Personal Identifier for a persona, bottom line.

>   OpenID basically
> proved this when they moved away from "people are URIs." Users do think
> of email addresses as handles for people.

I would say that mailto: URIs are more intuitive handles (identifiers) 
for people. HTTP URIs are less intuitive, but when dealing with the 
WebID protocol, http:, mailto:, acct:, ldap: all work fine, already. 
Irrespective of what scheme drives an X.509 cert hosted WebID, the 
identifier doesn't surface i.e., user doesn't have to know or remember 
zilch. The identifier is just a pointer mechanism in the WebID 
verification protocol. This is something that IdPs and Relying parties 
deal with rather than end-users.


> (c) every web site wants an email address from you so they can contact
> you. I need to guarantee that, when you log into a site with BrowserID,
> the site gets an email address.

mailto: scheme URI.
> Put (b) and (c) together, and that's why we chose email addresses as the
> right identifier.

As stated already, no problem with mailto: scheme URIs. They are 
prevalent and intuitive. They work!

Webfinger makes mailto: URIs resolvable.

All you have to do is have an implicit abstraction in your solution that 
allows implementations to leverage resolvable URIs, even if mailto: URIs 
are the preferred default option.

> (a) is the reason that, even if we could guarantee that every FOAF
> profile has an email address, I'm not sure a publicly reachable HTTP
> profile is the right approach for letting users just log in.

The IdP provides a data space for a user to achieve the following:

1. Make a Cert. that bears a  WebID and associated Private Key
2. Save the above to local keystore or browsers keystore -- all via 
keygen leaving the browsers implementation to determine final storage 
place ; if IE, the IdP can talk directly to Windows keystore (we already 
offer such a solution)
3. Persist a relation that associates X.509 cert's public key with a WebID.


>> So far I've barely glanced at the docs, but I get the impression that
>> the email address will be passed around in a little bundle of JSON.
> Correct.
>

Why can that just take the form of a resource where representation is 
negotiated? Remember, you can express relations in triple form using a 
variety of syntaxes. Your can serialize using a variety of formats. HTTP 
as a data access protocol is endowed with this capability.

>> while using URIs (including mailto:) would strike me as the neatest
>> approach, would it hurt to add another field for a profile URI?
> To the JSON assertion? We have plans of eventually adding means for web
> sites to discover additional information about you, but I'm not sure
> they would go in that initial assertion.

But you are veering off a track that's already in place. You are already 
heading into structured profile land (with or without FOAF). Nothing is 
an island which is why I am pushing for AWWW exploitation right now 
since it save future hassles. "Eventually adding means for sites to 
discover additional information about you.." == what FOAF and similar 
efforts are  all about, as you know anyway.

>> Whatever, some kind of convergence/compatibility between BrowserID and
>> WebID seems very desirable.
> Maybe. I'm still not sure I see the advantage. More in my response to
> Nathan shortly.
>
> -Ben
>


-- 

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 Saturday, 16 July 2011 16:14:18 UTC