<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Ahmet here from Tyk, an API Gateway vendor.<br>
<br>
I really appreciate what you're all working on and the goals you’re
aiming to achieve - it's exciting to see how this will evolve.<br>
<p>When I initially read through the proposal, I shared some of the
same confusions others have raised. </p>
<p>A few thoughts:</p>
Name Clarity: The term "API Gateway Profile" suggests a
general-purpose profile for API Gateways, but the current proposal
is limited to REST-ish APIs. As others mentioned, in our world, API
Gateways need to support not just REST, but also GraphQL, gRPC,
SOAP, HTTP/3, WebSocket, SSE, Kafka and more.<br>
<br>
PDP on the Hot Path: Calling out to a Policy Decision Point (PDP) on
the hot path raises concerns for latency, security, and reliability.
It would be worth exploring the possibility of embedding the PDP
instead, which could alleviate some of these challenges.<br>
<br>
REST API Matching: If we're limiting this to REST-style APIs, it
might be worth considering aligning the spec with OpenAPI v3 Schema.
Using operationId to uniquely identify operations could
significantly simplify the mapping process compared to relying on
URL, path, method, headers, etc.<br>
<p>JWT Claims: In the examples provided, I saw mentions of the sub
claim. However, for medium-grained authorization with an Access
Token, the Gateway would typically look at other claims, such as
client_id, to determine what the client is authorized to do on the
subject's behalf. If the JWT is then passed along to the target
microservice, it’s typically the microservice that performs the
finer-grained authorization logic with the sub claim - unless a
token exchange is performed by the Gateway. Does your proposal
support this kind of flexibility?<br>
</p>
<p>Response Filtering: Michael's mention of filtering responses from
the target API is a fantastic idea - definitely a +1 from me.</p>
Looking forward to hearing more as this develops!<br>
<br>
Best regards,<br>
<p>Ahmet</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 24/01/2025 18:36, Alex Babeanu via
Openid-specs-authzen wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CANwAPZbudRGL_fShPpOVpe8czZq_eMQhr1uDGCx3FFxknGytYw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hi there,
<div><br>
<div>The important part in Omri's email I think is: "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,"</div>
<div><br>
</div>
<div>--> ok so this is not a spec, that wasn't clear to me.
So let's not write it as one. It's a definition for a
specific event: the March interop. Sure why not. But again,
this is more in the line of the previous docs you created
for past interops Omri. Again, make it an article, or an
opinion piece on how GTwy vendors <i>could</i> use AuthZen.</div>
</div>
<div><br>
</div>
<div>--> if we want Gtwy vendors to map stuff in a specific
way, we should just call it out in the Authzen protocol
itself, and assume they're smart enough to figure out how to
map their "stuff" (route and all) into it. I.e., let's not
write a design spec for them. This document still reads like a
design spec, it's something I'd give my engineers to work
on...</div>
<div><br>
</div>
<div>So it might be easier to agree on this if framed like
that? <br>
If this is just for the interop, then yeah I don't have a pb
with the doc, if Gtwy vendors find it helpful, good...</div>
<div><br>
</div>
<div>My $0.02..</div>
<div><br>
</div>
<div>cheers,</div>
<div><br>
</div>
<div>./\.</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Fri, Jan 24, 2025 at
5:38 AM Michael Schwartz via Openid-specs-authzen <<a
href="mailto:openid-specs-authzen@lists.openid.net"
moz-do-not-send="true" class="moz-txt-link-freetext">openid-specs-authzen@lists.openid.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">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.
<div><br>
</div>
<div>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.<br>
<div>
<div><br>
</div>
<div>- Mike </div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Jan 24, 2025 at
12:52 AM Omri Gazitt <<a href="mailto:omri@aserto.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">omri@aserto.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>Michiel is correct on all counts in his response.</div>
<div><br>
</div>
<div>Additional comments:</div>
<div><br>
</div>
<div><u>Scope</u></div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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 "<a
href="https://hackmd.io/MTJPf_vzSmubctNtHis99g#Scope" target="_blank"
moz-do-not-send="true">Scope</a>" section). We can
have other proposals for other protocols.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><u>Too opinionated</u></div>
<div>The proposal suggests default mappings. Everything
should be overridable by a developer configuring a
gateway's authzen filter. Please re-read the "<a
href="https://hackmd.io/MTJPf_vzSmubctNtHis99g#Purpose" target="_blank"
moz-do-not-send="true">purpose</a>" section (also
quoted below):</div>
<blockquote
style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div>
<p>Ideally, the filter implementation <span
style="background-color:rgb(255,255,0)">allows
the developer to indicate which HTTP elements
(method, path, headers, body) to map into which
fields of the AuthZEN evaluation request</span>.</p>
</div>
<div>
<p>So why define an AuthZEN profile for API
gateways? <span
style="background-color:rgb(255,255,0)">To
provide a simple mapping as a sensible default
(which a developer can ideally override).</span></p>
</div>
<div>
<p>This in turn can accelerate the process of
enabling API Gateways to easily become AuthZEN
clients.</p>
</div>
</blockquote>
<div>
<h2
id="m_-1979186327547575944m_-3221772943351243300gmail-Scope"><a
href="#m_-1979186327547575944_m_-3221772943351243300_Scope"
title="Scope" moz-do-not-send="true"><span></span></a></h2>
</div>
<div>
<div>Stepping back, there are three usages that the
proposal is trying to cover. </div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>This is what the "default mapping" is good for.
This is what Michiel's original proposal was trying
to accomplish as well.</div>
<div><br>
</div>
<div>2. PEP allows the developer to pick what HTTP
fields they want to put in which AuthZEN fields. <i>This
doesn't require a profile or spec or anything. </i>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.</div>
<div><br>
</div>
<div>3. PEP calls out to the PDP to <i>Authorize
access to routes. </i> 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. </div>
</div>
<div><u><br>
</u></div>
<div><u>Where various HTTP fields go</u></div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>
<div><u>Type names</u></div>
<div>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). </div>
<div><br>
</div>
<div><br>
</div>
<div>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 <i>route
authorization</i> scenario.</div>
</div>
<div><br>
</div>
<div><br>
</div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Jan 23, 2025
at 1:21 PM Michiel Trimpe via Openid-specs-authzen
<<a
href="mailto:openid-specs-authzen@lists.openid.net" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">openid-specs-authzen@lists.openid.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div dir="ltr">
<div dir="ltr">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.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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?”</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Regards, Michiel</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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. </div>
</div>
<hr style="display:inline-block;width:98%">
<div
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682divRplyFwdMsg"
dir="ltr"><font face="Calibri, sans-serif"
style="font-size:11pt" color="#000000"><b>From:</b>
Openid-specs-authzen <<a
href="mailto:openid-specs-authzen-bounces@lists.openid.net"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">openid-specs-authzen-bounces@lists.openid.net</a>>
on behalf of Antonio Radesca via
Openid-specs-authzen <<a
href="mailto:openid-specs-authzen@lists.openid.net" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">openid-specs-authzen@lists.openid.net</a>><br>
<b>Sent:</b> Thursday, January 23, 2025
9:45:46 PM<br>
<b>To:</b> AuthZEN Working Group List <<a
href="mailto:openid-specs-authzen@lists.openid.net" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">openid-specs-authzen@lists.openid.net</a>>;
<a href="mailto:mike@gluu.org" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">mike@gluu.org</a>
<<a href="mailto:mike@gluu.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">mike@gluu.org</a>><br>
<b>Cc:</b> Antonio Radesca <<a
href="mailto:antonio.radesca@nitroagility.com" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">antonio.radesca@nitroagility.com</a>><br>
<b>Subject:</b> Re: [Openid-specs-authzen]
Comments on the Authzen API GW Profile</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div>Hi All,<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
Finally, there is also a latency concern
when passing unnecessary information, as it
adds processing overhead without any clear
benefit.</div>
<div><br>
</div>
<div>Thank you for your time</div>
<div><br>
</div>
<div>
<div dir="ltr">
<div dir="ltr">
<p
style="color:rgb(32,31,30);margin:0px"><font
face="arial, sans-serif"><b><span
style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;line-height:inherit;vertical-align:baseline;color:rgb(102,102,102)">Antonio
Radesca</span></b><br>
</font></p>
<p style="color:rgb(80,0,80);margin:0px"><font
face="arial, sans-serif"
color="#3d85c6"><span
style="font-style:inherit;font-weight:inherit">Co-founder / </span>Chief
Technology Officer</font></p>
<p style="color:rgb(80,0,80);margin:0px"><span
style="color:rgb(61,133,198);font-family:arial,sans-serif;font-size:12px"><b><br>
</b></span></p>
<p style="color:rgb(80,0,80);margin:0px"><font
size="1"><span
style="color:rgb(61,133,198);font-family:arial,sans-serif"><b>M:</b></span>+373
698 04 974<font color="#000000"> </font><span
style="color:rgb(61,133,198);font-family:arial,sans-serif"><b>P:</b></span><font
color="#000000"
face="arial, sans-serif">+39 0835
170 0059 </font><span
style="font-family:arial,sans-serif"><font color="#3d85c6"
style="font-weight:bold">P:</font><font
color="#000000"> </font></span><font
color="#000000"
face="arial, sans-serif">+44 20
3966 5620</font></font></p>
<p style="color:rgb(80,0,80);margin:0px"><font
size="1"><b
style="color:rgb(61,133,198);font-family:arial,sans-serif">E:</b><a
href="mailto:antonio.radesca@nitroagility.com"
style="color:rgb(17,85,204)"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">antonio.radesca@nitroagility.com</a> </font><b
style="font-size:x-small;color:rgb(61,133,198);font-family:arial,sans-serif">in:</b><a
href="https://www.linkedin.com/in/antonioradesca/"
style="color:rgb(17,85,204);font-size:x-small" target="_blank"
moz-do-not-send="true"><span
style="font-family:arial,sans-serif"><font color="#000000">antonioradesca</font></span></a></p>
<p style="color:rgb(80,0,80);margin:0px"><font
size="1"><b
style="color:rgb(61,133,198);font-family:arial,sans-serif">W:</b><a
href="https://www.nitroagility.com/" style="color:rgb(17,85,204)"
target="_blank"
moz-do-not-send="true">nitroagility.com</a> <b
style="color:rgb(61,133,198);font-family:arial,sans-serif">in:</b><a
href="https://www.linkedin.com/company/20520302"
style="color:rgb(17,85,204)"
target="_blank"
moz-do-not-send="true">nitroagility</a></font></p>
<p style="color:rgb(80,0,80);margin:0px"><img
width="200" height="77"
src="https://ci3.googleusercontent.com/mail-sig/AIorK4wUB01EIrlYVsq8xjWyG9QdKXffayXD2EkOXZabKTrmSaXEVcPnHLnG1YNid88M67u1HPXDUuFAAgF2"
moz-do-not-send="true"><br>
</p>
<p style="color:rgb(80,0,80);margin:0px"><span
style="font-size:x-small;color:rgb(102,102,102);font-family:arial,sans-serif">Nitro
Agility Srl </span><span
style="font-size:x-small;color:rgb(102,102,102);font-family:arial,sans-serif">- </span><font
color="#666666"
style="font-size:x-small;font-family:arial,sans-serif">C.F./P.IVA:
01364090777 </font><span
style="font-size:x-small;font-family:arial,sans-serif;color:rgb(0,0,0)">- </span><span
style="font-size:x-small;font-style:inherit;font-weight:inherit;font-family:arial,sans-serif;color:rgb(102,102,102)">PEC: <a
href="mailto:nitroagility@pec.it"
style="color:rgb(17,85,204)"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">nitroagility@pec.it</a></span><br>
</p>
<div
style="color:rgb(80,0,80);margin:0px;padding:0px;border:0px;font-stretch:inherit;line-height:inherit;vertical-align:baseline">
<p
style="color:rgb(32,31,30);margin:0px"><font size="1"><span
style="color:rgb(102,102,102);font-family:arial,sans-serif">SEDE LEGALE:
VIA F. PARRI 44, 75100 MATERA
(MT), ITALY</span><br>
</font></p>
<p
style="color:rgb(32,31,30);margin:0px"><font size="1"><span
style="color:rgb(102,102,102);font-family:arial,sans-serif">SEDE
OPERATIVA: VIA LUCANA 259, 75100
MATERA (MT), ITALY </span><font
color="#666666"
style="font-family:arial,sans-serif"> </font></font></p>
<p style="margin:0px"><font size="1"><span
style="color:rgb(102,102,102);font-style:inherit;font-variant:inherit;font-weight:inherit;font-family:arial,sans-serif;margin:0px;padding:0px;border:0px;font-stretch:inherit;line-height:inherit;vertical-align:baseline">CODICE
DESTINATARIO: </span><font
color="#666666"
face="arial, sans-serif">M5UXCR1</font><span
style="color:rgb(102,102,102);font-style:inherit;font-weight:inherit;font-family:arial,sans-serif"> </span></font></p>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
<div>
<div dir="ltr">On Thu, Jan 23, 2025 at 8:58 PM
Nicola Gallo via Openid-specs-authzen <<a
href="mailto:openid-specs-authzen@lists.openid.net" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">openid-specs-authzen@lists.openid.net</a>>
wrote:<br>
</div>
<blockquote
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>Hi All,</div>
<div><br>
</div>
<div>I completely agree with <a
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691gmail-plusReplyChip-1"
moz-do-not-send="true">@</a><a
href="mailto:alex.babeanu@indykite.com" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">alex.babeanu@indykite.com</a>’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.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<p
style="color:rgb(32,31,30);margin:0px"><font face="arial, sans-serif"><b><span
style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;line-height:inherit;vertical-align:baseline;color:rgb(102,102,102)">Nicola
Gallo</span></b><br>
</font></p>
<p
style="margin:0px"><font face="arial, sans-serif" color="#3d85c6"><span
style="font-style:inherit;font-weight:inherit">Co-founder /
</span>Chief
Technology
Officer</font></p>
<p
style="margin:0px"><span
style="color:rgb(61,133,198);font-family:arial,sans-serif;font-size:12px"><b><br>
</b></span></p>
<p
style="margin:0px"><font size="1"><span
style="color:rgb(61,133,198);font-family:arial,sans-serif"><b>M:</b></span><span
style="color:rgb(0,0,0)">+39 </span><font color="#000000">349 3305248 </font></font><span
style="font-size:x-small;color:rgb(61,133,198);font-family:arial,sans-serif"><b>P:</b></span><font
color="#000000" face="arial, sans-serif" size="1">+39 0835 170 0059 </font><span
style="font-size:x-small;font-family:arial,sans-serif"><font
color="#3d85c6" style="font-weight:bold">P:</font><font color="#000000"> </font></span><font
color="#000000" face="arial, sans-serif" size="1">+44 20 3966 5620</font></p>
<p
style="margin:0px"><font size="1"><b
style="color:rgb(61,133,198);font-family:arial,sans-serif">E:</b><a
href="mailto:nicola.gallo@nitroagility.com" style="color:rgb(17,85,204)"
target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">nicola.gallo@nitroagility.com</a> </font><b
style="font-size:x-small;color:rgb(61,133,198);font-family:arial,sans-serif">in:</b><a
href="https://www.linkedin.com/in/nicolagallo83/"
style="font-size:x-small;color:rgb(17,85,204)" target="_blank"
moz-do-not-send="true"><span style="font-family:arial,sans-serif"><font
color="#000000">nicolagallo83</font></span></a></p>
<p
style="margin:0px"><font size="1"><b
style="color:rgb(61,133,198);font-family:arial,sans-serif">W:</b><a
href="https://www.nitroagility.com/" style="color:rgb(17,85,204)"
target="_blank" moz-do-not-send="true">nitroagility.com</a> <b
style="color:rgb(61,133,198);font-family:arial,sans-serif">in:</b><a
href="https://www.linkedin.com/company/20520302"
style="color:rgb(17,85,204)" target="_blank" moz-do-not-send="true">nitroagility</a></font></p>
<p
style="margin:0px"><img width="200" height="77"
src="https://ci3.googleusercontent.com/mail-sig/AIorK4wUB01EIrlYVsq8xjWyG9QdKXffayXD2EkOXZabKTrmSaXEVcPnHLnG1YNid88M67u1HPXDUuFAAgF2"
moz-do-not-send="true"><br>
</p>
<p
style="margin:0px"><span
style="font-size:x-small;color:rgb(102,102,102);font-family:arial,sans-serif">Nitro
Agility Srl </span><span
style="font-size:x-small;color:rgb(102,102,102);font-family:arial,sans-serif">- </span><font
color="#666666" style="font-size:x-small;font-family:arial,sans-serif">C.F./P.IVA:
01364090777 </font><span
style="font-size:x-small;font-family:arial,sans-serif;color:rgb(0,0,0)">-
</span><span
style="font-size:x-small;font-style:inherit;font-weight:inherit;font-family:arial,sans-serif;color:rgb(102,102,102)">PEC: <a
href="mailto:nitroagility@pec.it" style="color:rgb(17,85,204)"
target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">nitroagility@pec.it</a></span><br>
</p>
<div
style="margin:0px;padding:0px;border:0px;font-stretch:inherit;line-height:inherit;vertical-align:baseline">
<p
style="color:rgb(32,31,30);margin:0px"><font size="1"><span
style="color:rgb(102,102,102);font-family:arial,sans-serif">SEDE LEGALE:
VIA F. PARRI
44, 75100
MATERA (MT),
ITALY</span><br>
</font></p>
<p
style="color:rgb(32,31,30);margin:0px"><font size="1"><span
style="color:rgb(102,102,102);font-family:arial,sans-serif">SEDE
OPERATIVA: VIA
LUCANA 259,
75100 MATERA
(MT), ITALY </span><font
color="#666666" style="font-family:arial,sans-serif"> </font></font></p>
<p
style="margin:0px"><font size="1"><span
style="color:rgb(102,102,102);font-style:inherit;font-variant:inherit;font-weight:inherit;font-family:arial,sans-serif;margin:0px;padding:0px;border:0px;font-stretch:inherit;line-height:inherit;vertical-align:baseline">CODICE
DESTINATARIO: </span><font
color="#666666" face="arial, sans-serif">M5UXCR1</font><span
style="color:rgb(102,102,102);font-style:inherit;font-weight:inherit;font-family:arial,sans-serif"> </span></font><font
color="#666666" size="1"
style="color:rgb(32,31,30);font-family:arial,sans-serif"><br>
</font></p>
<p
style="margin:0px"><span
style="color:rgb(94,94,94);font-family:arial,sans-serif;font-size:9px">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.</span></p>
<p
style="margin:0px"><span
style="color:rgb(94,94,94);font-family:arial,sans-serif;font-size:9px"><br>
</span></p>
<p
style="text-align:left;margin:0px"><img width="200" height="37"
src="https://ci3.googleusercontent.com/mail-sig/AIorK4y3sQmpirYHl37mvD3reoh7YopRFpaMDqKyMUUvHDRyqIeFtVw9my383vLbQNAUaD8kG0xJTTYKGwME"
style="font-family: arial, sans-serif;" moz-do-not-send="true"></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
<div>
<div dir="ltr">On Thu, 23 Jan 2025 at
19:02, Michael Schwartz via
Openid-specs-authzen <<a
href="mailto:openid-specs-authzen@lists.openid.net" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">openid-specs-authzen@lists.openid.net</a>>
wrote:<br>
</div>
<blockquote
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">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.
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>- Mike </div>
<div><br>
</div>
</div>
<br>
<div>
<div dir="ltr">On Thu, Jan 23, 2025 at
9:51 AM Alex Babeanu <<a
href="mailto:alex.babeanu@indykite.com" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">alex.babeanu@indykite.com</a>>
wrote:<br>
</div>
<blockquote
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Hi all,
<div><br>
</div>
<div>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??</div>
<div> 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...<br>
<br>
This could therefore be a
recommendations article rather
than a formal standard/spec. My
$0.02...<br>
<br>
And sry if the decision was
already made to go ahead in this
direction, I may have missed it
- been too busy.</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div>./\.</div>
</div>
<br>
<div>
<div dir="ltr">On Thu, Jan 23,
2025 at 7:39 AM Michiel Trimpe
via Openid-specs-authzen <<a
href="mailto:openid-specs-authzen@lists.openid.net" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">openid-specs-authzen@lists.openid.net</a>>
wrote:<br>
</div>
<blockquote
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div dir="ltr">
<div
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<b>Collision Resistance</b><br>
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
<a
href="https://datatracker.ietf.org/doc/html/rfc9396#name-authorization-details-types"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427LPlnk693057"
title="https://datatracker.ietf.org/doc/html/rfc9396#name-authorization-details-types"
target="_blank"
moz-do-not-send="true">
section in the OAuth RAR
specification</a> recently
which does a fairly good
job at explaining this IMO
(although I'm not a fan of
URI's as namespaces.)<br>
<br>
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":
<a class="moz-txt-link-rfc2396E" href="http:route">"http:route"</a>} and {"type":
<a class="moz-txt-link-rfc2396E" href="http:uri">"http:uri"</a>} and {"action":
<a class="moz-txt-link-rfc2396E" href="http:get">"http:get"</a>}<br>
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".<br>
<br>
</div>
<div
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<b>What goes where</b></div>
<div
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Looking at terminology
alone it seems logical for
me to put:<br>
- information from/about
the Uniform <u>Resource</u> Identifier
in the `<u>resource</u>`
section</div>
<div
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
- the HTTP <u>method/verb</u> in
the `<u>action</u>`section
and</div>
<div
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
- the <u>subject</u> as
extracted from e.g. the
Authorization header in
the `<u>subject</u>`
section<br>
<br>
I'd personally say 'body'
belongs in the `action`
section as well since it's
*what* your are PUTting or
POSTing.<br>
<br>
Then you get a sentence
like "As
`mtrimpe`(subject) I `POST
{"json":"string"}`(action)
to `<a
href="http://example.com/json-store(resource)" target="_blank"
moz-do-not-send="true">http://example.com/json-store`(resource)</a>."<br>
<br>
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.<br>
<br>
Cheers, Michiel</div>
<div
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427appendonsend">
</div>
<hr
style="display:inline-block;width:98%">
<div dir="ltr"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427divRplyFwdMsg">
<span
style="font-family:Calibri,sans-serif;font-size:11pt;color:rgb(0,0,0)"><b>From:</b> Openid-specs-authzen
<<a
href="mailto:openid-specs-authzen-bounces@lists.openid.net"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">openid-specs-authzen-bounces@lists.openid.net</a>>
on behalf of Michael
Schwartz via
Openid-specs-authzen
<<a
href="mailto:openid-specs-authzen@lists.openid.net" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">openid-specs-authzen@lists.openid.net</a>><br>
<b>Sent:</b> 23 January
2025 00:37<br>
<b>To:</b> AuthZEN
Working Group List <<a
href="mailto:openid-specs-authzen@lists.openid.net" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">openid-specs-authzen@lists.openid.net</a>><br>
<b>Cc:</b> Michael
Schwartz <<a
href="mailto:mike@gluu.org" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">mike@gluu.org</a>><br>
<b>Subject:</b> Re:
[Openid-specs-authzen]
Comments on the Authzen
API GW Profile</span>
<div> </div>
</div>
<div style="direction:ltr">Here
are some more comments
about Omri's "AuthZEN REST
API Gateway Profile
proposal" we've been so
heatedly discussing,
described here:
<a
href="https://hackmd.io/MTJPf_vzSmubctNtHis99g"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWA6ef01596-5c6c-e41d-cf1f-162d00b0cb55"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">
https://hackmd.io/MTJPf_vzSmubctNtHis99g</a> </div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">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...). </div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">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...)</div>
<div style="direction:ltr">
- In the Subject, <b>type
"user"</b>. What about:
"OpenID Authzen API GW
Profile 0.1 User",
"OpenID::Authzen::API-GW::0.1::User",
or
<a
href="https://openid.net/authzen/types/User"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWA16835dd9-5773-ae79-a688-7bdc7f4db8c1"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">
https://openid.net/authzen/types/User</a>" (today the best practice for
OAuth scopes is to use a
unique URI)</div>
<div style="direction:ltr">
- In the Action, <b>type
"GET"</b>, to
"OpenID::Authzen::API-GW::GET"
(or one of the other
formats above)</div>
<div style="direction:ltr">
- In the Resource,<b> "type":
"route"</b>, -->
"OpenID::Authzen::API-GW::0.1::Route" </div>
<div style="direction:ltr">
- 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". </div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">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. </div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">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.</div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">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. </div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">-
Mike </div>
<div style="direction:ltr"><br>
</div>
<br>
<div style="direction:ltr">On
Fri, Jan 17, 2025 at
1:42 AM Omri Gazitt via
Openid-specs-authzen <<a
href="mailto:openid-specs-authzen@lists.openid.net"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWA483ee2aa-f536-236c-ca0f-6a8e5ac04f15"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">openid-specs-authzen@lists.openid.net</a>>
wrote:</div>
<blockquote
style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204,204)">
<div style="direction:ltr">Thank
you Michael, Michiel,
and Julio for your
comments.</div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">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. </div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">Julio
is exactly right on all
counts:</div>
<ul style="direction:ltr">
<li
style="direction:ltr">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</li>
<li
style="direction:ltr">the
question you're asking
in "medium-grained
authz" is "can this
subject invoke the
route represented by {
HTTP method, HTTP
route }"</li>
<li
style="direction:ltr">"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</li>
</ul>
<div style="direction:ltr">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". </div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">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). </div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">Stepping
back, I do think we can
represent the two
scenarios in a single
profile.</div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">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.</div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">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.</div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">The
"default" mapping for
this scenario feels to
me like the following
(in pseudo-code):</div>
<div style="direction:ltr"><br>
</div>
<div
style="direction:ltr;font-family:monospace">{</div>
<div
style="direction:ltr;font-family:monospace"> "subject": {</div>
<div
style="direction:ltr;font-family:monospace"> "type": "user",</div>
<div
style="direction:ltr;font-family:monospace"> "id":
"<decode_jwt(request.headers["authorization"]).sub>"</div>
<div
style="direction:ltr;font-family:monospace"> },</div>
<div
style="direction:ltr;font-family:monospace"> "action": {</div>
<div
style="direction:ltr;font-family:monospace"> "name":
"<request.method>"</div>
<div
style="direction:ltr;font-family:monospace"> },</div>
<div
style="direction:ltr;font-family:monospace"> "resource": {</div>
<div
style="direction:ltr;font-family:monospace"> "type": "route", // or
"uri" if "route" is not
available</div>
<div
style="direction:ltr;font-family:monospace"> "id":
"<request.route>",
// or "uri" if "route"
is not available</div>
<div
style="direction:ltr;font-family:monospace"> "properties": {</div>
<div
style="direction:ltr;font-family:monospace"> // uri components,
path parameters, query
(or query parameters if
they get parsed)</div>
<div
style="direction:ltr;font-family:monospace"> },</div>
<div
style="direction:ltr;font-family:monospace"> "context": {</div>
<div
style="direction:ltr;font-family:monospace"> "headers": [],</div>
<div
style="direction:ltr;font-family:monospace"> "body": ...</div>
<div
style="direction:ltr;font-family:monospace"> }</div>
<div
style="direction:ltr;font-family:monospace"> }</div>
<div
style="direction:ltr;font-family:monospace">}</div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">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.</div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">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
<span
style="font-family:monospace">context.headers["Authorization"]</span>. </div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">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.</div>
<br>
<div style="direction:ltr">On
Wed, Jan 15, 2025 at
7:28 AM Julio Auto De
Medeiros (BLOOMBERG/ 731
LEX) via
Openid-specs-authzen
<<a
href="mailto:openid-specs-authzen@lists.openid.net"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWA2bcf9990-8b3b-1110-2a5c-dbcdbc2b2509"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">openid-specs-authzen@lists.openid.net</a>>
wrote:</div>
<blockquote
style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204,204)">
<div
style="white-space:pre-wrap;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:rgb(0,0,0)">
A couple of thoughts: </div>
<div
style="font-family:Arial,"BB.Proportional";font-size:9.75pt;color:rgb(0,0,0)">
<br>
</div>
<div
style="white-space:pre-wrap;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:rgb(0,0,0)">
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.</div>
<div
style="font-family:Arial,"BB.Proportional";font-size:9.75pt;color:rgb(0,0,0)">
<br>
</div>
<div
style="white-space:pre-wrap;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:rgb(0,0,0)">
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:
{ </div>
<div
style="white-space:pre-wrap;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:rgb(0,0,0)">
"subject": {</div>
<div
style="white-space:pre-wrap;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:rgb(0,0,0)">
"type": "user",</div>
<div
style="white-space:pre-wrap;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:rgb(0,0,0)">
"id": {</div>
<div
style="white-space:pre-wrap;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:rgb(0,0,0)">
"format" : "JWT",</div>
<div
style="white-space:pre-wrap;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:rgb(0,0,0)">
"jwt": "eyJhb..."</div>
<div
style="white-space:pre-wrap;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:rgb(0,0,0)">
}</div>
<div
style="white-space:pre-wrap;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:rgb(0,0,0)">
}</div>
<div
style="white-space:pre-wrap;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:rgb(0,0,0)">
}</div>
<div
style="font-family:Arial,"BB.Proportional";font-size:9.75pt;color:rgb(0,0,0)">
<br>
</div>
<div
style="white-space:pre-wrap;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:rgb(0,0,0)">
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 '<a
href="mailto:john.doe@acmecorp.com"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWA2196c9ee-ae0e-35e8-58eb-082dd8ab989c"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">john.doe@acmecorp.com</a>',
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.
</div>
<div
style="white-space:pre-wrap;font-family:"Courier New",Courier,"BB.FixedWidth";font-size:9.75pt;color:rgb(0,0,0)">
From: <a href="mailto:openid-specs-authzen@lists.openid.net"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWA1fc70314-f50b-da88-b420-a8abee6370d4"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">
openid-specs-authzen@lists.openid.net</a> At: 01/15/25 04:33:30 UTC-5:00</div>
<div
style="white-space:pre-wrap;font-family:"Courier New",Courier,"BB.FixedWidth";font-size:9.75pt;color:rgb(0,0,0)">
To: <a href="mailto:openid-specs-authzen@lists.openid.net"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWA6b336038-a9d8-0dc8-0dfb-ea138ceffb23"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">
openid-specs-authzen@lists.openid.net</a>
Cc: <a href="mailto:Michiel.Trimpe@VNG.NL"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWAbcdcadfc-d6dd-2d6b-15a9-eaae5ff9f244"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">
Michiel.Trimpe@VNG.NL</a>
Subject: Re: [Openid-specs-authzen] Comments on the Authzen API GW Profile</div>
<div
style="font-family:"Courier New",Courier,"BB.FixedWidth";font-size:9.75pt;color:rgb(0,0,0)">
<br>
</div>
<div
style="background-color:white">
<blockquote>
<div
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Hi Michael,</div>
<div
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div
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
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div
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="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720appendonsend">
</div>
<hr
style="display:inline-block;width:98%">
<div dir="ltr"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720divRplyFwdMsg">
<span
style="font-family:Calibri,sans-serif;font-size:11pt;color:rgb(0,0,0)"><b>From:</b> Openid-specs-authzen
<<a
href="mailto:openid-specs-authzen-bounces@lists.openid.net"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWAc6ca2f99-50b8-643a-1638-4337dd73d416"
target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">openid-specs-authzen-bounces@lists.openid.net</a>>
on behalf of
Michael Schwartz
via
Openid-specs-authzen
<<a
href="mailto:openid-specs-authzen@lists.openid.net"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWAc3d98771-36b3-a9f3-f4d3-439a60822619"
target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">openid-specs-authzen@lists.openid.net</a>><br>
<b>Sent:</b> 15
January 2025
02:51<br>
<b>To:</b> AuthZEN
Working Group
List <<a
href="mailto:openid-specs-authzen@lists.openid.net"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWAb4a62c22-4e25-2866-dc20-0adb017448ef"
target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">openid-specs-authzen@lists.openid.net</a>><br>
<b>Cc:</b> Michael
Schwartz <<a
href="mailto:mike@gluu.org"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWA6f27776d-fd09-c3ce-7aa2-f06a91e52338"
target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">mike@gluu.org</a>><br>
<b>Subject:</b> [Openid-specs-authzen]
Comments on the
Authzen API GW
Profile</span>
<div> </div>
</div>
<div
style="direction:ltr;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
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;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
<br>
</div>
<div
style="direction:ltr;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
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)">
<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;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
<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;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
<br>
</div>
<div
style="direction:ltr;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
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="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720OWA795e2991-0ed0-a4d2-6657-fb1b346c4cae"
target="_blank"
moz-do-not-send="true">
google.com</a> domain
do this.. for <a
href="http://gmail.com/"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720OWA1ecc0585-6234-534d-2177-e4aeb60289c8"
target="_blank"
moz-do-not-send="true">
gmail.com</a> domain...
do something else.</div>
<div
style="direction:ltr;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
<span
style="background-color:rgb(255,255,0)"><br>
> That can be
done using a
simple "eq '<a
href="http://google.com/"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWA589110c5-3203-8ac5-aa97-4d3a53cadb7d"
target="_blank" moz-do-not-send="true">google.com</a>' or endsWith '.<a
href="http://google.com/"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWAb450102c-3280-29f6-12c3-3e1978a8dd66"
target="_blank" moz-do-not-send="true">google.com</a>'" 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;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
<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;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
<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;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
<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;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
<br>
</div>
<div
style="direction:ltr;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
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;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
<br>
</div>
<div
style="direction:ltr;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif">
<span
style="font-size:9.75pt;color:black;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="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720OWA48cc550a-3204-8c09-77ab-91c1a4b8275e"
target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">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="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720OWAfcf896d9-49d2-d342-0184-826481b314eb"
target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">
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;font-size:9.75pt;color:black">
<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;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
<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;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
<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="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720LPlnk845435"
target="_blank" moz-do-not-send="true">
JSON objects
are specified
to be
unordered</a> .</span></div>
<div
style="direction:ltr;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
<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;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
<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;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
<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;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
<span
style="background-color:rgb(255,255,0)"><br>
</span></div>
<div
style="direction:ltr;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
8 .For the
resource... what
about something
like this:</div>
<div
style="direction:ltr;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
<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="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720OWA488468d0-fae3-4b3d-5f3d-778e26540ef8"
target="_blank"
moz-do-not-send="true">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="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720OWA08158ac8-4665-7ec4-fbd4-7754b56512e5"
target="_blank"
moz-do-not-send="true">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;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
--------------------------------------</div>
<div
style="direction:ltr;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
Michael Schwartz</div>
<div
style="direction:ltr;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
Glue</div>
<div
style="direction:ltr;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
Founder/CEO</div>
<div
style="direction:ltr;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
<a
href="mailto:mike@gluu.org"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720OWAadc3d9f8-f348-21e7-677b-cde32aade5b4"
target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">mike@gluu.org</a></div>
<div
style="direction:ltr;font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black">
<a
href="https://www.linkedin.com/in/nynymike"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720OWA04568d1d-dc8d-6790-113f-d19b363c704e"
target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.linkedin.com/in/nynymike</a></div>
<div
style="font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black"><br>
</div>
<div
style="font-family:Arial,"BB.Proportional";font-size:10px;color:black"><img
moz-do-not-send="true"></div>
<hr>
<div
style="font-family:"Sans Serif";font-size:10px;color:rgb(128,128,128)"><b>CONFIDENTIALITY
NOTICE</b></div>
<div
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</div>
<div
style="margin:14px 14px 14px 0px;padding-top:4px;border-top:1px dotted black">
</div>
<pre><div
style="font-size:9.75pt;color:black">--
Openid-specs-authzen mailing list
<a href="mailto:Openid-specs-authzen@lists.openid.net"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWA71487311-c426-c71f-946b-fe18261945ca"
target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">Openid-specs-authzen@lists.openid.net</a>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-authzen"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWAe44556b2-dd24-4fa8-8d38-65e1c8fc0d81"
target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.openid.net/mailman/listinfo/openid-specs-authzen</a>
</div></pre>
</blockquote>
<div
style="font-family:Arial,"BB.Proportional";font-size:9.75pt;color:black"><br>
</div>
</div>
--<br>
Openid-specs-authzen
mailing list<br>
<a
href="mailto:Openid-specs-authzen@lists.openid.net"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWA421a7e78-377e-671a-22ec-13f5e4333ac8"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">Openid-specs-authzen@lists.openid.net</a><br>
<a
href="https://lists.openid.net/mailman/listinfo/openid-specs-authzen"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWA204f9895-f328-a7fc-1325-dd5b3d268dfb"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.openid.net/mailman/listinfo/openid-specs-authzen</a><br>
</blockquote>
--<br>
Openid-specs-authzen
mailing list<br>
<a
href="mailto:Openid-specs-authzen@lists.openid.net"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWA97a44c04-f191-e6e0-9648-765e692dce81"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">Openid-specs-authzen@lists.openid.net</a><br>
<a
href="https://lists.openid.net/mailman/listinfo/openid-specs-authzen"
id="m_-1979186327547575944m_-3221772943351243300m_5378161741629038682x_m_-2543444195844532691m_-7504012787283786433m_-8060408478212832151m_-3337262532688309427OWA8d99992e-e2f0-6346-112d-1bc900679540"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.openid.net/mailman/listinfo/openid-specs-authzen</a><br>
</blockquote>
<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"
moz-do-not-send="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>
</div>
-- <br>
Openid-specs-authzen mailing
list<br>
<a
href="mailto:Openid-specs-authzen@lists.openid.net" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">Openid-specs-authzen@lists.openid.net</a><br>
<a
href="https://lists.openid.net/mailman/listinfo/openid-specs-authzen"
rel="noreferrer"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.openid.net/mailman/listinfo/openid-specs-authzen</a><br>
</div>
</blockquote>
</div>
<div><br clear="all">
</div>
<div><br>
</div>
<span>-- </span><br>
<div dir="ltr">
<div dir="ltr">
<table width="600"
cellspacing="0"
cellpadding="0" border="0"
style="font-size:13px;color:rgb(0,0,0);padding:32px 0px;font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol"">
<tbody>
<tr>
<td width="44"
style="vertical-align:top;padding:0px 16px"><img
src="https://lh6.googleusercontent.com/t9ujvLE5ixncgTZdMRypM3BVdboAHbvIP0ENG6TwOqyegNnox4CtJXTNCyp7v7u3N-D6hxkZFn_N2GAttGtVtIAJkg7k7kp4K4GJGFH4WjlSfRyE0jXPP9MW1NXgMDVlPV4iZJjt"
width="71"
height="129"
style="font-family: Arial; font-size: 14.6667px; margin-left: 0px; margin-top: 0px;"
moz-do-not-send="true"><span
style="font-family:Arial;font-size:14.6667px"></span><br>
</td>
<td width="16"
style="border-left:1px solid rgb(212,212,212)"><br>
</td>
<td
style="vertical-align:top"><span
style="display:block;padding-top:10px;line-height:0px;font-size:15px;font-weight:bold"><br>
</span><span
style="display:block;padding-top:10px;line-height:0px;font-size:15px;font-weight:bold">Alex
Babeanu</span><span
style="display:block;padding-top:10px;line-height:0px;font-size:15px"><br>
</span><span
style="display:block;padding-top:10px;line-height:0px">Lead Product
Manager, Access
Management<br>
<br>
</span><span
style="display:block;padding-top:10px;line-height:0px;font-size:15px"><br>
</span><span
style="display:block;padding-top:10px;line-height:0px;font-size:15px"><br>
</span><span
style="margin-bottom:16px;color:rgb(76,76,76)"><font
style="vertical-align:inherit"><font style="vertical-align:inherit">t.
+1 604 728 8130</font></font><br>
<font
style="vertical-align:inherit"><font style="vertical-align:inherit">e. </font></font><a
href="mailto:alex.babeanu@indykite.com" style="color:rgb(17,85,204)"
target="_blank"
moz-do-not-send="true"><font style="vertical-align:inherit"><font
style="vertical-align:inherit">alex.babeanu@indykite.com</font></font></a> <br>
<font
style="vertical-align:inherit"><font style="vertical-align:inherit">w. </font></font><a
href="http://www.indykite.com/" style="color:rgb(17,85,204)"
target="_blank"
moz-do-not-send="true"><font style="vertical-align:inherit"><font
style="vertical-align:inherit">www.indykite.com</font></font></a></span></td>
</tr>
</tbody>
</table>
</div>
</div>
</blockquote>
</div>
<br>
<div><font size="1"><img
src="https://github.com/GluuFederation/docs-gluu-server-prod/blob/master/docs/source/small_logo.png?raw=true"
moz-do-not-send="true"><br>
</font></div>
<div>
<hr>
</div>
<div><font size="1"><b
style="color:rgb(128,128,128);font-family:"Sans Serif"">CONFIDENTIALITY
NOTICE</b><br>
</font></div>
<font face="Sans Serif" color="#808080"
size="1">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</font><br>
-- <br>
Openid-specs-authzen mailing list<br>
<a
href="mailto:Openid-specs-authzen@lists.openid.net" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">Openid-specs-authzen@lists.openid.net</a><br>
<a
href="https://lists.openid.net/mailman/listinfo/openid-specs-authzen"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.openid.net/mailman/listinfo/openid-specs-authzen</a><br>
</blockquote>
</div>
-- <br>
Openid-specs-authzen mailing list<br>
<a
href="mailto:Openid-specs-authzen@lists.openid.net" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">Openid-specs-authzen@lists.openid.net</a><br>
<a
href="https://lists.openid.net/mailman/listinfo/openid-specs-authzen"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.openid.net/mailman/listinfo/openid-specs-authzen</a><br>
</blockquote>
</div>
</div>
</div>
-- <br>
Openid-specs-authzen mailing list<br>
<a
href="mailto:Openid-specs-authzen@lists.openid.net" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">Openid-specs-authzen@lists.openid.net</a><br>
<a
href="https://lists.openid.net/mailman/listinfo/openid-specs-authzen"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.openid.net/mailman/listinfo/openid-specs-authzen</a><br>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
<div><font size="1"><img
src="https://github.com/GluuFederation/docs-gluu-server-prod/blob/master/docs/source/small_logo.png?raw=true"
moz-do-not-send="true"><br>
</font></div>
<div>
<hr></div>
<div><font size="1"><b
style="color:rgb(128,128,128);font-family:"Sans Serif"">CONFIDENTIALITY
NOTICE</b><br>
</font></div>
<font face="Sans Serif" color="#808080" size="1">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</font><br>
-- <br>
Openid-specs-authzen mailing list<br>
<a href="mailto:Openid-specs-authzen@lists.openid.net"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">Openid-specs-authzen@lists.openid.net</a><br>
<a
href="https://lists.openid.net/mailman/listinfo/openid-specs-authzen"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.openid.net/mailman/listinfo/openid-specs-authzen</a><br>
</blockquote>
</div>
<div><br clear="all">
</div>
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<table width="600" cellspacing="0" cellpadding="0" border="0"
style="font-size:13px;color:rgb(0,0,0);padding:32px 0px;font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol"">
<tbody>
<tr>
<td width="44"
style="vertical-align:top;padding:0px 16px"><img
src="https://lh6.googleusercontent.com/t9ujvLE5ixncgTZdMRypM3BVdboAHbvIP0ENG6TwOqyegNnox4CtJXTNCyp7v7u3N-D6hxkZFn_N2GAttGtVtIAJkg7k7kp4K4GJGFH4WjlSfRyE0jXPP9MW1NXgMDVlPV4iZJjt"
width="71" height="129"
style="font-family: Arial; font-size: 14.6667px; margin-left: 0px; margin-top: 0px;"
moz-do-not-send="true"><span
style="font-family:Arial;font-size:14.6667px"></span><br>
</td>
<td width="16"
style="border-left:1px solid rgb(212,212,212)"><br>
</td>
<td style="vertical-align:top"><span
style="display:block;padding-top:10px;line-height:0px;font-size:15px;font-weight:bold"><br>
</span><span
style="display:block;padding-top:10px;line-height:0px;font-size:15px;font-weight:bold">Alex
Babeanu</span><span
style="display:block;padding-top:10px;line-height:0px;font-size:15px"><br>
</span><span
style="display:block;padding-top:10px;line-height:0px">Lead Product
Manager, Access Management<br>
<br>
</span><span
style="display:block;padding-top:10px;line-height:0px;font-size:15px"><br>
</span><span
style="display:block;padding-top:10px;line-height:0px;font-size:15px"><br>
</span><span
style="margin-bottom:16px;color:rgb(76,76,76)"><font
style="vertical-align:inherit"><font
style="vertical-align:inherit">t. +1 604 728
8130</font></font><br>
<font style="vertical-align:inherit"><font
style="vertical-align:inherit">e. </font></font><a
href="mailto:alex.babeanu@indykite.com"
style="color:rgb(17,85,204)" target="_blank"
moz-do-not-send="true"><font
style="vertical-align:inherit"><font
style="vertical-align:inherit">alex.babeanu@indykite.com</font></font></a> <br>
<font style="vertical-align:inherit"><font
style="vertical-align:inherit">w. </font></font><a
href="http://www.indykite.com/"
style="color:rgb(17,85,204)" target="_blank"
moz-do-not-send="true"><font
style="vertical-align:inherit"><font
style="vertical-align:inherit">www.indykite.com</font></font></a></span></td>
</tr>
</tbody>
</table>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
</body>
</html>