Looks like I didn't read all the specs before writing such a long e-mail. Sorry!
"JSON Signatures" does indeed support a key and says that, for HMAC and RSA, there should be an out-of-band mechanism for a client to retrieve a key to go along with a particular token. Should we have a spec that specifies how an OAuth 2.0 client can securely retrieve a key for each token in a way that makes sense for OAuth 2.0 and is easy to implement? Or is this already specified somewhere else? *From:* Greg Brail [mailto:gbr...@sonoasystems.com] *Sent:* Thursday, July 22, 2010 2:58 PM *To:* 'OAuth WG' *Subject:* RE: [OAUTH-WG] signatures, v2 I apologize since I have a feeling that this decision was made long ago but I'd like to understand... OAuth 1.0 had a secret associated with every token and used an HMAC to generate the signature. So, there is no way for an intermediary to see the token secret, regardless of whether SSL is used. OAuth 2.0 removed the token secret, which means that SSL must be used and any "legitimate" intermediaries like proxies and load balancers can see the token. We all agreed that this was a good thing and it greatly simplifies OAuth but it does eliminate some of the old OAuth 1.0 use cases. Are there still cases in which an API provider wishes to *avoid* using SSL, but still wants to ensure that a network eavesdropper or a legitimate intermediary cannot deduce the token and secret? I can imagine that such a mechanism might still be useful in environments where SSL is cost-prohibitive, such as for storage APIs that return very large data sets that are not sensitive enough to require SSL. For instance, Amazon uses something like OAuth 1.0 signatures in their AWS APIs. Does anyone have an idea whether they are still happy with that decision, or do they wish that they had just required SSL for everything? Is there any proposal to introduce an extension that works like the "old" OAuth 1.0 signature mechanism, including the usage of a token secret? Is that idea totally dead or just dormant? *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Dirk Balfanz *Sent:* Thursday, July 15, 2010 8:44 PM *To:* OAuth WG *Subject:* [OAUTH-WG] signatures, v2 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? - 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
