Skip to content
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

Explain motivation behind the "can_*" naming pattern for common actions #154

Open
randomstuff opened this issue Sep 23, 2024 · 2 comments
Open
Assignees

Comments

@randomstuff
Copy link

Common action names follow a can_* naming pattern. It is not clear, why this pattern is chosen. Why is it can_read and not `read?

All the examples in the repository follow this pattern. Are custom actions expected to follow this pattern as well?

Having plain actions names seems better to me as an implementation could directly map authzen action names to OAuth scope.

@independentid
Copy link
Contributor

Following on this thread and Issue #123, I think actions should be defined only as case-insensitive strings. Applications and PDPs use a wide variety of ways to express actions (example: URNs). The PDP/PEP interaction should be agnostic to the value of the action. IMO, the use of can may be common but it also seems stylistic more than useful.

For example: GCP Bind uses forms like roles/iap.httpsResourceAccessor, Cedar uses PhotoApp::Action::"viewPhoto".

I think standardizing formats for subject, actions, and resources would have to come in another specification because it requires the PDP and PEP to agree on a common application information model.

@ogazitt
Copy link
Collaborator

ogazitt commented Dec 3, 2024

We've decided to take out the "common actions" from the 1.0 version of the spec, because it's confusing. This will show up in 1.0.2.

@ogazitt ogazitt self-assigned this Dec 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants