i concur that it should be the client that decides -- the client knows what its access requirements are, and can (possibly) be trusted to better make the choice. of course, it could be possibly be the server's decision whether to support signatures or not.
by "when the token is issued", do you mean that during each "flow" a secret token could be issued, or (using recordon's notes above) is it #3 -- where during the "refresh" you could say "please give me a secret with this token, and then make this token impossible to use in a non-signature way". On Fri, Mar 26, 2010 at 8: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 > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
