On 25 Jan 2011, at 20:33, Stéphane Corlosquet wrote:

> However, mentioning ACL and some existing ontologies could be relevant in the requirements document.
> > For example standardising ACLs could end up require work comparing
> > all kinds of ACLs ontologies, not an easy task.
> >
> > Perhaps the question to ask is: where does not having ACLs start creating
> > interoperability limitations for WebID implementations? Ie, how far can we
> > go without them?
> My feeling is that we could get WebID (authentication) without ACL issues.
> What people do when the user is authenticated (e.g. use ACL ontology to deliver X or Y) is IMO a matter of the implementation, not of WebID itself.
> Alex has put it well and I agree: the WebID authentication mechanism merely ensure you are who you say you are, and that you can trust that the WebID profile doc is owned by the user trying to access something,

To be precise - realising that you already understand this, but just for newcomers - it ensures that you are the referent of the WebID.  Just as e-mail verification used so widely since the beginning of the web ensures that you are the owner of an e-mail box. Just as OpenId verifies that you are indirectly identified by the OpenId. E-mail verification does not guarantee that the details you then enter into the form about yourself are true, just as OpenId authentication does not guarantee that the attribute values are themselves correct. And so what you write in your Personal Profile document is not guaranteed to be true.

BUT! Because that document has a global reference able address (and you too) it can be linked to by others who can make trust statements about you, be they as simple as that you are their friend, to a bank certifying somehow that you have an account with them.... Of course it is here that things get really interesting. When this web is large enough trust builds up - that is part of the reason why Facebook is so big. :-) But we are trying to limit this XG to formally solidify the WebID spec. Implementations that show how these other things can be done will be very useful and may impact the WebID spec. So we do look for useful return from these. 

(But then again if timbl comes in here and shows us how we can do more than we thought ... )

> but the decisions that the server/app makes from there onwards are your problems :) This feeling was also expressed on foaf-protocols a few times. That said, ACL could relevant in the examples to show how WebID is useful in the bigger picture, and what kind of applications it enables.


So ACL and even trust logics are outside our most intense focus, even though these are going to be really important. At the same time everybody here implementing WebID will be working on these areas, and few implementations will limit themselves to pure identification.  

It may be that we should write little reports on some of these issues from the point of view of WebID. After all we will also be doing things like that with respect to OpenID and OAuth, and other identity mechanisms. That is: WebID by itself without ACL or trust logics that it makes possible does not help show this technology it it's best light. What makes WebID so interesting is that it works so well with REST, with browsers, with the Web and with linked data. And if one fails to see its position in the large sphere of things one will fail to grasp the advantages. 

If we were an IETF group speccing out HTTP then we could say ACL and trust metrics are completely out of scope. But we are an incubator group and hope to move to a Working Group. So as we work on our main focus, we may want to build bridges towards other groups that can do ACL and trust better or help those groups get created too... 

Perhaps we should determine how much time we spend on periphery questions, and allocate so much time every week on some of them.


> Steph.

Social Web Architect

Received on Tuesday, 25 January 2011 20:06:15 UTC