# Meeting Notes 2026-03-12

## Attendees
- Atul Tulshibagwale (CrowdStrike)
- Alex Babeanu (Indykite)
- John Gren
- John Jiang
- Roland Baum
- Edmind jay
- George Fletcher

## Agenda
* Actions from last week
- [ ] Finalize MCP/coaz profile - map AuthZEN format first.
- [X] AlexB - revive the obligations spec
* Gartner IAM Recap
* Typos in schema - https://github.com/openid/authzen/pull/446
* Talk about process for Profiles, SDKs, OpenAI spec, PRs etc.
* Upcoming talks - who else will be there?
* EIC (David, AlexB)
* Possible Forrester engagement
* Possible Identiverse session
* Authenticate CFP (David, AlexO)
* Certification progress (Edmund adding to harness)
* Todo: how to name the certification levels/tiers?
* XACML profile for AuthZEN (DavidB)

## Notes
- coaz spec not ready yet

### Versioning the spec
* (Atul) We will create a new draft called "1.1 - draft1", which will be in a file named "authorization-api-1_1.md". The Draft 1 will be maintained until this is proposed as an implementers draft, but the date will change based on the checkins
* The first check-in to this file will not have any changes over the 1.0 draft
* The changes will be added into the second check-in onwards, so that the PR shows diffs from the 1.0 draft clearly.

### Obligations
* (Atul) Why only obligations and why not "advice"
* (Roland) Obligations could be problematic in some situations
* (Atul) One place where advice could be useful is say the server wants the client to use MFA, but it doesn't obligate the client to do it.
* (Atul) I don't have a good example of using advice in the "allow" case
* (John G) Obligations would be say "in order to access this resource, you need to present higher authentication". The obligation would be for the client to redirect the user to IdP for MFA. Whereas in the advice case, the client won't be obligated to do that.
* (Alex) We discussed this in a previous meeting, and may be we don't need it.
* (Atul) If the PDP and PEP evolve differently, the PEP may not be in a position to fulfil the obligation, which is why you might need advice.
* (Alex) I'll look into adding it.
* (Alex) Advice might follow the same structure as obligations
* (Roland) It may be at the top-level, because if not it might be ignored by the PEP
* (Roland) It would be good to get vendors / users to provide defined behaviors for obligations and advices in order to standardize the "id" field URIs. Every PEP may not have a way to "notify manager"
* (Atul) Having a base set of advices or obligations will help interoperability
* (Roland) There could be some more logic in the obligation response. E.g. no transaction > $50
* (Alex) Won't that be included in the request? (the value of the transaction)
* (Roland) It might or it might not be in the request. The request may be "is the user allowed to spend money?".
* (Alex) I don't want to step over into another topic, viz. Partial Searches.
* (Roland) Obligations sound more process related
* (Alex) True. Like "do something"
* (Roland) What are the standard set of obligations
* (Alex) Just for now, it is interesting to formalize a list of actions, e.g. MFA, notifications,
* (Roland) In the deny case, "terminate session" might be an obligation
* (George) One obligation could be "re-establish session". Another core action in IPSIE is "invalidate everything". This is in the context of an enterprise scenario, where you need to invalidate all active sessions, including access tokens, refresh tokens, etc. These two capabilities are being discussed right now.
* (George) There are some larger questions here.
* (George) We should be able to find it in the IPSIE notes. It's a document that Karl McGuiness is proposing.
* (George) Another thing I want to talk about: ACR, scope, max_age are things from OAuth. But OAuth cannot say "the user needs to follow this policy", which the PDP may be in control of, or it might belong to another PDP. The PEP may or maynot have any clue as to how to implement the specified policy. It is a DENY with an obligation.
* (George) In the context of "step up", it should not be an accept.
* (Roland) An obligation should never change the result of the authorization call. I.e. DENY means DENY.
* (George) The PDP needs to communicate additional context in case of the deny.
* (Alex) Perhaps that is the advice.
* (Roland) The MFA use case is like this.
* (John G) I agree. I'm also thinking of the relationship to SSF. Another case I'm seeing a lot is the ability to instruct the PDP to mask or redact certain fields. This is not at the authorization level, but at the data level.
* (George) In Roland's MFA case, I'm trying to figure out how its different from an obligation. We're just communicating to the PEP to do something to get over the DENY.
* (Alex) This is just about precision.
* (George) The URI would be known to the PEP, should the other be allowed?
* (Roland) How about AI uses cases. You could do obligations. How about PDP chaining? One PDP obliges another PDP to do something.
* (John G) We talked about giving instructions about the session TTL. But this could be managed in the access token lifetime. In agentic delegation, we recognize that the session should be task based, and it should be short-lived. Do we want to govern the policies regarding a session as an advice?
* (Roland) This is a use case for an IdP
* (Atul) I think sessions should be governed by tokens. AuthZen is a point-in-time system, so we should not have any lifetime concerns there.
* (Alex) Should we do this with RAR. I'd like to investigate that
* (John G) We're also looking into how we can separate the consent from the permissions. Can we embed the scope based RAR from the user consent into the token and the PDP can decide based on that.
* (Alex) I'm trying to figure out a way to standardize intent through RAR
* (Alex) We'll look into IPSIE for standard obligations, but there are some we can think of:
* Human in the loop
* Chaining
* Invalidate everything
* Re-authenticate user
* (Alex) If we have these and custom in addition, then that could cover a good amount of the ground.
* (George) The IPSIE command is "invalidate access".
* (Alex) Step up could be an advice or an obligation
* (Roland) Obligations are mandatory, and advice is not. If a PEP is not able to comply to advice, then its OK. If it's an obligation, then the PEP must fail.
* (Alex) In either case we aren't changing the authorization result.
* (Roland) It seems to me that obligations don't make much sense in the DENY case.
* (Alex) Advice would help in the DNEY case.
* (Atul) Roland's thought is interesting: Are obligations more meaningful in ALLOW, and advice in the DENY case?
* (Alex) not true, because ...
* (Roland) The clarification based on something the PDP is allowing.
* (Roland) The PDP could allow, but request the PEP to do MFA.
* (Atul) Would that be a DENY in that case?
* (Roland) It depends on the PDP.
* (Alex) Assurance level may be a better example.
* (Roland) Speaking of data, the obligation could be...
* (Michael) A governmental use case which is common for us, the allow could be associated with an obligation like "logs should be retained for no more than x days".
* (Alex) That's an interesting one.
* (Michael) The obligations are things that the PDP wants to enforce, but cannot.
* (Alex) Obligations is all we need, otherwise it would confuse everyone.
* (Atul) Advice can help the user experience.
* (Roland) User experience could be within the error response.
* (Alex) Who is in favor of having advice?
* Roland and Atul raised hands
* (Alex) So those who did not raise their hands are in favor of having only obligations?
* (Roland) Obligations and advices are similar, except regarding the expectation relating to the client
* (George) In my context, would a PEP follow advice. If it is optional, why would the client do something?
* (Atul) In order to provide a better user experience?
* (George) I cannot vote until we clarify whether this is regarding allow, or deny.
* (Alex) I was avoiding this question. But if people feel strongly, then I can work on it.

## AOB

## Actions
-