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

[John Bradley]

I think the idea is to use dynamic client registration with a software statement to register a different public key and client_id for each client.

Sharing public keys between clients using magic crypto is not a serious option, in m,y opinion.   Lets discuss on the call.

John B.

> On Sep 26, 2017, at 1:01 PM, Mike Varley via Openid-specs-igov <openid-specs-igov at lists.openid.net> wrote:
> 
> 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
> 
> 
> 
> _______________________________________________
> Openid-specs-igov mailing list
> Openid-specs-igov at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-igov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4383 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-igov/attachments/20171003/d1c1bf34/attachment.p7s>