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 20:02:20 +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: <51D29557-D141-4A02-A06D-9743391C2AA1@bblfish.net>
To: "Harry Halpin" <hhalpin@w3.org>

On 26 Oct 2011, at 19:39, Harry Halpin wrote:

>> 
>> 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.
> 
> I do not determine what is in and out of scope personally. Final decisions
> will be made via the W3C membership, who intially express their views via
> the workshop and then finalize formal AC review. Our job is to get it as
> close to possible to what will be a good scope. WebID spec as it currently
> stands [1] is out-of-scope as was determined by a vote at the end of the
> workshop.

"as currently stands" 

So I suppose that means that it is in fact open.
 
If it is open then this discussion is not out of scope.

> WebID will not be excluded. WebID will be a valuable input to this work
> and we will liason with the WebID community. Also, member employees who
> support WebID will of course be allowed to join the WG, and there will be
> the usual invited expert policy.

The first sentence I had about your proposal was  "sounds good, but why no mention of WebID?"

http://lists.w3.org/Archives/Public/public-identity/2011Oct/0002.html

Your answer then was that the same as above. Some voter somewhere, which you know is not that serious
because you keep saying "as currently stands".


> Neither WebID, BrowserID, or exiting work like OAuth and OpenID will be
> "rubber-stamped" by the W3C. That's not how the W3C works. It will require
> serious work to determine the base-level minimal functionality that can
> help them all - that's why we call it a Working Group :)

Good, of course it should be like that. Indeed, I am quite willing to work with all of those. As it happens, I am just putting a demo together to show how they can work together seamlessly.

> For the time being, the group will focus on minimal Javascript APIs and
> possibly sync functionality.

Ah, is that a decision to change the charter?
I have not seen any text on that up yet.

http://www.w3.org/2011/08/webidentity-charter.html

> 
> Please do not send any more off-topic emails to this list, but help
> determine the functionality of the APIs so that they can best help WebID.

I will gladly, but I don't think that it is too much to ask that you include us formally as you included
others in the discussion.

> I will respond to the rest of your email later re the technical concerns
> expressed in the workshop over WebID on the correct list for such matters,
> i.e. public-webid-xg@w3.org.

Some of those discussions are quite properly made here, on this list, especially after your mischaracterisations of WebID such as in your earlier claim that there were serious security issues with WebID. This has placed the conversation clearly on this list. 

> 
> And calm down :)

Harry you are lighting a fire in a room full of people and then asking people to calm down. Stop spreading misinformation, and instead please help put out the fire you just started.

Thanks,

	Henry


> 
>   cheers,
>       harry
> 
> [1] http://www.w3.org/2005/Incubator/webid/spec/
>> 
>> 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.
>> 
>> 	Henry
>> 
>> 
>>> 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
>> http://bblfish.net/
>> 
>> 
>> 
> 

Social Web Architect
http://bblfish.net/
Received on Wednesday, 26 October 2011 18:02:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 26 October 2011 18:02:55 GMT