Seth, I've stumbled across your post before and it's in fact the document which I've based my initial assumptions upon.
So technically the changes seem to come down to add one more parameter, right? As the 1.0 spec already incorporates all parameters into the signing algorithm, we'll get that part automagically without any additional work on the *technical* part of the signing process. Would you say this is correct? -Ralf On 03.06.09 19:05, "Seth Fitzsimmons" <[email protected]> wrote: > > I put this together a couple weeks ago, seeing such a vacuum and > attempting to implement the changes myself: > > http://mojodna.net/2009/05/20/an-idiots-guide-to-oauth-10a.html > > Fortunately, when you get down to it, the changes aren't very > complicated and are fairly straightforward to implement. > > seth > > On Wed, Jun 3, 2009 at 7:01 AM, Ralf Rottmann <[email protected]> wrote: >> >> Thanks for the reply. I believe it would do good if somebody from the OAuth >> Core Team would to a more in-depth blog post for implementers that outlines >> the technical changes in greater detail. >> >> Would speed up adoption. >> >> -Ralf >> >> >> >> On 03.06.09 15:39, "Manish Pandit" <[email protected]> wrote: >> >>> >>> >>> On Jun 2, 1:39 pm, 24z <[email protected]> wrote: >>>> Just two quick questions for clarity: >>>> >>>> 1.) Do I understand "Signed Callback URLs" correctly in that "signed" >>>> here has nothing to do with generating a signature as described in >>>> 1.0? >>> >>> oauth_signature becomes a part of the process while calculating the >>> signature for the get_request_token endpoint, i.e. it is encoded/ >>> sorted/re-encoded etc. just like any other oauth parameter to generate >>> the signature. >>> >>>> >>>> 2.) Does "Signed Callback URLs" in essence mean that the Service >>>> Provider returns a unique vetifier (= an arbitrary string) after >>>> authorization that is therefore only known to the honest consumer/user >>>> and must be send back to the provider when requesting the Access >>>> token? >>>> >>> >>> Right - signed callback URLs will ensure that no one can change the >>> callback in the middle of the oauth-dance, as it is signed with the >>> secret during the very first call (to get_request_token). The verifier >>> is generated by the provider as a result of the authorize_token step >>> and can be sent to the consumer via the callback parameter, or >>> manually (if oauth_callback = oob). This verifier is then used as a >>> part of the request to get_access_token, which BTW is signed too. >>> >>>> Did I get all of this right? And: What's the current status of OAuth >>>> 1.0a. Is 1.0a an official version or is it still draft? >>>> >>> >>> I believe 1.0a is in its 3rd draft dubbed as "implementer's draft" and >>> no further changes were expected. This may need confirmation from the >>> editor(s) though. >>> >>> Hope this helps! >>> >>> -cheers, >>> Manish >>>> >> >> >> >> Ralf Rottmann >> >> eMail: [email protected] >> Blog: www.thenextweb.com | www.24100.net >> Twitter: www.twitter.com/24z >> LinkedIn: www.linkedin.com/in/rottmann >> >> >> >>> >> > > > Ralf Rottmann eMail: [email protected] Blog: www.thenextweb.com | www.24100.net Twitter: www.twitter.com/24z LinkedIn: www.linkedin.com/in/rottmann --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
