[Openid-specs-igov] Public Native Clients + PKCE?

[Mike Varley]

Hello all, in attempting to update the OAuth spec, I have run into a blindspot around native clients and the use of PKCE. Other have pointed out the inconsistencies, but I don't know how to resolve it :)

I am confused as to the intent of supporting "public native clients" that do not dynamically register.

In Section 2.1.3.2 the spec mentions that Native Clients SHOULD register a public key to authenticate themselves to the Token Endpoint, OR if they don't do that (and the AS allows it?) then they MUST use PKCE.

Later in that section, there is a statement:"Client credentials MUST NOT be shared among instances of client software." But there is no indication HOW the public native client should authenticate to the Token Endpoint.

The spec then later assumes that all clients authenticate to the Token Endpoint with a signed claim_assertion (with the registered public key). But if I'm a public native client... <segfault>

I see a couple way to resolve this (and am open to others) but the first question is what use case are we trying to support with these "public native clients"?


Resolution 1:
=============
All clients require a registered public key. "public native clients" MUST use the private_key_jwt method like every other client, and MUST sign the assertion with a private key associated to (one of) their client_id's registered public key(s). This would mean that public native clients share client credentials (the private keys). Yes - there is a security consideration that a shared private key (or secret) is no secret, so what's the point of this? Which leads to:

Resolution 2:
=============
"public native clients" don't need to authenticate to the Token Endpoint at all; they attempt to prevent MitM attacks by using PKCE. (considering the client can't be trusted with a secret in Resolution 1, I don't even see what PKCE is adding here).


I fully support the use of PKCE (for all authZ/token requests) and if there is value in "public native clients" I am happy to include clear instructions on their integration (I prefer Resolution 1) - but I need more info on the use case.

Thanks!

MV