[Openid-specs-authzen] Notes from today's call

[David Brossard]

Link to notes <https://hackmd.io/8OQVOCrbRt6g6_cFuPbO6A?view>

Meeting Notes 2024-04-16
 Comment
 Suggest edit
 Edit from here
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
OpenID Foundation Workshop 2024-04-15 Readout
Slides
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
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
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
define the obligation format for the response message
define the .well-known endpoint
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240416/50dfd34d/attachment-0001.html>