The risk to the future of OAuth from callback-with-request-token's structural change is greater than the risk from shorter security review of callback-with-access-token. --
To my mind, the OAuth delegation flow really starts when a service says, in response to an HTTP request: "This request is rejected, but it can succeed if a user delegates you their permission to make this request. You can get that permission using the OAuth protocol, for which you will need a request token, request secret, and an authorization URI." Today, a consumer app uses hard-wired service-specific knowledge to make an explicit request for a Request Token. It knows it is doing OAuth before it makes the first request. In future, I hope consumer apps can interoperate with services more dynamically. An app will not always know that OAuth is required when it makes the first request so it cannot include an OAuth callback URI in the first request. That will require a second request. I think it is quite likely that the callback-with-request-token proposal will require an extra round-trip (compared other solutions such as the callback-with-access-token proposal) once "discovery" options are defined. Callback-with-request-token changes the *structure* of the OAuth delegation flow by making the consumer (instead of the service) send the first message that is specific to OAuth delegation. This structural change is somewhat hidden with OAuth Core 1.0, because 1.0 tightly couples request signing and delegation. It will become more obvious as those independent aspects are separated, which is starting with Eran's IETF OAuth draft. We obviously don't want to define "discovery" now before fixing the security issue, so we should be very wary about making structural changes now since we are not taking the time to understand their implications. The risk to the future of OAuth from callback-with-request-token's structural change is greater than the risk from shorter security review of callback-with-access-token. James Manger [email protected] Identity and security team — Chief Technology Office — Telstra --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
