-
Notifications
You must be signed in to change notification settings - Fork 37
Meeting Notes 2026‐02‐05
Alex Olivier edited this page Feb 5, 2026
·
1 revision
- Alex Olivier
- Atul Tulshibagwale
- Thomas Tran
- Robin Vanhove
- John Jiang
- Martin Besozzi
- Edumand Jay
- Roland Baum
-
SDK Promotion
- We will link from webpage/GitHub
- Go (Gert), .NET (RSK), Java ( @davidbrossard )
- Any more:
- Python
- JS
- Rust?
-
Certification questions (@alexolivier)
-
Open questions
- Certification levels: Given we have different endpoints, should we have levels?
Level APIs Covered Description Basic Access Evaluation Single request/response decision Batch Access Evaluations Multiple decisions in a single request (boxcarring) Search Subject Search, Resource Search, Action Search Searching of authorized entities -
Unknown entity types in search: The spec defines search results as "zero or more entities", so empty results for unknown identifiers within known types are clearly valid. However, the spec does not specify behaviour when the entity type itself is unrecognised by the PDP (e.g. searching for type
"spaceship"). Should PDPs return an emptyresultsarray or HTTP 400? - Fixture size: Is the current fixture (2 subjects, 2 resources, 3 actions, 8 known decisions) sufficient? Or should it be expanded to cover more edge cases eg pagination? The tradeoff is implementer burden vs. harness coverage.
- Pagination testing depth: Should the harness require PDPs that advertise pagination support to demonstrate multi-page results? This would require a larger fixture to generate enough results for pagination.
-
AOB
- Certification testing (Alex O)
- API Gateway profile (Gert, David)
- MCP/A2A profile (Atul, Alex B)
- Obligations profile (Alex B)
- Partial evaluation (David, Julio)
- Protocol Bindings - gRPC (Gert, Julio)
- Contact external vendors -> Adopt AuthZEN, reach-out
- Gartner IAM London March 9th 2026
- The agenda lists the AuthZEN session
- European Identity Conference Berlin May 20th 2026 - we have a few sessions including with OpenID and EIC will likely give us a breakout room for the WG to work.
- David talking to Forrester to see whether they want to host interop events
-
SDKs
- Martin - Can we have an authorization sidecar in front of API
- Thomas - isn't this is the API gateway? The app layer still needs to know the format
- Martin - just use a proxy (api, mcp gateway etc) to delegate the authZ
- AlexO - depends on the use case if the sturcture is know
- Thomas - on if you are a consumer or supplier what you expose. App team exposes an endpoints and delegate the API gateway
- Martin - the application layer shouldn't know, its handled before it gets to the app layer. Foward the token along the chain.
- Need differniate between 'code' sdks and 'app plugins'
- Thomas - are we going to have certification for SDKs?
- Edmund - normally they can certify it, but the vendor would have to have the program around it to test
- Thomas - could there be a door open in the certfication framework to use a different SDK rather than raw HTTP calls?
- Edmund - other specs require the SDK vendor to build a wrapper around it to take the HTTP and call the PDP via the SDK
- Edmund - they can certify each version of the SDK. they pin the certifcation against a specific build of the SDK
- Alex - any prior art?
- Edmund - don't get many SDK certification work but possible. Recommend having every major version of an SDK to be cerrtified. Look at OpenODIC and FAPI (speak to Phillip Skulkin)
-
MCP Proposal
-
Certification
- AlexO - do we need levels?
- Martin - core is the check, others are optional. eg OpenFGA does evaluations.
- Edmund - we can make seperate certifications for batch & search. Discovery can be part of the test config to be static endpoint or use the discovery. These would be seperate test plans.
- Thomas - FAPI has one certification with multiple profiles.
- Edmund - FAPI has country specific profiles as well.
- Thomas - do we want to keep the fixture set consistent between the 'profiles'.
-
AuthZEN MCP proposal
- Atul - two issues (MCP and AuthZEN repo)
- Martin - MCP repo is about starting the conversation around AuthZEN support. Authzen repo is to start defining the actual profile.
- Maritn - been building an MCP gateway using AuthZEN to start forming the profile.
- Atul - are we changing the API?
- Martin - trying to follow the spec and mapping the MCP structure to an AuthZEN subject/action/resource model.
- Martin (https://github.com/openid/authzen/issues/429)
- MCP adopted OAuth2
- Mapping subject to the bearer token
- Is the subject type an agent?
- Atul - when we are talking about subject, we aren't always meaning the end user, its the identity being authorized. How does this work when the agent is acting onbehalf of a user? Would the subject be the agent identity or the user identity?
- Roland - the "properties" was always "open" for custom elements - negotiable between PDP & PEP. i don't understand why it should be made mandotory, because the current structure already supports this usage ?
- Martin - the proposal is just a example of how to structure the properties from a provided access token.
- Atul - its not mandatory, its showing how to populate the request
- Thomas - believe the acr should remain in the token. The PDP can't trust the MCP server to provide it.
- Atul - the entity calling the API is providing the data and getting the answer. garbage in, garbage out. Proposal is how to pass the data, not trust model.
- AlexO - mapping ther arguements can lead to very large messages eg a Write tool has the whole file contents.
- AlexO - the list operations use /evaluation rather than /search?
- Martin - if authZ is at the gateway then it doesn't know the tools
- Alex - this is more an MCP Gateway profile rather than the server level? Yes
-
AOB
- Mattermost looking to implement AuthZEN