Scenario The next interoperability demonstration will focus on the Search API (Draft 03). https://openid.github.io/authzen/ Description We have a basic web app that allows users to get access to records. Records have metadata associated with them: owner

Scenario The next interoperability demonstration will focus on the Search API (Draft 03). https://openid.github.io/authzen/ Description We have a basic web app that allows users to get access to documents. Documents have metadata associated with them: owner

Request Format The request follows the same pattern as an AuthZEN evaluation request. The main difference is that one of subject action resource may be omitted. The type attribute must always be specified.

Attendees Jeff Lombardo Gert Drapers George Fletcher Victor Lu Alex Olivier Gerry Gebel Omri Gazitt David Brossard Vladi Berger

Attendees Darin McAdams Jeff Lombardo Alex Babeanu Vladi Berger David Brossard Michiel Trimpe Partial Evaluation in Cedar Experimental feature for the time being

Attendees Vladi Berger Eve Maler Jeff Lombardo Gerry Gebel Julio Auto de Medieros Omri Gazitt Dave Hyland Amos Alubala Alex Babaneau

Attendees Michiel Trimpe David Brossard Omri Gazitt Alex Babeanu Gerry Gebel Eve Maler JF Lombardo Vladi Berger David Hyland

Attendees JF Lombardo Alex Babeanu Julio Auto De Medeiros Victor Lu Gerry Gebel Ravi Erakulla David Brossard Mat Hamlin Shannon Roddy

Attendees Gerry Gebel Andy Clymer JF Lombardo Roland Baum Dave Hyland Agenda Interop update Draft 03 of the specification

Created: Jan 23 2025 Updated: Feb 22 2025 (subject.type: "user" -> "identity") Context On March 25 2025, Gartner is holding their IAM Summit in London. AuthZEN has 3 interop showcase sessions secured. In addition to demonstrating the existing Todo application, which works with about 15 PDP implementations, we are also bringing in API Gateways as Policy Enforcement Points.

Attendees Gerry Gebel Alex Olivier Victor Lu David Hyland George Fletcher Agenda Gartner interop update

Attendees Gerry Gebel Michiel Trimpe Vladi Berger Omri Gazitt Phillip Messerschmidt Eve Maler Ahmet Soormally Roland Baum David Hyland

Author: Omri Gazitt Initial draft: Jan 13 2025 Update: Feb 20 2025 Update: Feb 22 2025: "user" -> "identity" Context API Gateways are natural AuthZEN Policy Enforcement Points (PEPs). An API gateway executes a set of filters before forwarding the request to the endpoint that it is proxying, and can execute a set of filters before returning the response to the caller.

Related documents Partial Evaluation Draft Decisions for partial evaluation API Notes Mixes use of JSON objects and object arrays, which may introduce unnecessary complexity on the client that needs to process the responseIn UC1-3, field decision in the response has a JSON object for value, but in UC4 it has an array. In the response, decision.partial is sometimes a JSON object, sometimes a JSON array The literals in the returned filter expression seem to be of the form <attribute> <op> <constant>.

Attendees Roland Baum Budhaditya Bhattacharya (Budha) - Tyk Eve Maler Agenda Partial evaluation update (David B) Action Search (David H) Interop participation update (Omri) Security review process by OpenID Foundation (David B)

--- abstract The Authorization API enables Policy Decision Points (PDPs) and Policy Enforcement Points (PEPs) to communicate authorization requests and decisions to each other without requiring knowledge of each other's inner workings. The Authorization API is served by the PDP and is called by the PEP. The Authorization API includes an Evaluation endpoint, which provides specific access decisions. Other endpoints may be added in the future for other scenarios, including searching for subjects, resources or actions. The Action Search API defines the message exchange pattern between a client (PEP) and an authorization service (PDP) for returning all of the actions that match the search criteria. The Action Search API is based on the Access Evaluation information model. The Action Search API Request {#action-search-request} The Action Search request is a 3-tuple constructed of three previously defined entities:

Top level response options (allow/deny/partial) How should we indicate, at the top-level, whether an evaluation is partial or full with a given result? Deny and allow operators { "decision": { "operator": "allow" } } {

Step-up Request Response Request Initial request by PEP without any indications of which residual policy types are supported. { "subject": { "type": "user", "id": "alice@the-smiths.com" }, "action": "read",

This API is designed as part of an access control and data filtering system to enforce user-specific access policies in a document management, data retrieval system or RAG for AI. Its primary purpose is to allow or restrict access to data based on predefined rules that specify which documents or records a user can access and under what conditions. Here’s a breakdown of how this API works and what it achieves: Decision-making for Access Control The API operates as a Policy Decision Point (PDP), which evaluates the user’s access rights against a policy and returns specific instructions to the Policy Enforcement Point (PEP). These instructions help determine whether a user is allowed to view or perform certain actions on documents or data entries. Data Filtering and Search Guidance The returned decision is not just a simple allow or deny response but includes detailed filtering conditions to help the enforcement point (PEP) apply granular access rules based on the user's attributes, such as ownership or department. For instance: In the response, users who are either the document owner (e.g., alice@the-smiths.com) or are part of the sales department are permitted to read specific documents.

Attendees omri Gazitt David Brossard Michiel Trimpe Vladi Berger Amos Alubala Gerry Gebel Eve Maler Alex Babeanu Roland Baum