I realise there's a link between the Token and the Verification code but not the Verification Code and Token VALUE which is how I would read the first one, i.e. the verification value has to be some kind of hash of the oauth_token value. Anyway, I'm playing devils advocate and it's not like I mind anyway the language all looks fine, it's just I'm explaining how I read it (and therefor some other laymen would/could read it).
*"The verification code is the same as the verification code sent by the stored procedure during the previous step"?* O 2009/5/8 Dirk Balfanz <[email protected]> > > > On Thu, May 7, 2009 at 12:45 PM, Owen Evans <[email protected]> wrote: > >> 2009/5/8 Dirk Balfanz <[email protected]> >> >>> >>> You didn't like my "the verification code matches the request token" >>> language? >>> >>> Dirk. >>> >> >> IMHO that implies that the verification code value has some intrinsic link >> to the request token value, which is presumptuous about the implementation >> method. >> > > I think that any implementation that doesn't have such an intrinsic link > (be it as an explicit link in a database, as a signature, or perhaps as an > implicit link through some other means) is broken, hence my proposed > language. > > It might be the case that "the verification code matches the user that > approved the request token" is good enough - it seems to prevent the session > fixation attack we identified. But I thought that for good measure, we > should actually require the verification code to be bound to a particular > request token, not just a particular user (I don't know what can happen if > we allow a user to approve two different request tokens, and then swap the > verifiers he got for the two before returning to the Consumer). > > All we want to say is that the verification code matches the expected >> verification code at the SP. Without implying how the SP saves or comes >> about the expected verification code. >> > > That, again, assumes that there are two verification codes - the "expected" > one, and the "actual" one. If the way I'm implementing this is have my > verification code be the DSA signature of the request token, then there is > no way for me to calculate the "expected" verification code (re-doing the > signature on the request token will yield a different signature). All I can > do is check that the "actual" one is kosher (b/c it matches the request > token, not some "expected" verification code). > > Dirk. > > > >> >> O >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
