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

gerry gebel ggebel at gmail.com
Wed Jul 16 02:16:02 UTC 2025


plus the recording
https://zoom.us/rec/share/tKFMBP8djBq2OpupWC0QQO2jvlr8EKf6v_UG_PnKORMjklwzwGxcxXvL93XDFe8.675a8HLrfz4EFWCW?pwd=DLwn-Y7oD4QxS77fYgAAIAAAAPP-opJMDrW0MisN5r_Ea54AwCmwEVi0sVZIViE5xg9SwNXcxZLFVyFu2-c1E_neazAwMDAwMQ

Attendees

   - Alex Babeanu
   - Jeff Lombardo
   - Phillip Messerschmidt
   - Victor Lu
   - Gerry Gebel
   - Roland Baum
   - David Hyland
   - Eve Maler

<#Agenda>Agenda

   - OPA/Styra authzen todo implementation from Styra (
   https://github.com/open-policy-agent/contrib/pull/268/files)
   - Alex B has a presentation to review resource_id from the ReBAC
   perspective
   - Potentially moving the time for this call
   - AuthZEN briefing for EIC last week
   - More open issues to discuss
      - 278 Inconsistent use of reason…
      - 268 Security section needs details on Client AuthN failure
      - 250 Deny_on_first_deny… examples are cumbersome
      - 230 Search API statistics needed
      - 55 Sign access decision?
      - 46 and 47 Device ID and IP address

<#Notes>Notes

OPA/Styra

   - Omri has been talking to them about taking over the OPA integration
   and there is a PR has been reviewed and merged
   https://github.com/open-policy-agent/contrib/pull/268/files
   - They will try to host an endpoint for future interops

Resource_id

   - Alex goes thru his presentation
   - JL: Suggestion to change this to optional was not intended to be
   exclusionary
   - JL: Making resource_id optional can cover both optional and mandatory
   scenarios
   - JL: There could be scenarios other than create that also have this
   issue, such as list
   - OG: Reviewed first principles of creating a spec that can be
   implemented by the widest number of PDPs. We wanted a spec that comprised
   of a well formed request that could be sent to any of the participating
   PDPs. We also tried to keep semantics out of the spec and focus on syntax.
   What is missing is a practices/patterns document that provides guidance for
   certain use cases, such as create. If the PEP's objective is to interop
   with a variety of PDPs, then there is a minimum required to interop.
   - JL: Thinks the PDP may interpret some placeholder resouce_id in an
   inconsistent fashion.
   - OG: Believes we've gone to great lengths to accommodate to keep the
   spec focused on syntax but again we have not provided guidance that a
   practices/patterns document to address these questions because implementers
   are going to ask, "how do I do this?"
   - GG: This issue is now resolved to keep resource_id mandatory

Meeting time discussion

   - GG: with David B now based in Europe, we are looking for alternate
   times for this call
   - DH: Open for other times as long as it is not 4 am :-)
   - OG: Would prefer to have a single time to ensure consistent momentum
   - GG: Will address this offline

Issue 278 Inconsistent use of reason and pagination

   - see https://github.com/openid/authzen/pull/341
   - OG: suggest you go back to cleaning up reason and break this into 2
   PRs, AB agreed

Issue 268: Security section needs details on Client AuthN failure

   - Suggested text change to include SHOULD in this section "MUST respond
   with a 401 HTTP code and include the HTTP"
   - Alex will update accordingly

Issue 55: Sign access decision?

   - This will be addressed in a specific profile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20250715/a8820c6c/attachment.htm>


More information about the Openid-specs-authzen mailing list