<html><head></head><body>Hi Vladimir,<br>
<br>
Brian, Justin and I discussed such an option in Vancouver. As far as I remember, we came to the same conclusion. Although it is not puristic security practice, it seem to be convenient for developers.<br>
<br>
Regards,Torsten.<br><br><div class="gmail_quote"><br>
<br>
Vladimir Dzhuvinov / NimbusDS <vladimir@nimbusds.com> schrieb:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Hi guys,<br /><br />Ticket #903 that Nat posted calls for a new jwks parameter to enable<br />native clients to register their public keys directly with the provider:<br /><br /><a href="https://bitbucket.org/openid/connect/issue/903">https://bitbucket.org/openid/connect/issue/903</a>/<br /><br />What do you think of allowing this parameter to also be used as simple<br />mean to provision clients with keys generated by the provider? Do you<br />see any problems with that? I find this a very attractive option for a<br />use case that we face. Currently there's no standard OIDC way to<br />provision keys to clients when they register.<br /><br />It could work like this:<br /><br />The client sends a registration request that implies use of an<br />asymmetric key (e.g. JWT private key auth, or signed requests) but<br />doesn't provide any jwks_url or jwks parameter. In that case the server<br />generates a key pair and returns it with the jwks parameter in th
e<br
/>response JSON.<br /><br />Cheers,<br /><br />Vladimir<br /><br />--<br />Vladimir Dzhuvinov : <a href="http://www.NimbusDS.com">www.NimbusDS.com</a> : vladimir@nimbusds.com<br /><hr /><br />Openid-specs-ab mailing list<br />Openid-specs-ab@lists.openid.net<br /><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br /></pre></blockquote></div></body></html>