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

Re: Documenting implicit assumptions?

From: Nathan <nathan@webr3.org>
Date: Mon, 31 Jan 2011 18:07:24 +0000
Message-ID: <4D46FA5C.4060209@webr3.org>
To: Henry Story <henry.story@bblfish.net>
CC: Benjamin Heitmann <benjamin.heitmann@deri.org>, public-xg-webid@w3.org, Manu Sporny <msporny@digitalbazaar.com>, Michael Hausenblas <michael.hausenblas@deri.org>, Tim Berners-Lee <timbl@w3.org>
Henry Story wrote:
> On 31 Jan 2011, at 17:54, Nathan wrote:
> 
>> Henry Story wrote:
>>> The WebID protocol currently only requires that the WebID be related to one or more public keys.
>> even that isn't required to get the same result, the presence of any token in a profile that you can prove the agent owns will do.
> 
> We are trying to build a RESTful protocol that works very cleanly with Web Architecture. That is an absolutely fundamental design assumption.  talk of might "tokens" has the ring of Remote procedure 
> calls, XMLRPC, and so on to it.

+TLS which is stateful, precludes intermediaries, doesn't allow for 
network caching, isn't very RESTful, if you mean HTTP friendly then 
the webid could be passed in an HTTP request header, and a response 
token (even if that's a public key) could be in http response header.

>>> I think it is probably a good principle that that file be public, because of the danger otherwise
>> which file?
> 
> I was thinking of the "Profile Document", as we have called it in the spec.

so we're all agreed on having a "Profile Document" as a requirement? 
where was this discussed in the XG?

>> all we need is a token to be returned via whatever the dereferencing process is (whether that's public key from HTTP GET or a string in a header returned from HTTP+TLS or many other things).
> 
> If you think that placing it in the header has advantages, then please put forward a proposal on that.

Yes, decoupling from the public key has some advantages, for instance 
using a token passed from the server via the agent to resource 
responding to a webid dereference ensures that the user still has 
write permission to that resource.

Decoupling the presenting of a webid from subjectAltName in a 
certificate allows usage over standard HTTP (and other transfer 
protocols), but doesn't require encryption over the wire (although we 
could require TLS independently), SAN is an extension coupled to 
X509v3 iirc and we don't need to couple that tightly.

Both of these are just illustrations of alternatives, and picking from 
the pool of options requires certain design trade offs to be made and 
agreed.

We don't even have that pool of options yet.

>>> of creating some form of deadlock, where the Profile Document requires WebID authentication on a WebID that itself first requires authentication. Public keys are designed to be public. 
>> or, that could be a useful feature, only allow auth from agents you can auth yourself - four party.
> 
> I am not sure the protocol as is makes that impossible. I am not sure what the use case is either.
> So I can't comment.

So we need a pool of use-cases defined.

>>> Perhaps this is a FAQ, or a HOWTO question. And perhaps we should add a best practices document,
>> all of it is up for discussion, the result of those discussions may end up in FAQs, notes or howto docs.
>>
>> FOAF+SSL != WebID, if it is then why are any of us here? just call it a standard or a spec and be done with it. WebID is what we'll end up with at the end of this process.
> 
> FOAF+SSL was also evolving, just as WebID is. I am just saying that you will find some resistance
> for revisiting everything and starting from scratch.

from who? I believe that's why we're all here, it's an incubator activity:
   http://www.w3.org/2005/Incubator/about.html

Social Web XG and Provenance XG and many others before us have shown 
the way well.

Deliverables:
   A requirements and use case document for the WebID protocol.
   An interoperability report on existing WebID implementations.
   A final XG report that includes suggestions for the next steps.

If I need to create conflicting implementations just to ensure this 
process happens and all elements are discussed correctly, then that's 
what I'll do.

But I'd far rather that everybody was on board with the idea of 
incubating this, exploring the options, ensuring the correct decisions 
have been made, especially you Henry, as chair.

>>>> and that's if RDF is returned..?
>>> It is RDF that is returned, the spec clearly states that the representation is not mandated
>>> as long as one can GRDDL it. See section 2.3
>> when did we decide that RDF is returned?
> 
> Did you look at section 2.3 of the spec? It mentions that any XML can be used, JSON, N3, and so
> on, as long as we have an automatic way of mapping that to RDF triples. Is that a problem. If so
> please open a specific thread on it.

We're only one week in, surely it's wise to start with use cases, 
options and documenting what's already there, so we can later start to 
discuss each option.

At the minute the XG is being lined up as if WebID as it stands just 
has a few minor issues to attend to (basic clarifications on things 
like multiple SANs) and then we'll be done.

If the final WebID report consists of a proposed standard which we 
want to migrate to REC track, then we need to do everything properly 
during the course of this XG, which includes covering all options of 
elements of the potential protocol.

We /do not/ have any backwards compatibility issues to consider here, 
and the scope is very much wide open. (xx people with existing webids 
and a handful of prototype implementations != a bc issue).

The social web XG report has outlined the stage for us, we should 
continue on from their to get specific use cases, options, and then go 
from there.

> What is the issue you find with the current spec? 
> 
> Sorry, many of us have spent years working on this. We are not closing doors to all new ideas, but what would be the point to start a discussion from 0 here? What are your issues exactly?

Well historically many other issues have been brought up and 
consequently rejected or ignored, tell me what has changed in the 
protocol since FOAF+SSL [1] almost 3 years ago?

The current set of elements is but one set out of many combinations, 
those other options and combinations have not been defined, listed, 
weighed up or considered properly yet, how each applies to different 
use cases, and I for one am certainly not sure that the major design 
decisions made so far are the best (I can't assert that without the 
proof, who can?).

[1] http://blogs.sun.com/bblfish/entry/foaf_ssl_creating_a_global

Best,

Nathan
Received on Monday, 31 January 2011 18:09:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 31 January 2011 18:09:12 GMT