# Meeting Notes 2025-01-14

## Attendees
@omri
@gerryatstrata
George Fletcher
@vladi
@xmlgrrl
@alexbabeanu
Amos Alubala
Julio Auto De Medeiros
Michiel Trimpe
Mike Schwartz
@zirotrust (Atul Tulshibagwale)

## Agenda

- Discuss partial evaluation feedback
- Gartner IAM interop scenarios
- Mapping a JWT to an AuthZEN subject (profile proposal)
- Mapping API gateway requests to an AuthZEN payload (profile proposals from Michiel and Omri)

## Notes
- Gartner interop scenarios (in this doc: https://hackmd.io/FgnDl4iMTIa7xPQ18D7mfQ)
- During authN ceremony, IDP can make an AuthZEN call
- Profile of API gateway making an AuthZEN call
- Relying party makes an AuthZEN call to a PDP

- Some discussion of whether this is too many scenarios for the interop
- The relying party scenario is one we've already done a few times, so that would not require new work.
- EM: It seems good to me to have all the scenarios for education, but prioritizing one for heavy lifting in any one specific interop. Gateways is the ambitious one and worth pursuing. IdPs are already “easier to talk to/find”

- API gateway profile (https://hackmd.io/MTJPf_vzSmubctNtHis99g)
- By default, spec recommends certain actions that are done by the gateway, such as validate signature on the token
- There could also be use cases where the implementer will want to validate signatures as well.
- GF: Don't add complexity to the PDP to figure out the data
- MS: Have a use case where they want to send the principal via adding a token to the request
- GF: Value of protocol is to enable interoperability via more specification in the profile so all implementations do it the same way
- OG: (1) Use an API gateway with a variety of different PDPs or (2) I picked a PDP and I want to ensure the a wide variety of gateways work with that PDP
- GF: More optionality results in more complexity in certification
- Next we walked thru the API gateway profile proposal
- Add text indicating this is a REST profile
- Need to specify somewhere that it is recommended whether the body is to be serialized and where it should be placed (i.e. resource.properties.body)
- OG discussed reasons of using path vs. route for the resource (targeting a medium granularity). Prefer scenarios that do not require a lookup so that processing can be limited
- MT: If a route is available, great - if not, give me a URI (path)
- VB shared example with Kong. In the config, you can instruct the GW where to get values from. Plugins are per route, so you can hard code it. Extract the values from JWT on the gateway.

## Chat window message text

* Eve Maler (Venn Factory) (Jan 14, 2025, 3:16 PM)
It seems good to me to have all the scenarios for education, but prioritizing one for heavy lifting in any one specific interop. Gateways is the ambitious one and worth pursuing. IdPs are already “easier to talk to/find”

* Julio Auto De Medeiros (Jan 14, 2025, 3:38 PM)
+1 for body in context

* George Fletcher (Jan 14, 2025, 3:39 PM)
The one comment I will make about the Subject mapping is that in the 1.1 version of the spec… subject.type is defines as defining the type of the Subject. To me JWT isn’t the type of the Subject (i.e. it’s not workload or user like the other examples) it’s format of the subject.id field.

* Michael Schwartz (Jan 14, 2025, 3:41 PM)
Here’s how we defined the sample request in our demo:
{
"subject": {
"type": "JWT",
"id": "cedarling",
"properties": {
"access_token": ""
}
},
"resource": {
"type": "Jans::HTTP_Request",
"id": "some_id",
"properties": {
"header": {},
"url": {
"host": "protected.host",
"path": "/protected",
"protocol": "http"
}
}
},
"action": {
"name": "Jans::Action::\"GET\""
},
"context": {}
}

* Michael Schwartz (Jan 14, 2025, 4:06 PM)
Note: the route “/api/vi/pets/{id}” assumes some kind of pattern matching or regular expression capability.