Re: NOTICE! this is 4pm Paris time -> Re: WebID XG Meeting: back to spec writing

On 31 Oct 2011, at 15:26, Mike Jones via mobile wrote:

> Either is fine with me.

Ok, let's do it at 4pm, 1500 UTC as programmed then, since I don't hear a lot of last minute worries.

Henry

> -- 
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
> 
> Henry Story <henry.story@bblfish.net> wrote:
> NOTICE, because of daylight savings 1500 UTC is 4pm paris time.
> The Zakim teleconf is booked for that time.
> 
> If people prefer we can make the meeting on Skype one hour later.  But please respond now.
> 
> My Skype ID is bblfish.
> 
> Henry
> 
> 
> On 27 Oct 2011, at 16:34, Henry Story wrote:
> 
> > 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/
> > 
> 
> Social Web Architect
> http://bblfish.net/
> 
> 

Social Web Architect
http://bblfish.net/