[Openid-specs-authzen] Meeting notes from Oct 02

[gerry gebel]

Hi all,

I'd like to alert everyone that we are approaching the review period for
Working Group draft 05. We plan to create the draft tomorrow (Friday) and
announce the 14 day review period on the call next week.

Recording:
https://zoom.us/rec/share/mR76Egmy3qqbn6CmrxKNLR5Q3IclM8oMjXTz_r6Xi9YXVJeEf6YJwes4oHWyCs-S.HyrQaEXZKYWkm4ac?pwd=DHIRpQqEctddkl8e2AAAIAAAAPmEq410WiF38i9wr4lw6tZKdJyu4kj4KESidV9l2z-Ylv7uDPiD3uP8WgUPSsqirjAwMDAwNA

Attendees

   - Jeff Lombardo
   - Michiel Trimpe
   - David Brossard
   - Alex Olivier
   - Gerry Gebel
   - Julio Auto De Medeiros
   - Dave Hyland
   - Edmund Jay
   - Vladi Berger

<#Agenda>Agenda

   - Final disposition of pagination topic (spoiler alert: only
   cursor-based is mandatory)
   - Review of closed issues and pull requests since last meeting
   - Discuss Michiel's comments from AuthZEN slack channel
   - Interop prep: final list of user data, access policies, and connection
   info for IDPs
   - Interop roll call for participants
   - Review process and timeline for 1.0 Final Specification

<#Notes>Notes <#Pagination>Pagination

   - We've decided to stick to cursor-based pagination
   - Michiel will keep a draft of offset-based pagination in his own repo
   in case anyone wants to create a later profile (post 1.0)
   - The chairs will merge the last outstanding PR tomorrow.

<#Schedule>Schedule

   - We will kickstart the ratification of draft 5 next week on the regular
   call
   - This starts a two-week window for internal WG review and approval
   - We will use the following 2 calls to take in comments and feedback.
   - Past this point, we will request OpenID start the 60-day public review
   period
   - This takes us past Gartner but we will already be on track so we can
   announce the upcoming spec at Gartner IAM TX '25.

<#Feedback-on-the-OpenID-AuthZEN-Slack-Channel>Feedback on the OpenID
AuthZEN Slack Channel <#URL-path-inconsistency>URL path inconsistency

Feedback from Michiel.

I’m working on the HTTPS binding section and I have a question regarding
the PDP base path. In PDP metadata we list the following example URLs:

{
  "policy_decision_point": "https://pdp.example.com",
  "access_evaluation_endpoint": "https://pdp.example.com/access/v1/evaluation",
  "search_subject_endpoint": "https://pdp.example.com/access/v1/search/subject",
  "search_resource_endpoint":
"https://pdp.example.com/access/v1/search/resource"
}

However in 4. API Version we say

All API methods for version 1.0 MUST be immediately preceded by the
relative URL path /v1/.

And I defined the method to determine default URLs like this:

   - The request URL MUST be the value of the access_evaluation_endpoint
   parameter if it is provided in the PDP Metadata (Section 11.1.1).
   - If the parameter is not provided, the URL SHOULD be formed by
   appending the relative path /access/v1/evaluation to the Policy Decision
   Point’s base URL (which is the policy_decision_point value from the PDP
   Metadata, if available).

That seems incompatible with each other…. does anyone know what is intended
here?

Suggested fix: add access in front of v1 in the first paragraph.
<#Allowing-other-bindings>Allowing other bindings

And as a second concern; the API version requirement enforces that we use
URLs and thus HTTP(S) for the API.
The Transport section however states:

Additional transport bindings (e.g. gRPC) MAY be defined in the future in
the form of profiles, and MAY be implemented by a PDP.

Even though gRPC is also HTTP-based, the wording seems to imply that
non-HTTP transport bindings can also be added.
To clarify that we should either:

   - be explicit in the Transport that different serialization formats may
   be allowed; but all transport happens over HTTP(S)
   - state that the API version should contain /v1 when using HTTP or move
   that requirement to the HTTPS transport binding altogether
   Which way should we go there?

WG decision: we should reword to make

   1. The HTTPS/JSON binding normative (as it is today)
   2. Add text that says future bindings (not just HTTP) are possible
   through dedicated profiles.

<#Component-Naming>Component Naming

One final point which would be nice to tackle before going to final is
regarding consistency in terminology.
Currently the spec refers to the server in these ways:

   - authorization service (PDP)
   - Policy Decision Point service
   - Policy Decision Point
   - Policy decision point
   - PDP
   And it refers to the client in these ways:
   - PEP
   - Policy Enforcement Point
   - API client (PEP)
   - client (PEP)
   - client(s)
   - Consumer(s) of the metadata (in “PDP Metadata” section)
   The easiest would be to just use PDP and PEP everywhere; but Search APIs
   can also be called by UIs directly so in those cases it’s not fully
   accurate.

WG Decision: we will stick to PEP and PDP terminology. We can add a
paragraph in the spec (non-normative) that explains PEP in the broader
sense (search, boxcarring)
<#Demo-Update>Demo Update

   - David produced a diagram that needs refinement - see
   https://hackmd.io/1xG8MxATR_KsuYF7fXOVoA?both
   - Jonas (Curity) is ready to be integrated
   - Alex O. needs the sample data to be set in stone before onboarding a
   new IdP
      - David will provide the sample data ASAP.
      - Alex & David will sync up tomorrow

<#Participant-Outreach>Participant Outreach

   - See https://hackmd.io/@oidf-wg-authzen/idp-demo-participants
   - Make sure to check IdP and PDP lists
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20251002/ce2abd67/attachment.htm>