[Openid-specs-ab] Use new jwks registration parameter to provision keys to clients?
nat at sakimura.org
Fri Nov 22 13:41:49 UTC 2013
The problem I see with this approach is that the private key is no more
The server also knows the private key, so the non-repudiation type of
advantage is gone.
It seems it is more or less on par with the symmetric key then.
What advantage do you see with it?
On the other hand, server generated random can be very useful and Ryo Ito
is writing an extension spec on it, which I am helping. He's got the
implementation live on mixi, which is one of the largest social network in
Japan. The reason he came up with the idea is that the random/nonce etc.
generated by the client tends to be not really random undermining
everything that follows. Are you concerned with the key-pair generated by
the client follows the same kind of problem?
2013/11/21 Vladimir Dzhuvinov / NimbusDS <vladimir at nimbusds.com>
> Hi guys,
> Ticket #903 that Nat posted calls for a new jwks parameter to enable
> native clients to register their public keys directly with the provider:
> What do you think of allowing this parameter to also be used as simple
> mean to provision clients with keys generated by the provider? Do you
> see any problems with that? I find this a very attractive option for a
> use case that we face. Currently there's no standard OIDC way to
> provision keys to clients when they register.
> It could work like this:
> The client sends a registration request that implies use of an
> asymmetric key (e.g. JWT private key auth, or signed requests) but
> doesn't provide any jwks_url or jwks parameter. In that case the server
> generates a key pair and returns it with the jwks parameter in the
> response JSON.
> Vladimir Dzhuvinov : www.NimbusDS.com : vladimir at nimbusds.com
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab