W3C home > Mailing lists > Public > public-identity@w3.org > October 2011

Re: future of Identity on the Web

From: Harry Halpin <hhalpin@w3.org>
Date: Wed, 26 Oct 2011 17:23:09 +0100 (BST)
Message-ID: <a6401b403b985c210d52c336dccdf02b.squirrel@webmail-mit.w3.org>
To: "Henry Story" <henry.story@bblfish.net>
Cc: "Edward O'Connor" <eoconnor@apple.com>, public-identity@w3.org

Just to be clear - as per the results of the workshop, WebID is itself
currently out-of-scope for this WG. However, what is clearly in-scope and
which would clearly help your effort would be what functionality that a
Crypto API and a possible "identity" API functionality would help your
effort both in terms of exposing functionality of the browser/device as
APIs and possibly "sync" to help your effort work across multiple devices.

 For the third time, a single e-mail with textual changes to the charter
and an explanation of the functionality will be sufficient and greatly

  Please keep this thread and similar protocol-specific threads over WebID
on your XG mailing list in the future.


> 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 Wednesday, 26 October 2011 16:23:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:47 UTC