- changed status to wontfix
ClientMetadata or ClientInformation should allow retrieving and setting ClientType
Issue #224
wontfix
RFC 6749, section 2. Client Registration:
* When registering a client, the client developer SHALL: o specify the client type as described in Section 2.1, *
Thus, the representation of the client characteristics do include client type, and it is independent of any other characteristics (in particular OIDC application type: native, web, ...).
The implication in: [ClientInformation].inferClientType() is also an error, as it is reversed. Confidential clients need to have some method of authenticating themselves, however not all clients able to authenticate are confidential.
Please provide a method for setting, retrieving, and storing client type on one of the levels (probably ClientMetadata).
Comments (1)
-
- Log in to comment
Please use the
token_endpoint_auth_method
parameter to set the desired way for clients to authenticate, and thus the "client type":https://tools.ietf.org/html/rfc7591#section-2
The ClientMetadata class implements RFC 7591, which builds on top of RFC 6749.
Yes, there is no "client_type" parameter, and this is done for a reason: the delineation confidential vs public clients is too abstract and inexact for practical purposes. If you request a client to be registered as "client_type=confidential" you say nothing about the desired authentication method - it could be basic, client secret JWT, public key JWT, or something else. If you're implementing a server, you wouldn't know what to provision for the client if you're supporting multiple auth methods. You could also have a client registered with
token_endpoint_auth_method
set to none, yet using signed authZ / authentication requests - is this client then public or confidential?