Skip to content

Conversation

@baboulebou
Copy link
Collaborator

…cluding reasons.

{: #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.
Copy link
Contributor

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?

Suggested change
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`.

Copy link
Collaborator

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.

Copy link
Collaborator

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.

Copy link
Contributor

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?

@davidjbrossard davidjbrossard self-assigned this Aug 6, 2025
@davidjbrossard davidjbrossard self-requested a review August 6, 2025 20:34
davidjbrossard and others added 4 commits August 6, 2025 22:35
Co-authored-by: Michiel Trimpe <michiel@trimpe.nl>
Co-authored-by: Michiel Trimpe <michiel@trimpe.nl>
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.
Copy link
Collaborator

@davidjbrossard davidjbrossard left a 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

@davidjbrossard davidjbrossard merged commit 454c63b into main Aug 14, 2025
2 checks passed
@davidjbrossard davidjbrossard deleted the feature/issue-278-fix-reason-context branch August 14, 2025 19:29
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

Successfully merging this pull request may close these issues.

5 participants