# Meeting Notes 2024-0409

## Attendees
👉 Add your names here
@omri
@gerryatstrata
Allan Foster
Alex Olivier
George Fletcher
Jeff Broberg
Eve Maler
Jamie Lin
Mickey Martin
@zirotrust (Atul)
Ash Narkar
@davidbrossard
Victor Lu
Roland Baum
Wade Ellery
Steve Venema
Bjorn Hjelm
Scott Guyer

## Agenda
- Can we change the time of this meeting?
- Some discussion of different approaches to accommodate as many people as possible
- Separate meetings?
- Rotate times between early and late PT?
- One call per month that is APAC friendly?
- David B will put the options in a poll and send to email list
- David is working on Glitch
- Built an environment for the AuthZEN interop
- https://glitch.com/~openid-authzen-interface
- Omri's updates to the spec
- Some inconsistencies in spec and interop payload
- Made a set of changes to make the spec synchronized with the interop payload
- Two end points: evaluation and evaluations
- All interop implementations should adopt the "evaluation" endpoint
- Talk about next steps on API spec
- boxcarring?
- search API?
- GF: what about including obligation/advice support
- DB: if we separately target single requests from multiple requests, they should not introduce breaking changes
- AF: Advice is more interesting because it is the model that many apps use for things like step up authN. Obligations introduce a new burden
- DB: The plumbing for obligations and advice are the same and therefore it simplifies the spec
- EM: There’s a way to treat different obligation semantics as extensions, and possibly to require the PEP to indicate its intent to accept particular such semantics
- SG: What if obligations are left to an extension?
- OG: Prefer if ob/ad are included in advanced profile, rather than basic permit/deny
- GF: Ability of PDP to inform PEP about information is important and an MVP capability.
- AT: Thinks there is a distinction between 2 models where PEPs are more or less intelligent
- JB: Important to deal with advice so we have a standardized way of approaching it going forward and not have this significant difference between basic and advanced spec
- DB: it could contain a simple json payload, to trigger MFA for example.
- DB: Could also look at prior art to see how different systems implement this function
- AT: capturing some of the conversation in the chat, we use a reason code but could use advice instead.
- GF: Thinks advice is needed for MVP and obligation could be optional
- OG: Atul already put some mechanism in the draft for handling additional data. Likes David's idea of a json payload. Influences the complexity of the PEP. Should not conflate topics of multiple decisions and obligations/advice
- DB: Ob/Ad always required more work on PEP side to interpret content of message.
- AF: Per David's comment, challenge to interop - how to standardize the effect of the ob/ad
- AT: The easier we can make this for PEPs, the better. If there are some concrete semantics, that would be beneficial
- OG: Many discrete scenarios that do not conflate authN and authZ. Don't cross the streams.
- AF: Advice doesn't tell PEP to do anything. You received a deny, but you can also do something to get a permit
- GF: Many network examples or machine scenarios are fine with simple permit/deny. But for humans, ob/ad is needed and can be domain specific in some cases. We want to build something more abstract.
- OG: Liked Eve's approach of providing a framework so that anyone can create specific profiles.

- Previous meeting recordings: https://m.youtube.com/playlist?list=PLKSWk7HHDSMAlnNG58Iv5j2k_BCYYaunj
- [GitHub Pages build is broken](https://github.com/openid/authzen/issues/87)
- It seems to be broken for 2 months now

## Action
Omri to take a look at the reason code in the current spec and come up with a proposal for adding context

- PR from @omri: https://github.com/openid/authzen/pull/90

All 3 AuthZEN implementations now support the `/access/v1/evaluation` endpoint.