RE: WebID TLS

 Since webid was unable to pursuade anyone (at all?) to adopt https client certs for use on the general internet, I guess the group nhas decided that its appropirate to ensure webid is security protocol agnostic.  I heartily agree. It will help the "portrayal" of W3C to show the webid is not tied to any one security protocol (e.g. a transport layer or IPsec layer protocol). That is, its not just another religiously-motivated group wanting its own security token forma (for no particular reason other than it uses some or other preferred presentation syntax/format). Ive long argued that when my IDP using a signed SAML2 assertion delivers the webid in a web services call, the properties of said "proof" version of SAML2 are really not that different to a cert delivering the webid. The cert is a signed object, and is carried by a security protocol between browser and site. Said protocol ensures the cert is delivered to the intended recipient (when TLS handshake tunneling is used).  Similarly, in the web services world, the SAML2 token is a signal from browser-hosted script to the site, similarly. The SAML2 handshakes accomplish what jhttps accomplishes : deliverrs an identitificatio blob to the intended recipient. Obviousl, this web services version of SAML2 (available worldwide in windows, now) varies from the more traditional websso version of SAML2, in which the browser is involved - being a mere conduit in the passing of a signed token from one site, to another. Obvbiously, its pretty trivial to move off of SAML2 blobs for web services and use signed JSON blobs, swapping bit formats (yet again).    From: henry.story@bblfish.net
Date: Sun, 6 Nov 2011 01:37:41 +0100
CC: public-xg-webid@w3.org
To: scorlosquet@gmail.com
Subject: Re: WebID TLS




On 5 Nov 2011, at 23:57, Stéphane Corlosquet wrote:Hi Henry,

On Sat, Nov 5, 2011 at 6:42 PM, Henry Story <henry.story@bblfish.net> wrote:

Can we agree to specialise on WebID over TLS for the rest of this Incubator Group, and leave all the other possible protocol implementations for later, say like for when the Cryptography Working Group has finished its API?


I thought that was already the case. Can you clarify and give some examples of what would *not* be included then?
There was a bit of confusion in a few e-mail exchanges recently on the list, so I just wanted to make sure we are in agreement. We can have this document be WebID over TLS leaving open for later WebId over BrowserId type JSON certificate for example.
We still have quite a bit of work to do to finish the current spec. It will be quite an achievement to finish it. I'll put more energy back into the spec now. ( I was of in Saint Etienne this week, and was taken up into a lot of meetings at the university there - which also had very bad connectivity). 
Btw, don't forget we have our weekly meetings now in Skype, so we can do a bit of video conferencing and even some screen sharing. Every month we then will have a more formal meeting.
Henry

Steph. 



We need to focus on getting something done so at the end we have some real things to show.



Henry





Social Web Architect

http://bblfish.net/









Social Web Architect
http://bblfish.net/