Profile/obligations

[baboulebou]

First draft of the AuthZEN Obligations profile.

• Takes into account the latest group discussions (as of 07/03/2026)
• Includes: Obligation definition, normative Obligations and their IANA registration
• Obligation metadata for PDPs
• Obligation negotiation protocol for PEP-PDP interaction.

[ogazitt]

@baboulebou This is a really solid first draft, thank you!

I have a few comments:

1. s/AuthZen/AuthZEN/g
2. s/GRANT/PERMIT/g
3. it would be great to have the obligation type have a mandatory type and id as you suggest, but then put any type-specific members in an ext JSON object. This makes schema (both for jsonschema and especially for protobuf mappings) much more valuable since the obligation doesn't have to be typed as "struct" which doesn't provide any validation.
4. I don't think the search results add a context for every result in the array - I believe https://openid.github.io/authzen/#name-the-search-api-response shows that context is global for the entire response. The examples all confirm this. And I think for the purpose of obligations, this is completely fine - having context/obligations per result would be overkill IMO.

For expediency I have approved, subject to the changes I'd like to see before you merge this.

[ogazitt]

See my review feedback before merging

[graphel]

I know it's an aesthetic preference; but I'd prefer supported_obligations as a naturally readable phrase.

[baboulebou]

Agreed. Change made.

[graphel]

We should also offer support for a wildcard like * here; so that the PEP can efficiently indicate support for a broad range of obligation types.

The PEP then fails closed when it receives an obligation type it does not support.

So

 { "context" : { "supported_obligations": "vnd.cel.filter.*" } } 

or even

 { "context" : { "supported_obligations": "*" } } 

for maximum wire-format efficiency.

[baboulebou]

Not sure I agree with that one. What does it mean "all obligation"? It assumes the PEP "knows" ahead of time all the obligations that the PDP supports, and can enforce all of them. Otherwise, saying * for obligations it can't enforce or support is rather meaningless. Not going to make this change, we can discuss with the group if necessary.

[ogazitt]

I agree that “*” is an anti-pattern for capability negotiation. The set of known obligations will grow over time and a PEP that was deployed at time T1 can’t possibly know that it can support all the obligations emitted by a PDP deployed at a later time T2.