<div dir="ltr"><div>I've reviewed this draft and have some significant feedback and questions that need clarification before this is ready for the implementer's draft approval process. Notes are below.</div><div><br></div><div>The OAuth Security BCP was recently published as RFC9700, these references should be updated throughout.</div><div><br></div><div>Section 2.1.2: Native Clients </div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-2.1.2" target="_blank">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-2.1.2</a></div><div><br></div><div>The bullet list in this section makes it appear that native clients using dynamic client registration do not need to use PKCE, as those are presented as a list of OR options. However, section 2.5.1 says "all clients MUST use PKCE". I believe the easiest resolution for this is to remove "and use PKCE [RFC7636] to protect calls to the token endpoint" from the second option in this section.</div><div><br></div><div>Section 2.4: Client Registration</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-2.4" target="_blank">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-2.4</a></div><div><br></div><div>> Clients that share client identifiers are considered public clients.</div><div><br></div><div>I am confused about the purpose of this sentence. The language elsewhere in the document is what I would expect, talking about public clients as clients that don't have credentials. Even the section about native apps correctly does not conflate native apps with public clients if the native app was issued a credential. This sentence seems to contradict the previous definition of public clients.</div><div><br></div><div>Section 2.4.1: Redirect URIs</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-2.4.1" target="_blank">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-2.4.1</a></div><div><br></div><div>Correct me if I'm wrong, but it looks like the intent is to match the redirect URI recommendations that are in the Security BCP. It doesn't hurt to summarize them here, but would be useful to add a normative reference to section 4.1.3 of RFC9700 to be explicit: <a href="https://datatracker.ietf.org/doc/html/rfc9700#section-4.1.3" target="_blank">https://datatracker.ietf.org/doc/html/rfc9700#section-4.1.3</a></div><div><br></div><div>> Clients SHOULD NOT have multiple redirect URIs on different domains</div><div><br></div><div>I don't recognize this recommendation, it could use some expansion on the justification for why, perhaps adding a section to the security considerations explaining what this protects against.</div><div><br></div><div>Section 2.5.1: Requests to the Authorization Endpoint</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-2.5.1" target="_blank">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-2.5.1</a></div><div><br></div><div>The term "browser-embedded clients" first appears in this section, but was not defined earlier. It's not clear to me what this is describing, and I would have expected to see this term defined in Section 2.1 Client Types like the term "full client". A few paragraphs later, it uses the term "web-based client" which also does not appear prior to this, so I am not clear on whether this term is meant to encompass "full clients" and "browser-embedded clients" or something else.</div><div><br></div><div>The request examples should not include the parameter "nonce", as the parameter is optional in OpenID Connect when using response_type=code, and there is no other mention of "nonce" in the entire document.</div><div><br></div><div>Section 2.5.2: Requests to the Token Endpoint:</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-2.5.2" target="_blank">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-2.5.2</a></div><div><br></div><div>Given the recent changes of the "aud" parameter in various other specs, it is probably a good idea to match those changes here and use the issuer URL as the aud value.</div><div><br></div><div>Mid way through this section includes the sentence "Furthermore, if the authorization request is a follow-up to a prior request that did not meet". However this section is about the request to the token endpoint, so it is a token request, not an authorization request. This paragraph seems misplaced.</div><div><br></div><div>The example request at the bottom of this section is missing the PKCE code_verifier parameter, which is required according to section 2.5.1.</div><div><br></div><div>Section 2.5.3: Client Keys</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-2.5.3" target="_blank">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-2.5.3</a></div><div><br></div><div>This section says "Clients using the authorization code grant type... MUST have a public and private key pair...". However section 2.1.2 allows for native clients to not use client authentication. I am not clear on the intent here, but this is currently contradictory. Is the intent that all clients maintain key pairs, including native clients? Or is the native public client exception intended, in which case this section needs changes.</div><div><br></div><div>Section 3: Authorization Server Profile</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3" target="_blank">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3</a></div><div><br></div><div>The first section would benefit from a reference back up to Section 1.4 describing the details of the TLS requirements.</div><div><br></div><div>Section 3.1.1: Grant Types</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.1.1" target="_blank">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.1.1</a></div><div><br></div><div>This section describes the two grant types in use, but then refers to section 2.1 which describes three client types. It is ambiguous whether the intent is to have the AS treat a single client_id as a client type defined in 2.1 or limit a single client_id to one of the two grant types, please clarify the intent.</div><div><br></div><div>Section 3.1.2: Client Authentication</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.1.2" target="_blank">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.1.2</a></div><div><br></div><div>Typo: "Public client cannot..." </div><div><br></div><div>The redirect URI sentence should refer to the specific requirements of redirect URI validation either in this document or the Security BCP.</div><div><br></div><div>Section 3.1.3: Dynamic Registration</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.1.3" target="_blank">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.1.3</a></div><div><br></div><div>The description of acr_values_supported and dpop_signing_alg_values_supported are written from the opposite point of view. Since this section describes parameters of a software statement the client sends to the AS, it should be written from the client's point of view, for example "indicates the acr_values the client may send to the AS..." or similar.</div><div><br></div><div>Section 3.1.4: Client Approval</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.1.4" target="_blank">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.1.4</a></div><div><br></div><div>The "For example" sentence is extremely hard to parse and should be rewritten. The header of this section should indicate who is doing the approval, otherwise it is ambiguous and could appear that this is about the authorization server approving dynamically registered clients. This isn't so much "client approval" as it is "End user authorization request approval" or "End user consent".</div><div><br></div><div>Section 3.1.7: Revocation</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.1.7" target="_blank">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.1.7</a></div><div><br></div><div>This section needs a reference to RFC7009 Token Revocation. Also I believe the intent is to require the AS to support token revocation, but it is not actually explicitly mentioned here, so that should be clarified either way.</div><div><br></div><div>Section 3.1.10 Refresh Tokens</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.1.10" target="_blank">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.1.10</a></div><div><br></div><div>Heading needs a space.</div><div><br></div><div>The requirements under which an AS may issue a refresh token are somewhat confusing:</div><div><br></div><div>> Clients MUST be registered with the Authorization Server.</div><div><br></div><div>Section 2.4 already says all clients must be registered with the authorization server. Under what scenario would this not be true here?</div><div><br></div><div>> Clients MUST present a valid client_id</div><div><br></div><div>This is part of the refresh token grant, so what does it mean to be a special requirement called out here?</div><div><br></div><div>> Confidential clients MUST present a signed client_assertion with their associated keypair.</div><div><br></div><div>Is this just a different way of saying clients MUST authenticate at the token endpoint? That is already a requirement if the client is issued credentials, so this seems redundant as well.</div><div><br></div><div>I suspect the intent is to prevent public clients from being issued refresh tokens, but that is not actually said here. Is that the intent? If so, that is different from the Security BCP recommendations, which is fine, but it should be clarified why the difference.</div><div><br></div><div>Section 3.2: Connections with protected resources</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.2" target="_blank">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.2</a></div><div><br></div><div>The header is confusing at first, since clients also connect with protected resources. It took me a minute to realize this is talking about the connection between an authorization server and protected resources. I suggest renaming this.</div><div><br></div><div>I am also opposed to the language "Unlike the core OAuth protocol". This would be better phrased in the positive, describing how this profile defines the interoperability between authorization servers and resource servers. </div><div><br></div><div>Section 3.2.1 JWT Bearer Tokens</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.2.1" target="_blank">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.2.1</a></div><div><br></div><div>The first sentence is missing a "MUST".</div><div><br></div><div>It looks like these claims differ slightly from the claims described in RFC 9068 JWT Access Tokens. I assume this is because this profile was started before the OAuth JWT Access Token spec was started in 2019. It's unfortunate that these are not exactly compatible, as it means authorization servers compliant with RFC 9068 will have to do new work to be compliant with this profile. I realize it's probably too late to change the claims in this profile to reference RFC 9068, so instead there should be a paragraph added here explaining the context for why these tokens are not RFC 9068 compliant.</div><div><br></div><div>While it does say the list of claims is the minimum claims, I believe the list should include "scope" to avoid each implementer having to come to the conclusion that scope needs to be in the tokens and adding it to the token in a non-interoperable way.</div><div><br></div><div>I am also concerned about the requirement to issue JWT refresh tokens. Since refresh tokens are not meant to be understood by the client or the resource server, I don't see any value in requiring them to be JWTs. This requirement only adds complexity to the authorization server, and even leaks information unnecessarily to clients and resource servers unless the token is encrypted.</div><div><br></div><div>In the sentence "If private_key_jwt is used, the authorization server MUST support...", the link between private_key_jwt and signed access tokens is not clear, this sentence should be clarified.</div><div><br></div><div>The last paragraph says "Encrypted access tokens MUST be encrypted using the public key of the protected resource". I don't see any description of how to discover or declare the public key of the protected resource. I hope this is not intentionally left out of scope, because that would lead to challenges in achieving interoperability between authorization servers and resource servers, which is the whole point of this section. There is a new in-progress IETF draft for Protected Resource Metadata <a href="https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/">https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/</a> which defines a way for a resource server to advertise its jwks_uri. Please reference this as appropriate, either normatively or as a suggestion.</div><div><br></div><div>Section 3.2.2. Token Introspection</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.2.2">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.2.2</a></div><div><br></div><div>This sentence should reference the Token Introspection RFC7662.</div><div><br></div><div>The paragraph "The authorization server MUST require authentication" refers to Section 2.5.2, however that section is about OAuth Clients, whereas this section is about the Resource Server. This is potentially confusing to readers, since it could be interpreted such that Clients are allowed to introspect tokens. I would suggest adding a sentence to make it explicit that the Token Introspection endpoint is only for use by the Resource Server, and that the Resource Server needs to authenticate to the endpoint and uses either of the mechanisms that Clients use for authentication to the token endpoint. It is a subtle language difference but I think it will help.</div><div><br></div><div>Section 3.3: Response to Authorization Requests</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.3">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.3</a></div><div><br></div><div>The sentence "as described above" should be updated to the actual section where it is described. The section immediately above this is not at all about the authorization code flow.</div><div><br></div><div>The first paragraph should be expanded to make it clear that this section is not actually defining any new behavior over what is defined in OAuth 2.0.</div><div><br></div><div>Section 3.4: Token Lifetimes</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.4">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.4</a></div><div><br></div><div>The second paragraph, "by including the max_age claim in authorization requests" should be replaced with "by including the max_age claim in the authentication requirements challenge as described in Section 3 of RFC9470." Note that the resource server is the one sending this so the correct term to use is "authentication requirements challenge" rather than the "authorization request". <a href="https://www.rfc-editor.org/rfc/rfc9470.html#section-3">https://www.rfc-editor.org/rfc/rfc9470.html#section-3</a></div><div><br></div><div>Section 3.5: Scopes</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.5">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.5</a></div><div><br></div><div>This section should link up to Section 3.1.4 which talks about displaying the requested scopes to the end user for approval.</div><div><br></div><div>Section 4.1: Protecting Resources</div><div><a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-4.1">https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-4.1</a></div><div><br></div><div>This section is extremely long and seems to cover a few different topics. I suggest breaking this into smaller sections.</div><div><br></div><div>This section is also missing any mention of the step-up auth spec, RFC9470, which provides an interoperable mechanism for some aspects of what is described with the scope and "trust level" language.</div><div><br></div><div>Paragraph 5 says "...to clients that have permission to request these scope levels" but there is no mention of how to determine/register whether clients have permission. Since I assume you are not intending this to be part of the interoperability, it should be mentioned that how clients are determined to have permission is out of scope of this profile.</div><div><br></div><div>Paragraph 8 "The client makes a access grant request" should be changed to "The client makes a refresh token request".</div><div><br></div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr" style="color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif"><div dir="ltr" style="color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif"><p style="margin:0px;font-family:Calibri,Arial,Helvetica,sans-serif;font-weight:bold;padding:0px;line-height:14pt"><br></p><p style="margin:0px;font-family:Calibri,Arial,Helvetica,sans-serif;font-weight:bold;padding:0px;line-height:14pt">
Aaron Parecki</p>
<p style="margin:0px;font-family:Calibri,Arial,Helvetica,sans-serif;padding:0px;line-height:14pt">Director of Identity Standards</p>
<p style="margin:0px;font-family:Calibri,Arial,Helvetica,sans-serif;padding:0px;line-height:14pt">
<a href="mailto:aaron.parecki@okta.com" target="_blank">aaron.parecki@okta.com</a></p>
<div style="font-family:Times"><span></span><span></span><br></div>
</div>
<div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<br>
</div>
</div>
</div>
</div></div></div><br><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 30, 2025 at 5:28 PM Tom Clancy via Openid-specs-igov <<a href="mailto:openid-specs-igov@lists.openid.net" target="_blank">openid-specs-igov@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 lang="EN-US">
<div>
<p><strong>This message originated outside your organization.</strong></p><br>
<hr><br>
</div><div><p class="MsoNormal">Dear Working Group,<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">We would like to get WG consensus that the current International Government Assurance Profile (iGov) for OAuth 2.0 - draft (05) - is ready to start the Implementer’s Draft approval process.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><b>ACTION: Please respond to this email within the next 7 days, by Feb 6th end of business hours in PST, whether you believe the current draft should proceed or not.<u></u><u></u></b></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">The iGov OAuth 2.0 profile document to be reviewed can be found here: <a href="https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html" target="_blank">International Government Assurance Profile (iGov) for OAuth 2.0 - draft 05</a><u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">The details of the Implementer’s Draft approval process can be found here: <a href="https://openid.net/wg/resources/approving-specifications/" target="_blank">Approving Specifications - OpenID Foundation</a><u></u><u></u></p><p class="MsoNormal">This email is about the first bullet point on this list, which is sometimes called Working Group Last Call (WGLC).<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">The next steps are to start a 45-day Foundation-wide review, followed by the 7 day voting period (the poll itself will open 7 days before the end of the Foundation-wide review ends): WGLC ends Feb 6 – Foundation-wide review ends Mar 24 – Voting from Mar 17-31<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Kindest Regards,<u></u><u></u></p><p class="MsoNormal">Editors & Chairs<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p></div></div>
_______________________________________________<br>
Openid-specs-igov mailing list<br>
<a href="mailto:Openid-specs-igov@lists.openid.net" target="_blank">Openid-specs-igov@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-igov" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-igov</a><br>
</div></blockquote></div>