I don't want to put parameters into the protocol that aren't necessary.
So far, I've heard one argument for adding the consumer key in the
association request: to give a hint to the authorization UI as to whether or
not the consumer is authorized to request the scope passed in the
openid.oauth.scope parameter. The idea is, as far as I can tell, to encode
the consumer key into the association handle, and thus have the consumer key
available at authorization time.
I'm saying "hint", because it is nothing more than that - neither the
association request nor the auth request are signed, and the consumer can
put whatever they want into the consumer key (in the association request) or
association handle (in the auth request). Which is fine, since an attacker
lying about these things won't be able to exchange the request token for an
access token later.
So, again, the proposal seems to be to embed a hint to the consumer key into
the association request (which will then be threaded through the association
handle into the auth request). This doesn't buy us any additional security,
it just hints at what scope the consumer is allowed to request (for those
SPs that encode scope in consumer keys) - the security is provided later in
the access token request step.
Now, my argument is that we already _have_ a place to signal scope. It's the
openid.oauth.scope parameter. If you don't want to put consumer keys there,
let consumers put some other encoding of the scope there. If you're an OP
where scope isn't really decided at authorization time (but later, when we
know the real consumer key of the consumer), then this will just be a hint
for you to get the UI right. But that's no different from putting the
consumer key into the association request - that's only a hint, too.
So we get the same guarantees with less parameters if we stick with the
proposal.
Right? :-)
Dirk.
On Thu, Nov 13, 2008 at 8:32 PM, Breno de Medeiros <[EMAIL PROTECTED]> wrote:
> I changed my mind on this one.
>
> A. The fact that scopes are not standardized in OAuth today does not
> mean that in the future *some* scopes (e.g., related to portable
> contacts) may be standardized.
>
> B. The consumer key is an intrinsic identifier of the party requesting
> association and probably should be included, with the realm, in the
> association request (if available).
>
> There is no need, however, to include any additional information in
> the authentication request. The consumer key can be bound to the
> association handle.
>
>
> On Thu, Nov 13, 2008 at 6:43 PM, Allen Tom <[EMAIL PROTECTED]> wrote:
> > In the future, we might update our OAuth service to allow developers to
> pass
> > us the scope dynamically, rather than binding the scope to the CK.
> However,
> > we'd still probably require developers to agree to a TOS in order to get
> a
> > CK/CS.
> >
> > I'm concerned about having to tell developers to pass the CK via the
> scope
> > parameter for the first revision, and then later telling them that scope
> > parameter actually means the scope. I'd like to have one parameter
> (possibly
> > optional) that means CK, and another parameter (also optional) that means
> > Scope. Overloading a single parameter can get really messy in the long
> run.
> >
> > Allen
> >
> >
> >
> >
> >
> >
> >
> > Breno de Medeiros wrote:
> >>
> >> 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?
> >>
> >
> >
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
