Re: Draft Web Identity Working Group Charter for Discussion

I also think there is a problem in the title of this working group. 

WebID which is a working group and even has a spec

  http://www.w3.org/2005/Incubator/webid/spec/

already does Identity on the Web, using already standard protocols and formats.  It is not complete - nothing can be  - but it works now. So to have a Working group be called Web Identity is clearly going to be confusing. As far as I can see this is not a group about Web Identity but rather a working group to put in place enablers for certain types of web identity protocols. Especially ones such as BrowserId, which I have argued is in fact compatible with the WebID philosophy.

  It seems to me furthermore that the three components you put together in this working group Cryptography API, Identity Sync, and Identity API are three very different projects that could each have its own working group. Let's look at them in turn: 

 •1 Cryptography API: This could well be a good thing, but is a lot of work just by itself, and has a lot of issues of which a few were brought up in the public-identity mailing list recently [2]. Doing this right and well is going to be a lot of work by itself.  
   Such an API would be useful for BrowserID, which I believe is compatible with WebID as stated above and argued in detail on Stack Exchange [1]. So there is no need to tie a cryptography API to one particular way of developing security.

 •2 Web Identity Sync: Well synchronising profiles across multiple browsers is quite easy: you use HTTP PUT to put your profile on a server and HTTP GET to fetch it from a different browser. So you want to encrypt the data before putting it out on the blog in the cloud? Ok, but that could and should be its own working group, as encrypting stuff is not going to be limited to identity profiles.

 •3 Identity API: If BrowserId or BrowserAuth wish to come to the W3C to use the javascript APIs developed in 1 to develop their protocol then that is fine. But that can be done in parallel in a different group. It would be interesting for BrowserId and WebID to work together, which is quite possible as argued in [1]
( Note that since BrowserId uses an e-mail identifier it already looses the anonymity that is set out as an aim in •2 ) The advantage of BrowserId over WebID is essentially that authentication could happen without web sites needing to deploy TLS. Of course that reduces security very seriously at the same time, but it could be useful way to help bring more people over. 

  So by splitting the work up, one could perhaps go faster, and one would not try to impose an initial prejudice on what a whole identity stack should look like.

	Henry
  

[1] http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid
[2] http://lists.w3.org/Archives/Public/public-identity/2011Sep/0007.html

On 18 Oct 2011, at 19:53, Harry Halpin wrote:

> Everyone,
> 
> While its still not fully baked, we'd like to open the discussion on the
> list over this draft charter for a "Web Identity" Working Group:
> 
> http://www.w3.org/2011/08/webidentity-charter.html
> 
> Everything is fair game - I'm not quite comfortable even with the Working
> Group name. Also, there are issues of how we should scope this, whether or
> not we should split the work into two WGs (one for a Crypto API and
> another for a higher-level identity API and hooks for device/browser-aware
> authentication) or stick it in one WG - and of course relations to other
> standards bodies.
> 
> Also, if any of you are near Silicon Valley we can discuss this in person
> at the W3C Technical Plenary on Nov 1st. I'll send that email out in one
> sec..
> 
> And if anyone is at Internet Identity Workshop I'm here to discuss the
> charter.
> 
>  cheers,
>        harry
> 
> 

Social Web Architect
http://bblfish.net/

Received on Thursday, 20 October 2011 14:01:56 UTC