On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt <dick.ha...@gmail.com> wrote:
> On 2010-07-10, at 9:58 AM, Paul Tarjan wrote: > > Hi OAuthers, > > First of all, I think I should introduce myself. I work at Facebook on the > Platform team (anything not facebook.com). Before this I was at Yahoo! > doing SearchMonkey (semantic web stuff). I've written a few OAuth > applications and libraries, both at Yahoo and in my spare time. > > For Facebook apps we're going to use your signature scheme with the > following changes: > > > I would hope you would think it is "our" signature scheme rather than > "your" signature scheme > I think Paul was referring to the proposal Dirk put forward since there isn't anything which has become part of OAuth yet. ;) * the signature comes before the payload > * we used the key 'algorithm' instead of 'alg' and 'expires' instead of > 'not_before' > > > Good points to add to the discussion. Perhaps you would articulate why you > made those choices? > I think Naitik talked about the signature coming before the payload in this thread. Through implementations we've found that lsplit is easier in some languages. The benefit of using 'alg' is unclear compared to spelling out the word 'algorithm' which adds clarity for developers. * we aren't sending any keys except algorithm, expires, and oauth_token > (since we're a special use case) > > > If you are a special use case, then not sure why there is any point in > being a standard. > Some more background is needed here. We're not currently implementing signatures for our protected resources, but rather to send some trusted parameters from the authorization server to the client. We're starting with a use case entirely on Facebook.com (our canvas applications) and thus have a different set of security considerations. There is value in the underlying signature format being the same. Thus making use of signed JSON – the hard part – even if some of the parameters within are different. > Assuming you meant "parameters" instead of "keys"? "key" has special > meaning when you are discussing crypto. > Yes. * we named the parameter signed_request because it is the signed part of a > request > > > Which parameter? > The context above should be helpful. This would be the parameter name coming from the AS to the client. > We would love if you could adopt those changes. Then you'd have a real > world implementation out the door already :) We plan on launching July 20. > > > Er, we welcome feedback on the standard. Facebook can deploy whatever they > want to deploy. An early implementation is useful to see what the issues > might be. While possible, it is unlikely what you deploy will be the > standard. > > > Paul > > Sent from my iPhone > > > Thanks for letting us know what device you use. > > -- Dick > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
