<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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);">
<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="LPlnk693057" class="OWAAutoLink" title="https://datatracker.ietf.org/doc/html/rfc9396#name-authorization-details-types">
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": "http:route"} and {"type": "http:uri"} and {"action": "http:get"}<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 class="elementToProof" 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 class="elementToProof" 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 class="elementToProof" 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 class="elementToProof" 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 `http://example.com/json-store`(resource)."<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 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 id="appendonsend"></div>
<hr style="display: inline-block; width: 98%;">
<div dir="ltr" id="divRplyFwdMsg"><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> 23 January 2025 00:37<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> 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="OWA6ef01596-5c6c-e41d-cf1f-162d00b0cb55" class="OWAAutoLink" originalsrc="https://hackmd.io/MTJPf_vzSmubctNtHis99g" data-auth="Verified">
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="OWA16835dd9-5773-ae79-a688-7bdc7f4db8c1" class="OWAAutoLink" originalsrc="https://openid.net/authzen/types/User" data-auth="Verified">
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="OWA483ee2aa-f536-236c-ca0f-6a8e5ac04f15" class="OWAAutoLink">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="OWA2bcf9990-8b3b-1110-2a5c-dbcdbc2b2509" class="OWAAutoLink">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:<br>
{ </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="OWA2196c9ee-ae0e-35e8-58eb-082dd8ab989c" class="OWAAutoLink">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.<br>
<br>
</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="OWA1fc70314-f50b-da88-b420-a8abee6370d4" class="OWAAutoLink">
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="OWA6b336038-a9d8-0dc8-0dfb-ea138ceffb23" class="OWAAutoLink">
openid-specs-authzen@lists.openid.net</a><br>
Cc: <a href="mailto:Michiel.Trimpe@VNG.NL" id="OWAbcdcadfc-d6dd-2d6b-15a9-eaae5ff9f244" class="OWAAutoLink">
Michiel.Trimpe@VNG.NL</a><br>
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="x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720appendonsend">
</div>
<hr style="display: inline-block; width: 98%;">
<div dir="ltr" id="x_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="OWAc6ca2f99-50b8-643a-1638-4337dd73d416" class="OWAAutoLink">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="OWAc3d98771-36b3-a9f3-f4d3-439a60822619" class="OWAAutoLink">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="OWAb4a62c22-4e25-2866-dc20-0adb017448ef" class="OWAAutoLink">openid-specs-authzen@lists.openid.net</a>><br>
<b>Cc:</b> Michael Schwartz <<a href="mailto:mike@gluu.org" id="OWA6f27776d-fd09-c3ce-7aa2-f06a91e52338" class="OWAAutoLink">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="x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720OWA795e2991-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="x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720OWA1ecc0585-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; 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="OWA589110c5-3203-8ac5-aa97-4d3a53cadb7d" class="OWAAutoLink" originalsrc="http://google.com/" data-auth="Verified">google.com</a>' or endsWith '.<a href="http://google.com/" id="OWAb450102c-3280-29f6-12c3-3e1978a8dd66" class="OWAAutoLink" originalsrc="http://google.com/" data-auth="Verified">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="x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720OWA48cc550a-3204-8c09-77ab-91c1a4b8275e" class="OWAAutoLink" originalsrc="https://swagger.io/specification/#paths-object" data-auth="Verified">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="x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720OWAfcf896d9-49d2-d342-0184-826481b314eb" class="OWAAutoLink" originalsrc="https://www.w3schools.com/react/react_router.asp" data-auth="Verified">
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="x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720LPlnk845435" class="OWAAutoLink" originalsrc="https://www.rfc-editor.org/rfc/rfc7159.html#section-1" data-auth="Verified">
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="x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720OWA488468d0-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="x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720OWA08158ac8-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; 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="x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720OWAadc3d9f8-f348-21e7-677b-cde32aade5b4" class="OWAAutoLink">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="x_m_6217921018588231553m_7740259539453125901m_7377079112566041071m_119951681576229217m_-8975110352418948720OWA04568d1d-dc8d-6790-113f-d19b363c704e" class="OWAAutoLink" originalsrc="https://www.linkedin.com/in/nynymike" data-auth="Verified">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 src="data:text/html;base64,PCFET0NUWVBFIGh0bWw+IDxodG1sIGRpcj1sdHIgeG1sbnM9aHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbCB0cmFuc2xhdGU9bm8+IDxoZWFkPiA8bWV0YSBjaGFyc2V0PXV0Zi04PiA8bWV0YSBodHRwLWVxdWl2PVgtVUEtQ29tcGF0aWJsZSBjb250ZW50PSJJRT1lZGdlIj4gPG1ldGEgaHR0cC1lcXVpdj1wcmFnbWEgY29udGVudD1uby1jYWNoZT4gPG1ldGEgbmFtZT12aWV3cG9ydCBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lkdGgsaW5pdGlhbC1zY2FsZT0xLHVzZXItc2NhbGFibGU9MCI+IDxtZXRhIG5hbWU9Z29vZ2xlIHZhbHVlPW5vdHJhbnNsYXRlPiA8bWV0YSBuYW1lPWZvcm1hdC1kZXRlY3Rpb24gY29udGVudD0idGVsZXBob25lPW5vIj4gPG1ldGEgbmFtZT1zY3JpcHRWZXIgY29udGVudD0yMDI1MDExMDAwMy4yMz4gPG1ldGEgbmFtZT1oYXNoZWRQYXRoIGNvbnRlbnQ9aGFzaGVkLXYxPiA8bWV0YSBuYW1lPXBoeXNpY2FsUmluZyBjb250ZW50PVdXPiA8bWV0YSBuYW1lPWVudmlyb25tZW50IGNvbnRlbnQ9UHJvZD4gPG1ldGEgbmFtZT1ib290RmxpZ2h0cyBjb250ZW50PWZ3ay1hbmFseXRpY3MtYWRkb25zLGRldi1vZmZsaW5lTXVsdGlBY2NvdW50REIsY2FsLXdpZGdldHMtdXBuLXZhbGlkYXRpb24sYXV0aC1jYWNoZVRva2VuRm9yTWV0YU9zSHViLGF1dGgtdXNlQXV0aFRva2VuQ2xhaW1zRm9yTWV0YU9zSHViLGF1dGgtY29kZUNoYWxsZW5nZSxjYWwtd2lkZ2V0cy1kaXNhYmxlV2lkZ2V0cyxhdXRoLW1zYWxqcy1sYW5kaW5ncGFnZSxzaGVsbG11bHRpb3JpZ2luOjM5NDkyNyxjYWwtcGVyZi1ldmVudHNpbnN0YXJ0dXBkYXRhOjUyNTQ5Mixmd2stc2tpcG5hdmJhcmRhdGFvbmhvc3RlZDo1MDMxNDAsY2FsLXBlcmYtdXNlYXNzdW1lb2Zmc2V0OjUyMjE0MSxmd2stY3NzcGVyZmNmOjUwMjAzMyxjYWwtcGVyZi1ldmVudHNpbm9mZmxpbmVzdGFydHVwZGF0YTo1NDk5OTgsYWNjdC1hZGQtYWNjb3VudC1lMS1pbXByb3ZlbWVudDo1MTU3ODgsYXV0aC1jYWNoZXRva2VuZm9ybWV0YW9zaHViOjU3OTI2NixjYWwtcGVyZi1ldmVudHNpbnN0YXJ0dXBkYXRhYnl2aWV3dHlwZTo1NDI0NTEsYm9vdGZsaWdodGJ1c2luZXNzdXNlcjo2OTgwMzUsd29ya2VyYXN5bmNsb2FkOjYzNDkyMSxhdXRoLW1zYWxqcy1wbGFjZXM6NjU3NTIzLGF1dGgtdXNlYXV0aHRva2VuY2xhaW1zZm9ybWV0YW9zaHViOjY1MzQ2MCxhY2N0c3RhcnRkYXRhb3dhdjI6NzAwODAxLGF1dGgtbXNhbGpzLXBsYWNlcy1zZXNzaW9uc3RvcmFnZTo2NTY0MTEsY2FsLXN0b3JlLW5hdmJhcmRhdGE6NjgzODA5LGF1dGgtbXNhbGpzLXNlc3Npb25zdG9yZWFzY2FjaGVsb2NhdGlvbjo2NzA3NDA+IDxtZXRhIG5hbWU9Y2RuVXJsIGNvbnRlbnQ9Ly9yZXMucHVibGljLm9uZWNkbi5zdGF0aWMubWljcm9zb2Z0Lz4gPG1ldGEgbmFtZT1iYWNrdXBDZG5VcmwgY29udGVudD0vL3Jlcy5jZG4ub2ZmaWNlLm5ldC8+IDxtZXRhIG5hbWU9Y2RuQ29udGFpbmVyIGNvbnRlbnQ9b3dhbWFpbC8+IDxtZXRhIG5hbWU9ZGV2Q2RuVXJsIGNvbnRlbnQ9PiA8bWV0YSBuYW1lPWFyaWFVcmwgY29udGVudD0+IDxtZXRhIG5hbWU9d2ViU2VydmVyRm9yZXN0IGNvbnRlbnQ9ZXVycHJkMDg+IDxtZXRhIG5hbWU9d2ViU2VydmVyQ2xpcXVlIGNvbnRlbnQ9Q0xFVVJQUkQwOFZJRTA1PiA8bWV0YSBuYW1lPWNvbXBhY3RBcmlhVXJsIGNvbnRlbnQ9PiA8bWV0YSBuYW1lPXdjc3NGcmFtZVVybCBjb250ZW50PWh0dHBzOi8vd2Vic2hlbGwuc3VpdGUub2ZmaWNlLmNvbT4gPG1ldGEgbmFtZT13Y3NzRnJhbWVVcmxzIGNvbnRlbnQ9eydEZWZhdWx0VXJsJzonaHR0cHM6Ly93ZWJzaGVsbC5zdWl0ZS5vZmZpY2UuY29tJywnV3dkYlVybCc6J2h0dHBzOi8vd3dkYi53ZWJzaGVsbC5zdWl0ZS5vZmZpY2UuY29tJywnRXVkYlVybCc6J2h0dHBzOi8vZXVkYi53ZWJzaGVsbC5zdWl0ZS5vZmZpY2UuY29tJ30+IDxtZXRhIG5hbWU9c2NyaXB0UGF0aCBjb250ZW50PXNjcmlwdHMvPiA8bWV0YSBuYW1lPW93YUlzQXV0aGVudGljYXRlZCBjb250ZW50PXt7SXNBdXRoZW50aWNhdGVkfX0+IDxtZXRhIG5hbWU9anNUaW1lc3RhbXAgY29udGVudD0xNzM3NjQ0MTU4MDY0PiA8bWV0YSBuYW1lPXB1YmxpY1VybCBjb250ZW50PWh0dHBzOi8vb3V0bG9vay5vZmZpY2UuY29tPiA8bWV0YSBuYW1lPWFhZEF1dGhvcml0eVVybCBjb250ZW50PWh0dHBzOi8vbG9naW4ubWljcm9zb2Z0b25saW5lLmNvbS8+IDxtZXRhIG5hbWU9YnVzaW5lc3NDYW5vbmljYWxIb3N0TmFtZSBjb250ZW50PW91dGxvb2sub2ZmaWNlMzY1LmNvbT4gPG1ldGEgbmFtZT1pc1JQU0F1dGhDb29raWVQcmVzZW50IGNvbnRlbnQ9RmFsc2U+IDxsaW5rIHJlbD1wcmVjb25uZWN0IGhyZWY9Ly9yZXMucHVibGljLm9uZWNkbi5zdGF0aWMubWljcm9zb2Z0LyBjcm9zc29yaWdpbj1hbm9ueW1vdXM+IDxsaW5rIHJlbD1wcmVjb25uZWN0IGhyZWY9aHR0cHM6Ly9sb2dpbi5taWNyb3NvZnRvbmxpbmUuY29tLyBjcm9zc29yaWdpbj11c2UtY3JlZGVudGlhbHM+IDxsaW5rIHJlbD0ic2hvcnRjdXQgaWNvbiIgaHJlZj0vbWFpbC9mYXZpY29uLmljbyB0eXBlPWltYWdlL3gtaWNvbj4gPGxpbmsgcmVsPWFwcGxlLXRvdWNoLWljb24gaHJlZj0vL3Jlcy5wdWJsaWMub25lY2RuLnN0YXRpYy5taWNyb3NvZnQvYXNzZXRzL21haWwvcHdhL3YxL3BuZ3MvYXBwbGUtdG91Y2gtaWNvbi5wbmc+IDxub3NjcmlwdD5KYXZhU2NyaXB0IG11c3QgYmUgZW5hYmxlZC48L25vc2NyaXB0PiA8dGl0bGU+T3V0bG9vazwvdGl0bGU+PGxpbmsgaW50ZWdyaXR5PSJzaGEyNTYtN2I2RWtuS0pWR2x4ekV4UkhHQW9kKy9pWWsrRjl4UXJlL2FOdE1EeTVkOD0iIHJlbD0icHJlbG9hZCIgaHJlZj0iLy9yZXMucHVibGljLm9uZWNkbi5zdGF0aWMubWljcm9zb2Z0L293YW1haWwvaGFzaGVkLXYxL3NjcmlwdHMvb3dhLm1haWwucnVudGltZS4xZWIxZTcwMy5qcyIgYXM9InNjcmlwdCIgY3Jvc3NvcmlnaW49ImFub255bW91cyIvPjxsaW5rIGludGVncml0eT0ic2hhMjU2LUtvS2hOcXhkR2hTSGdjQWs3OXo3bENxdnMxaUp4Rzlkdnl6dVVmb2JjYlU9IiByZWw9InByZWxvYWQiIGhyZWY9Ii8vcmVzLnB1YmxpYy5vbmVjZG4uc3RhdGljLm1pY3Jvc29mdC9vd2FtYWlsL2hhc2hlZC12MS9zY3JpcHRzL293YS5tYWlsaW5kZXguZGY1MGU4MjkuanMiIGFzPSJzY3JpcHQiIGNyb3Nzb3JpZ2luPSJhbm9ueW1vdXMiLz4gPHN0eWxlPkBmb250LWZhY2V7Zm9udC1mYW1pbHk6RmFicmljTURMMkljb25zO3NyYzp1cmwoJy8vcmVzLnB1YmxpYy5vbmVjZG4uc3RhdGljLm1pY3Jvc29mdC9vd2FtYWlsLzIwMjUwMTEwMDAzLjIzL3Jlc291cmNlcy9mb250cy9vMzY1aWNvbnMtbWRsMi53b2ZmJykgZm9ybWF0KCd3b2ZmJyk7Zm9udC13ZWlnaHQ6NDAwO2ZvbnQtc3R5bGU6bm9ybWFsfUBmb250LWZhY2V7Zm9udC1mYW1pbHk6b2ZmaWNlMzY1aWNvbnM7c3JjOnVybCgnLy9yZXMucHVibGljLm9uZWNkbi5zdGF0aWMubWljcm9zb2Z0L293YW1haWwvMjAyNTAxMTAwMDMuMjMvcmVzb3VyY2VzL2ZvbnRzL29mZmljZTM2NWljb25zLndvZmY/JykgZm9ybWF0KCd3b2ZmJyk7Zm9udC13ZWlnaHQ6NDAwO2ZvbnQtc3R5bGU6bm9ybWFsfSNsb2FkaW5nU2NyZWVue3Bvc2l0aW9uOmZpeGVkO3RvcDowO2JvdHRvbTowO2xlZnQ6MDtyaWdodDowO2JhY2tncm91bmQtY29sb3I6I2ZmZn0jbG9hZGluZ0xvZ297cG9zaXRpb246Zml4ZWQ7dG9wOmNhbGMoNTB2aCAtIDkwcHgpO2xlZnQ6Y2FsYyg1MHZ3IC0gOTBweCk7d2lkdGg6MTgwcHg7aGVpZ2h0OjE4MHB4fSNNU0xvZ297cG9zaXRpb246Zml4ZWQ7Ym90dG9tOjM2cHg7bGVmdDpjYWxjKDUwdncgLSA1MHB4KX0uZGFyayAjbG9hZGluZ1NjcmVlbntiYWNrZ3JvdW5kLWNvbG9yOiMzMzN9LmRhcmtOZXcgI2xvYWRpbmdTY3JlZW57YmFja2dyb3VuZC1jb2xvcjojMWYxZjFmfTwvc3R5bGU+IDxzY3JpcHQgbm9uY2U9QlZ4NVZ0UkV0cjhxTDdaY3lvVjAxUT09PnRyeXshZnVuY3Rpb24oKXtpZigibG9jYWxTdG9yYWdlImluIHdpbmRvdyl7dmFyIGU9IlVzZXJzTm9ybWFsaXplZFRoZW1lIix0PXdpbmRvdy5sb2NhbFN0b3JhZ2UsYT10LmdldEl0ZW0oIm9say0iK2UpfHx0LmdldEl0ZW0oZSk7YSYmL1wuZGFyayQvLnRlc3QoYSkmJmRvY3VtZW50LmRvY3VtZW50RWxlbWVudC5jbGFzc0xpc3QuYWRkKCJkYXJrIiksYSYmL1wuZGFya1wubmV3JC8udGVzdChhKSYmZG9jdW1lbnQuZG9jdW1lbnRFbGVtZW50LmNsYXNzTGlzdC5hZGQoImRhcmtOZXciKTt2YXIgbj10LmdldEl0ZW0oIlB3YVRoZW1lIik7aWYobil7dmFyIG89ZG9jdW1lbnQuZ2V0RWxlbWVudHNCeU5hbWUoInRoZW1lLWNvbG9yIik7byYmby5sZW5ndGgmJm9bMF0uc2V0QXR0cmlidXRlKCJjb250ZW50IixuKX19fSgpfWNhdGNoKGUpe308L3NjcmlwdD4gPHNjcmlwdCBub25jZT1CVng1VnRSRXRyOHFMN1pjeW9WMDFRPT0+ZnVuY3Rpb24gbG9nRXJyb3IobixvLGUscixhLGkpe3dpbmRvdy5vd2FFcnJvckhhbmRsZXI/d2luZG93Lm93YUVycm9ySGFuZGxlcihuLG8sZSxyLGEsaSk6d2luZG93Lm93YUJhY2tmaWxsZWRFcnJvcnMucHVzaChhcmd1bWVudHMpfWZ1bmN0aW9uIGhhc2hDaGFuZ2VIYW5kbGVyKCl7d2luZG93Lm93YUxvY2F0aW9uSGFzaD13aW5kb3cubG9jYXRpb24/d2luZG93LmxvY2F0aW9uLmhhc2g6dm9pZCAwfXdpbmRvdy5GYWJyaWNDb25maWc9e2ZvbnRCYXNlVXJsOm51bGx9LHdpbmRvdy5vd2FCYWNrZmlsbGVkRXJyb3JzPVtdLHdpbmRvdy5vbmVycm9yPWxvZ0Vycm9yLCJvbnVuaGFuZGxlZHJlamVjdGlvbiJpbiB3aW5kb3cmJndpbmRvdy5hZGRFdmVudExpc3RlbmVyKCJ1bmhhbmRsZWRyZWplY3Rpb24iLChmdW5jdGlvbihuKXt2YXIgbz1uJiZuLnJlYXNvbnx8IltubyByZWFzb24gZ2l2ZW5dIjtvIGluc3RhbmNlb2YgRXJyb3I/bG9nRXJyb3IoIlVuaGFuZGxlZCBSZWplY3Rpb246ICIrbywiIiwwLDAsbyk6by5yZXNwb25zZUVycm9yTWVzc2FnZSYmby5jYWxsc3RhY2tBdFJlcXVlc3QmJm8gaW5zdGFuY2VvZiBSZXNwb25zZT9sb2dFcnJvcihvLnJlc3BvbnNlRXJyb3JNZXNzYWdlLCIiLHZvaWQgMCx2b2lkIDAsdm9pZCAwLG8uY2FsbHN0YWNrQXRSZXF1ZXN0KTpsb2dFcnJvcigiVW5oYW5kbGVkIFJlamVjdGlvbjogIisoInN0cmluZyI9PXR5cGVvZiBvP286SlNPTi5zdHJpbmdpZnkobykpKX0pKSx3aW5kb3cub25sb2FkPWZ1bmN0aW9uKCl7dmFyIG49c2VsZi5sb2NhdGlvbjshc2VsZi5Pd2EmJm4mJnZvaWQgMCE9PW4uc2VhcmNoJiYtMT09bi5zZWFyY2guaW5kZXhPZigiZ3VscCIpJiYtMT09bi5zZWFyY2guaW5kZXhPZigiYnJhbmNoIikmJigtMT09bi5zZWFyY2guaW5kZXhPZigiYk89MiIpP24uc2VhcmNoKz0obi5zZWFyY2g/IiYiOiI/IikrImJPPTIiOm4uYXNzaWduKCIvb3dhL2F1dGgvZnJvd255LmFzcHg/YnJldD1mYWlsJmVzcmM9SW5kZXhQYWdlSW5jb21wbGV0ZSZhcHA9TWFpbCZiTz0yIikpfSxoYXNoQ2hhbmdlSGFuZGxlcigpLHdpbmRvdy5hZGRFdmVudExpc3RlbmVyKCJoYXNoY2hhbmdlIixoYXNoQ2hhbmdlSGFuZGxlcik8L3NjcmlwdD4gPGxpbmsgaW50ZWdyaXR5PSJzaGEyNTYtZGc2QnVvSHhZVit0UnArL1JvTVBFQkRmb3o0RTVBcThtSFYxSVFOZHV5OD0iIHJlbD0icHJlbG9hZCIgaHJlZj0iLy9yZXMucHVibGljLm9uZWNkbi5zdGF0aWMubWljcm9zb2Z0L293YW1haWwvaGFzaGVkLXYxL3NjcmlwdHMvb3dhLjg1MzMxLm0uMjUwNmIxZGEuanMiIGFzPSJzY3JpcHQiIGNyb3Nzb3JpZ2luPSJhbm9ueW1vdXMiLz48bGluayBpbnRlZ3JpdHk9InNoYTI1Ni04b3dLdXh1clliRlVkdGFFQUhWU2Q0WlRKZ00vVVBzZjRwRlNqbmZwRzc0PSIgcmVsPSJwcmVsb2FkIiBocmVmPSIvL3Jlcy5wdWJsaWMub25lY2RuLnN0YXRpYy5taWNyb3NvZnQvb3dhbWFpbC9oYXNoZWQtdjEvc2NyaXB0cy9vd2EuQXBwQm9vdC5tLjM1MjVhNGQzLmNzcyIgYXM9InN0eWxlIiBjcm9zc29yaWdpbj0iYW5vbnltb3VzIi8+PGxpbmsgaW50ZWdyaXR5PSJzaGEyNTYtSkhtdm92VkZ6eExMTFJFQ0YxOG03clFiSU5ZbWlBTWZ1OWo4MmlQSGMyQT0iIHJlbD0icHJlbG9hZCIgaHJlZj0iLy9yZXMucHVibGljLm9uZWNkbi5zdGF0aWMubWljcm9zb2Z0L293YW1haWwvaGFzaGVkLXYxL3NjcmlwdHMvb3dhLkFwcEJvb3QubS44Y2UyNmE5NC5qcyIgYXM9InNjcmlwdCIgY3Jvc3NvcmlnaW49ImFub255bW91cyIvPjxsaW5rIGludGVncml0eT0ic2hhMjU2LXNCUGYvYnVKbDFGckxscU4ycDkyUWszWE01MHdxb0dEVER5T09xSkRMc1k9IiByZWw9InByZWxvYWQiIGhyZWY9Ii8vcmVzLnB1YmxpYy5vbmVjZG4uc3RhdGljLm1pY3Jvc29mdC9vd2FtYWlsL2hhc2hlZC12MS9zY3JpcHRzL293YS4yNTE0Ny5tLmE5YTAwNGY3LmpzIiBhcz0ic2NyaXB0IiBjcm9zc29yaWdpbj0iYW5vbnltb3VzIi8+PGxpbmsgaW50ZWdyaXR5PSJzaGEyNTYtVTJBZnppUzh5QUxtbiszOUxYWE9RZDJ0R0VMVHkzTXVwOEFqRDh2REp4MD0iIHJlbD0icHJlbG9hZCIgaHJlZj0iLy9yZXMucHVibGljLm9uZWNkbi5zdGF0aWMubWljcm9zb2Z0L293YW1haWwvaGFzaGVkLXYxL3NjcmlwdHMvb3dhLjYxMzQ4Lm0uZDYzNzc3YjEuanMiIGFzPSJzY3JpcHQiIGNyb3Nzb3JpZ2luPSJhbm9ueW1vdXMiLz48bGluayBpbnRlZ3JpdHk9InNoYTI1Ni1HYzlvSytPYkthZXRLZ29Gcm5SZDg5ajE0WFdWV3dPS25xU0cvY3JYWDg0PSIgcmVsPSJwcmVsb2FkIiBocmVmPSIvL3Jlcy5wdWJsaWMub25lY2RuLnN0YXRpYy5taWNyb3NvZnQvb3dhbWFpbC9oYXNoZWQtdjEvc2NyaXB0cy9vd2EuMjA2OS5tLjNhYmJmYjZkLmpzIiBhcz0ic2NyaXB0IiBjcm9zc29yaWdpbj0iYW5vbnltb3VzIi8+PGxpbmsgaW50ZWdyaXR5PSJzaGEyNTYtelJXL3lFS0FqZ3lpL2h2Z3doZmdVdWZMOUF1ZkZiRjJHeFZVN2F2WHpNZz0iIHJlbD0icHJlbG9hZCIgaHJlZj0iLy9yZXMucHVibGljLm9uZWNkbi5zdGF0aWMubWljcm9zb2Z0L293YW1haWwvaGFzaGVkLXYxL3NjcmlwdHMvb3dhLk1zYWxBdXRoLm0uOWU4ZmFlNWEuanMiIGFzPSJzY3JpcHQiIGNyb3Nzb3JpZ2luPSJhbm9ueW1vdXMiLz48c2NyaXB0IGludGVncml0eT0ic2hhMjU2LTdiNkVrbktKVkdseHpFeFJIR0FvZCsvaVlrK0Y5eFFyZS9hTnRNRHk1ZDg9IiBzcmM9Ii8vcmVzLnB1YmxpYy5vbmVjZG4uc3RhdGljLm1pY3Jvc29mdC9vd2FtYWlsL2hhc2hlZC12MS9zY3JpcHRzL293YS5tYWlsLnJ1bnRpbWUuMWViMWU3MDMuanMiIGNyb3Nzb3JpZ2luPSJhbm9ueW1vdXMiPjwvc2NyaXB0PjxzY3JpcHQgaW50ZWdyaXR5PSJzaGEyNTYtS29LaE5xeGRHaFNIZ2NBazc5ejdsQ3F2czFpSnhHOWR2eXp1VWZvYmNiVT0iIHNyYz0iLy9yZXMucHVibGljLm9uZWNkbi5zdGF0aWMubWljcm9zb2Z0L293YW1haWwvaGFzaGVkLXYxL3NjcmlwdHMvb3dhLm1haWxpbmRleC5kZjUwZTgyOS5qcyIgY3Jvc3NvcmlnaW49ImFub255bW91cyI+PC9zY3JpcHQ+PC9oZWFkPiA8Ym9keSByb2xlPWFwcGxpY2F0aW9uIGNsYXNzPSJtcy1mb250LXMgZGlzYWJsZVRleHRTZWxlY3Rpb24gbXMtRmFicmljLS1pc0ZvY3VzSGlkZGVuIj4gPGRpdiBpZD1hcHA+PC9kaXY+IDxkaXYgaWQ9bG9hZGluZ1NjcmVlbj4gPGRpdiBpZD1sb2FkaW5nTG9nbyBkaXI9bHRyPiA8c3R5bGU+OnJvb3R7LS1zOjE4MHB4Oy0tZW52VzoxMzBweDstLWVudkg6NzFweDstLWNhbFc6MTE4cHg7LS1zcVc6Y2FsYyh2YXIoLS1jYWxXKSAvIDMpOy0tc3FIOjM3cHg7LS1jYWxISDoyMHB4Oy0tY2FsSDpjYWxjKHZhcigtLXNxSCkgKiAzICsgdmFyKC0tY2FsSEgpKTstLWNhbFk6Y2FsYyh2YXIoLS1jYWxIKSArIDIwcHgpOy0tY2FsWUV4dDpjYWxjKHZhcigtLWNhbEgpIC0gODBweCk7LS1jYWxZT3ZlckV4dDpjYWxjKHZhcigtLWNhbEgpIC0gOTJweCk7LS1mbGFwUzo5NnB4Oy0tZmxhcEg6Y2FsYygwLjU1ICogdmFyKC0tZW52SCkpOy0tZmxhcFNjYWxlWTpjYWxjKHZhcigtLWZsYXBIKSAvIHZhcigtLWZsYXBXaWR0aCkpOy0tZHVyOjVzfSNjb250YWluZXJ7d2lkdGg6dmFyKC0tcyk7aGVpZ2h0OnZhcigtLXMpO2FuaW1hdGlvbjpib3VuY2UgdmFyKC0tZHVyKSBpbmZpbml0ZX1Aa2V5ZnJhbWVzIGJvdW5jZXswJSwxMDAlLDEyLjUlLDMyLjUlLDc2LjEle3RyYW5zZm9ybTp0cmFuc2xhdGVZKDApfTIyLjUlLDg2JXt0cmFuc2Zvcm06dHJhbnNsYXRlWSg3cHgpfX0jbG9nb3toZWlnaHQ6MTc5cHg7d2lkdGg6MTMwcHg7b3ZlcmZsb3c6aGlkZGVuO21hcmdpbi10b3A6LTU5cHg7bWFyZ2luLWxlZnQ6MjVweH0jY29udGFpbmVyU2hhZG93e3Bvc2l0aW9uOnJlbGF0aXZlO3RvcDoxMjBweDtsZWZ0OjI1cHg7d2lkdGg6dmFyKC0tZW52Vyk7aGVpZ2h0OnZhcigtLWVudkgpO2JvcmRlci1yYWRpdXM6MCAwIDdweCA3cHg7Ym94LXNoYWRvdzpyZ2JhKDAsMCwwLC4yNSkgMCA0cHggNXB4O2FuaW1hdGlvbjpzaGFkb3ctZmFkZSB2YXIoLS1kdXIpIGluZmluaXRlfUBrZXlmcmFtZXMgc2hhZG93LWZhZGV7MCUsMTAwJSwyMS4yJSw4MCV7b3BhY2l0eTowfTQ3JSw3MCV7b3BhY2l0eToxfX0jZmxhcENvbnRhaW5lcnt3aWR0aDp2YXIoLS1lbnZXKTttYXJnaW4tdG9wOjE3OXB4fSNlZnt3aWR0aDp2YXIoLS1lbnZXKTtoZWlnaHQ6dmFyKC0tZW52SCk7Ym9yZGVyLXJhZGl1czowIDAgN3B4IDdweDtvdmVyZmxvdzpoaWRkZW47bWFyZ2luLXRvcDotNDFweH0jZWY+Lmx7d2lkdGg6Mjg3cHg7aGVpZ2h0OnZhcigtLWVudkgpO2JhY2tncm91bmQ6IzI4YThlYTt0cmFuc2Zvcm06dHJhbnNsYXRlKC0xNTNweCwtNzBweCkgcm90YXRlKDI4ZGVnKX0jZWY+LnJ7d2lkdGg6Mjg3cHg7aGVpZ2h0OnZhcigtLWVudkgpO2JhY2tncm91bmQ6IzE0OTBkZjt0cmFuc2Zvcm06dHJhbnNsYXRlKC0xMjBweCw2M3B4KSByb3RhdGUoLTI4ZGVnKX0jZWJ7d2lkdGg6dmFyKC0tZW52Vyk7aGVpZ2h0OjQwcHg7YmFja2dyb3VuZDojMTIzYjZkO21hcmdpbi10b3A6LTcwcHh9I2NhbHtkaXNwbGF5OmZsZXg7ZmxleC13cmFwOndyYXA7d2lkdGg6dmFyKC0tY2FsVyk7aGVpZ2h0OnZhcigtLWNhbEgpO2JvcmRlci1yYWRpdXM6N3B4O292ZXJmbG93OmhpZGRlbjttYXJnaW46MCBhdXRvO21hcmdpbi10b3A6LTMwNnB4O2FuaW1hdGlvbjpjYWwtYm91bmNlIHZhcigtLWR1cikgaW5maW5pdGU7YW5pbWF0aW9uLXRpbWluZy1mdW5jdGlvbjpjdWJpYy1iZXppZXIoMCwwLjUsMCwxKTt0cmFuc2Zvcm06dHJhbnNsYXRlWSh2YXIoLS1jYWxZRXh0KSkgc2NhbGVZKDEpfUBrZXlmcmFtZXMgY2FsLWJvdW5jZXswJSwxMDAlLDE2LjUlLDc2LjEle3RyYW5zZm9ybTp0cmFuc2xhdGVZKHZhcigtLWNhbFkpKSBzY2FsZVkoMSl9Mjgle3RyYW5zZm9ybTp0cmFuc2xhdGVZKHZhcigtLWNhbFlPdmVyRXh0KSkgc2NhbGVZKDEpfTMxJXt0cmFuc2Zvcm06dHJhbnNsYXRlWSh2YXIoLS1jYWxZRXh0KSkgc2NhbGVZKDEuMDUpfTMzJXt0cmFuc2Zvcm06dHJhbnNsYXRlWSh2YXIoLS1jYWxZRXh0KSkgc2NhbGVZKC45Nil9MzQlLDY4LjUle3RyYW5zZm9ybTp0cmFuc2xhdGVZKHZhcigtLWNhbFlFeHQpKSBzY2FsZVkoMSl9NjguNSV7YW5pbWF0aW9uLXRpbWluZy1mdW5jdGlvbjpjdWJpYy1iZXppZXIoMC42NiwtMC4xNiwxLC0wLjI5KX19I2NhbD4udHt3aWR0aDp2YXIoLS1jYWxXKTtoZWlnaHQ6Y2FsYyh2YXIoLS1jYWxISCkgKyAxcHgpO21hcmdpbi1ib3R0b206LTFweDtiYWNrZ3JvdW5kOiMwMzU4YTd9I2NhbD4ucntkaXNwbGF5OmZsZXg7d2lkdGg6dmFyKC0tY2FsVyk7aGVpZ2h0OnZhcigtLXNxSCl9LnN7d2lkdGg6dmFyKC0tc3FXKTtoZWlnaHQ6Y2FsYyh2YXIoLS1zcUgpICsgMXB4KX0uczF7YmFja2dyb3VuZDojMDA3OGQ0fS5zMntiYWNrZ3JvdW5kOiMyOGE4ZWF9LnMze2JhY2tncm91bmQ6IzUwZDlmZn0uczR7YmFja2dyb3VuZDojMDM2NGI4fS5zNXtiYWNrZ3JvdW5kOiMxNDQ0N2R9I29wZW5lZEZsYXB7d2lkdGg6dmFyKC0tZW52Vyk7aGVpZ2h0OjEwN3B4O2FuaW1hdGlvbjpvcGVuZWQtZmxhcC1zd2luZyB2YXIoLS1kdXIpIGluZmluaXRlO2FuaW1hdGlvbi10aW1pbmctZnVuY3Rpb246Y3ViaWMtYmV6aWVyKDAuMzIsMCwwLjY3LDApO3RyYW5zZm9ybS1vcmlnaW46dG9wO3RyYW5zZm9ybTp0cmFuc2xhdGVZKC02OHB4KSByb3RhdGUzZCgxLDAsMCwtMTgwZGVnKX1Aa2V5ZnJhbWVzIG9wZW5lZC1mbGFwLXN3aW5nezAlLDEwMCUsMTQuNSUsNzYle3RyYW5zZm9ybTp0cmFuc2xhdGVZKC02OHB4KSByb3RhdGUzZCgxLDAsMCwtOTBkZWcpfTE2LjUlLDc0JXt0cmFuc2Zvcm06dHJhbnNsYXRlWSgtNjhweCkgcm90YXRlM2QoMSwwLDAsLTE4MGRlZyl9fSNjbG9zZWRGbGFwe3dpZHRoOnZhcigtLWVudlcpO2FuaW1hdGlvbjpjbG9zZWQtZmxhcC1zd2luZyB2YXIoLS1kdXIpIGluZmluaXRlO2FuaW1hdGlvbi10aW1pbmctZnVuY3Rpb246Y3ViaWMtYmV6aWVyKDAuMzIsMCwwLjY3LDApO3RyYW5zZm9ybS1vcmlnaW46dG9wO3RyYW5zZm9ybTp0cmFuc2xhdGVZKGNhbGMoLTEgKiB2YXIoLS1lbnZIKSkpIHJvdGF0ZTNkKDEsMCwwLDkwZGVnKX1Aa2V5ZnJhbWVzIGNsb3NlZC1mbGFwLXN3aW5nezAlLDEwMCUsNzclLDguNSV7dHJhbnNmb3JtOnRyYW5zbGF0ZVkoY2FsYygtMSAqIHZhcigtLWVudkgpKSkgcm90YXRlM2QoMSwwLDAsMCl9MTQuNSUsNzYle3RyYW5zZm9ybTp0cmFuc2xhdGVZKGNhbGMoLTEgKiB2YXIoLS1lbnZIKSkpIHJvdGF0ZTNkKDEsMCwwLDkwZGVnKX19I2ZtYXNre3dpZHRoOnZhcigtLWVudlcpO2hlaWdodDoxMDdweDtvdmVyZmxvdzpoaWRkZW59LmZsYXBUcmlhbmdsZXt3aWR0aDp2YXIoLS1mbGFwUyk7aGVpZ2h0OnZhcigtLWZsYXBTKTtiYWNrZ3JvdW5kOiM1MGQ5ZmY7bWFyZ2luOi00OHB4IGF1dG8gMCBhdXRvO2JvcmRlci1yYWRpdXM6N3B4O3RyYW5zZm9ybTpzY2FsZVkoLjYpIHJvdGF0ZSg0NWRlZyl9I29wZW5lZEZsYXAgLmZsYXBUcmlhbmdsZXtiYWNrZ3JvdW5kOiMxMjNiNmR9I2Nsb3NlZEZsYXAgLmZsYXBUcmlhbmdsZXtiYWNrZ3JvdW5kOiM1MGQ5ZmZ9PC9zdHlsZT4gPGRpdiBpZD1jb250YWluZXI+IDxkaXYgaWQ9Y29udGFpbmVyU2hhZG93PjwvZGl2PiA8ZGl2IGlkPWxvZ28+IDxkaXYgaWQ9ZmxhcENvbnRhaW5lcj4gPGRpdiBpZD1vcGVuZWRGbGFwPiA8ZGl2IGlkPWZtYXNrPjxkaXYgY2xhc3M9ZmxhcFRyaWFuZ2xlPjwvZGl2PjwvZGl2PiA8L2Rpdj4gPGRpdiBpZD1jYWw+IDxkaXYgY2xhc3M9dD48L2Rpdj4gPGRpdiBjbGFzcz1yPiA8ZGl2IGNsYXNzPSJzIHMxIj48L2Rpdj4gPGRpdiBjbGFzcz0icyBzMiI+PC9kaXY+IDxkaXYgY2xhc3M9InMgczMiPjwvZGl2PiA8L2Rpdj4gPGRpdiBjbGFzcz1yPiA8ZGl2IGNsYXNzPSJzIHM0Ij48L2Rpdj4gPGRpdiBjbGFzcz0icyBzMSI+PC9kaXY+IDxkaXYgY2xhc3M9InMgczIiPjwvZGl2PiA8L2Rpdj4gPGRpdiBjbGFzcz1yPiA8ZGl2IGNsYXNzPSJzIHM1Ij48L2Rpdj4gPGRpdiBjbGFzcz0icyBzNCI+PC9kaXY+IDxkaXYgY2xhc3M9InMgczEiPjwvZGl2PiA8L2Rpdj4gPC9kaXY+IDwvZGl2PiA8ZGl2IGlkPWViPjwvZGl2PiA8ZGl2IGlkPWVmPiA8ZGl2IGNsYXNzPXI+PC9kaXY+IDxkaXYgY2xhc3M9bD48L2Rpdj4gPC9kaXY+IDxkaXYgaWQ9Y2xvc2VkRmxhcD4gPGRpdiBpZD1mbWFzaz48ZGl2IGNsYXNzPWZsYXBUcmlhbmdsZT48L2Rpdj48L2Rpdj4gPC9kaXY+IDwvZGl2PiA8L2Rpdj4gPC9kaXY+IDxpbWcgc3JjPS8vcmVzLnB1YmxpYy5vbmVjZG4uc3RhdGljLm1pY3Jvc29mdC9hc3NldHMvZnJhbWV3b3JrL21pY3Jvc29mdC5zdmcgaWQ9TVNMb2dvIGFsdD1NaWNyb3NvZnQ+IDwvZGl2PiA8L2JvZHk+IDwvaHRtbD4g"></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="OWA71487311-c426-c71f-946b-fe18261945ca" class="OWAAutoLink">Openid-specs-authzen@lists.openid.net</a>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-authzen" id="OWAe44556b2-dd24-4fa8-8d38-65e1c8fc0d81" class="OWAAutoLink" originalsrc="https://lists.openid.net/mailman/listinfo/openid-specs-authzen" data-auth="Verified">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="OWA421a7e78-377e-671a-22ec-13f5e4333ac8" class="OWAAutoLink">Openid-specs-authzen@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-authzen" id="OWA204f9895-f328-a7fc-1325-dd5b3d268dfb" class="OWAAutoLink" originalsrc="https://lists.openid.net/mailman/listinfo/openid-specs-authzen" data-auth="Verified">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="OWA97a44c04-f191-e6e0-9648-765e692dce81" class="OWAAutoLink">Openid-specs-authzen@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-authzen" id="OWA8d99992e-e2f0-6346-112d-1bc900679540" class="OWAAutoLink" originalsrc="https://lists.openid.net/mailman/listinfo/openid-specs-authzen" data-auth="Verified">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"></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>