<div dir="ltr"><div>Actually <span style="color:rgb(0,0,0)">7591 is, just the update/delete isn't.</span></div><br><div>Filip</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 9, 2019 at 7:46 PM Filip Skokan <<a href="mailto:panva.ip@gmail.com">panva.ip@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi George,</div><div><br></div><div>We touched on this in the certification issue tracker</div><div><br></div><div dir="ltr"><a href="https://github.com/openid-certification/oidctest/issues/59" target="_blank">https://github.com/openid-certification/oidctest/issues/59</a> (initial access token)</div><div dir="ltr"><a href="https://github.com/openid-certification/oidctest/issues/60" target="_blank">https://github.com/openid-certification/oidctest/issues/60</a> (software id)<br></div><div dir="ltr"><a href="https://github.com/openid-certification/oidctest/issues/72" target="_blank">https://github.com/openid-certification/oidctest/issues/72</a> (software statement)<br></div><div dir="ltr"><br></div><div>From #59 by Mike</div><div><br></div></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>> 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.</div></div></div></div></blockquote><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><div>To certify, the registration must be open at the time of certification only.</div><div dir="ltr"><br></div></div></div></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>>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.</div></div></div></div></div></div></blockquote><div dir="ltr"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>>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.</div><div><br></div></div></div></div></div></blockquote>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.</div><div dir="ltr"><br></div><div dir="ltr">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.<br><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br clear="all"><div><div dir="ltr" class="gmail-m_-4152039870256580343gmail_signature">Best,<br><b>Filip</b></div></div><br></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 9, 2019 at 5:22 PM George Fletcher via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Since the OIDC dynamic client registration specs were published before <br>
the RFCs for OAuth2, there is no mention of the use of <br>
software_statements. However, the OIDC flows allow for use of additional <br>
parameters. What's not clear to me is how an implementation can be <br>
certified for OIDC DCR if it requires software statements.<br>
<br>
Also, if the client is going to be a mobile app client and generate a <br>
private key locally on the device (or via trusted hardware) it seems <br>
that it MUST use the 'jwks' parameter and NOT the 'jwks_uri' parameter. <br>
However, the use of the 'jwks' parameter is kind of discouraged by the <br>
spec language saying that 'jwks_uri' should be used if possible do to <br>
"key rotation not supported" with the 'jwks' parameter.<br>
<br>
All this leads to a couple of questions...<br>
<br>
1. Is there any best practice recommendations around OIDC dynamic client <br>
registration. I'm specifically interested in experience where the mobile <br>
app is using a private key generated on the device and/or use of <br>
software_statements with OIDC.<br>
<br>
2. Why can't the application (once it's registered it's public key) <br>
update it's configuration with a new public thus supporting key <br>
rotation? It should be able to sign any such update with its existing <br>
private key thus making the request secure.<br>
<br>
Thanks,<br>
George<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>
</blockquote></div>