[Openid-specs-igov] user notification of dynamic registration

[Mike Varley]

Another question on the intent of a written spec:
3.1.4 states the user MUST be informed if the client dynamically registered or was statically provisioned, and the nature of the software statement used for registration.



What't the purpose of this requirement? I see a few issues:
1) explaining to a user what dynamic client registration and software statements are, and
2) typically legal disclosure type language is covered by legal reps - if an IdP/OP decides not to include this language, are they non-compliant?
3) I don't see how this is technically enforceable.

If this is a "best practices" thing then we can move it to another section. If this is super important then please provide a reference as to the rationale and I can update the text accordingly (and cover other cases like static registration - as pointed out by a few reviewers).

If this came from HEART maybe they have some of this covered already?

Much thanks!

MV



On 2017-09-26, 12:01 PM, "Openid-specs-igov on behalf of Mike Varley via Openid-specs-igov" <openid-specs-igov-bounces at lists.openid.net on behalf of 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