<br><br><div class="gmail_quote">On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom <span dir="ltr"><<a href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Dirk Balfanz wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I don't think this is true - I believe the realm is sufficient. Let me try and explain. (We'll assume registered consumers.) On the approval page, we need to identify the consumer. In its current form, the spec basically assumes that you're gonna use the realm for that.<br>
</blockquote>
<br></div>
You're assuming that a realm has only one CK. A site might have multiple consumer keys, with different scopes attached to them...<br><font color="#888888">
</font></blockquote><div><br>Actually, I wasn't assuming that. At access token request time, you follow the map from consumer-key to realm (that's the direction you can do, right)? If that's a many-to-one map then this will give you one realm. Then you check whether that's the realm that the request token was issued to.<br>
<br>The one thing you're losing is that you can't, at approval time, figure out whether that realm is requesting a scope that they have access to. So a realm could ask for a certain scope in their auth request, the user approves it, and then at access-token-request time, you won't issue the token b/c they're using a CK that doesn't have enough privileges. It's still secure, but gives you a crappy user experience if the consumer mixes up their CKs.<br>
<br>Wait - I think I have an idea: what if the Yahoo-specific way of requesting the scope is to include the CK into the openid.oauth.scope parameter? That way, you can at approval time make sure that they are requesting a scope that they are actually authorized to pick up. This wouldn't be for security purposes - just as a way to make sure the user experience isn't surprising.<br>
<br>Dirk.<br></div></div><br>