W3C home > Mailing lists > Public > public-identity@w3.org > October 2011

Re: future of Identity on the Web

From: Henry Story <henry.story@bblfish.net>
Date: Wed, 26 Oct 2011 21:26:54 +0200
Cc: Harry Halpin <hhalpin@w3.org>, Edward O'Connor <eoconnor@apple.com>, public-identity@w3.org, WebID Incubator Group WG <public-xg-webid@w3.org>, Tim Berners-Lee <timbl@w3.org>
Message-Id: <A79BB511-7238-4CB2-87A3-BA6B9949C752@bblfish.net>
To: nathan@webr3.org

On 26 Oct 2011, at 20:33, Nathan wrote:

> Henry Story wrote:
>> On 26 Oct 2011, at 18:23, Harry Halpin wrote:
>>> Henry,
>>> 
>>> Just to be clear - as per the results of the workshop, WebID is itself
>>> currently out-of-scope for this WG.
>> Harry from your previous e-mail it is clear that you don't master the subject about WebID and how it functions. You are therefore in no position to say whether it is or not in scope.  
> 
> Perhaps if it's stated that the web-identity charter is complementary, rather than competing.
> 
> To me at least, standardization of WebID is clearly far out of charter for the web-identity wg, and always will be. However as they are complimentary, I'm sure that WebID will benefit exponentially from any APIs produced by the web-identity group (I'm already most looking forward to seeing and using what is produced), and similarly I doubt they'd be possible to define properly without thoroughly considering the needs of both WebID and the Read-Write Web.
> 
> Thus, just what is the issue? I really can't see one.

I agree there is not much of an issue.  Here are those I see:

1. Calling it Web Identity makes it difficult for the WebID XG to explain what it is doing, and is going to be confusing. Suggestions:

  a. the group could be called cryptography apis, then it would be closer to what it wants to do and there is no problem
  b. grow the charter to allow WebID in, by for example opening a 4th section on how to go from public key identity gained through cryptography to a WebID through claims made in a certificate: then it is also about identity, and would give a space for BrowserId and WebID to cooperate. BrowserId does this using Issuer Ids, WebID does that using Subject Alternative names, but there is something here we can work on together.
  c. browserid depends on a way to tie a domain to a public key. I suggest this could be done using DNSsec, perhaps we could discuss this, and add some information of this to the WebID spec.

2. There are places in the cryptography API where WebID has some direct interest. For example BrowserId needs to be able to send certificates to the server. Questions that would be useful would be to know how legacy X509 certificates and BrowserId JSON based certificates can by synchronised, so that legacy TLS can be used with the same public keys. That is until TLS upgrades to JSON certificates, which I think it could legally do (one should check).


I agree with Nathan, that if javascript APIs can be developed securely, then that would give WebIDs all the more value.

Btw, I also would like to invite people who think that WebID has issues - be they big or small - to voice them. I think we can answer your questions and we can also improve the spec by doing so. It may be that the spec needs re-rewriting in depth.


Henry

> 
> Best,
> 
> Nathan
> 

Social Web Architect
http://bblfish.net/
Received on Wednesday, 26 October 2011 19:27:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 26 October 2011 19:27:30 GMT