Re: [OAUTH-WG] signatures, v2

[Greg Brail <[e-mail]>]

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:[e-mail]]
*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:* [e-mail] [mailto:[e-mail]] *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.