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

Breno de Medeiros breno at google.com
Fri Nov 14 01:46:22 UTC 2008


2008/11/13 Allen Tom <atom at yahoo-inc.com>:
> In the registered consumer case, why not just do:
>
> openid.assoc_handle=consumer_key
> openid.mac_key=consumer_secret

This implies that the consumer key is HMAC-SHA1. What if it is RSA?

>
> ?
>
> In the unregistered consumer case, the OpenID association request could be
> extended to hand out Consumer keys, which are then used as the association
> handle. The scopes and realm could be passed to the association request as
> well.
>
>
> Allen
>
>
>
> Dirk Balfanz wrote:
>
> 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 <darren at cliqset.com> 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 <balfanz at google.com> wrote:
>>
>>
>>
>> On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom <atom at yahoo-inc.com> 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 openid.net
>> http://openid.net/mailman/listinfo/specs
>
>
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)



More information about the specs mailing list