[Openid-specs-authzen] Meeting notes for Nov 14, 2023

[Gerry Gebel]

Hi all,

These meeting notes are also posted in the new HackMD section of the GitHub
repo, accessible here: https://github.com/openid/authzen/wiki/Meetings

Thanks to David Brossard for setting it up.

Feel free to add items to the agenda for the next meeting, likely on Nov 28

Meeting Notes for November 14, 2023
<https://hackmd.io/@oidf-wg-authzen/wg-meeting-20231114#Attendees>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)

<https://hackmd.io/@oidf-wg-authzen/wg-meeting-20231114#Notes>Notes
<https://hackmd.io/@oidf-wg-authzen/wg-meeting-20231114#Logistics>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.

<https://hackmd.io/@oidf-wg-authzen/wg-meeting-20231114#General-discussion>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

<https://hackmd.io/@oidf-wg-authzen/wg-meeting-20231114#GitHub-issues>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

<https://hackmd.io/@oidf-wg-authzen/wg-meeting-20231114#Reviewedclosed-issues>Reviewed/closed
issues

   - #51 “Subject Lookup Query”
   - #49 rename “Resource Query” -> “Resource Lookup Query”

<https://hackmd.io/@oidf-wg-authzen/wg-meeting-20231114#Useful-links>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20231115/e5d08155/attachment-0001.html>