[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 -~----------~----~----~----~------~----~------~--~---
