RE: Documenting implicit assumptions?

I look at FOAF+SSL as the thing one had to do to get to this stage - recognition of the validity of the "idea" by a more formal body with lots more reach. Its not the output of the process, however (and renaming FOAF+SSL to webid protocol is not enough). This process's output must be one of incubation, and may well be quite distinct from the "founding" "ideas" that formed the group's motivating input. if webid protocol looks nothing like FOAF+SSL at the end of the day, I could not care less. What I recognize in Henry's original case , 3 years ago or more, was the story and the opportunity. There was a clarity of rationale, and it felt good (compared to the faffiness of the openid auth protocol)
 
Its like a tell my adolsecent kid: you pass your latin exam to get to the next stage, not because you need to parse latin in real life. Its a proof of skill - upon which to build some more language-capabilities. Pick a stage where you want to be at 25, and now work at the next barrier called getting into the better middle school...(which gates high school... which gates university... which gates...).
 
I dont think "we" collectively do have 3 years experience. We simply had three temporal years to gel the communication and presentation of some interesting oppotunistic thinking into a case - that made it to this point. This is about the time Id expect folks to take to gather evidences of practicality - one of the particular tests that this group applies as its gating function. 
 
SSL and key management really goes back to about 1921, when real math and machines started to enjoy the game of make and break ciphers. If you look at it using game theory, it really helps. Now, we design a better game, one fitting the culture of the web. Im looking forward to hearing what everyone else's ideas are about https for the Semantic Web project, rather than engineering a better widget that improves the https kludge thrown together in world of 1994.
 
Get this right and browser makers and server makers will happily completely rewrite their SSL and https libraries - and then fasihon viable migration strategies for the older stuff. They already do it every 4-5 years anyways, just to combat architectural rot.
 
 

 
> From: henry.story@bblfish.net
> Date: Mon, 31 Jan 2011 17:29:04 +0100
> CC: benjamin.heitmann@deri.org; public-xg-webid@w3.org
> To: nathan@webr3.org
> Subject: Re: Documenting implicit assumptions?
> 
> 
> On 31 Jan 2011, at 16:25, Nathan wrote:
> 
> > Benjamin Heitmann wrote:
> >> It might be an interesting exercise to figure out more implicit assumptions / requirements, document and discuss them, to figure out if there is a decision attached or if something is actually out of scope. 
> > 
> > I agree, and would suggest that almost every element other than the abstract flow be up for discussion, this is a new protocol and we must consider all potential avenues, the strengths and weaknesses of each, then agree on a set of design trade-offs from which the final protocol will be born.
> 
> Yes, everything is up to be looked at, but we have already 3 years of experience here, and there
> is no reason to dismiss those out of hand either. We also have a lot of working code and demos. 
> 
> Please do question, and get us to think. A very good way is by showing implementations and problems they have, or by proposing improvement text to the code, or by starting a thread on a specific topic. Threads on topics should start by explaining concisely the reason for a change, the problem the change hopes to solve, so that people can understand why they should spend time reading the proposal. 
> 
> >> Here are two implicit assumptions I have noticed: * the list of friends which is published together with a WebID is assumed to be public
> 
> Where do you notice those assumptions? 
> Not here?
> http://www.w3.org/2005/Incubator/webid/ED-spec-20110121/
> 
> 
> > this is indeed an assumption,
> > - is anything published?
> > - is their a list of friends?
> > - is the list of friends split in to grouped lists?
> > - list(s) are pointed to (acl controlled resource(s)) or in the returned data after a dereferencing action on a webid uri?
> 
> The WebID protocol currently only requires that the WebID be related to one or more public keys.
> That is enough for authentication. Nothing else is required or presupposed.
> 
> Of course it makes sense to add extra information there to point to other places, to
> describe the agent somewhat, and so on. 
> 
> I think it is probably a good principle that that file be public, because of the danger otherwise
> 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. 
> 
> Perhaps this is a FAQ, or a HOWTO question. And perhaps we should add a best practices document,
> or something similar, which we can fill out to help flesh out parts that we have good intuitions f
> or, but for which we don't yet have enough consensus, due to lack of applications.
> 
> > 
> >> (alternative: in order to participate in a web of trust, a WebID user has to make a part of his list of friends public) 
> 
> No, he can point to a protected file, that will list his friends. This is something that goes a little
> beyond authentication. 
> 
> > 
> > indeed, should a users list of friends (if there is one) even be considered, are not the inbound links from other sources more valuable here?
> > 
> > is any of this part of WebID, or merely related? are these to be considered as design considerations and use cases for WebID separate to the protocol or core requirements?
> 
> If we start having more applications with protected friend files then it will be easy to put together
> a document stating best practices. I have been waiting for people to put these together for a while, but have not yet seen anything. I am working on something basic here myself with Clerezza.
> 
> > 
> >> * the RDF which is returned when accessing a WebID is assumed to be public
> > 
> > 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
> 
> > 
> >> Equally importantly: Are there other assumptions which need to be documented?
> > 
> > yes, every element of the protocol and flow thus far.
> > All we can say for certain, roughly, is that we need encryption over the wire, and to assert ownership/writership of a URI (name).
> 
> I think we rather start with what we have that functions, and see what issues that has. 
> I really don't see why we should start form scratch. 
> 
> Henry
> 
> > 
> > Best,
> > 
> > Nathan
> > 
> 
> Social Web Architect
> http://bblfish.net/
> 
>