I agree in theory and disagree in practice. Please bring all this with you to the IETF WG. There is nothing to prevent us from rolling back this change and replacing it with another change, or make any other changes we achieve consensus for.
EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Manger, James H > Sent: Thursday, May 07, 2009 6:17 PM > To: [email protected] > Subject: [oauth] Re: Confirm callback when getting access token > > 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 -~----------~----~----~----~------~----~------~--~---
