Skip to content

changes to the Notiication obligation: to as Array, support for Decis… - #596

Open
baboulebou wants to merge 3 commits into
mainfrom
feature/obligation-decision-subject
Open

changes to the Notiication obligation: to as Array, support for Decis…#596
baboulebou wants to merge 3 commits into
mainfrom
feature/obligation-decision-subject

Conversation

@baboulebou

Copy link
Copy Markdown
Collaborator

Changes to the Notification normative Obligations:

  • to becomes an Array of strings
  • support for decision_subject, the entity that the decision pertains to.

run: |
echo "Checking for RFC9110 xrefs in api/authorization-api-1_0.xml"
grep -n 'target="RFC9110"' api/authorization-api-1_0.xml || echo "none found"
# Replace any <xref target="RFC9110" section="...">text</xref> with a ulink to the RFC HTML+fragment.perl -0777 -pe 's#<xref\s+([^>]*?)target="RFC9110"([^>]*?)section="([^"]+)"([^>]*?)>(.*?)</xref>#<ulink url="https://www.rfc-editor.org/rfc/rfc9110.html#section-$3">$5</ulink>#igs' -i api/authorization-api-1_0.xml

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you mean for a line break before perl ?

to:

: REQUIRED. A String. An implementation-specific identifier for the destination of the notification (e.g., an email address such as `manager@example.com`, or a queue/topic name). The identifier MUST be unique and meaningful within the deploying implementer's environment.
: REQUIRED. A JSON array of Strings, each an implementation-specific identifier for a destination of the notification (e.g., an email address such as `manager@example.com`, or a queue/topic name). The array MUST contain at least one element. Each identifier MUST be unique and meaningful within the deploying implementer's environment. The PEP MUST transmit the notification to every destination listed in the array; the obligation is satisfied only when transmission to all listed destinations succeeds. If transmission to any listed destination fails, the PEP cannot comply with the obligation, and, per {{non-compliance}}, MUST treat the overall response as a DENY, regardless of whether the original `decision` was `true` or `false`.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PEP MUST transmit the notification [...]

Is this something we can test for when we develop the conformance testing suites? And in case we can't test for conformance, is the MUST here a problem?

: OPTIONAL. A String. A short, high-level subject or purpose for the message, e.g., an email subject line, or a routing topic identifier for a pub/sub transport.

The following is a non-normative example of a `notification` obligation:
If the AuthZEN request that gave rise to this decision included a `context.decision_subject` element -- an implementation-defined identifier for the entity the authorization request pertains to, which is typically distinct from the requesting `subject` (for example, the patient whose record a doctor is requesting access to) -- the PDP MUST include that identifier as an additional destination in the `to` array of every `notification` obligation it issues for that decision, so that the decision subject is notified alongside any other configured destinations.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quoting Anivar Aravind from the mailing list thread: MAY rather than MUST, since using it as the destination stays the policy author's choice, same as everything else a PDP resolves internally

I think are arguments both for MAY as well as MUST, but probably worth debating it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants