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

[George Fletcher]

Thanks! This is helpful!

On 1/9/19 1:51 PM, Filip Skokan wrote:
> 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 
> <mailto: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
>     <mailto: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
>         <mailto: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/a58d687e/attachment.html>