<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Michael,</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Please see my responses in-line.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Cheers, Michiel</div>
<div id="appendonsend"></div>
<hr style="display: inline-block; width: 98%;">
<div id="divRplyFwdMsg" dir="ltr"><span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b> Openid-specs-authzen <openid-specs-authzen-bounces@lists.openid.net> on behalf of Michael Schwartz via Openid-specs-authzen
<openid-specs-authzen@lists.openid.net><br>
<b>Sent:</b> 15 January 2025 02:51<br>
<b>To:</b> AuthZEN Working Group List <openid-specs-authzen@lists.openid.net><br>
<b>Cc:</b> Michael Schwartz <mike@gluu.org><br>
<b>Subject:</b> [Openid-specs-authzen] Comments on the Authzen API GW Profile</span>
<div> </div>
</div>
<div style="direction: ltr;" class="elementToProof">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: </div>
<div style="direction: ltr;" class="elementToProof"><br>
</div>
<div style="direction: ltr;" class="elementToProof">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.<br>
<br>
</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<span style="background-color: rgb(255, 255, 0);">> 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.</span></div>
<div style="direction: ltr;" class="elementToProof"><br>
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.</div>
<div style="direction: ltr;" class="elementToProof"><br>
</div>
<div style="direction: ltr;" class="elementToProof">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
<a href="http://google.com/" id="OWA795e2991-0ed0-a4d2-6657-fb1b346c4cae" class="OWAAutoLink" originalsrc="http://google.com/" data-auth="Verified">
google.com</a> domain do this.. for <a href="http://gmail.com/" id="OWA1ecc0585-6234-534d-2177-e4aeb60289c8" class="OWAAutoLink" originalsrc="http://gmail.com/" data-auth="Verified">
gmail.com</a> domain... do something else.</div>
<div style="direction: ltr;" class="elementToProof"><span style="background-color: rgb(255, 255, 0);"><br>
> 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.</span></div>
<div style="direction: ltr;" class="elementToProof"><br>
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.<br>
<br>
</div>
<div style="direction: ltr;" class="elementToProof"><span style="background-color: rgb(255, 255, 0);">> 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.</span></div>
<div style="direction: ltr;" class="elementToProof"><span style="background-color: rgb(255, 255, 0);">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.<br>
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.</span></div>
<div style="direction: ltr;" class="elementToProof"><br>
</div>
<div style="direction: ltr;" class="elementToProof">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.</div>
<div style="direction: ltr;" class="elementToProof"><br>
</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif;" class="elementToProof">
<span style="background-color: rgb(255, 255, 0);">> Route here refers to the something like "path templates" concept as described in e.g.
</span><span style="font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 0);"><a href="https://swagger.io/specification/#paths-object" id="OWA48cc550a-3204-8c09-77ab-91c1a4b8275e" class="OWAAutoLink">https://swagger.io/specification/#paths-object</a> or
the router concept from SPA's like you e.g. <a href="https://www.w3schools.com/react/react_router.asp" id="OWAfcf896d9-49d2-d342-0184-826481b314eb" class="OWAAutoLink">
https://www.w3schools.com/react/react_router.asp</a></span></div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif;" class="elementToProof">
<span style="background-color: rgb(255, 255, 0);">That's what you will generally want to base your policies on if they're available. </span></div>
<div style="direction: ltr;" class="elementToProof"><br>
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.</div>
<div style="direction: ltr;" class="elementToProof"><span style="background-color: rgb(255, 255, 0);">> What value would that add over leaving it empty then? Consistent JSON hashing is also surprisingly difficult as
<a href="https://www.rfc-editor.org/rfc/rfc7159.html#section-1" id="LPlnk845435" class="OWAAutoLink" title="https://www.rfc-editor.org/rfc/rfc7159.html#section-1">
JSON objects are specified to be unordered</a> .</span></div>
<div style="direction: ltr;" class="elementToProof"><br>
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?</div>
<div style="direction: ltr;" class="elementToProof"><span style="background-color: rgb(255, 255, 0);">> I agree with this for the same reason I gave on #4.<br>
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.</span></div>
<div style="direction: ltr;" class="elementToProof"><span style="background-color: rgb(255, 255, 0);">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.</span></div>
<div style="direction: ltr;" class="elementToProof"><span style="background-color: rgb(255, 255, 0);"><br>
</span></div>
<div style="direction: ltr;" class="elementToProof">8 .For the resource... what about something like this:</div>
<div style="direction: ltr;" class="elementToProof"><br>
"type": "AuthZen::HTTP_REQUEST",<br>
"id": "31d342599750a22f90a1d6b3d765549231e6b3091530f8f813e2f754e9d62422",<br>
"properties": {<br>
"header": {<br>
"Accept": "application/json",<br>
"User-Agent": "AuthzenClient/1.0",<br>
"Host": "<a href="http://www.acme.com/" id="OWA488468d0-fae3-4b3d-5f3d-778e26540ef8" class="OWAAutoLink" originalsrc="http://www.acme.com/" data-auth="Verified">www.acme.com</a>",<br>
"Content-Type": "multipart/form-data"<br>
},<br>
"url": {<br>
"scheme": "https",<br>
"host": "www",<br>
"domain": "<a href="http://acme.com/" id="OWA08158ac8-4665-7ec4-fbd4-7754b56512e5" class="OWAAutoLink" originalsrc="http://acme.com/" data-auth="Verified">acme.com</a>",<br>
"port": 443,<br>
"path": "/protected",<br>
"query": "query": {<br>
"param1": "value"<br>
}<br>
"fragment": "TOC"<br>
},<br>
"body": {<br>
"form1": {<br>
"field1": "value1",<br>
"field2": "value2"<br>
}<br>
}<br>
}<br>
<br>
<br>
</div>
<div style="direction: ltr;">--------------------------------------</div>
<div style="direction: ltr;">Michael Schwartz</div>
<div style="direction: ltr;">Glue</div>
<div style="direction: ltr;">Founder/CEO</div>
<div style="direction: ltr;"><a href="mailto:mike@gluu.org" id="OWAadc3d9f8-f348-21e7-677b-cde32aade5b4" class="OWAAutoLink">mike@gluu.org</a></div>
<div style="direction: ltr;"><a href="https://www.linkedin.com/in/nynymike" id="OWA04568d1d-dc8d-6790-113f-d19b363c704e" class="OWAAutoLink" originalsrc="https://www.linkedin.com/in/nynymike" data-auth="Verified">https://www.linkedin.com/in/nynymike</a></div>
<br>
<div style="font-size: 10px;"><img src="https://github.com/GluuFederation/docs-gluu-server-prod/blob/master/docs/source/small_logo.png?raw=true"></div>
<hr>
<div style="font-family: "Sans Serif"; font-size: 10px; color: rgb(128, 128, 128);">
<b>CONFIDENTIALITY NOTICE</b></div>
<span style="font-family: Sans Serif; font-size: 10px; color: rgb(128, 128, 128);">This message may contain confidential or legally privileged information.<br>
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.<br>
Thank you for your cooperation</span><br>
</body>
</html>