[Openid-specs-ab] Dynamic client registration and software statements
panva.ip at gmail.com
Wed Jan 9 18:46:52 UTC 2019
We touched on this in the certification issue tracker
https://github.com/openid-certification/oidctest/issues/59 (initial access
https://github.com/openid-certification/oidctest/issues/60 (software id)
>From #59 by Mike
> This seems like something that could be useful for testing but it's
outside the scope of certification, since it's using functionality that's
not interoperable. An OP must support open registration to enable
certification. It's fine to also support an initial access token in the
software, as long as the deployment doesn't require it when certifying the
To certify, the registration must be open at the time of certification only.
>1. Is there any best practice recommendations around OIDC dynamic client
registration. I'm specifically interested in experience where the mobile
app is using a private key generated on the device and/or use of
software_statements with OIDC.
>2. Why can't the application (once it's registered its public key) update
its configuration with a new public thus supporting key rotation? It should
be able to sign any such update with its existing private key thus making
the request secure.
It surely can, but the Update (and Delete) mechanisms aren't mentioned in
OIDC DCR at all and only come in RFC 7592 which is marked as experimental.
That being said i have seen deployments of this using my OP software
including software statements, initial access tokens, registration access
tokens and per-app private_key_jwt enabled clients that rotate its keys
when they want to.
I'm not familiar with the history of Dynamic Client Registration Management
Protocol and why it's marked as experimental or why neither RFC 7591 or
7592 aren't mentioned in the OIDC spec.
On Wed, Jan 9, 2019 at 5:22 PM George Fletcher via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:
> Since the OIDC dynamic client registration specs were published before
> the RFCs for OAuth2, there is no mention of the use of
> software_statements. However, the OIDC flows allow for use of additional
> parameters. What's not clear to me is how an implementation can be
> certified for OIDC DCR if it requires software statements.
> Also, if the client is going to be a mobile app client and generate a
> private key locally on the device (or via trusted hardware) it seems
> that it MUST use the 'jwks' parameter and NOT the 'jwks_uri' parameter.
> However, the use of the 'jwks' parameter is kind of discouraged by the
> spec language saying that 'jwks_uri' should be used if possible do to
> "key rotation not supported" with the 'jwks' parameter.
> All this leads to a couple of questions...
> 1. Is there any best practice recommendations around OIDC dynamic client
> registration. I'm specifically interested in experience where the mobile
> app is using a private key generated on the device and/or use of
> software_statements with OIDC.
> 2. Why can't the application (once it's registered it's public key)
> update it's configuration with a new public thus supporting key
> rotation? It should be able to sign any such update with its existing
> private key thus making the request secure.
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab