[Openid-specs-authzen] Comments on the Authzen API GW Profile
Michael Schwartz
mike at gluu.org
Fri Jan 24 13:38:30 UTC 2025
I disagree with just about everything you said Omri, but let's proceed as
you say. At least we've discussed it at this point.
BTW, I don't think it's "high stakes"... this Interop doesn't matter very
much at all. I just wanted the WG to make a good impression, and I thought
we could put forward something more compelling.
- Mike
On Fri, Jan 24, 2025 at 12:52 AM Omri Gazitt <omri at aserto.com> wrote:
> Michiel is correct on all counts in his response.
>
> Additional comments:
>
> *Scope*
> It seems like a few people are still confused about the purpose and scope
> of the proposal. It is meant to be a starting point for API gateway vendors
> and PDP vendors to be able to implement an interop scenario for an event we
> are having in March, no more, no less. I'm honestly at a loss to understand
> why the "stakes feel so high". I've already started sharing this with API
> gateway vendors, to ensure we have a shot of making the interop showcase.
>
> No doubt we learn a lot from doing this showcase... as we have with
> previous interops at Identiverse, EIC, Authenticate, which all eventually
> led to the AuthZEN implementer's draft.
>
> Also, I don't really understand the continuing comments about gRPC and
> graphQL. The proposal is titled "HTTP REST API Gateway Profile proposal".
> It is explicitly scoped for HTTP / REST (see "Scope
> <https://hackmd.io/MTJPf_vzSmubctNtHis99g#Scope>" section). We can have
> other proposals for other protocols.
>
> Note that NONE of this has gone into any OpenID document that looks like a
> "spec" as of yet - we are doing the interop first, learning from it, and
> eventually distilling the learnings into more formal documents.
>
> *Too opinionated*
> The proposal suggests default mappings. Everything should be overridable
> by a developer configuring a gateway's authzen filter. Please re-read the "
> purpose <https://hackmd.io/MTJPf_vzSmubctNtHis99g#Purpose>" section (also
> quoted below):
>
> Ideally, the filter implementation allows the developer to indicate which
> HTTP elements (method, path, headers, body) to map into which fields of the
> AuthZEN evaluation request.
>
> So why define an AuthZEN profile for API gateways? To provide a simple
> mapping as a sensible default (which a developer can ideally override).
>
> This in turn can accelerate the process of enabling API Gateways to easily
> become AuthZEN clients.
>
> <#m_-3221772943351243300_Scope>
> Stepping back, there are three usages that the proposal is trying to
> cover.
>
> 1. PEP just puts all the HTTP fields in predictable places in the AuthZEN
> request, and PDP has code to utilize the fields it needs in an
> authorization policy. The benefits of this approach is that logic only
> needs to be written in one place, and a generic AuthZEN filter can be used
> for every endpoint that the gateway is proxying. (although, of course, each
> of the policies will likely be different).
>
> This is what the "default mapping" is good for. This is what Michiel's
> original proposal was trying to accomplish as well.
>
> 2. PEP allows the developer to pick what HTTP fields they want to put in
> which AuthZEN fields. *This doesn't require a profile or spec or
> anything. *There is what amounts to a "per-route protocol" between the
> API gateway and the PDP. I expect most/all gateways will support this
> usage scenario. The advantage is that the caller can tune the AuthZEN
> payload to something that an existing policy (already running in a PDP)
> expects. But it means code on both sides, for every route.
>
> 3. PEP calls out to the PDP to *Authorize access to routes. * This third
> scenario is more narrow (and therefore more opinionated with respect to
> "what goes where"). This is also the scenario that the interop in London
> will focus on, and that's why I've been trying to get it written up in the
> same proposal.
>
> *Where various HTTP fields go*
> This is of course up for discussion and is ultimately a judgment call, but
> I would suggest that for the first usage case, as long as the fields are
> found in predictable places, the PDP can extract them in predictable ways.
>
> For the third scenario (authorizing routes), the required fields actually
> matter. The idea is that PDPs can have a specific policy that is written
> around authorizing access to routes. This is why the proposal suggests
> using subject for the subject of the request (extracted from the
> Authorization header), HTTP method for action name, and the route as the
> resource.
>
> *Type names*
> I fail to understand the argument about type names working in various
> languages. Simple strings work in every language. There have been suggested
> type names in this thread that contain spaces - I think that's a very bad
> idea, because most languages I know use spaces to separate tokens. But in
> the end, these are strings. Making them URIs or URNs or scoped identifiers
> just makes things harder to read and harder to construct (on the gateway
> side) and parse (on the PDP side).
>
>
> In the interest of time, I will turn my attention towards writing up the
> actual interop document for the showcase in London (i.e. the specific
> application routes for the Todo application and the AuthZEN payloads that
> participating gateways are expected to send to participating PDPs for the *route
> authorization* scenario.
>
>
> On Thu, Jan 23, 2025 at 1:21 PM Michiel Trimpe via Openid-specs-authzen <
> openid-specs-authzen at lists.openid.net> wrote:
>
>> I don't think anyone is talking about making this a mandatory standard.
>> It’s a draft proposal to engage gateway providers that want to enable some
>> degree of interoperability for authorizing gateway requests. Within the
>> profile pretty much everything is also optional and free-form.
>>
>> In essence it’s just answering the question that every gateway provider
>> will inevitably ask: “I have a request. You have subject, action, resource
>> and context. Where should I put what?”
>>
>> So far I don't think we have much opinion there at all. We just say that
>> subject is your authorization header, action is the method, resource is
>> route or uri and headers is context. If you want to include them, include
>> them there.
>>
>> Regards, Michiel
>>
>> P.S. The body is required for cases where sensitive query parameters are
>> placed in a POST body to prevent them from being logged by intermediate
>> proxies. It should indeed only be used in such cases though which is why
>> it would also be an optional field.
>> ------------------------------
>> *From:* Openid-specs-authzen <
>> openid-specs-authzen-bounces at lists.openid.net> on behalf of Antonio
>> Radesca via Openid-specs-authzen <openid-specs-authzen at lists.openid.net>
>> *Sent:* Thursday, January 23, 2025 9:45:46 PM
>> *To:* AuthZEN Working Group List <openid-specs-authzen at lists.openid.net>;
>> mike at gluu.org <mike at gluu.org>
>> *Cc:* Antonio Radesca <antonio.radesca at nitroagility.com>
>> *Subject:* Re: [Openid-specs-authzen] Comments on the Authzen API GW
>> Profile
>>
>> Hi All,
>> Agreed, it’s fine as an example, but I am not sure it works as a
>> standard. The AuthZEN API Gateway Profile feels too narrow. It works for
>> simple cases like a wrapper but it ignores more complex scenarios like SSE,
>> WebSockets, or HTTP/3. It also seems inconsistent because it doesn’t
>> include gRPC or GraphQL, which are common in API gateways. I think this
>> "standard" should first be tested by multiple vendors and get their
>> feedback. Making it mandatory now, while it’s incomplete, doesn’t seem like
>> a good idea. IMHO basically it should be more agnostic to be adaptable to
>> more protocols and scenarios as said.
>>
>> Also, since this is a security tool, requests might be logged in the
>> decision logs. Logging an entire POST body might not only be unnecessary
>> but could also be a security risk. The same applies to headers.
>>
>> Adding to the security concern, why should policies for authorization
>> depend on a BODY DTO? What happens if an application uses a BFF pattern,
>> where the DTO for mobile is different from the one for the frontend? Should
>> policies handle these differences? And what about versioning for the API
>> and the policies? Coupling DTO and policies doesn’t seem like a good idea.
>> Instead if the body is not used in any policy, the Zero Trust Least
>> Privilege Principle should apply instead, so why pass it?
>>
>> Finally, there is also a latency concern when passing unnecessary
>> information, as it adds processing overhead without any clear benefit.
>>
>> Thank you for your time
>>
>> *Antonio Radesca*
>>
>> Co-founder / Chief Technology Officer
>>
>>
>> *M:*+373 698 04 974 *P:*+39 0835 170 0059 P: +44 20 3966 5620
>>
>> *E:*antonio.radesca at nitroagility.com *in:*antonioradesca
>> <https://www.linkedin.com/in/antonioradesca/>
>>
>> *W:*nitroagility.com <https://www.nitroagility.com/> *in:*nitroagility
>> <https://www.linkedin.com/company/20520302>
>>
>>
>> Nitro Agility Srl - C.F./P.IVA: 01364090777 - PEC: nitroagility at pec.it
>>
>> SEDE LEGALE: VIA F. PARRI 44, 75100 MATERA (MT), ITALY
>>
>> SEDE OPERATIVA: VIA LUCANA 259, 75100 MATERA (MT), ITALY
>>
>> CODICE DESTINATARIO: M5UXCR1
>>
>>
>> On Thu, Jan 23, 2025 at 8:58 PM Nicola Gallo via Openid-specs-authzen <
>> openid-specs-authzen at lists.openid.net> wrote:
>>
>> Hi All,
>>
>> I completely agree with @alex.babeanu at indykite.com’s comments. This is a
>> great example and a helpful recommendation article. However, I think I
>> wouldn’t feel as comfortable if it were turned into a formal standard or
>> specification.
>>
>> Cheers,
>>
>> *Nicola Gallo*
>>
>> Co-founder / Chief Technology Officer
>>
>>
>> *M:*+39 349 3305248 *P:*+39 0835 170 0059 P: +44 20 3966 5620
>>
>> *E:*nicola.gallo at nitroagility.com *in:*nicolagallo83
>> <https://www.linkedin.com/in/nicolagallo83/>
>>
>> *W:*nitroagility.com <https://www.nitroagility.com/> *in:*nitroagility
>> <https://www.linkedin.com/company/20520302>
>>
>>
>> Nitro Agility Srl - C.F./P.IVA: 01364090777 - PEC: nitroagility at pec.it
>>
>> SEDE LEGALE: VIA F. PARRI 44, 75100 MATERA (MT), ITALY
>>
>> SEDE OPERATIVA: VIA LUCANA 259, 75100 MATERA (MT), ITALY
>>
>> CODICE DESTINATARIO: M5UXCR1
>>
>> This message may contain confidential and/or proprietary information, and
>> is intended only for the person/entity to whom it was originally addressed.
>> The content of this message may contain private views and opinions, which
>> do not constitute a formal disclosure or commitment unless specifically
>> stated.
>>
>>
>>
>>
>> On Thu, 23 Jan 2025 at 19:02, Michael Schwartz via Openid-specs-authzen <
>> openid-specs-authzen at lists.openid.net> wrote:
>>
>> A few follow-up thoughts... I was just using Cedar syntax as an example
>> for expediency, but I mentioned using URIs, URNs, ASNs, etc. are other ways
>> to address the issue. But what I think is important is that we prefix the
>> following: OpenID, Authzen, and API GW Profile--specifying the version.
>> Not just "http" or "graphql", which I don't think is actually
>> collision resistant.
>>
>> Just as an example in another domain, in the DID space, anyone can define
>> a DID method. Certain DID methods started to get traction, and
>> eventually will become "standardized". I think this is an interesting
>> approach, because we can stay open minded here that we might not know best.
>> So at the Interop we are showing how to profile Authzen, and the quick
>> profile we are using is just an example of one possible profile.
>>
>> - Mike
>>
>>
>> On Thu, Jan 23, 2025 at 9:51 AM Alex Babeanu <alex.babeanu at indykite.com>
>> wrote:
>>
>> Hi all,
>>
>> Finally caught up with all this... Was the consensus that this GTWY
>> profile was going to actually be helpful in bringing Gtwy vendors on board??
>> It does really seem VERY opinionated to me: it's basically telling them
>> HOW to build their product. It seems to me that defining a good AuthZEN
>> protocol that includes the protocol-side things that would be required for
>> their integration (Omri's the JWT Profile draft for example) should be
>> sufficient. This here feels to me like, saying: "here's the OAuth spec, and
>> oh, btw, here's how you MUST implement it". Not sure I like that myself...
>> The AuthZEN protocol spec should be sufficient for all vendors to adopt in
>> the way they see fit. I'm sure they have smart people that can figure it
>> out, especially if the protocol itself makes it obvious what the
>> expectation is...
>>
>> This could therefore be a recommendations article rather than a formal
>> standard/spec. My $0.02...
>>
>> And sry if the decision was already made to go ahead in this direction, I
>> may have missed it - been too busy.
>>
>> Regards,
>>
>> ./\.
>>
>> On Thu, Jan 23, 2025 at 7:39 AM Michiel Trimpe via Openid-specs-authzen <
>> openid-specs-authzen at lists.openid.net> wrote:
>>
>> *Collision Resistance*
>> I agree that it's probably wise to include guidance towards ensuring
>> collision resistance for implementers in the base AuthZEN spec. I came
>> across a similar section in the OAuth RAR specification
>> <https://datatracker.ietf.org/doc/html/rfc9396#name-authorization-details-types> recently
>> which does a fairly good job at explaining this IMO (although I'm not a fan
>> of URI's as namespaces.)
>>
>> After considering the GraphQL case I do agree it might be wise to give
>> this profile a top-level namespace like 'http' instead. So then you'd get
>> something like {"type": "http:route"} and {"type": "http:uri"} and
>> {"action": "http:get"}
>> That leaves API gateways free to model GraphQL calls as plain HTTP
>> request using this profile or to use a (yet to be defined) GraphQL profile
>> with action types like "graphql:query".
>>
>> *What goes where*
>> Looking at terminology alone it seems logical for me to put:
>> - information from/about the Uniform *Resource* Identifier in the `
>> *resource*` section
>> - the HTTP *method/verb* in the `*action*`section and
>> - the *subject* as extracted from e.g. the Authorization header in the `
>> *subject*` section
>>
>> I'd personally say 'body' belongs in the `action` section as well since
>> it's *what* your are PUTting or POSTing.
>>
>> Then you get a sentence like "As `mtrimpe`(subject) I `POST
>> {"json":"string"}`(action) to `http://example.com/json-store`(resource)
>> <http://example.com/json-store(resource)>."
>>
>> Only the headers are a tough one. You can see it as metadata about the
>> action but we're also parsing the Authorization header to populate the
>> subject as well. Given that headers are now used for so many purposes I'd
>> argue that makes most sense to put it in the `context` section.
>>
>> Cheers, Michiel
>>
>> ------------------------------
>> *From:* Openid-specs-authzen <
>> openid-specs-authzen-bounces at lists.openid.net> on behalf of Michael
>> Schwartz via Openid-specs-authzen <openid-specs-authzen at lists.openid.net>
>> *Sent:* 23 January 2025 00:37
>> *To:* AuthZEN Working Group List <openid-specs-authzen at lists.openid.net>
>> *Cc:* Michael Schwartz <mike at gluu.org>
>> *Subject:* Re: [Openid-specs-authzen] Comments on the Authzen API GW
>> Profile
>>
>> Here are some more comments about Omri's "AuthZEN REST API Gateway
>> Profile proposal" we've been so heatedly discussing, described here:
>> https://hackmd.io/MTJPf_vzSmubctNtHis99g
>>
>> I know there is a time challenge around the interop, so I'll try to be
>> brief. BTW, I very likely won't be at the meeting next week, so it would be
>> great if we could have this conversation in the mailing list (or the OIDF
>> Slack...).
>>
>> My first suggestion is that the "type" values should be collision
>> resistant. For example, here are some types and what I might like better
>> (just suggestions...)
>> - In the Subject, *type "user"*. What about: "OpenID Authzen API GW
>> Profile 0.1 User", "OpenID::Authzen::API-GW::0.1::User", or
>> https://openid.net/authzen/types/User" (today the best practice for
>> OAuth scopes is to use a unique URI)
>> - In the Action, *type "GET"*, to "OpenID::Authzen::API-GW::GET" (or
>> one of the other formats above)
>> - In the Resource,* "type": "route"*, -->
>> "OpenID::Authzen::API-GW::0.1::Route"
>> - In the Context, the type is missing... maybe Contexts don't have
>> types in Authzen... but I would define it anyway as something like
>> "OpenID::Authzen::API-GW::0.1::Context".
>>
>> While you "could" put information anywhere, I find the organization of
>> the request in the current proposal very confusing. I don't understand why
>> half the data about the request is in the resource (like the params), but
>> the other half is in the Context (like the body). There is no clean
>> explanation for that organization. I would like to suggest that an easy
>> explanation might be to say the request itself is put in the resource --
>> url, headers, body. And all the information added by the API GW -- time of
>> day, network, etc. -- is in the Context.
>>
>> Having the Profile version in the type is also important. API GW plugin
>> developers will write against a certain version, so if a PDP is expecting a
>> different version, things may break.
>>
>> I understand that optionality is the enemy of interoperability. But at
>> this phase, I feel like this current proposal is too opinionated. IMHO, we
>> want to invite the API GW community to come up with more innovative ideas
>> for how to add new subject, action, resource or context types. For example
>> we need different actions and resources for GraphQL. So I'd like to see the
>> proposal be more extensible, which always ends up being good for a spec.
>> Maybe a vendor won't support every API GW Profile feature (e.g. a GW may
>> not support GraphQL). Then we're not saying there is one "right" way...
>> we're giving a way to define different ways, and then when adoption becomes
>> clear, we can promote or demote schemas.
>>
>> - Mike
>>
>>
>> On Fri, Jan 17, 2025 at 1:42 AM Omri Gazitt via Openid-specs-authzen <
>> openid-specs-authzen at lists.openid.net> wrote:
>>
>> Thank you Michael, Michiel, and Julio for your comments.
>>
>> I have been pondering this for the last couple of days and have come to
>> the conclusion that we are trying to represent two separate scenarios in
>> the same profile.
>>
>> Julio is exactly right on all counts:
>>
>> - the proposal I reviewed in the meeting is meant for "medium-grained
>> authz", but I agree that fine-grained authz is a valid scenario as well
>> - the question you're asking in "medium-grained authz" is "can this
>> subject invoke the route represented by { HTTP method, HTTP route }"
>> - "route" is meant to be an OpenAPI path template, which is widely
>> implemented by many HTTP frameworks / API gateways. These pieces of
>> software typically make the matched route available in the request or in
>> some developer-accessible context
>>
>> In the context of this scenario, I also agree that the JWT is
>> uninteresting, and what you really as the subject is a claim inside the
>> JWT. So I agree with the feedback from George, Julio, and Michael that we
>> don't want the subject to be of type "JWT".
>>
>> Julio, your memory is very good. We considered RFC 9493 as a way to
>> represent subjects, but realized that we were conflating "format" (e.g.
>> "JWT", "email", etc) and the "type" ("user", "identity", etc).
>>
>> Stepping back, I do think we can represent the two scenarios in a single
>> profile.
>>
>> For the generic fine-grained authz scenario (where every field in the
>> HTTP request information model is essentially an "attribute" that a policy
>> can reason over), we want the API gateway to pass along most/all of the
>> fields in the HTTP request information model, and what is placed in the
>> required fields isn't all that important. The PDP's policy will likely be
>> written around the various properties in the information model (subject,
>> action, resource, context) and not the required fields.
>>
>> For the medium-grained authz scenario, what we pick for the required
>> fields actually matters more, because we are designing an authorization
>> protocol for HTTP routes.
>>
>> The "default" mapping for this scenario feels to me like the following
>> (in pseudo-code):
>>
>> {
>> "subject": {
>> "type": "user",
>> "id": "<decode_jwt(request.headers["authorization"]).sub>"
>> },
>> "action": {
>> "name": "<request.method>"
>> },
>> "resource": {
>> "type": "route", // or "uri" if "route" is not available
>> "id": "<request.route>", // or "uri" if "route" is not available
>> "properties": {
>> // uri components, path parameters, query (or query parameters if
>> they get parsed)
>> },
>> "context": {
>> "headers": [],
>> "body": ...
>> }
>> }
>> }
>>
>> For the fine-grained authz scenario, each API request (and its
>> corresponding filter) essentially has its own contract with the PDP. What
>> is most important for this scenario is a predictable way of mapping the
>> HTTP request information model into the AuthZEN information model. The PDP
>> policy will lift whatever fields it wants out of the AuthZEN request, and
>> use those fields in the policy.
>>
>> For example, if (as Michael suggests) the PDP really wants the encoded
>> access token as the subject and will process whatever it wants to extract
>> out of that, this is easy to do by writing a policy that extracts that
>> field out of context.headers["Authorization"].
>>
>> Therefore, it stands to reason that the mapping sketched out above would
>> work for the (more constrained) medium-grained authz scenario, and the
>> (less constrained) fine-grained authz scenario.
>>
>> On Wed, Jan 15, 2025 at 7:28 AM Julio Auto De Medeiros (BLOOMBERG/ 731
>> LEX) via Openid-specs-authzen <openid-specs-authzen at lists.openid.net>
>> wrote:
>>
>> A couple of thoughts:
>>
>> 1. On the matter of "/api/v1/pets/{id}", my understanding was that no
>> replacement/rewriting was being proposed. Authorizing on that would have
>> the meaning of "principal can POST on some pet" (non-pet-ID-specific). The
>> pet-specific authorization would only happen later, at the actual API
>> provider. In other words, the API gateway would only perform
>> "medium-grained" (as Omri put it) authorization, and the API provider would
>> do fine-grained authorization. I also understood that it didn't mean that
>> API gateways weren't allowed do fine-grained authorization, but more of a
>> question of picking the example/use case to include in the profile.
>>
>> 2. George (IIRC) had a good point on the JWT subject 'type', in that
>> previously the authzen spec evoked differences between type and "format".
>> Subject types would be things "user", "group", "workload", I reckon. So, in
>> that spirit, perhaps the example in the profile would better read:
>> {
>> "subject": {
>> "type": "user",
>> "id": {
>> "format" : "JWT",
>> "jwt": "eyJhb..."
>> }
>> }
>> }
>>
>> Having that said, I'm of the opinion that the JWT doesn't belong in the
>> subject at all, but rather in the context. Conceptually, I think the
>> subject identifier is of the format 'email' and its value is '
>> john.doe at acmecorp.com', the JWT being sent in the 'context' mostly to
>> allow for identity validation. But I understand the concern with giving the
>> gateway the "burden" of deserializing the JWT to extract the subject ID.
>>
>> From: openid-specs-authzen at lists.openid.net At: 01/15/25 04:33:30
>> UTC-5:00
>> To: openid-specs-authzen at lists.openid.net
>> Cc: Michiel.Trimpe at VNG.NL
>> Subject: Re: [Openid-specs-authzen] Comments on the Authzen API GW Profile
>>
>> Hi Michael,
>>
>> Please see my responses in-line.
>>
>> Cheers, Michiel
>> ------------------------------
>> *From:* Openid-specs-authzen <
>> openid-specs-authzen-bounces at lists.openid.net> on behalf of Michael
>> Schwartz via Openid-specs-authzen <openid-specs-authzen at lists.openid.net>
>> *Sent:* 15 January 2025 02:51
>> *To:* AuthZEN Working Group List <openid-specs-authzen at lists.openid.net>
>> *Cc:* Michael Schwartz <mike at gluu.org>
>> *Subject:* [Openid-specs-authzen] Comments on the Authzen API GW Profile
>>
>> Here is the feedback on the discussion about the API GW authzen profile
>> that I also posted on OpenID Authzen Slack for the official mailing list
>> record:
>>
>> 1. IMHO, the Resource type should be "HTTP_Request" not "path" -- there
>> is always way more to an API proxy decision than just a path. And the path
>> itself is not even enough to uniquely identify a resource. The entitlement
>> request is to perform an HTTP Request with a certain method and
>> context--not to just access a certain path.
>>
>> > I spent quite a bit of time pondering the alternatives and given that
>> we are looking for common identifier for a resource in the context of HTTP
>> REST request; the Uniform Resource Identifier (a.k.a. `uri`) does really
>> seem like the optimal fit.
>>
>> 2. We can define a minimum required schema but allow room for extension.
>> I guess what I'm wondering is if we can reduce the scope of this profile
>> more.
>>
>> 3. A URL may include schema, host, port, path, query, and fragment. Also,
>> I wonder if the host should allow for policies based on the domain, i.e.
>> for google.com domain do this.. for gmail.com domain... do something
>> else.
>>
>> > That can be done using a simple "eq 'google.com' or endsWith '.
>> google.com'" expression right? Determining what's colloquially
>> understood as "the domain" requires an up-to-date TLD list to disambiguate
>> e.g. "smtp.local" hostnames which are perfectly valid as well.
>>
>> 4. The HTTP request includes url , headers, body . These are all things
>> the developer is sending from Postman in the request. IMHO, Context should
>> be for data that is external to the resource, like the time of day, which
>> you don't send in the Postman request.
>>
>> > From my perspective the Subject, Action and Resource is the information
>> model of the authorization request. In the Dutch standard we'll also
>> recommend implementers to define their AuthZEN information model up to the
>> same standard of quality as their domain model. That includes defining
>> syntax, semantics, constraints and relations for everything in their domain
>> specific AuthZEN information model.
>> When viewed from that perspective the "raw JWT" token or "raw X509
>> certificate" feel more like an implementation detail. That is why I
>> suggested moving them to context.
>> For headers I can also make a case that they're properties
>> describing/annotating the action that you intend to take (e.g. Accept
>> headers request specific the type of content you wish to GET) so that it
>> would make sense to include them in the `action` instead.
>>
>> 5. It's unclear why the sample shows the route as ".../pets/{id}". The
>> request would be for an exact path3. It may seem trivial, but we don't
>> want to define any kind of replacement or regex syntax here.
>>
>> > Route here refers to the something like "path templates" concept as
>> described in e.g. https://swagger.io/specification/#paths-object or the
>> router concept from SPA's like you e.g.
>> https://www.w3schools.com/react/react_router.asp
>> That's what you will generally want to base your policies on if they're
>> available.
>>
>> 6. For the resource id (or the subject id), why not make it a hash of the
>> properties? That way it will be unique, and represent the totality of the
>> request. It's really quick and easy for the API gateway to generate a
>> sha-256 hash.
>> > What value would that add over leaving it empty then? Consistent JSON
>> hashing is also surprisingly difficult as JSON objects are specified to
>> be unordered <https://www.rfc-editor.org/rfc/rfc7159.html#section-1> .
>>
>> 7. I really don't like the subject sent as "JWT" with the value as the
>> id. At a minimum, you should use the fingerprint of the token, and not the
>> token itself. Perhaps it would be better to send client claims in the
>> subject properties, like client_id, scopes, and allow for extension for
>> customers who have custom access token claims?
>> > I agree with this for the same reason I gave on #4.
>> For me it still feels logical to define it as the value of 'sub' in the
>> JWT token by default and provide the additional JWT parameters in the
>> `subject.properties` to disambiguate that further if needed. That same
>> pattern can then also be applied to X509/mTLS since they also have a
>> Subject field that is generally enough but sometimes needs additional
>> properties to be provided.
>> I can also think of lots of counter examples though. An API gateway that
>> resolves several different authentication patterns to the same identity
>> probably wouldn't too happy to be forced to have a subject type for each
>> authentication pattern.
>>
>> 8 .For the resource... what about something like this:
>>
>> "type": "AuthZen::HTTP_REQUEST",
>> "id": "31d342599750a22f90a1d6b3d765549231e6b3091530f8f813e2f754e9d62422",
>> "properties": {
>> "header": {
>> "Accept": "application/json",
>> "User-Agent": "AuthzenClient/1.0",
>> "Host": "www.acme.com",
>> "Content-Type": "multipart/form-data"
>> },
>> "url": {
>> "scheme": "https",
>> "host": "www",
>> "domain": "acme.com",
>> "port": 443,
>> "path": "/protected",
>> "query": "query": {
>> "param1": "value"
>> }
>> "fragment": "TOC"
>> },
>> "body": {
>> "form1": {
>> "field1": "value1",
>> "field2": "value2"
>> }
>> }
>> }
>>
>>
>> --------------------------------------
>> Michael Schwartz
>> Glue
>> Founder/CEO
>> mike at gluu.org
>> https://www.linkedin.com/in/nynymike
>>
>> ------------------------------
>> *CONFIDENTIALITY NOTICE*
>> This message may contain confidential or legally privileged information.
>> If you are not the intended recipient, please immediately advise the
>> sender by reply e-mail that you received this message, and delete this
>> e-mail from your system.
>> Thank you for your cooperation
>>
>> --
>> Openid-specs-authzen mailing listOpenid-specs-authzen at lists.openid.nethttps://lists.openid.net/mailman/listinfo/openid-specs-authzen
>>
>>
>> --
>> Openid-specs-authzen mailing list
>> Openid-specs-authzen at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>>
>> --
>> Openid-specs-authzen mailing list
>> Openid-specs-authzen at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>>
>>
>> ------------------------------
>> *CONFIDENTIALITY NOTICE*
>> This message may contain confidential or legally privileged information.
>> If you are not the intended recipient, please immediately advise the
>> sender by reply e-mail that you received this message, and delete this
>> e-mail from your system.
>> Thank you for your cooperation
>> --
>> Openid-specs-authzen mailing list
>> Openid-specs-authzen at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>>
>>
>>
>> --
>>
>>
>> Alex Babeanu
>> Lead Product Manager, Access Management
>>
>>
>>
>> t. +1 604 728 8130
>> e. alex.babeanu at indykite.com
>> w. www.indykite.com
>>
>>
>>
>> ------------------------------
>> *CONFIDENTIALITY NOTICE*
>> This message may contain confidential or legally privileged information.
>> If you are not the intended recipient, please immediately advise the
>> sender by reply e-mail that you received this message, and delete this
>> e-mail from your system.
>> Thank you for your cooperation
>> --
>> Openid-specs-authzen mailing list
>> Openid-specs-authzen at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>>
>> --
>> Openid-specs-authzen mailing list
>> Openid-specs-authzen at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>>
>> --
>> Openid-specs-authzen mailing list
>> Openid-specs-authzen at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>>
>
--
*CONFIDENTIALITY NOTICE*
This message may contain confidential or
legally privileged information.
If you are not the intended recipient,
please immediately advise the sender by reply e-mail that you received this
message, and delete this e-mail from your system.
Thank you for your
cooperation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20250124/1470de63/attachment-0001.htm>
More information about the Openid-specs-authzen
mailing list