The key here the transmission of auth parameters, not singing bodies. EHL > -----Original Message----- > From: George Fletcher [mailto:gffletch at aol.com] > Sent: Friday, October 02, 2009 11:06 AM > To: oauth at ietf.org > Cc: Eran Hammer-Lahav > Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) > > Eran Hammer-Lahav wrote: > > I can live with something like that. The problem will be that it will > require normalizing the request URI to remove the OAuth parameter > before validating the signature. But this is completely on the server > so I don't mind it. > > > > I'll include something like this in the upcoming revision (pending > more feedback). > > > > As for sending form-encoded auth parameters, no one has argued to > keep that so I think it is save to drop it completely. > > > > > I actually had a use case for this (as an idea) but it didn't go > anywhere. Basically it was leveraging the signing mechanism as a > binding > for SAML messages. Logically it would be similar to SAML Simple Sign > but > for server-to-server calls. > > However, if we add the body-hash support then I think that covers > POST'd > content and it can be in any format. > > Thanks, > George > > EHL > > > > > > > > > >> -----Original Message----- > >> From: George Fletcher [mailto:gffletch at aol.com] > >> Sent: Friday, October 02, 2009 10:31 AM > >> To: oauth at ietf.org > >> Cc: Eran Hammer-Lahav > >> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) > >> > >> This is possible but it gets complicated. If server A (the one > issuing > >> the long encrypted opaque token) is separate (meaning not from the > same > >> company) from server B (the server receiving and validating the > token) > >> then both server A and Server B have to agree on the format of the > >> token > >> and the mechanism for "encrypting" or "signing" it. > >> > >> Since OAuth provides a way to secure requests via signing, this > becomes > >> a very easy way to support servers A and B being from multiple > >> companies > >> (or whatever). For sure, the partners could agree to take the string > >> that would be the value of the Authorization header, base64 it and > add > >> it to the URL. > >> > >> Maybe this could be the simplifying mechanism for adding OAuth to > URLs. > >> Just define an oauth_authz parameter that is optional and contains > the > >> base64 encoded version of the Authorization header. Simple to > process > >> and easy to implement. > >> > >> Thanks, > >> George > >> > >> Eran Hammer-Lahav wrote: > >> > >>> Actually, I am going to take this back. > >>> > >>> This is not really a valid reason to support authentication > >>> > >> parameters in the query. In this scenario, the resource owner is > able > >> to make an authenticated request using the auth headers. That > request > >> produces a special URI which can be shared, bypassing the access > >> controls. Why does this needs to be covered by OAuth? What prevents > any > >> server from issuing a time-limited/restricted/single-use/etc URI > using > >> long token such as: > >> > >>> > >> > http://example.com/resource/share/1k2j3h1oi823h123hk1j23ho182h31j2h3o18 > >> 2h3o12hi3o182h3o182h3 > >> > >>> I just don't see any reason why this is lesser than producing a URI > >>> > >> that uses OAuth parameters. Whatever the server needs can be either > >> encoded into this long token or maintained in a database. > >> > >>> So back to no real use case for query parameters support. > >>> > >>> EHL > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: George Fletcher [mailto:gffletch at aol.com] > >>>> Sent: Friday, October 02, 2009 9:16 AM > >>>> To: oauth at ietf.org > >>>> Cc: Eran Hammer-Lahav > >>>> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) > >>>> > >>>> I would expect that in the Amazon case being able to reuse the URL > >>>> would > >>>> be beneficial, but I'm not really familiar with that use case. > >>>> > >>>> For the SSO use cases, the desire is to prevent replay and make > the > >>>> > >> URL > >> > >>>> one time use only. We do set cookies during the redirect process > so > >>>> > >> a > >> > >>>> cache replaying those cookies could be problematic. There are a > >>>> > >> number > >> > >>>> of cache control directives that can be used for correctly > >>>> > >> implemented > >> > >>>> proxies. > >>>> > >>>> A couple reasonable links on the topic > >>>> > >>>> [1] http://blog.isc2.org/isc2_blog/2008/09/proxy-caches-ar.html > >>>> [2] http://www.oucs.ox.ac.uk/cache/faq.xml?splitLevel=-1 > >>>> [3] http://code.google.com/speed/page-speed/docs/caching.html > >>>> > >>>> However, I think this issue is bigger than just requests with URL > >>>> parameters. If I access a rest resource > >>>> http://photos.example.com/alice/album/vacation along with it's > >>>> Authorization header, if this request goes through a proxy, the > >>>> > >> proxy > >> > >>>> will mostly likely ignore the Authorization header. Hence the next > >>>> > >> time > >> > >>>> that static URL is requested, the contents is returned. The same > >>>> > >> cache > >> > >>>> control headers the server needs to send for these specific use > >>>> > >> cases > >> > >>>> will apply to the general case as well. I'm a little behind in the > >>>> lists > >>>> servs. Has this issue already been solved for the general case > using > >>>> the > >>>> Authorization header? > >>>> > >>>> Thanks, > >>>> George > >>>> > >>>> > >>>> > >>>> Eran Hammer-Lahav wrote: > >>>> > >>>> > >>>>> Thanks James, George. > >>>>> > >>>>> If we are going to support sending authentication credentials in > >>>>> > >> the > >> > >>>> URI query, what are the requirements to make sure it works well > with > >>>> proxies and caches? What headers do we need to require the server > to > >>>> return to make sure it doesn't get cached? Do we need to require a > >>>> nonce value for all signature methods to ensure making the request > >>>> > >> more > >> > >>>> unique and less likely to repeat? > >>>> > >>>> > >>>>> In these two use cases, is there a reason for the URI to be used > >>>>> > >> more > >> > >>>> than once? Can we simplify the credentials passed via the URI > query > >>>> > >> to > >> > >>>> provide adequate security but without the need for a long and ugly > >>>> > >> URI > >> > >>>> with multiple oauth_ prefixed parameters? > >>>> > >>>> > >>>> > >>>>> These are valid use cases and something we need to worry about to > >>>>> > >> get > >> > >>>> this new protocol deployed where other proprietary ones are > >>>> > >> deployed. > >> > >>>> But I am not that concerned about the use case mentioned earlier > of > >>>> 'just making it easier to send requests'. So if we support query > >>>> parameters but after some processing of the parameters to make the > >>>> > >> URI > >> > >>>> simpler, that would be acceptable to me. > >>>> > >>>> > >>>>> EHL > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: George Fletcher [mailto:gffletch at aol.com] > >>>>>> Sent: Friday, October 02, 2009 5:04 AM > >>>>>> To: oauth at ietf.org > >>>>>> Cc: Eran Hammer-Lahav; Brian Eaton > >>>>>> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) > >>>>>> > >>>>>> In addition to the use case James described, we use this to > enable > >>>>>> single sign on from a client/desktop app into a browser session. > >>>>>> > >> The > >> > >>>>>> client signs the URL and then opens the browser with that URL. > The > >>>>>> backend validates the signature and access token and then > >>>>>> > >>>>>> > >>>> establishes > >>>> > >>>> > >>>>>> an > >>>>>> authentication session for the user. > >>>>>> > >>>>>> A variant of this case is where a partner uses a back-channel > >>>>>> federation > >>>>>> call to authenticate their user to the AOL authentication > service. > >>>>>> > >> A > >> > >>>>>> successful response includes an access token and secret (the > >>>>>> > >>>>>> > >>>> equivalent > >>>> > >>>> > >>>>>> of) which the partner can then user to sign an URL when their > user > >>>>>> invokes an AOL service (again providing SSO). > >>>>>> > >>>>>> Thanks, > >>>>>> George > >>>>>> > >>>>>> P.S. Documentation on this signed API call can be found here: > >>>>>> http://dev.aol.com/authentication_for_clients#client2web > >>>>>> > >>>>>> P.P.S. While these APIs are not OAuth specifically, the patterns > >>>>>> > >> are > >> > >>>>>> needed for OAuth compliant APIs to be developed > >>>>>> > >>>>>> Eran Hammer-Lahav wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Can you describe the actual use case? > >>>>>>> > >>>>>>> EHL > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: oauth-bounces at ietf.org [mailto:oauth-bounces at ietf.org] > On > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> Behalf > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> Of Brian Eaton > >>>>>>>> Sent: Thursday, October 01, 2009 9:01 PM > >>>>>>>> To: George Fletcher > >>>>>>>> Cc: oauth at ietf.org > >>>>>>>> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) > >>>>>>>> > >>>>>>>> On Thu, Oct 1, 2009 at 7:52 PM, George Fletcher > >>>>>>>> > >> <gffletch at aol.com> > >> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> One use case (I think I saw it mentioned somewhere else on > the > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>> list) > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> where > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> we've used the URI parameters is when we want the server to > >>>>>>>>> > >> sign > >> > >>>> a > >>>> > >>>> > >>>>>>>> URL and > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> then pass that signed value to the browser to load. This can > be > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>> done > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> with a > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> simple 302 and the signed URL. Switching to just supporting > the > >>>>>>>>> Authorization header will make this more difficult but > probably > >>>>>>>>> > >>>>>>>>> > >>>> not > >>>> > >>>> > >>>>>>>>> impossible. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> Yep. I've seen that done multiple places. > >>>>>>>> > >>>>>>>> One more unexpected use of OAuth... > >>>>>>>> _______________________________________________ > >>>>>>>> OAuth mailing list > >>>>>>>> OAuth at ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth at ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> > >>>>> > >>>>> > >>>>> > >>> > > > >
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.