Sounds reasonable.
# just started to catch up with the emails of past 6 days...
2013/2/13 Mike Jones :
> +1
>
>
> From: John Bradley
> Sent: 2/12/2013 8:20 AM
> To: Justin Richer
> Cc: Mike Jones; oauth@ietf.org
> Subject: Re: [OAUTH-
+1
From: John Bradley
Sent: 2/12/2013 8:20 AM
To: Justin Richer
Cc: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: Client secret rotation
Yes, that agrees with my thoughts on it.
John B.
On 2013-02-12, at 11:29 AM, Justin Richer wrote:
> T
Yes, that agrees with my thoughts on it.
John B.
On 2013-02-12, at 11:29 AM, Justin Richer wrote:
> This is actually the approach that I favor now as well -- let the server do
> the secret rotation if it wants to, and have the client be prepared to
> receive a new client_secret or registration
This is actually the approach that I favor now as well -- let the server
do the secret rotation if it wants to, and have the client be prepared
to receive a new client_secret or registration_access_token on any read
or update request.
This would necessitate changing the returned values, essent
OAuth doesn't say anything about client secrets other than they are provisioned
in a magic realm outside the OAuth spec (Getting in the mood for the next IETF).
Rotating client secrets was something I made up for connect because it seemed
like a good idea at the time given that someone breaking
The rotate_secret operation was added to OpenID Connect Registration as a
workaround to the fact that registration updates used to be authenticated using
the client secret, so it seemed overly dangerous to have an update operation
potentially return an updated secret and have the secret be lost
