[Openid-specs-authzen] Obligations and Advices

Tue Mar 17 18:22:52 UTC 2026

Hey Omri !
Welcome back !

So I like the profile idea, it makes sense, and we can decide on shifting
to it during our next discussion. I also like adding this to the
capabilities metadata.

Note that the current PR already proposes some normative obligations, as we
discussed in our last meeting. That list of standard Obligations could be
expanded when needed.

Where I don't agree, though, is the negotiation flow. There's nothing to
negotiate: the PEP MUST deny/fail any obligation it doesn't understand or
cannot follow. That's clearly stated already in the proposal. Makes things
simpler too and ensures the obligations are actually carried-out. The PDP
doesn't need to care, it just issues the obligations; up to the PEP to be
compliant.

Sounds like there's a lot to discuss Thursday, between this and the MCP
proposal... :)
Cheers,

./\.

On Mon, Mar 16, 2026 at 5:47 PM Omri Gazitt <omri at aserto.com> wrote:

> (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
>>
>

-- 
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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20260317/9eaf5f23/attachment-0001.htm>