- From: mike amundsen <mamund@yahoo.com>
- Date: Sun, 18 Nov 2012 13:30:57 -0500
- To: nathan@webr3.org
- Cc: Ruben Verborgh <ruben.verborgh@ugent.be>, Read-Write-Web <public-rww@w3.org>
- Message-ID: <CAPW_8m7Ne8PsVtSX4+VJxMEY7GYbqO3dyFXmrRVOgmOdWgBo=A@mail.gmail.com>
<snip> Nope, that's it bang on - implementation details local to the use case, so the general question would be whether we want to cater for that in a WebACL schema/ontology/mediatype which gets developed, or whether it's something we're best staying silent on (don't preclude, but don't include specific provision for). </snip> yeah - sounds fine. my regrets for the side tracking as i misunderstood Ruben's reply. Cheers. mca+1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mikeamundsen On Sun, Nov 18, 2012 at 1:28 PM, Nathan <nathan@webr3.org> wrote: > mike amundsen wrote: > >> <snip> >> Extending slightly what Ruben wrote - Nothing wrong with it, that's what >> WebACL is - the proposal is to look at the lexical representation of the >> URI and base access control on whether the URI regexp matches not, or >> perhaps further, to base access control rules on specific server side >> directory structures which are only known behind the interface. >> </snip> >> >> the URL interface in most implementations I work on rarely has any >> (meaningful) relation to the storage model on the server. keep in mind >> most >> of the work i do treats URIs as transient identifiers, not meaningful >> names. I suspect that is why my POV may not match well with what's >> discussed here; fair enough. >> >> <snip> >> If we consider the case of generic data storage, then WebACL rules may >> often be sent sent by the client, for the server to apply to the resource, >> in relation to resources they control - would we want clients to have to >> know about implementation details hidden by the interface, such as >> directory structures (or even if there are directories!). >> </snip> >> >> based on a reply from Ruben, i think what we're on about here is an >> implementation/optimization detail and that's fine. looks like i >> misunderstood Ruben's initial reply. >> >> in cases where you have some person in the role of defining security using >> a client app that has the power to apply security rules, i would *assume* >> that person *does* have knowledge about the URI structure in general (e.g. >> whether /admin/.* is a reasonable rule to apply to a URI space). if that's >> not the case (e.g. those applying rules have no knowledge of the URI space >> save the one URI they are attempting to secure), then certainly any use of >> regular expressions is a bad idea. >> >> again, these seem like implementation details local to the use case, but i >> might be missing the point. >> > > Nope, that's it bang on - implementation details local to the use case, so > the general question would be whether we want to cater for that in a WebACL > schema/ontology/mediatype which gets developed, or whether it's something > we're best staying silent on (don't preclude, but don't include specific > provision for). > > Best, > > Nathan >
Received on Sunday, 18 November 2012 18:31:45 UTC