RE: Documenting implicit assumptions?

The tone is wrong. 
Try to remember its an incubator - whose output justifiedsgetting an even bigger audience, with even more resources. You dont build an atomic bomb, until you get a pile to arm, which you dont fund until some nutty Italian proves some theorems about graphite...based on a idea by a German, using math invented by a Russian thinking about circles in 4d spaces.

> From:
> Date: Mon, 31 Jan 2011 19:41:36 +0100
> CC:;;;;
> To:
> Subject: Re: Documenting implicit assumptions?
> On 31 Jan 2011, at 19:19, Nathan wrote:
> > 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.
> Nathan, just put forward some proposal with if possible detailed text for the spec, howto, 
> or whatever, and proposals for changes you wish to put forward. Make those changes clear 
> and concise. Spell out why you think they are needed, what issue the change will solve.
> Then we can have something to agree with, criticise, accept or shoot down. We will need to 
> think about the implications of your proposal, test the idea with real code, see if it 
> interoperates, if it is easy to implement or not, etc... etc...
> We have limited time, so take the most important issues you have first, and put those 
> forward. 
> Henry 
> > 
> > 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:
> >>
> >> 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]
> >> Best,
> >> Nathan
> > 
> Social Web Architect

Received on Monday, 31 January 2011 19:16:24 UTC