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/

Received on Monday, 31 January 2011 16:29:41 UTC