On Thu, May 7, 2009 at 12:45 PM, Owen Evans <owenmcev...@gmail.com> wrote:
> 2009/5/8 Dirk Balfanz <dirk.balf...@gmail.com> > >> >> 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
