Sounds reasonable. # just started to catch up with the emails of past 6 days...
2013/2/13 Mike Jones <michael.jo...@microsoft.com>: > +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 <jric...@mitre.org> 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_access_token on any read or >> update request. >> >> This would necessitate changing the returned values, essentially >> collapsing the returns from the read/update and rotate actions into one >> structure that's closer to the one returned from initial registration. This >> has the added benefit of parallelizing the responses for these three >> actions, which I like as well. >> >> -- Justin >> >> On 02/11/2013 08:42 PM, John Bradley wrote: >>> 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 in to the >>> registration endpoint could take over a connection. >>> >>> We later separated the authentication to the token endpoint from the >>> registration endpoint,in what I think was a good move. >>> >>> It is sort of up to the authorization server to make decisions about >>> rotating client secrets, I expect that in the real world a client would try >>> access ing the token endpoint and get back a invalid_client error response >>> and then heck it's registration to see if the client_secret has changed. >>> >>> I suppose that a client could request rotating its secret if it thinks it >>> has been compromised, however the compromiser is more likely to quickly >>> change the secret to lock out the legitimate clients before the good one >>> notices. I think the client wanting to rotate is enough of a edge case >>> that it could deal with it out of band. >>> >>> Letting the server rotate the client secret according to what ever policy >>> it decides is best is probably safest. >>> >>> We didn't have anything for rotating the access token. I suspect that >>> rotating it under the clients control is going to create as many problems as >>> it solves. >>> >>> If you want to rotate it, make it a refresh token that is issues and use >>> OAuth to provide access tokens from the token endpoint. Creating a new >>> endpoint to duplicate existing OAuth functionality is overkill. >>> >>> John B. >>> On 2013-02-11, at 10:18 PM, Mike Jones <michael.jo...@microsoft.com> >>> wrote: >>> >>>> 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 >>>> due to communication problems - leaving the client stranded. Since then, >>>> registration was changed to use a bearer token to authenticate update >>>> operations, and so this failure mode can't occur anymore. It was an >>>> omission not to have deleted the unneeded operation then. >>>> >>>> It's been deleted from OpenID Connect Registration and should likewise >>>> be deleted from OAuth registration, since it is unneeded. If a new client >>>> secret is needed, there's nothing stopping the registration server from >>>> returning it in the result of an update operation. >>>> >>>> -- Mike >>>> >>>> -----Original Message----- >>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >>>> Of Justin Richer >>>> Sent: Monday, February 11, 2013 1:15 PM >>>> To: oauth@ietf.org >>>> Subject: [OAUTH-WG] Registration: Client secret rotation >>>> >>>> Draft -05 of OAuth Dynamic Client Registration [1] defines a means of >>>> the client requesting a new client_secret (if applicable) and a new >>>> registration_access_token. Client secrets MAY expire after some period of >>>> time, and this method allows for a refresh of that secret. Draft -00 >>>> defined >>>> no such operation, drafts -01 through -04 defined this operation in terms >>>> of >>>> the operation=rotate_secret parameter, and draft -05 defines it through a >>>> secondary endpoint, the Client Secret Rotation Endpoint. >>>> This raises several questions: >>>> >>>> - Should the client be allowed to request rotation of its secret? >>>> - Would a client ever take this action of its own accord? >>>> - Can a server rotate the secret of the client without the client >>>> asking? (This seems to be an obvious "yes") >>>> >>>> Alternatives that keep this functionality include defining the >>>> rotate_secret operation in terms of an HTTP verb, a query parameter, or >>>> separate endpoint. Alternatively, we could drop the rotate_secret operation >>>> all together. If we do this, we have to decide if the client secret can >>>> still expire. If it can, then we need a way for the client to get this new >>>> secret through a means that doesn't require it to request a change in >>>> secret, such as sending it back as part of the client READ operation (see >>>> other thread on RESTful verbs). >>>> >>>> -- Justin >>>> >>>> >>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
