And I realize that this issue was created because WRAP describes a different refresh token flow for each profile whereas this draft combines them all together. I think it's important to realize that implementors will want to write one refresh_token(identifier, refresh_token, secret?) function and expect it to work for each flow.
The language I used today was that the client secret should be included if the client has access to it. On Tue, Mar 23, 2010 at 6:51 PM, David Recordon <record...@gmail.com> wrote: > What about clients which don't have access to the client secret? For > example, rich desktop applications and devices. > > Seems like if the client secret is optional then a server can enforce > in policy what type of clients must pass it in. > > --David > > On Tue, Mar 23, 2010 at 5:56 PM, Brian Eaton <bea...@google.com> wrote: >> On Tue, Mar 23, 2010 at 12:01 PM, David Recordon <record...@gmail.com> wrote: >>>> §3 >>>> - Why is the parameter oauth_client_secret required for refreshing access >>>> tokens? Use cases 2.2 and 2.3 do not require the client to use (possess) a >>>> secret. Does this imply such client are not entitled to refresh tokens? I >>>> would suggest to simply remove this parameter. >>> >>> It shouldn't be required. Fixed! >>> http://github.com/daveman692/OAuth-2.0/commit/a30843724f241f3ea1052c83dcfec0127a11fe00 >> >> It was required in WRAP because is lets you recover if a client web >> server that holds many refresh tokens is compromised. You rotate the >> client secret, and then the attacker loses access to user data. >> >> Please add it back. =) >> > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
