-
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
[wac-ucr] add initial definitions #83
Conversation
@@ -42,5 +42,111 @@ This is where we explain the use case. | |||
Definitions {#definitions} |
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.
Why is the UCR defining terminology instead of referring to where they are actually defined?
The UCR should have no knowledge about the things that's being defined here. When this is defined, it is reverse-engineering the UCR where it should instead work from its own needs to come up with the requirements.
The criteria in the WAC spec will backreference the requirements in UCR.
An <dfn>access mode</dfn> denotes a class of operations that an | ||
[=authorization subject=] can perform on an [=authorization target=] in an | ||
[=authorization statement=]. | ||
|
||
<dfn>Read access</dfn> is an [=access mode=] that allows the | ||
[=authorization subject=] to the ability to read, but not modify, the | ||
[=authorization target=]. | ||
|
||
<dfn>Write access</dfn> is an [=access mode=] that allows the | ||
[=authorization subject=] to the ability to create, update, or delete the | ||
[=authorization target=]. | ||
|
||
<dfn>Append access</dfn> is an [=access mode=] that allows the | ||
[=authorization subject=] to add data to a resource, but not modify any | ||
data that already exists. | ||
[=authorization target=]. | ||
|
||
<dfn>Control access</dfn> is an [=access mode=] that allows the | ||
[=authorization subject=] to view and modify [=acl resources=] associated | ||
with an [=authorization target=]. |
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.
Do these need to be defined in the UCR? If it is referring to the ACL vocab, simply refer to that.
Can we make sure to address all comments/reviews to a PR before closing? At the very least ensure that there is a mutual understanding whether the comments/reviews are significant and need further attention. In this particular case, it is not clear whether https://github.com/solid/authorization-panel/pull/83/files/d89013a658479cff2c2f05f1a837b76dc6f518b7#r452461263 and https://github.com/solid/authorization-panel/pull/83/files#r452462668 are taken into account in the new PR. There are no back references indicating that they are addressed. It is just out of sight out of mind. |
Initial set of definitions for the WAC use cases and requirements document.