-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create wac-acp-diff-story.md #178
Conversation
A little store to bootstream WAC users to understand ACP
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is describing WAC with Shex not over constraining WAC? Will not any WAC extension that is consistent with the semantics not break any of the rules presented here?
Shex it seems to me is good at describing the current very constrained situation, but not one where description logics are deployed.
proposals/acp/wac-acp-diff-story.md
Outdated
|
||
<AclShape> { | ||
# who | ||
( acl:agentClass @<GroupShape> OR [foaf:Agent] ; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to Shex Value sets this statement says that ACL Shapes are constraining the acl:agentClass
range to be a Group with member or the singleton foaf:Agent
.
But that is overly restrictive interpretation of WAC:
- In Issue 176 I point to the fact that WAC has a subclass of foaf:Agent that is
acl:AuthenticatedAgent
. This shows that WAC always intended to allow subclasses of foaf:Agent to be allowed in the range ofacl:agentClass
- Given that one can use subclasses of
foaf:Agent
as the range ofacl:AgentClass
one can also build descriptions of agents in many more ways, as show again in issue Limitations: Only Trust Certain issuers of Identity #176. This may not fit current deployments of WAC but those don't fit current deployments of ACP either.
There is nothing therefore stopping WAC to grow to allow these extensions.
The danger of using Shex here is that its argument works by over constraining WAC and then showing it cannot be extended in the way it clearly can.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is overly restrictive. The acl ontology has
acl:agentClass a rdf:Property;
:comment "A class of persons or social entities to being given the right";
:domain acl:Authorization;
:label "agent class";
:range :Class .
which states that the range of agent can be any Class, eg the class of people over 18, or over 21, or married people, etc. The ShEX states that the only class can only be foaf:Agent.
proposals/acp/wac-acp-diff-story.md
Outdated
|
||
# to what resource | ||
( acl:accessTo IRI | ||
| acl:accessToClass [foaf:Document] OR @<AclRegexShape> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure enough about the Shex shape language. But it seems to be saying that acl:accessToClass is either the class foaf:Document
or a RegexShape. But that is not right
- foaf:Document is a class but that is the least likely class one would use in an access control rule: It would be stating that some set of agents is allowed access to all documents. What is interesting is to place subclasses in that position.
- I used regexes in rww-play, but I don't think the current WAC does this. (I may be mistaken). Still a regex can be used as a way among others define a set resources. Other ways are by describing sets of resources related to a date, to authorship, etc... So if you cut out the subclassing possibilities of RDF then you will come to conclusions about the limitations of WAC that are related to the constraint language used, not to wac as an RDF vocabulary.
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
I have written up issue #184 showing how one can extend WAC with one relation, to get the same results as ACP gets above (without using regexes). I think that would be even a clearer way to explain the difference between WAC and ACP, or the contribution of ACP to WAC, however one wants to look at this. |
Co-authored-by: Ted Thibodeau Jr <[email protected]>
proposals/acp/wac-acp-diff-story.md
Outdated
# ACP Compared to Web Access Control | ||
|
||
Audience: those familiar with WAC or those who learn from comparisons | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indicate that this is for the purpose of discussion/exercise -- as other things are moving in parallel - and not to be taken as authoritative definitions of the mechanisms.
proposals/acp/wac-acp-diff-story.md
Outdated
This document is intended to reflect the following authoritative-ish definitions: | ||
- [W3C wiki](http://www.w3.org/wiki/WebAccessControl) | ||
- [solid/specification](http://github.com/solid/specification) | ||
- [sold/web-access-control](http://github.com/solid/solid-spec) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This document is intended to reflect the following authoritative-ish definitions: | |
- [W3C wiki](http://www.w3.org/wiki/WebAccessControl) | |
- [solid/specification](http://github.com/solid/specification) | |
- [sold/web-access-control](http://github.com/solid/solid-spec) | |
This document is intended to reflect the following authoritative-ish definitions/clarifications e.g.: | |
- [W3C wiki](http://www.w3.org/wiki/WebAccessControl) | |
- [solid/specification](http://github.com/solid/specification) | |
- [solid/solid-spec](http://github.com/solid/solid-spec) | |
- [solid/web-access-control-spec](http://github.com/solid/web-access-control-spec) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This document is intended to reflect the following authoritative-ish definitions/clarifications e.g.:
the following
fights with e.g.
(readable as, for example
)
I suggest either --
This document is intended to reflect the following authoritative-ish definitions/clarifications:
-- or --
This document is intended to reflect a number of authoritative-ish definitions/clarifications, including the following:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The over restrictive nature of the ShEx is provably false by consulting the ontology.
proposals/acp/wac-acp-diff-story.md
Outdated
|
||
<AclShape> { | ||
# who | ||
( acl:agentClass @<GroupShape> OR [foaf:Agent] ; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is overly restrictive. The acl ontology has
acl:agentClass a rdf:Property;
:comment "A class of persons or social entities to being given the right";
:domain acl:Authorization;
:label "agent class";
:range :Class .
which states that the range of agent can be any Class, eg the class of people over 18, or over 21, or married people, etc. The ShEX states that the only class can only be foaf:Agent.
proposals/acp/wac-acp-diff-story.md
Outdated
)+ ; | ||
|
||
# can do what | ||
acl:mode [acl:Read acl:Write acl:Append acl:Control] + ; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The value set for acl:mode is overly restrictive as per ACL Ontology:
acl:mode a rdf:Property;
:comment "A mode of access such as read or write.";
:domain acl:Authorization;
:label "access mode";
:range :Class .
The rule may reflect deployments however ACL permits any class eg. :Create
, :Delete
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: the acl Ontology would be a lot clearer if it restricted the range of acl:mode
to the subclasses of acl:Access. See issue #187
I like this story, as it helps understand what the differences are with how WAC is currently deployed. But if these documents are not just going to be one way conversations, but a way to help grow our common understanding, it should refer to #184 which shows how WAC could do the same. From there we can move on to the next feature of ACP, to see what it brings to the table. |
Note: the non-normative ShEx for WAC would actually work with the |
Co-authored-by: elf Pavlik <[email protected]>
Per the data interop meeting today, i migrated this to a new file and added a couple properties to WAC's ShEx |
Co-authored-by: Ted Thibodeau Jr <[email protected]>
A little store to bootstream WAC users to understand ACP