-
Notifications
You must be signed in to change notification settings - Fork 28
Issue #278 - proposed new wording for context response + examples, in… #348
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
Conversation
…cluding reasons.
api/authorization-api-1_0.md
Outdated
| {: #response-with-context-example title="Example Response with Context"} | ||
| {: #response-with-step-up-example title="Non-normative Example Response with a step-up request Context"} | ||
|
|
||
| Even though this specification doesn't enforce any semantics for the `context` response object, if provided at all, the PEP MUST be able to understand this object. |
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 quite a strong requirement. It should be included at top-level in the description. I do like the idea as it would prevent a lot of negotiation on whether PDP's support certain functionality.
It would make it a lot harder to add fields to the context though as all PEP's must then be able to understand it.
Either way we should rephrase it from "MUST understand" to what the PEP should do if it doesn't understand. Something like this then?
| Even though this specification doesn't enforce any semantics for the `context` response object, if provided at all, the PEP MUST be able to understand this object. | |
| If the PEP does not understand information in the `context` response object the PEP SHOULD interpret the request as having a `"decision"` field with the value`false`. |
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.
@mtrimpe I disagree here - we cannot force a PEP to fail safe (though it sounds like the right behavior from a security mindset's PoV). Some implementations will want to fail open. The only option is to force the PEP to understand the object or fail using an error code at the discretion of the PEP. @baboulebou's wording reflects this better.
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.
Based on discussion on Aug 7 call, we will revert to Alex's original text: Even though this specification doesn't enforce any semantics for the context response object, if provided at all, the PEP MUST be able to understand this object.
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 support the intent of Alex's version, but even then still find the original phrasing difficult to interpret. Whether the PEP understands what it receives is not really under its control right?
And what does this MUST enforce if all observable behaviors are allowed?
Co-authored-by: Michiel Trimpe <michiel@trimpe.nl>
Co-authored-by: Michiel Trimpe <michiel@trimpe.nl>
Fixed spelling
Co-authored-by: Michiel Trimpe <michiel@trimpe.nl>
We agreed on the appropriate wording for minimal PEP behavior when unable to understand the context object.
davidjbrossard
left a comment
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.
reviewed on the call on August 14th
…cluding reasons.