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

Allen Tom atom at yahoo-inc.com
Fri Nov 14 01:58:00 UTC 2008


Adding OAuth signature methods, including RSA-SHA1, to OpenID 2.1 is 
supposed to happen. It is probably not a good idea to return RSA keys 
via association requests for unregistered consumers though.

Allen


Breno de Medeiros wrote:
> 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
>>
>>
>>     
>
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081113/8769e428/attachment-0002.htm>


More information about the specs mailing list