# Meeting Notes 2024-03-26

## Attendees
👉 Add your names here
- @davidbrossard
- @gerryatstrata
- @omri
- Rifaat Shekh-Yusef
- @zirotrust (Atul Tulshibagwale, SGNL)
- @eaz (Elie Azerad)
- Roland Baum
- @hisgarden (Jin Wen)
- @alexbabeanu
- Jeff Broberg
- Allan Foster
- Sean O'Dell
- Mickey Martin
- Jamie Lin
- Victor Lu
- Joshua Roberts
- George Fletcher
- David Hyland
- Andrii Deinega
- Vladi Berger

## Agenda

- Interop update
- Design patterns (@alexbabeanu)

## Interop Update
(Omri)
There are now 2 compliant implementations (Cerbos and Aserto)

Sub repos
- AuthZEN-interop.net: static site generated from the docusaurus site in /interop/authzen-interop-website
- Contains the scenarios and the results pages
- To do app (todo.authzen-interop.net) in /interop/authzen-todo-application
- Back end: builds and deployes in Aserto k8s cluster in /interop/authzen-todo-backend
- Contains the test suite (/interop/authzen-todo-backend/test/assertions.json)
- Script to run the assertions (yarn test <pdp-url>)
- Set of PDPs (/interop/authzen-todo-backend/src/pdps.json)
- To add your PDP, email the URL (and implementation name) to [e-mail]

Test suite shows if an implementation is compliant

Ping Omri if you want to add your implementation, a drop down will allow you to select the PDP of choice

David, Atul, Gabriel and Alex are working on implementations

Q: is there a stub that implements the details? Interop payloads has been defined here: https://hackmd.io/gNZBRoTfRgWh_PNM0y2wDA
https://authzen-interop.net/docs/scenarios/todo

Eli suggested he could reach out to Kogito as a general purpose rules engine that could potentially participate

## Design Patterns document
https://hackmd.io/@oidf-wg-authzen/S1inmizEa

We have not looked at this doc in a while, since the group was working on the interop API

It could be useful to review the doc again as it can provide guidance for good practices for the audience we are trying to reach.

Reviewing some of the diagrams
- Provisioning
- Could also provision policies, not just roles or groups
- User Journeys
- Typically a scenario based on OAuth
- Different places for a PEP (app, API gateway or IDP)
- FGA could be inserted in different ways to make the implementation more dynamic
- PEP-PDP
- Is there an AuthZEN API interaction with an IDP? Via RAR profile?
- If an API gateway is in the flow, the PDP could return an ACL value (just for authentication)
- or you could make a call to the AS
- PDP could return data to the IDP AS for things like step up authN
- Are we including the Cedar policy work?
- That is likely outside our scope
- Less interested in implementation specific implementations
- We are interested in how AuthZEN interacts with other approaches
- IETF Brisbane update
- RAR-Cedar profile presentation
- missed the mark, because the put cedar policy in the payload instead of using AuthZEN profile
- not really the right place to determine what policy is evaluated
- there was some interest in embedding a policy in a token
- may be good idea to propose a profile of AuthZEN for RAR
- General
- PEP to PDP was considered low hanging fruit that a diverse set of vendors could interop on, since there was about 80% overlap already

### Useful links
- https://github.com/openid/authzen/tree/main/interop

## IETF
### RFC Work
- Let's submit an RFC for AuthZEN on top of Rich Authorization Requests
### IETF 120 Vancouver
- [Survey link](https://www.surveymonkey.com/r/8WD33GN)

## Action Items
- See action items from last week TBC

## George diagram

https://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgIkF1dGhvcml6YXRpb24gUGF0dGVybiIKCnBhcnRpY2lwYW50ICJjbGllbnQiIGFzIEMADA5BUEkgR1cAFQVHACYOUERQACwFUAA9DklEUC9BUwBGBUEAVw5yZXNvdXJjZQBiBVIKCgpDLT5HIDogcmVxIAAUCApHLT5QOiBhAIEuB2VkPwpQAA0FcnVuIHBvbGljeQpQLT5HOiBkZW55XG4AIQgAgVgGcmVxdWlyZWQgKGFkdmlzZSkKRy0-QzogVQAfCWVkIChnbyB0byAAgSIGKQpDLT5BAGYLADEKQQB8DgBzFkE6IGFkdmljZQpBPABmBXVzZXIAgToFTi9hdXRoWi9jb25zZW50CkEAgQUFYXV0aF9jb2RlAHEHZ2V0IHRva2VucwAZCGNjZXNzXwAPBSwgaWQAAgguLi4AgisFAIILJEc6IGFsbG93CkctPlI6IGludm9rZSBBUEkKUgCCNgVBUEkgcmVzcG9ucwCCbAVDOiA&s=default

title "Authorization Pattern"

participant "client" as C
participant "API GW" as G
participant "PDP" as P
participant "IDP/AS" as A
participant "resource" as R

C->G : req resource
G->P: authorized?
P->P: run policy
P->G: deny\nauthorization required (advise)
G->C: Unauthorized (go to IDP/AS)
C->A: authorize (advise)
A->P: authorize?
P->P: run policy
P->A: advice
A<->C: user authN/authZ/consent
A->C: auth_code
C->A: get tokens
A->C: access_token, id_token, ...
C->G: req resource
G->P: authorized?
P->G: allow
G->R: invoke API
R->G: API response
G->C:

## George's diagram using Mermaid JS syntax (Jin)

sequenceDiagram
    autonumber
    title Authorization Pattern
    participant C as client
    participant G as API GW
    participant P as PDP
    participant A as IDP/AS
    participant R as resource

    C->>G: req resource
    G->>P: authorized?
    P->>P: run policy
    P->>G: deny\nauthorization required (advise)
    G->>C: Unauthorized (go to IDP/AS)
    C->>A: authorize (advise)
    A->>P: authorize?
    P->>P: run policy
    P->>A: advice
    A->>C: user authN/authZ/consent
    A->>C: auth_code
    C->>A: get tokens
    A->>C: access_token, id_token, ...
    C->>G: req resource
    G->>P: authorized?
    P->>G: allow
    G->>R: invoke API
    R->>G: API response
    G->>C: API response