Re: future of Identity on the Web

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

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.

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 :)

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

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

And calm down :)

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

Received on Wednesday, 26 October 2011 17:40:02 UTC