First, thanks for putting this together. It provides a pretty comprehensive story about the signed tokens proposal. I don't have much to add at this point to the drafts.
My position, which I have expressed many times before about this approach is: Any solution involving repeating the HTTP request elements in some sort of envelope will require validation .In this case, you need to define all the rules for validating the 'audience' parameter. This approach makes it too tempting for server developers to ignore the HTTP request and only use the values of the 'audience' and 'method' parameters. In order to validate those parameters, the server needs to perform some sort of normalization (which eventually leads to the same signature mismatch problems). Not looking at the HTTP request will lead to security problems because it will allow bypassing existing HTTP firewall rules which operate on the request URI and HTTP method. As a matter of personal taste, this smells too much like SOAP. And that's a really bad thing. I am not in favor of any solution that replicates components of the HTTP request within the request (as is the case here). Recent experience shows that with a little help and good libraries, developers can figure out how to normalize and sign an HTTP request successfully, when motivated. EHL On 9/23/10 7:07 PM, "Dirk Balfanz" <balf...@google.com> wrote: On Thu, Sep 23, 2010 at 6:51 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: In part II, how is the signature bound to the HTTP request URI? I see the method and body, but not the request URI. The request URI goes in the audience parameter that's defined in part I. Dirk. EHL On 9/23/10 3:39 PM, "Dirk Balfanz" <balf...@google.com <http://balf...@google.com> > wrote: Hi guys, sorry it took a while, but here is an updated proposal. It's still in three parts: Part I is about "JSON Tokens" that can be used for all sorts of things, not just OAuth: http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html Part II is about how to embed an OAuth token and (some parts of) an HTTP request into a JSON Token: http://balfanz.github.com/jsontoken-spec/draft-balfanz-signedoauth2-00.html Part III is how to use signatures instead of client secrets for assertions in OAuth: http://balfanz.github.com/jsontoken-spec/draft-balfanz-clientassertions-00.html Diffs from the last specs are: - JSON Tokens are now just a profile of Magic Signatures, which John Panzer has helpfully extended for this purpose - There was a vulnerability to masquerading attacks in the last proposal, which is addressed in this proposal by adding a data_type parameter that is part of the signature, but _not_ part of the payload. - no more support of X.509 certs - the only supported format for discovered public keys is now the Magic Key format. We'll give people tools (which are quite easy to write) to convert their self-signed or CA-issued certs to magic keys. - The specs are now formatted as I-Ds. Comments, please! Dirk.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
