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> 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
