[Openid-specs-igov] Action required: WGLC - Seeking WG consensus on iGov OAuth 2.0 profile readiness to begin Implementers Draft review process

Mon Feb 3 23:49:25 UTC 2025

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.

The OAuth Security BCP was recently published as RFC9700, these references
should be updated throughout.

Section 2.1.2: Native Clients
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-2.1.2

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.

Section 2.4: Client Registration
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-2.4

> Clients that share client identifiers are considered public clients.

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.

Section 2.4.1: Redirect URIs
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-2.4.1

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:
https://datatracker.ietf.org/doc/html/rfc9700#section-4.1.3

> Clients SHOULD NOT have multiple redirect URIs on different domains

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.

Section 2.5.1: Requests to the Authorization Endpoint
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-2.5.1

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.

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.

Section 2.5.2: Requests to the Token Endpoint:
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-2.5.2

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.

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.

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.

Section 2.5.3: Client Keys
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-2.5.3

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.

Section 3: Authorization Server Profile
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3

The first section would benefit from a reference back up to Section 1.4
describing the details of the TLS requirements.

Section 3.1.1: Grant Types
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.1.1

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.

Section 3.1.2: Client Authentication
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.1.2

Typo: "Public client cannot..."

The redirect URI sentence should refer to the specific requirements of
redirect URI validation either in this document or the Security BCP.

Section 3.1.3: Dynamic Registration
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.1.3

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.

Section 3.1.4: Client Approval
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.1.4

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".

Section 3.1.7: Revocation
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.1.7

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.

Section 3.1.10 Refresh Tokens
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.1.10

Heading needs a space.

The requirements under which an AS may issue a refresh token are somewhat
confusing:

> Clients MUST be registered with the Authorization Server.

Section 2.4 already says all clients must be registered with the
authorization server. Under what scenario would this not be true here?

> Clients MUST present a valid client_id

This is part of the refresh token grant, so what does it mean to be a
special requirement called out here?

> Confidential clients MUST present a signed client_assertion with their
associated keypair.

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.

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.

Section 3.2: Connections with protected resources
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.2

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.

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.

Section 3.2.1 JWT Bearer Tokens
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.2.1

The first sentence is missing a "MUST".

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.

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.

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.

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.

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
https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/ which
defines a way for a resource server to advertise its jwks_uri. Please
reference this as appropriate, either normatively or as a suggestion.

Section 3.2.2. Token Introspection
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.2.2

This sentence should reference the Token Introspection RFC7662.

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.

Section 3.3: Response to Authorization Requests
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.3

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.

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.

Section 3.4: Token Lifetimes
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.4

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".
https://www.rfc-editor.org/rfc/rfc9470.html#section-3

Section 3.5: Scopes
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-3.5

This section should link up to Section 3.1.4 which talks about displaying
the requested scopes to the end user for approval.

Section 4.1: Protecting Resources
https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html#section-4.1

This section is extremely long and seems to cover a few different topics. I
suggest breaking this into smaller sections.

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.

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.

Paragraph 8 "The client makes a access grant request" should be changed to
"The client makes a refresh token request".

Aaron Parecki

Director of Identity Standards

aaron.parecki at okta.com

On Thu, Jan 30, 2025 at 5:28 PM Tom Clancy via Openid-specs-igov <
openid-specs-igov at lists.openid.net> wrote:

> *This message originated outside your organization.*
>
> ------------------------------
>
> Dear Working Group,
>
>
>
>
> 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.
>
>
>
> *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.*
>
>
>
> The iGov OAuth 2.0 profile document to be reviewed can be found here: International
> Government Assurance Profile (iGov) for OAuth 2.0 - draft 05
> <https://openid.bitbucket.io/iGov/openid-igov-oauth2-1_0.html>
>
>
>
> The details of the Implementer’s Draft approval process can be found here: Approving
> Specifications - OpenID Foundation
> <https://openid.net/wg/resources/approving-specifications/>
>
> This email is about the first bullet point on this list, which is
> sometimes called Working Group Last Call (WGLC).
>
>
>
> 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
>
>
>
> Kindest Regards,
>
> Editors & Chairs
>
>
> _______________________________________________
> Openid-specs-igov mailing list
> Openid-specs-igov at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-igov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-igov/attachments/20250203/4cf48b59/attachment-0001.htm>