Re: Documenting implicit assumptions?

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.

> Here are two implicit assumptions I have noticed: 
> 
> * the list of friends which is published together with a WebID is assumed to be public

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?

> (alternative: in order to participate in a web of trust, a WebID user has to make a part of his list of friends public) 

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?

> * the RDF which is returned when accessing a WebID is assumed to be public

and that's if RDF is returned..?

> 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).

Best,

Nathan

Received on Monday, 31 January 2011 15:26:41 UTC