On Wed, Jul 21, 2010 at 8:27 PM, Ben Laurie <b...@google.com> wrote: > On 16 July 2010 01:43, Dirk Balfanz <balf...@google.com> wrote: >> 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 >> - 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? > > Nearly missed this, somehow. Yes, looks good to me. A reference would > be nice (RFC 3447, for example).
Magic Signatures is using EMSA-PKCS1-v1_5 instead of PSS because it has wider library supports, I believe. For example, OpenSSL library interface in PHP does not seem to support PSS. > >> - 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). Perhaps http://tools.ietf.org/html/draft-sakimura-jsonenc-00 help? >> 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. With Sign + Encrypt, you are signing the (almost) plain text, while with Encrypt + Sign, you are sining the cypher text so you would have to have full trust on the Encrypt process that it did not tamper the original text. Also, with Sign + Encrypt, you can store the decrypted text and still verify the integrity of the data at a later date, but with Encrypt + Sign, you cannot. Thus, to me, Sign + Encrypt seem to be a better approach. -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
