Hi guys, after reading through the feedback, we did a pass over the OAuth signature proposals.
As a reminder, there are three documents: - a document (called "JSON Tokens") that just explains how to sign something and verify the signature: http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 - an extension of JSON Tokens that can be used for signed OAuth tokens:<http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU> http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU - a different extension of JSON Tokens that can be used whenever the spec calls for an "assertion": http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc (When used in the assertion flow, this last token can also be used to do "2-legged" OAuth) A summary of the (scant) changes: - we spelled out what we mean by RSA-SHA256.* Ben Laurie *- can you double-check that that sounds good? - we decided on unpadded websafe-base64 throughout. - some changes to parameter names. - some small changes I might be forgetting now... As explained in my message to the previous thread, there is still no envelope in there to help with encrypted tokens (b/c we don't understand well enough what the envelopes for encrypted tokens would look like). One question: What's the deal with having the signature go first? If you can explain to me why that is a good idea, I'm happy to oblige. Cheers, Dirk & Marius.
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
