# Meeting Notes 2025-10-02

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

## 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
### 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
- 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
#### 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

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

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

- 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
- See https://hackmd.io/@oidf-wg-authzen/idp-demo-participants
- Make sure to check IdP and PDP lists