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

Ordered vs. Mapped Evaluation Response #162

Open
independentid opened this issue Oct 3, 2024 · 0 comments
Open

Ordered vs. Mapped Evaluation Response #162

independentid opened this issue Oct 3, 2024 · 0 comments
Assignees

Comments

@independentid
Copy link
Contributor

independentid commented Oct 3, 2024

Draft 1.1 of the authorization API specifies evaluation responses be arranged in a map. This permits parallel processing.

Draft 1.1-01 of the authorization API specifies that results be returned in an array.

Discussion on slack was that the reason for the change is that batches should be performed in order. A reason given was that a fast fail could be implemented.

This suggests a lot of complex logic that has not been defined.

  1. Fast-fail suggests individual decisions are not just true/false, but might also result in error (e.g. invalid input value)
  2. Fast-fail suggests a need to have processing logic indicating the PEP's expectations (fail on first, process all)
  3. Is batch processing intended for one subject as part of a work flow, or is intended to support scale by allowing request pooling. E.g. reducing the overhead of validating an authzen request. Or is this NOT a goal. If so describe the limits to queries.

Finally how is fast-fail the same or different from a deny decision?

A PDP might be asking what a subject can do. So while the subject can't do one thing, they are allowed several other actions. How would this be processed in the event of fast fail.

If fast fail is due to invalid input (e.g. an attribute for a condition expression was missing) should this be a deny or an error? As an example both SCIM and LDAP define how undefined attributes are addressed in filter expressions. Should PDP's follow these conventions, or should PDP's have the ability to return errors instead of allowed true|false.

@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

2 participants