<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 Display", "Aptos Display_EmbeddedFont", "Aptos Display_MSFontService", "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: "Aptos Display", "Aptos Display_EmbeddedFont", "Aptos Display_MSFontService", "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
This is a +1 from me.</div>
<div class="elementToProof" style="font-family: "Aptos Display", "Aptos Display_EmbeddedFont", "Aptos Display_MSFontService", "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: "Aptos Display", "Aptos Display_EmbeddedFont", "Aptos Display_MSFontService", "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
## Common actions naming pattern<br>
<br>
Common action names follow a can_* naming pattern. Moreover, all<br>
the examples in the repository follow this pattern. Why is it<br>
"can_read" and not "read"? Semantically, it feels weird to have<br>
an action which is "can_read" instead of "read". The client is<br>
requesting whether the user can "read", not whether the user can<br>
"can_read".<br>
<br>
Proposition: remove the "can_" from the examples and from the<br>
common actions.</div>
<div class="elementToProof" style="font-family: "Aptos Display", "Aptos Display_EmbeddedFont", "Aptos Display_MSFontService", "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="ltr" style="mso-line-height-rule:exactly;-webkit-text-size-adjust:100%;font-size:1px;direction:ltr;"><table cellpadding="0" cellspacing="0" border="0" style="width:100%;border-collapse:collapse;font-size:1px;"><tr style="font-size:0;"><td align="left"><table dir="ltr" cellpadding="0" cellspacing="0" border="0" style="background-color:#FFFFFF;direction:ltr;border-collapse:collapse;font-size:0;"><tr style="font-size:0;"><td align="left" style="vertical-align:top;"><table cellpadding="0" cellspacing="0" border="0" style="width:100%;border-collapse:collapse;font-size:0;"><tr style="font-size:0;"><td align="left" style="vertical-align:top;line-height:normal;"><a href="https://registry.blockmarktech.com/certificates/f00f855a-3b35-4591-a6c0-de94ffe4ceb1/" target="_blank" id="LPlnk689713" style="text-decoration:none;"><img src="cid:image407751.png@450D18C1.4620527F" width="100" height="100" border="0" alt="" style="width:100px;min-width:100px;max-width:100px;height:100px;min-height:100px;max-height:100px;font-size:0;" /></a></td><td align="left" style="vertical-align:top;"><table cellpadding="0" cellspacing="0" border="0" style="border-collapse:collapse;font-size:0;line-height:normal;"><tr style="font-size:0;"><td align="left" style="padding:0;border-top:none;border-right:solid 4px #000001;border-bottom:none;border-left:none;vertical-align:top;"><img src="cid:image497184.png@BC9714CC.FBC0AD06" width="85" height="124.1" border="0" alt="" style="width:85px;min-width:85px;max-width:85px;height:124.1px;min-height:124.1px;max-height:124.1px;font-size:0;" /></td></tr></table></td><td align="left" style="vertical-align:top;"><table cellpadding="0" cellspacing="0" border="0" style="width:100%;border-collapse:collapse;font-size:0;"><tr style="font-size:0;"><td align="left" style="padding:7px 0 0 7px;vertical-align:top;"><table cellpadding="0" cellspacing="0" border="0" style="white-space:normal;color:#000001;font-size:14.67px;font-family:Calibri,Arial,sans-serif;font-weight:400;font-style:normal;text-align:justify;line-height:14px;width:100%;border-collapse:collapse;"><tr style="font-size:10.67px;"><td style="font-family:Calibri,Arial,sans-serif;"><span style="font-size:13px;"><br />We are the first IdentityServer partner to become a Certified B Corporation™.<span style="font-family:remialcxesans;font-size:1px;color:#FFFFFF;line-height:1px;"><span style="font-family:'template-CbyZv7ONEe6-oGBFvdGUFw';"></span><span style="font-family:'zone-1';"></span><span style="font-family:'zones-AQ';"></span></span><br />Head to our <span style="text-decoration:underline;color:#3A13CD;"><a href="https://www.rocksolidknowledge.com/mission-statement" target="_blank" id="LPlnk689713" title="https://www.rocksolidknowledge.com/mission-statement" style="text-decoration:none;color:#3A13CD;">mission </a><a href="https://www.rocksolidknowledge.com/mission-statement" target="_blank" id="LPlnk689713" title="https://www.rocksolidknowledge.com/mission-statement" style="text-decoration:none;color:#3A13CD;">sta</a><a href="https://www.rocksolidknowledge.com/mission-statement" target="_blank" id="LPlnk689713" title="https://www.rocksolidknowledge.com/mission-statement" style="text-decoration:none;color:#3A13CD;">tement</a></span> to read more about the ways we’re using business as a force for good.<br /><br />Rock Solid Knowledge Ltd is a company registered in England and Wales under number 6811209.<br />Registered office: C2, Vantage Office Park, Old Gloucester Road, Bristol, BS16 1GW, United Kingdom<br />Vat registered: GB948 1966 72</span><br /></td></tr></table></td></tr></table></td></tr></table></td></tr></table></td></tr></table></div><div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Openid-specs-authzen <openid-specs-authzen-bounces@lists.openid.net> on behalf of Gabriel Corona via Openid-specs-authzen <openid-specs-authzen@lists.openid.net><br>
<b>Sent:</b> 02 October 2024 07:47<br>
<b>To:</b> openid-specs-authzen@lists.openid.net <openid-specs-authzen@lists.openid.net><br>
<b>Cc:</b> Gabriel Corona <gabriel.corona@free.fr><br>
<b>Subject:</b> [Openid-specs-authzen] Feedback on Authzen Authorization API 1.0 – draft 01</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hello,<br>
<br>
You will find below my feedback on the Authorization API 1.0 –<br>
draft 01. For context, I did not follow the development of this<br>
specification so this is the point-of-view of a potential naive<br>
implementer<br>
<br>
Regards,<br>
<br>
## Common actions naming pattern<br>
<br>
Common action names follow a can_* naming pattern. Moreover, all<br>
the examples in the repository follow this pattern. Why is it<br>
"can_read" and not "read"? Semantically, it feels weird to have<br>
an action which is "can_read" instead of "read". The client is<br>
requesting whether the user can "read", not whether the user can<br>
"can_read".<br>
<br>
Proposition: remove the "can_" from the examples and from the<br>
common actions.<br>
<br>
## Request Identification (X-Request-ID) does not seem useful<br>
<br>
The HTTP binding introduces a X-Request-ID without any<br>
reason/motivation. There is no explanation about why this would<br>
be beeded. This looks like a implementation detail of some<br>
existing implementations and feels quite out of place in the<br>
specification.<br>
<br>
Note: RFC6648 deprecated the usage of the "X-" prefix.<br>
("Deprecates the "X-" convention for newly defined parameters in<br>
application protocols, including new parameters for established<br>
protocols.")<br>
<br>
Proposition: remove X-Request-ID.<br>
<br>
Proposition 2: explain why this would be needed and remove the<br>
"X-" prefix.<br>
<br>
## Example Context<br>
<br>
The example context is supposed to be an example and therefore it<br>
appears it is not normative. However, this is not stated<br>
explicitly and the wording ("REQUIRED") seems to implies that it<br>
might be normative. This might need to be clarified.<br>
<br>
This section is either too precise (if this is merely an example)<br>
or too ambiguous if this is supposed to be interoperable.<br>
<br>
### Reason field is underspecified<br>
<br>
If the example context section is not normative, there lacks a<br>
standard/normative way to express a failure reason. If this<br>
section is normative, the reason field is underspecified:<br>
<br>
> A Reason Field is a JSON object that has keys and values of<br>
> type string.<br>
<br>
The content of the reason field is not specified. The examples<br>
seems to indicate that this should be a mapping from locale to<br>
strings but this is not explained explicitely. This make it<br>
impossible to communicate reason phrases in an standard way.<br>
<br>
Moreover an example uses:<br>
<br>
"reason_user": {<br>
"en-403": "Insufficient privileges. Contact your administrator",<br>
"es-403": "Privilegios insuficientes. Póngase en contacto con su <br>
administrador"<br>
}<br>
<br>
while I would expect,<br>
<br>
"reason_user": {<br>
"en": "Insufficient privileges. Contact your administrator",<br>
"es": "Privilegios insuficientes. Póngase en contacto con su <br>
administrador"<br>
}<br>
<br>
Proposition: specifiy that this is a mapping from locale to<br>
localized messages and replace "en-403" by "en" in the examples.<br>
<br>
### The semantic of the reason "id" is not clear<br>
<br>
If the example context section is normative the explanation for<br>
the reason ID should probably be clarified:<br>
<br>
> id: REQUIRED. A string value that specifies the reason within<br>
> the scope of a particular response.<br>
<br>
The text does not explain where/how this ID could be used.<br>
I believe this is intended to the administrator, maybe changing<br>
the example this way would be clearer:<br>
<br>
{<br>
"id": "C076E82F",<br>
"reason_admin": {<br>
"en": "Request failed policy C076E82F"<br>
},<br>
"reason_user": {<br>
"en-403": "Insufficient privileges. Contact your administrator",<br>
"es-403": "Privilegios insuficientes. Póngase en contacto con su <br>
administrador"<br>
}<br>
}<br>
<br>
### Usage of the reason object is not specified<br>
<br>
Section 6.2.3.1.2 explains that:<br>
<br>
> A Reason Object specifies a particular reason.<br>
<br>
But it is not explained anywhere explicitly in the draft where it<br>
should be used. The examples suggests that this may be used in<br>
the "context" of the response but this is not stated explicitely<br>
and the specification suggests we could include anything we want<br>
in the context.<br>
<br>
Proposition: define a "reason" field in the access evaluation<br>
response.<br>
<br>
{<br>
"decision": false,<br>
"reason": {<br>
"id": "C076E82F",<br>
"reason_admin": {<br>
"en": "Request failed policy C076E82F"<br>
},<br>
"reason_user": {<br>
"en": "Insufficient privileges. Contact your administrator",<br>
"es": "Privilegios insuficientes. Póngase en contacto con su <br>
administrador"<br>
}<br>
}<br>
}<br>
<br>
### Returning multiple reasons<br>
<br>
The draft specified that multiple failure reasons might be<br>
returned:<br>
<br>
> in which it presents the reasons that an authorization request<br>
> failed.<br>
><br>
> * A list of identifiers representing the items (policies,<br>
> graph nodes, tuples)<br>
> that were used in the decision-making process.<br>
><br>
> * A list of reasons as to why access is permitted or denied.<br>
<br>
However, no example is provided for returning multiple reasons.<br>
Should we expect a flat list of reasons of a nested structure<br>
representing failure reasons?<br>
<br>
Proposition: define a "reasons" field in the access evaluation<br>
response.<br>
<br>
{<br>
"decision": false,<br>
"reasons": [<br>
{<br>
"id": "C076E82F",<br>
"reason_admin": {<br>
"en": "Request failed policy C076E82F"<br>
},<br>
"reason_user": {<br>
"en": "Insufficient privileges. Contact your administrator",<br>
"es": "Privilegios insuficientes. Póngase en contacto con <br>
su administrador"<br>
}<br>
}<br>
]<br>
}<br>
<br>
## Lack of compatibility with Subject Identifiers for SET<br>
<br>
The draft includes a reference to RFC9493 (Subject Identifiers<br>
for SET) in the references section but this is never used in the<br>
main content. The identifier format in this draft is not<br>
compatible with Subject Identifiers for SET.<br>
<br>
In Subject Identifiers for SET, identifiers look like:<br>
<br>
{<br>
"format": "email",<br>
"email": "user@example.com"<br>
}<br>
{<br>
"format": "iss_sub",<br>
"iss": "<a href="https://issuer.example.com/">https://issuer.example.com/</a>",<br>
"sub": "145234573"<br>
}<br>
{<br>
"format": "opaque",<br>
"id": "11112222333344445555"<br>
}<br>
{<br>
"format": "did",<br>
"url": "did:example:123456"<br>
}<br>
{<br>
"format": "uri",<br>
"uri": "<a href="https://user.example.com/">https://user.example.com/</a>"<br>
}<br>
<br>
Authorization API only support plain string id:<br>
<br>
{<br>
"type": "user",<br>
"id": "alice@acmecorp.com"<br>
}<br>
<br>
The specification should specify how it relates (or does not<br>
relate) to RFC9493 and reference RFC9493 somehow in the main<br>
content.<br>
<br>
## The examples are ambiguous<br>
<br>
The example are ambiguous, for example, 6.2.4 gives this example:<br>
<br>
{<br>
"decision": true,<br>
"context": {<br>
"id": "0",<br>
"reason_admin": {<br>
"en": "Request failed policy C076E82F"<br>
},<br>
"reason_user": {<br>
"en-403": "Insufficient privileges. Contact your administrator",<br>
"es-403": "Privilegios insuficientes. Póngase en contacto con <br>
su administrador"<br>
}<br>
}<br>
}<br>
<br>
The decision is true (accepted) bur error messages are included.<br>
<br>
Proposition: set the decision value to false (rejected). I guess<br>
this should be,<br>
<br>
{<br>
"decision": false, <- changed<br>
"context": {<br>
"id": "0",<br>
"reason_admin": {<br>
"en": "Request failed policy C076E82F"<br>
},<br>
"reason_user": {<br>
"en-403": "Insufficient privileges. Contact your administrator",<br>
"es-403": "Privilegios insuficientes. Póngase en contacto con <br>
su administrador"<br>
}<br>
}<br>
}<br>
<br>
## Content negotiation of the error response<br>
<br>
The body of the error responses might be suitable for content<br>
negotiation. This way, an implementation might support problem<br>
details (RFC 7807) when the status code is not 200.<br>
<br>
## Content negotiation of the returned language<br>
<br>
If the application supports 250 languages, should it return a<br>
"reason_user" (or "reason_admin") for each of them? Can the PDP<br>
rely on Accept-Language or another mechanism to choose which<br>
languages it should provide?<br>
<br>
## Misc. nitpick<br>
<br>
* 7.1.1 is "HTTPS Access Evaluation Request" but 7.1.2 is<br>
"Access Evaluation HTTPS Response". The same naming pattern<br>
should be used.<br>
</div>
</span></font></div>
</body>
</html>