When a token is issued, that's when a secret should be provided if the token is to be used with a signature. The specific mac algorithm can be provided either with the token or at the resource endpoint (I don't have a strong feeling since we are only talking about symmetric secrets at this point).
I don't think a token should be "upgraded" from bearer to a secret-enabled using the refresh process. EHL From: Raffi Krikorian [mailto:ra...@twitter.com] Sent: Friday, March 26, 2010 8:24 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oa...@core3.amsl.com; WG Subject: Re: [OAUTH-WG] Thinking about our secrets for signatures 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 <e...@hueniverse.com<mailto:e...@hueniverse.com>> 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:tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>] > 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: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> > >> [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] 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<esjew...@gmail.com<mailto:esjew...@gmail.com>> > >> 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 > >> OAuth@ietf.org<mailto:OAuth@ietf.org> > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org<mailto:OAuth@ietf.org> > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
