Native OIDC client types question

[chrisgolle]

Reading through the OIDC spec the first time, I had the impression that native clients must register dynamically, and each native application must use the code flow and authenticate with private_key_jwt.

Full clients, native clients with dynamically registered keys, and direct access clients as defined
above MUST authenticate to the authorization server’s token endpoint using a JWT assertion as
defined by the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants using
only the private_key_jwt method defined in OpenID Connect Core

Native applications using dynamic registration MUST generate a unique public and private key
pair on the device and register that public key value with the authorization server. Authorization
servers MUST NOT issue a public and private key pair to the client as part of the registration
process.

However, in the igov specs https://openid.net/specs/openid-igov-oauth2-1_0-ID1.html#rfc.section.2.1.2 it says that,

Native clients MUST either:

use dynamic client registration to obtain a separate client id for each instance, or
act as a public client by using a common client id and use PKCE to protect calls to the token endpoint.

Rereading the CATS spec, noting that whenever a native client is mentioned, it's with the caveat that it used dynamic client registration. Is it permissible under CATS that native clients just not register dynamically so they may use PKCE and no client authentication? Why would a native client ever go to the trouble of the dynamic registration route, considering the ease of PKCE? I can only think if they needed encrypted id tokens.

[harrdou]

Hi Chris;

That first paragraph you are quoting also comes from a later part of the iGov OAuth 2 spec (section 2.3.2) and is just quoted in CATS for context.

Given the order in which these requirements appear, my interpretation is that section 2.1.2 says that acting as a public client and using PKCE is acceptable, but for those that do bother to register client credentials the requirement in section 2.3.2 would then apply.

With respect to the CATS requirement [ODP-RP01], the intent is to relax the mandatory requirement from iGov OAuth 2.3.2 that clients can only use private_key_jwt for authenticating to the token endpoint, and allow for client secret authentication as well. This is simply because the majority of OpenID Connect clients currently used in the GC (hello Microsoft) do not support private_key_jwt.

For the CATS requirement [ODP-OP01], the intent is to disallow generation of the key pair by the OP during dynamic registration, so that the private key is always generated on the client device and never leaves it.