- From: Nathan <nathan@webr3.org>
- Date: Mon, 31 Jan 2011 15:25:53 +0000
- To: Benjamin Heitmann <benjamin.heitmann@deri.org>
- CC: public-xg-webid@w3.org
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