[Openid-specs-authzen] Obligations and Advices

Tue Mar 17 00:47:00 UTC 2026

(I'm back from the dead :))

Seems reasonable to me - specifically that the context field in the
response can include any information, so "advice" is already in essence
part of the spec.

With respect to having a formal concept of "obligations", I would assume
the following:

   1. Optional mechanism - many use-cases don't require this so it's not
   mandatory that a PDP implements obligations
   2. Therefore, likely belongs in a profile
   3. Requires capability negotiation in *both directions*:
      - PEP can use the metadata endpoint to find out if the PDP supports
      obligations, and indeed *requires* them to be honored as part of the
      interaction.
      - PEP would need to be able to indicate to the PDP that it
      understands and honors obligations (back in 2024 we discussed this and
      agreed this would be communicated in the request's context field).
      - So the message exchange pattern looks something like the
      following...
         - PEP calls the metadata endpoint, decides whether this is a PDP
         it wants to talk to based on whether the PDP supports obligations
         - PEP sends an evaluation request with "context.obligations: { ...
         }" or something equivalent (where the "..." needs to be
explicitly defined
         in the profile)
         - PDP sends a response with an optional "context.obligations: {
         ... }" (where the "..." needs to be explicitly defined in the profile)
         - PEP honors the obligations
      - Would need to specify what happens if a PDP that supports
      obligations gets a request from a PEP that is unaware of
obligations (e.g.
      a v1 PEP or simply a PEP that doesn't need that capability) -
does the PDP
      always return decision: false? Does the PDP simply omit the
      context.obligations field? Perhaps this is a setting on the PDP, and
      outside of the purview of the spec (or carry the SHOULD / RECOMMENDED
      terminology?)
      - Since the obligations themselves carry semantics, would likely need
      a "registry" of obligations so that the PEP and PDP can actually agree on
      *which obligations* they both support

In other words, a fair number of moving parts, which seem required not only
for proper specification of obligations, but also for back-compat (old PEPs
calling new PDPs and new PEPs calling old PDPs), and to make sure that both
PEPs and PDPs that have no need for this useful, but optional, capability
can continue to use the existing spec without issues.

So, given all the moving parts, I would assume this capability is delivered
through an "AuthZEN 1.0 profile for obligations" or similar.

Cheers,
Omri.

On Sun, Mar 15, 2026 at 11:01 AM Alex Babeanu via Openid-specs-authzen <
openid-specs-authzen at lists.openid.net> wrote:

> Hi all,
>
> If you missed last Thursday's weekly call, we discussed *Obligations* and
> *Advices* in AuthZEN responses. Much of the debate hinged on whether we
> actually needed both concepts. I argued that Obligations were sufficient
> for AuthZEN, some disagreed. We ended-up casting a vote during the call: of
> the six participants, only two expressed their conviction that Advices were
> necessary.
>
> I'd like to quickly justify why Advices are redundant and unnecessary in
> AuthZEN. I'm basing this on the following references:
>
> - *XACML* :
> https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html
> - *NIST SP 800-162, ABAC:*
> https://www.nist.gov/publications/guide-attribute-based-access-control-abac-definition-and-considerations-1#:~:text=Special%20Publication%20(NIST%20SP)%20%2D
>
> - *NGAC*: https://webstore.ansi.org/standards/incits/incits5652020
> - My Friend *Gemini* found other sources: a few additional academic
> papers I didn't know about.
>
> *Obligations* are actions that the PEP MUST perform, regardless of the
> decision. If the PEP cannot comply, or the actions fail, then the PEP MUST
> change the decision to `false` ("Denied"). I think everybody agreed here.
>
> *Advices* are supplemental information provided to the PEP that can be
> safely ignored. All literature (well XACML mainly) points to the fact that
> Advices are there just to supply information, metadata or reasons for the
> decisions.
>
> Comment: Only the XACML specification formally defines Advices. Both
> NIST's ABAC and NGAC papers, as well as several academic papers, completely
> ignore Advices (I invite you all here to do your own research).
>
> Consequently, we do not need advice because the context response element
> already serves the same purpose. Anything that is not a set of
> actions/instructions that the PEP MUST follow can already be expressed in
> other parts of the context response element. Adding "Advices" would be
> redundant and very confusing, as we saw during our debate Thursday.
>
> Obligation Examples:
>
> - Response: Denied (false) + Obligation: Must perform MFA => The PEP must
> force the subject into an MFA flow. The request is still denied, but maybe
> this was an attacker's attempt, and the PDP determined the Subject required
> stronger authentication. The next request may succeed, but the current
> request failed regardless.
>
> - Response: Granted (true) + Obligation: Must perform MFA => The PEP must
> force the subject into an MFA flow, but the PEP should now deny the request
> if it cannot comply, or if the user fails the MFA challenge.
>
> I'd therefore like to put this matter to rest. But of course, please
> express any concerns, but in that case, please also provide citations or
> references.
>
> Regards,
>
> ./\.
> --
> Alex Babeanu
>
> Lead Product Manager
> AI Control Suite
> [image: mobilePhone] +1 604 728 8130
> [image: emailAddress] <https://mail.google.com/mail/u/0/goog_101932960>
> alex.babeanu at indykite.com
> [image: website] www.indykite.com
> [image: linkedin] <https://www.linkedin.com/in/ababeanu/>
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20260316/5b753b76/attachment.htm>