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
