[Openid-specs-authzen] Call notes

[Atul Tulshibagwale]

Hi all,
The notes for today's call are stored in the AuthZen GitHub Wiki here. I'm
also copying them below for convenience.

A couple of questions to think about:

   1. What should be the quorum requirement for AuthZen WG calls?
   2. Do we need "advice" in addition to obligations in AuthZen? Alex is
   working on adding obligations. You will find more details about this in the
   notes.

Thanks,
Atul
---
Meeting Notes 2026-03-12 <#Attendees>Attendees

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

<#Agenda>Agenda

   - Actions from last week
      - Finalize MCP/coaz profile - map AuthZEN format first.
      - 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>Notes

   - coaz spec not ready yet

<#Versioning-the-spec>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>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>AOB <#Actions>Actions

   -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20260312/9915a265/attachment-0001.htm>