[Openid-specs-authzen] Obligations and Advices
Alex Babeanu
alex.babeanu at indykite.com
Sun Mar 15 18:01:26 UTC 2026
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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20260315/9ee062a4/attachment.htm>
More information about the Openid-specs-authzen
mailing list