OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

Darren Bounds darren at
Thu Nov 13 22:04:08 UTC 2008

Certainly but the consumer context you display to the user is falsely  
represented based solely on the realm in that circumstance.

Sent from a mobile device.

On Nov 13, 2008, at 4:58 PM, Dirk Balfanz <balfanz at> wrote:

> On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom <atom at> wrote:
> Dirk Balfanz wrote:
> 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.
> You're assuming that a realm has only one CK. A site might have  
> multiple consumer keys, with different scopes attached to them...
> 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.
> 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.
> 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.
> Dirk.
> _______________________________________________
> specs mailing list
> specs at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the specs mailing list