First, congrats on the new member of the Eaton family. > -----Original Message----- > From: Brian Eaton [mailto:bea...@google.com] > Sent: Tuesday, December 08, 2009 10:43 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft > > On Mon, Dec 7, 2009 at 11:52 PM, Eran Hammer-Lahav > <e...@hueniverse.com> wrote: > > Can you list the use cases it doesn't meet? This is largely a cosmetic > > rewrite of 1.0 with the exception of directly supporting form-encoded > > parameters which is still being discussed. Your reference is to a post about > mostly non-HTTP use cases. > > There are basically two use cases for the crypto in OAuth 1.0, and one major > problem. > > Major problem: people can't figure out the signature base string. > The new authentication spec does nothing to fix this, which is a shame. > It is > solvable.
Can you offer alternatives other than including a base64 copy of what is being signed. > Use case #1: security for people who won't use https. > We seem to have concluded that this isn't achievable. [1] HTTPS will be a required part of the protocol. The question is, are we going to accommodate the case where HTTPS is not desirable for every protected resource request? There seems to be consensus that yes. > Use case #2: security for people who need to send messages through > untrusted third-parties. > The new authentication spec makes this much, much harder. > > Here are a few examples of places where people are using OAuth to send > messages through untrusted third-parties. Every single one of these use > cases is broken by the token-auth spec [2]. If we can't solve these problems, > there is very little point in message authentication at all. > > For example: > - signed URLs embedded in the browser [3] > - opensocial identity parameters [4] > - google-specific identity parameters [5] > - intermediate xmpp servers [6] > - intermediate sip servers [6] What about the draft breaks these? Is it the need to access the raw HTTP request URI? That is the only difference between the token scheme and the current OAuth signature base string. This wasn't a new idea - I have asked about this more than once and the consensus was that it is not a problem. If it is, it certainly makes a difference and the side effect was not intentional. EHL > We should be trying to make those use cases *easier*, not make them > impossible. If we push a new OAuth spec that drops these use cases, we've > done more harm than good. > > Cheers, > Brian > > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00762.html > [2] http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt > [3] http://www.ietf.org/mail-archive/web/oauth/current/msg00689.html > [4] http://www.opensocial.org/Technical-Resources/opensocial-spec- > v09/Gadgets-API-Specification.html#gadgets.io.makeRequest > [5] > http://code.google.com/apis/accounts/docs/OAuth.html#GoogleAppsOAut > h > [6] http://www.ietf.org/mail-archive/web/oauth/current/msg00513.html _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
