Brian, > 1) Initial requests for user approval .. are signed using RSA. > 2) Data requests .. are signed only with the token secret using HMAC. > 3) Requests to renew access tokens (if we adopt something like the > scalable OAuth extension) are again signed using RSA. Why do you need to use the RSA key during token renewal? If renewal can be occur at any time at the discretion of the server, then the client will always need the RSA key handy. It sounds like it will be hard for a client to get any benefit from not needing the RSA key for resource requests if, at any moment, it needs the RSA key to renew the token to complete a resource request. It seems to make it tough to hand a user-specific token to javascript running in that user's browser, for instance. If I remember correctly, the threat that the Scalable OAuth extension addresses is that many content services accept tokens issued by one security server then one content server is compromised. Security for the other content servers should be restored in the short (eg 5 min) token lifetime. It should be sufficient for the security server to be able to distinguish the original client that a token was returned to, from a malicious party that learnt the token details from a compromised content server. Two quick ideas: 1. A cookie set by the security server when issuing the token would be sufficient. The client would return the cookie during renewal; the compromised content server never sees this cookie. 2. A better alternative might be for the security server to provide a renewal URL when issuing a token. The renewal URL can be unique to the token. A compromised content server never sees the renewal URL so it cannot renew a token. Both these ideas tackle the Scalable OAuth issue, while keeping the benefits of not needing the RSA key after the initial interactive delegation involving the user. James Manger James.H.Manger at team.telstra.com Identity and security team — Chief Technology Office — Telstra
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.