Re: future of Identity on the Web

On 25 Oct 2011, at 23:04, Henry Story wrote:

> 
> Next with 
> 
> 3. Performance and scalability is terrible relative to server-auth-only TLS
> 
> There is only one connection to the WEbID server and that can be cashed, so there is a bit of a cost on the first connection. But even normal TLS is supposed to do something like verification of the certificate on a revocation list. Other requests can use information from the cache as long as the cache is felt to be valid, which is no different from checking revocation lists.
> 
> But if you really feel this is a serious issue for large providers, then we can help you out, without any trouble at all. We were just waiting for people with such issues to talk up a bit, because I don't want to make the protocol more complex without reason. It is simple: We just need to use an Issuer WebID. So let's say Apple issues a number of certificates, they can issue each of them with a webid of
> 
> <https://apple.com/id#AAPL>
> 
> Then any server that finds the public key of AAPL, won't need to check the profile of the user: it will just need to verify that AAPL signed it. Of course it could then do another check on the WebID to get the latest information from there, but perhaps you are right - that could be done in a different thread between two connections.
> 
> Does that help? Is that something you would like us to add to the spec?

Btw. I just realised that we had two issues open for this

ISSUE-2: Explore the role of Issuer Alternative Names in WebIDs
ISSUE-3: Explore Large scale TLS WebID installation issues

It looks like ISSUE-2 could then be the way to solve ISSUE-3.

Henry

Links to issues:
http://www.w3.org/2005/Incubator/webid/track/issues/2
http://www.w3.org/2005/Incubator/webid/track/issues/3


Social Web Architect
http://bblfish.net/

Received on Tuesday, 25 October 2011 21:24:44 UTC