RE: ACL

 In terms of work activity organization there are perhaps 5 threads:
 
- the ssl handshake, and its relation to assertions, claims, certs, secure communications, speak-for channels, and webids
 
- naming authorities producing foaf cards supportin the theory of urirefs
 
- key manegement, trust path discovery, trust path closure between servers & browers exchaning ssl handshake messages
 
- access control to resources, based on self-asserted claims to a foaf card in linked data space
 
- overarching identity model, where in a foaf card there are named-graphs referencible using https URIs, where the very same URI may be cited in a cert which, when used in SSL client auth procedure,  works to assert the named-graph to a server perform resource-0level access control. (ugh.)
 
 

 
> Date: Wed, 26 Jan 2011 19:21:03 +0100
> From: melvincarvalho@gmail.com
> To: nathan@webr3.org
> CC: public-xg-webid@w3.org
> Subject: Re: ACL
> 
> On 25 January 2011 19:42, Nathan <nathan@webr3.org> wrote:
> > Hi All,
> >
> > Quick scope check, is ACL, like http://esw.w3.org/WebAccessControl under the
> > scope of this IG?
> 
> Need to get the Venn diagrams out for that one :-)
> 
> Pretty much out of scope for the XG
> 
> Very much in scope for examples, running code, discussions on foaf
> protocols etc.
> 
> The narrower we can make the WebID spec the high the quality and
> faster turn around.
> 
> Once authn is formalized we can go through the same process with authz
> (even if only at the documentation level), creating a constantly
> evolving ecosystem.
> 
> Perhaps we need one parent project that points to the key elements, or
> as an graphic, but maybe that's what the w3c wiki is for ... not sure
> ...
> 
> >
> > Best,
> >
> > Nathan
> >
> >
>