Re: Documenting implicit assumptions?

Henry,

Think of it as if you have invented the wheel, we have seen that it is 
great and useful, and now is the time to consider whether that wheel 
needs spokes, a hub for the axle, bearings, a tyre, an inner tube, 
should those elements be plastic, metal, rubber, wood, stone, do we 
need different kinds of wheels for different use cases and so forth.

Hope that clarifies my intentions here,

Best,

Nathan

Nathan wrote:
> 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:20:14 UTC