[Openid-specs-ab] Dynamic client registration and software statements
gffletch at aol.com
Wed Jan 9 21:04:22 UTC 2019
Thanks! This is helpful!
On 1/9/19 1:51 PM, Filip Skokan wrote:
> Actually 7591 is, just the update/delete isn't.
> On Wed, Jan 9, 2019 at 7:46 PM Filip Skokan <panva.ip at gmail.com
> <mailto:panva.ip at gmail.com>> wrote:
> Hi George,
> We touched on this in the certification issue tracker
> (initial access token)
> (software id)
> (software statement)
> 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 software.
> 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
> >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
> 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
> <mailto: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
> 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
> that it MUST use the 'jwks' parameter and NOT the 'jwks_uri'
> 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
> update it's configuration with a new public thus supporting key
> rotation? It should be able to sign any such update with its
> private key thus making the request secure.
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> <mailto:Openid-specs-ab at lists.openid.net>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab