>> -- BC gives the request token to Otherwise Good Consumer (OGC), whom >> the Resource Owner trusts > > How does this work? How does one consumer talks to another consumer? Is this > a MITM attack between the OGC and SP?
Sorry if I wasn't clear: It's not a MITM, it's a collusion attack. The OGC would be explicitly acting to get the BC's token authorized (unless the BC had some way of spoofing the OGC's authentication, but that has a lot more implications). Obviously, this step isn't part of the protocol, so from the protocol's perspective it's out of band. The BC could send the OGC and email, or provide a URI that the OGC could query for a token to authorize (the BC could proxy through the SP response with the request token). >> -- OGC gets the Resource Owner to authorize the BC's request token > > The token obtained by the BC should be marked as such by the SP. When the SP > asks the user to authorize access, it will show the name of the BC, not the > OGC. I apologize! I had missed that requirement in the spec; it does indeed address the above attack. I would still prefer to have this comparison as part of the protocol so that you wouldn't rely on a user comparing strings. In any case, the original point was that the verifier doesn't buy you anything, which is still true in light of the above. --Richard --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
