WebID XG Meeting: back to spec writing

Last meeting we decided to have meetings every two weeks again, as the weekly meeting schedule was just too hectic. I had trouble myself keeping up. Here are the minutes

   http://www.w3.org/2011/10/17-webid-minutes.html

The next meeting should be on Monday 31st October at the usual time of 15UTC

Time: 1500 UTC
W3C Zakim bridge, telecon code: WEBID (93243)
SIP: zakim@voip.w3.org
Phone US: +1.617.761.6200
Phone UK: +44.203.318.0479
Phone FR: +33.4.26.46.79.03
irc://irc.w3.org:6665/#webid
Duration: 60 minutes

next meeting
http://www.timeanddate.com/worldclock/fixedtime.html?month=10&day=31&year=2011&hour=15&min=00&sec=0&p1=0

Recent discussions have brought us some useful feedback. Especially a mail by Edward O'Connor [1] where he brings up an couple of issues that Brad Hill had brought up before.
   
  I think we can answer them easily, but it is very likely that we could make these clear in our specification http://webid.info/spec/

  1. There is the issue that the TLS handshake needs to be interrupted
  
    It does not. But we could make this clear in 
    http://www.w3.org/2005/Incubator/webid/spec/#initiating-a-tls-connection
    
    In an e-mail exchange with TimBl Harry even pointed to that part to substantiate his position.
    Does anyone wish to propose some text for this?

 2. There is an underlying issue of the problems of relying on the WebID servers, to fetch the public key. We can make clear a number of ways of dealing with this

     - we need to re-emphasise the caches and caching architecture
     - We could add Issuer logic. So that if we trust the issuer of the certificate and we know his public key then we don't need to do a check on the Subject WebID itself. This of course is especially useful for large service providers which may have millions of keys.
     - We can recommend putting e-mail like addresses in the CN of the subject DN and explain how this can be
used immediately as the certificate is resolved to name the user. So even without knowing either the issuer or having fetched the client, the server could use these as claimed names. It also means that it is easier for the user to recognise which certificate he wants to select in a cert selection box.
      This means that new users can have a page returned immediately, and the computer can address them with a familiar name, while it tries to fetch their profile or the issuer key.

   If DNSsec were ready then the issuer public keys could be found in DNSsec, which would be very tidy. Perhaps we should put a note about issuers for the moment and a reference to DANE as a possible way to continue.

 If we have such text ready then we could perhaps check with Ed or Brad to see if that helps settle those issues.

	Henry

  
[1] http://lists.w3.org/Archives/Public/public-identity/2011Oct/0036.html
[2] http://lists.w3.org/Archives/Public/public-identity/2011Oct/0038.html

Social Web Architect
http://bblfish.net/

Received on Thursday, 27 October 2011 14:35:28 UTC