[Openid-specs-authzen] Notes for 2024-01-14 call

[Omri Gazitt]

Hi folks!

On behalf of the co-chairs, apologies for getting the notes out late. The
conversation that ensued on the mailing list may make more sense with these
notes as context.

# Meeting Notes 2025-01-14

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

## Agenda

- Discuss partial evaluation feedback (Christopher Hendrix, assuming he can
make the call)
- 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
-    (Skipped partial eval agenda item because Christopher wasn't there)
-    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.

-- 

<http://www.aserto.com/>

Omri Gazitt | CEO

Aserto <http://www.aserto.com/> Inc. | (425) 765-0079
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20250116/e7936d86/attachment.htm>