One issue that arises is now the SP has no way to tell if we are using 1.0 old flow or the new flow.The SP will not know which one is being used until the consumer asks for the access token. So how will we know if the callback should use the old flow's format or the new flow w/ verifier?
We would either have to increment the wire version OR the SP would have to use different end points for the two flows. example: http://www.test.com/oauth/1.0a OR 1.0/request On Tue, May 5, 2009 at 9:06 PM, Manger, James H < [email protected]> wrote: > [I said] > >> An advantage of this approach for the Service Provider is that there is > >> no extra state that has to be maintained between the Request Token and > >> Authorization steps so the SP’s Request Token format should not need to > >> change to maintain stateless operation. > > [Breno replied] > > This does not have to change. The SP can encode the callback URL in > > the request token itself. > > This is a change to the SPs tokens. It can be done, but it is an extra > change and it might raise some awkward issues. I assume current tokens > encode consumer ids, scopes, times etc that are shortish, fixed length, and > chosen by the SP. > Encoding a whole callback URI feels a bit different. The consumer chooses > the callback. It might be long. The whole URI needs to be encoded as the > whole URI is needed during the authorization step so the user can be > redirected there. > > [The authorization URI shouldn't be much longer: the callback URI just > moves from an oauth_callback parameter into the oauth_token parameter > (assuming efficient encoding by the SP)] > > > The whole callback URI does not need to be encoded to remember it between > the authorization and access token steps. It is sufficient to remember a > fixed-length hash of the callback URI. Consequently, an SP can use a fixed > length "verifier" to encode the state they need to check the callback URI in > the access token step. > > > > 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 -~----------~----~----~----~------~----~------~--~---
