You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Fast-fail suggests individual decisions are not just true/false, but might also result in error (e.g. invalid input value)
Fast-fail suggests a need to have processing logic indicating the PEP's expectations (fail on first, process all)
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: