# Meeting Notes for November 14, 2023 # Attendees - Elie Azerad (independent) - Gerry Gebel (Strata Identity) - David Brossard (Axiomatics) - Atul Tulshibagwale (SGNL) - Omri Gazitt (Aserto) - Roland Baum (Umbrella Associates) - Alex Babeneau (3edges) - Victor Lu () - Mike Leszc (OIDF) - John Bradley (Yubico) - Bjorn Hjelm (OIDF) - Tom Clancy (MITRE) - George Fletcher (CapitalOne) # Notes ## Logistics - Atul shares how shared signals is using HackMD for agenda management and meeting notes. David will set it up for us so we can use it going forward. - There is a poll in slack for whether a meeting should be held next week due to the Thanksgiving holiday in the US. Please indicate your preference here and we will make a decision by the end of this week: https://oidf.slack.com/archives/C0630873JGK/p1699981993068479 - Andrew has stepped down as a co-chair due to an employment change. ## General discussion - Alex incorporated comments into the design patterns document - Roland began writing a document on use cases and is up to 9 pages so far. Omri and others asked to see the draft before it is shared with the wider group ## GitHub issues We spent most of the call on issue #52, which covered a lot of ground. - Roland suggested that the PDP send additional information to the PEP regarding the response, particulary in situations where the PDP evaluation resulted in some kind of error condition - Atul pointed out the error codes and status fields in section 3.11 - David: there are standard codes like 200, 4xx, 500, etc, but need to be careful about revealing too much information that an attacker could abuse - Roland: there is a difference between the HTTP interaction ad the authorization interaction - George: getting deep into design, but need to make decision on HTTP vs REST principles. Agree that we should not release too much info to attacker. But, can client do something based on error returned, then it is useful to add error messaging. If you have a 500, then you have some internal system error - then you know to retry. Whereas a 429 is a different kind of error. - David: My experience is that developers are use to handling permit/deny, but not for handling error conditions. A lot depends on how the PDP handles error messaging. Agree that we should use error messages accord to REST model. - Alex: If the response is other than Permit/Deny, then the error messaging needs to accommodate those use cases - David: XACML has model to provide additional information with advice/obligation statements, but specific to how dev handles it. Looking at 3.9.2, not sure PDP should respond with a reason - don’t want to make it a MUST - Atul: Spirit of API is PDP is instructing the PEP what to do. Reason is a MUST but could be given as an identifier. - Omri: Whether we want to have one specific API for simple use cases and have an additional API for extended queries - do we have one or two APIs? I would prefe to define a strict API and have an additional API for other use cases - Atul: Current doc has both, or are you suggesting something different? Current approach is to send an array of requests and return an array of responses. - Omri: There may be systems that can evaluate multiple requests at the same time and may be hard to assume all PDPs operate this way. There are a lot of similarities but lots of differences in underlying authZ systems. - Atul: Approach is the PEP can be as simple as you need and PDP can be as complex as you need. The way the API has been designed will require the PDP to support more complexity. - Roland: Can we use the SAML metadata approach to expose functionality that is supported? - George: Do we need a couple of patterns here? The simple one is the PEP is going to do what the PDP says. There may be other cases - do we need to have layers or profiles? In the context of OAuth and the step up RFC, would be nice to receive DENY plus what you need to do to ask for access. Also, some apps will want to know what user can do (admin button, transfer limit, etc). Need to create different APIs or ways to layer in this functionality. - Atul: It's been a while since we first shared the doc, so I can do an overview of the doc on the next call to summarize the existing spec - all agree ### Reviewed/closed issues - #51 "Subject Lookup Query" - #49 rename "Resource Query" -> "Resource Lookup Query" ## Useful links - GitHub issues list: https://github.com/openid/authzen/issues - Draft authorization API: https://openid.github.io/authzen/ - Draft use cases document: https://docs.google.com/document/d/1pOoqKkPgM_VNOfeB6wNSK_H2C--iZeIxR0DHKzeT3rI/edit#heading=h.c6l7q38c1zpl