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

Breno de Medeiros breno at google.com
Fri Nov 14 02:01:24 UTC 2008


On Thu, Nov 13, 2008 at 5:58 PM, Allen Tom <atom at yahoo-inc.com> wrote:
> 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.

Ok, but what is wrong for you to instruct the developers to insert the
consumer_key in the scope parameter, and they bind it to the approved
request token?

Since each OAuth SP has defined scope differently, they will have to
look it up what to put in the scope anyway.

>
> 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
>
>
>
>
>
>



-- 
--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