I agree with that approach, but in this case (where I read that we are effectively binding tokens to resource access methods) I think we need some indications during the delegation flow as far as what method the token is meant to be used with. Possibly a parameter oauth_token_method when a client requests an access, and then the same parameter in the server response to indicate what token type the server opted to provide.
We would probably also need at least a SHOULD in the resource access part of the spec recommending that servers invalidate tokens that are used with the wrong resource access method, as this could publicize secrets that are vital to the security of a different method. That is all assuming that I am understanding the suggestion. Ethan On Fri, Mar 26, 2010 at 9:09 AM, Eran Hammer-Lahav <[email protected]> wrote: > The client can ask for a specific token type, but it is the server's > decision. Either way, that decision should happen when the token is issued, > not when using it to access a resource. > > EHL > >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:[email protected]] >> Sent: Friday, March 26, 2010 12:43 AM >> To: Eran Hammer-Lahav >> Cc: Brian Eaton; Ethan Jewett; OAuth WG >> Subject: Re: [OAUTH-WG] Thinking about our secrets for signatures >> >> An interesting question is, who decides what kind of token to issue? 1) Is it >> the authorization server because it knows what tokens and signature >> algorithms are used by the targeted protected resource? 2) Or is it the >> client? >> I would tend to #2 because I can imagine protected resources with multiple >> endpoints (e.g. http and https) using different token types. So it would be >> the task of the client to decide which way is better suited for its use case. >> > I agree. >> > >> > Authorization servers should issue credentials (tokens) with clear >> semantics. If a token is to be used with a signature, its properties should >> reflect it. If a server doesn't require signatures, why waste storage and >> bandwidth with secrets. >> > >> > EHL >> > >> > >> >> -----Original Message----- >> >> From: [email protected] [mailto:[email protected]] On >> >> Behalf Of Brian Eaton >> >> Sent: Thursday, March 25, 2010 8:50 PM >> >> To: Ethan Jewett >> >> Cc: OAuth WG >> >> Subject: Re: [OAUTH-WG] Thinking about our secrets for signatures >> >> >> >> On Thu, Mar 25, 2010 at 7:54 PM, Ethan Jewett<[email protected]> >> >> wrote: >> >> >> >>> Possibly this is a silly question, but why not #2 and have the >> >>> bearer token method (over SSL of course) include the token secret? >> >>> The provider would always issue a token and a token secret. If the >> >>> client is not interested in signing methods, it can discard the >> >>> token and keep the token secret. This secret is never sent in the >> >>> clear using a signing method. I believe that this is the approach >> >>> taken in OAuth 1.0a and it seems like it should address this concern. >> >>> >> >> Well thought-out bearer tokens and well thought-out proof of >> >> possession tokens rarely look the same. >> >> _______________________________________________ >> >> OAuth mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > _______________________________________________ >> > OAuth mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
