Talk:WebAccessControl

From W3C Wiki

Points for discussion

  • Reference is often made to metadata/acl being stored on the file system, however an ACF (Access control file) is a resource, and must be in order to provide for multiserver replicated environments, and additionally the link from resource to acf may be many-to-one (no point replicating data, on my personal site for instance everybody has read, and I have write+control; why repeat this information for every resource?
  • Further, acf's and the resources they are for may be on completely different servers - data on S3, acf's locally etc.
  • Does "acl:Write" permission also indicate the agent with acl:Write can Delete? typical clients may assert that they want x-staff-member to only be able to "edit" a document, whereas I could assert that they can "edit" it empty which == delete (imho)
  • Logic for removal of an ACF could do w/ being covered if this isn't implementation specific.
  • Implementation-wise the trickiest part is storing and looking up the link from "resource to acl/acf"; thus far the most logical and easiest approach is using CERN Metafile Semantics, however the extension may need looked at to allow those metafiles to be shared between resources and to be resources themselves (ie resource on web, not files on the same filesystem = again multiserver/tier/replication reasons)
  • as confirmed by mod_authn_webid the identity+wac (foaf+ssl & acl) needs to be implemented at a layer where generally web developers are not used to working; after typical "apache" stuff and before normal scripts etc can be run; most implementations of acl will be specific to a domain/company with different rules for who can access resources + different levels of trust for foaf+ssl profiles (some may require ca valid certs and not self-signed); thus whilst mod_authn_webid is great for prototyping, a "real" mod_authn_* for wac would need to passthrough ssl_client_cert and requested resource to a user specified script which would handle foaf+ssl verification and wac before handing back a success/fail to the controlling http server and on to the resource.
--Nathan / webr3 02:36, 5 April 2010 (UTC)