Yes, I can see how that would happen. So how about for OPs who tie scope to Consumer Keys, their openid.oauth.scope syntax would look something like this:
openid.oauth.scope=consumer_key:scope1,scope2,scope3 Or, if there is a one-to-one mapping from consumer_key to scope, simply like this: openid.oauth.scope=consumer_key Dirk. On Thu, Nov 13, 2008 at 2:04 PM, Darren Bounds <[EMAIL PROTECTED]> wrote: > 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 <[EMAIL PROTECTED]> wrote: > > > > On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom < <[EMAIL PROTECTED]> > [EMAIL PROTECTED]> 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@openid.net > http://openid.net/mailman/listinfo/specs > >
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
