# Meeting Notes 2024-04-16

## Attendees
👉 Add your names here
@gerryatstrata
Allan Foster
@davidbrossard
Roland Baum
Granville Schmidt
Jeff Broberg
Eve Maler
Jason Garbis
Joshua Roberts
Eric Hoffman
Jamie Lin
Elie Azerad
Daniel Katzman
Mickey Martin

## Agenda
- 🕐Meeting Time
- Please fill in the [survey](https://www.surveymonkey.com/r/226W6FM)
- OpenID Foundation Workshop 2024-04-15 Readout
- [Slides](https://docs.google.com/presentation/d/1Z-g-e6TMUGDYW3PI2yF6rcphjb8SlgrO/edit#slide=id.p1)
- Omri's updates to the spec
- Eve's email on advice & obligations
- Design patterns
- Alex is OOF. Conversation deferred

## Notes

- 🕐Meeting Time
- Please fill in the [survey](https://www.surveymonkey.com/r/226W6FM)
- On the call, given we have 13 answers of which 10 are for a single call, we decided to go for alternating calls. 11am PT on even weeks and 3pm PT on odd weeks. Week numbers can be found in calendar apps as well as https://vecka.nu/.
- Survey responses: https://www.surveymonkey.com/results/SM-cl5wjcFkEnFLFxujpXYZdA_3D_3D/
- OpenID Foundation Workshop 2024-04-15 Readout
- [Slides](https://docs.google.com/presentation/d/1Z-g-e6TMUGDYW3PI2yF6rcphjb8SlgrO/edit#slide=id.p1)
- The feedback in the room was that the group made good progress on the interop
- Omri's updates to the spec
- Deferred to next week as Omri is speaking at IIW
- SGNL now supports AuthZEN becoming the 4th implementation
- Hexa (Strata) and Axiomatics are hoping to complete their implementation within the next few days
- Eve's email on advice & obligations
- Eve Maler: look at HEART and FHIR for inspiration on how obligations & advice should work
- Allan Foster: it's hard to define what needs to happen until you have a specific use case wrt obligations. We don't want all requests to become a double request
- DB: XACML did sort of allow for that (though a lot of the legwork is at the PEP which isn't fully spec'ed out):
- PEP - Can Alice view record 123?
- PDP - Deny + augment auth
- PEP does auth augmentation
- PEP - Can Alice who is MFAed view record 123?
- EM: some frameworks are very sensitive to time constraints, others to security/privacy
- AF: we almost need some kind of authority that implements the advice/obligation.
- EM: we almost need a discovery / .well-known endpoint in the authorization service much like there is one in OAuth.
- EM: See also https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#as-config
- AF & JG: rate limiting example
- Mickey M., Roland B., David: use of obligations for data filtering e.g. Can Alice view records? Yes only for US-based clients. That's an abuse of obligations (DB). It's akin to the search use case (RB)
- JG: Can we assume that we don’t have to solve for dynamically added PEPs right now, and therefore during an onboarding process we can define and get agreement on PEP capabilities, and semantics?
- GG: there could be a negotiation at start-up between PEP and PDP
- DB: we need to take different steps
1. define the obligation format for the response message
2. define the .well-known endpoint
3. agree on default PEP implementations?
- Design patterns
- Alex is OOF. Conversation deferred

## Action Items
- Who is willing to start formalizing what we want to achieve with obligation/advice?
- We need to write down what it means wrt the spec