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

Re: future of Identity on the Web

From: Henry Story <henry.story@bblfish.net>
Date: Wed, 26 Oct 2011 19:08:09 +0200
Cc: Edward O'Connor <eoconnor@apple.com>, public-identity@w3.org, WebID Incubator Group WG <public-xg-webid@w3.org>, Tim Berners-Lee <timbl@w3.org>
Message-Id: <11707C58-57FE-455D-BCB3-C67B747368AC@bblfish.net>
To: "Harry Halpin" <hhalpin@w3.org>

On 26 Oct 2011, at 18:23, Harry Halpin wrote:

> Henry,
> Just to be clear - as per the results of the workshop, WebID is itself
> currently out-of-scope for this WG.

Harry from your previous e-mail it is clear that you don't master the subject about WebID and how it functions. You are therefore in no position to say whether it is or not in scope.  

Let's list a few of your faux pas:

- You claim that there are security issues with WebID which you cannot back up
- You say WebID is out of scope because it uses certificates, yet BrowserId is built on certificates
  (not X509ones just JSON ones, but for someone who worked on GRDDL, to exclude or include on syntactic issues is a bit rich)
- You mention some discussions where WebID was apparently ruled out, but of the people on this list the feedback seems mostly to have been that the results of that workshop were that you a JSON api on cryptography was the consensus - with which I agree too.
- you try to name something an Identity working group, but don't wish to allow the WebID XG to participate, when clearly the subject is fully within scope at least of part of what is being proposed

For some reason you seem absolutely intent on excluding something you don't understand. Instead of trying to see where we can work together you start off assuming falsely that there is no common ground. Instead of trying to work in a way that would build on the tradition of the IETF and so build consensus, you try to exclude IETF technology a priori. There is no reason to do this, since what you and BrowserId wish to do can work seamlessly with what WebId is doing.

So all of that is completely counterproductive. These are engineering issues, not political issues, even though like all spheres of knowledge they are intermingled. That is you cannot avoid the WebID engineering issues through political manoeuvring. You cannot seriously put BrowserId in the group of people to consult, and not put WebId there too.

> 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.

The crypto API will certainly be useful for many things. 

It is not clear what syncing of information is about. PUTing and GETing information?
Does that need a working group? I suppose that is related with the bookmarks and other features including identity features in a browser...

> 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
> appreciated.

It is not really possible to move on to the charter if you keep misleading people about the issues with the technological possibilities they are confronted with. 

So there was a suggestion earlier that you put forward the issues one by one that you have with WebID.
The first ones I cam across do not hold water. Now you can ignore it, but sticking your head in the hole won't make your ignorance disappear.


>  Please keep this thread and similar protocol-specific threads over WebID
> on your XG mailing list in the future.
>       cheers,
>           harry
>> 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/

Social Web Architect
Received on Wednesday, 26 October 2011 17:08:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:47 UTC