[OAUTH-WG] Thinking about our secrets for signatures

[David Recordon <[e-mail]>]

Has anyone else put some thought into what secrets are used within the
signature algorithm for OAuth 2.0?

OAuth 1.0 combines the client secret and the token secret with an
ampersand in the middle.  WRAP doesn't support signatures and relies
on the fact that access tokens should remain secret via SSL or are
extremely short lived and thus lower risk.

Here are the options as far as I'm aware (without making changes to
WRAP's assumptions):

1) Sign using the client secret.  Doesn't work because the access
token would be sent over the wire in plaintext and some servers will
make them long lived in 2.0.

2) Issue an access token secret if an optional parameter is specified
by the client during the authorization profile request(s).  Doesn't
work for the same reason as #1 assuming that the same access token can
be used via SSL.

3) Instead of adding an optional parameter to each authorization
profile, have the client immediately refresh the access token and
support an optional parameter to request an access token secret.  This
lessons the impact of supporting signatures on most implementors when
reading the spec and given that most signature use cases have longer
lived tokens, the overhead of the extra HTTP request should be
infrequent compared to the number of protected resource requests
you'll make with it.  Doesn't work for the same reason as #1 assuming
that the same access token can be used via SSL.

While I'm not a crypto expert, it seems impossible to treat the same
access token as potentially public when using signatures but secret
when using SSL.  I believe that authorization servers will need to
keep track of the access tokens that the client has requested a secret
for and from that point on only allow the use of that particular
access token 1) via signatures or 2) via SSL when the access token
secret is passed in as well.

Thoughts?

Thanks,
--David