# Meeting Notes 2024-12-03

## Attendees

Omri Gazitt
David Brossard
Vladi Berger
Gerry Gebel
Alex Babeanu
Eve Maler
George Fletcher
Dinesh

## Agenda
- Presentation of work items for 2025
- APIs
- Design patterns document
- Industry Outreach

## Notes

- API endpoints
- **Draft 1 (First Implementers Draft)** (1.0.01) - Evaluation API: this API is complete. This is now an immutable document, and implementers can target it.
- **Draft 2 - Jan: Evaluations API** (1.0.02): the overall principle is complete but we have outstanding ideas & feedback to walk through such as the ability to control the evaluation behavior (evaluate all, deny on first deny, allow on first allow).
- Omri to propose further clarifications on how to process evaluations on deny on first deny, permit on first permit, etc.
- **Draft 3 - Feb: Search and Partial Evaluation APIs** (1.0.03): this is our biggest work-in-progress.
- Partial Evaluation: Vladi has a draft proposal as did Atul in the original spec.
- Search: AlexB and Omri will come up with a proposal
a predicate-based API that returns predicates/filters
a listing API that returns the entitled data
- **Draft 4 (Implementers Draft) - March** (1.0.04): Discovery endpoint: Given that PDPs can support a subset of authorization APIs, we need a means to discover what that subset is. The discovery endpoint can give us that (and more).
- **June: Finalize AuthZEN 1.0** (1.0.05) and submit it for review as a "Final Specification"
- Conformance suites on the APIs
- Talk to Joseph Heenan to discuss creating formal conformance tests for AuthZEN
- Start building test harness
- `evaluation` API first
- `evaluations` API next once the spec is finalized
- `search` API last when we have agreement on the format
- The conformance tests focus exclusively on the well-formedness of the requests and responses aiming to cover all features of a request/response but do not intend to validate the semantics of the response (whether we get true or false is out of scope to the conformance suite)
- The conformance tests should highlight the mandatory vs. optional features of the request/response structures.
- Outreach: for AuthZEN to be successful, we need to spread the word and encourage others to implement AuthZEN (as did Curity; Strata has plans for internal use). There are different groups we can address
- the Analyst community: Omri and David are speaking to Homan F. from Gartner and we need more interactions with other analysts
- the IdP vendors/software: let's talk to Entra, PingAccess, Okta, Gluu, etc... to get them to implement a PEP in their product for a wide range of use cases (on us: define the use cases)
- the API gateways. I put together a list (thanks to Gartner's Mark O'Neill) that you can browse here: https://hackmd.io/@oidf-wg-authzen/target-integrations
- Others: SaaS, COTS?
- Design patterns: we need to continue that stream of work and publicize the results so we can guide practitioners into the adoption of externalized authorization
In particular in light of OAuth: how can we collaborate?

## Other Notes

- Note that there will be no meeting on Dec 24 or 31
- An interop is planned for Gartner IAM in London March 24-25, 2025
- Building SDKs for broader adoption
- Code that would live under github.com/authzen (not github.com/openid/authzen)
- Plug 'n Play
- Target popular languages: Typescript/JS, Golang, Protobufs, other
- George's areas
- Where can I go? (access policy)
- What can I do? (privileges)
- What are my limitations? (restrictions)
- AuthZ Lifecycle - access management

## Action Items
- Those of us who have vendors assigned (Vladi, Omri, Gabriel, David, Dinesh...) figure out a contact