[Openid-specs-ab] Dynamic client registration and software statements

Filip Skokan panva.ip at gmail.com
Wed Jan 9 18:51:26 UTC 2019


Actually 7591 is, just the update/delete isn't.

Filip

On Wed, Jan 9, 2019 at 7:46 PM Filip Skokan <panva.ip at gmail.com> wrote:

> Hi George,
>
> We touched on this in the certification issue tracker
>
> https://github.com/openid-certification/oidctest/issues/59 (initial
> access token)
> https://github.com/openid-certification/oidctest/issues/60 (software id)
> https://github.com/openid-certification/oidctest/issues/72 (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 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.
>
> Best,
> *Filip*
>
>
> On Wed, Jan 9, 2019 at 5:22 PM George Fletcher via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>> Hi,
>>
>> 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.
>>
>> Thanks,
>> George
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190109/b009d0a3/attachment-0001.html>


More information about the Openid-specs-ab mailing list