Re: [keyassure] WebID at W3C and keyassure

[Henry Story <[e-mail]>]

John Gilmore rightly pointed out that I was not clear in my mail to the list, so I answered his questions in more detail below.

On 10 Feb 2011, at 21:17, John Gilmore wrote:

>> Where keyassure is attempting to identify a server using uniquely
>> identifying information in the DNS, WebID is identifying an end
>> user (human, robot or agency), via a profile document containing
>> cryptographically uniquely identifying information placed in the
>> web.
> 
> I understand this.
> 
>> Keyassure coul probably use the dns typed subject
>> alternative name to identify the verify X509 certifactes, WebID
>> uses the SAN (and IAN) with https IDs to identify the agent. We
>> are both using canonical referential lookups to get the meaning
>> of a name (Domain Name with keyassure, HTTP+TLS with WebID) which
>> we can then use to prove referential integrity (authentication).
> 
> This is so much gobbledygook to me.  Can you explain in English?

Ok, sorry I did type that a bit too quickly yesterday, and it would have done with a  bit more editing before pressing the send button. Let me just rewrite this with spelling mistakes fixed and in less terse style.

Also here is a quick UML Sequence diagram for how this works
     http://www.w3.org/wiki/Foaf%2Bssl#How_does_it_work.3F

So let me try again:

Keyassure will probably use the DNS-ID typed subject alternative name (SAN) or Issuer Alternative Name (IAN) in a *server* X509 certifactes to identify the server as suggested is good practice by 
http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14#section-2.3

WebID uses the SAN (and IAN) with https IDs to identify the agent of a *client* certificate.

We are both using canonical referential lookups to get the meaning of a name. In the  case of keyassure the name is a domain name. The canonical way to look up the meaning of a domain name is to look in the DNS. The canoncial way to look up the meaning of an ftp:// URL (think of a URL as a name) is to use the ftp protocol. So the canoncial way to look up an http or https URL is to use HTTP+TLS, which is what WebID does.

So if I understand correctly, in the future a browser will be able to verify from DNSSEC that a self signed server certificate is indeed able to authenticate the server.

> 
> I see zero point in working on this WebID thing if the actual goal is
> to actually identify me on the web.

You should of course have a choice to authenticate or be anonymous. Web Browsers should show you with what identity you have authenticated and allow you to logout in one click. If we can get together on issues like this to put some pressure on browser vendors, I'd be happy to help. I know of a few security holes that really need some external pressure.

>  I don't want the vast majority of web sites to be able to identify me on the web -- and I think this goal is shared by a large, possibly majority, fraction of web users.

Yes, you should be anonymous by default. 

> To the extent that "WebID" becomes standard, if it makes it easier for
> websites to demand that people "identify themselves" before
> "publishing" information (publishing = distributing "to the public",
> not to individual identified people), then it will be destructive of
> the kind of Web that I want to continue to exist.  I want ordinary
> un-identified people and browsers to continue to have broad access to
> everything published on the web.  I refuse to use sites like the New
> York Times that demand that I login "to a free account" merely so they
> can track what I'm reading.

It is going to be very easy to create a WebID: one click of a button. And you can have as many as you want, on as many sites as you want. It should be easy to create throw away webids too. There is no need to go to any government agency, no need to prove anything. WebIDs are built to enable a web of trust. But you don't need to participate in a web of trust, and if you do, you don't need to reveal it to anyone else than those you trust.

> To the extent that "WebID" makes it harder for people to use a
> different pseudonym with each current website that "demands"
> identifying information, it will be destructive.

WebID allows you to authenticate on sites in a very decentralised way. You can have any number of IDs and place them wherever you want. So it is not restrictive. 

> To the extent that "WebID" makes it impossible for sites like
> bugmenot.com or mailinator.com to exist and function well, it will be
> destructive.

They could provide temporal WebIDs as an additional service, without problem.

> 
> To the extent that "WebID" works like "OpenID", it will never catch on
> anyway.

The extent to which it is different to OpenID is detailed here
http://www.w3.org/wiki/Foaf%2Bssl/FAQ#OpenID_failed.2C_do_people_really_want_distributed_identity.3F

From the user perspective it is a lot easier to use.


>  I use OpenID with exactly one site, because they demand it and
> offer no alternative.  And it's incredibly cumbersome, harder than just
> logging in like other sites require.

Yes, WebID is point and click. No typing. See the short video I put together here
http://bblfish.net/

> 
> Now if somebody at W3C actually automated bugmenot.com in a new
> protocol, so that ordinary people could just set their web browser to
> pretend to be randomly generated other people on sites that demand
> their identities, I'd be much more interested in it.  

It would be very easy to do. You can get yourself a WebID at 
http://foaf.me/ in a few clicks. The UI should definitively be improved. 

> But after
> a brief look at:
> 
>  http://www.w3.org/2005/Incubator/webid/spec/
> 
> that doesn't seem at all to be what's happening.  Instead it's more
> totalitarian bullshit wrapped in X.509 encoding.

It's certainly not. (Perhaps it's a good thing that it looks like that, ...)

Anyway, what in particular makes you think that in the wording or presentation? We are working on the spec. 

Btw. has this group got a draft spec I could look at?

Henry Story


> 
> 	John Gilmore

Social Web Architect
http://bblfish.net/