OpenID/OAuth hybrid - without app pre-registration
Dirk Balfanz
balfanz at google.com
Wed Jan 7 20:16:16 UTC 2009
On Sun, Nov 30, 2008 at 3:07 PM, Manger, James H <
James.H.Manger at team.telstra.com> wrote:
>
> > here is a non-security reason [for openid.oauth.consumer in the
> response]:
> > Imagine the Consumer controlling more than
> > one consumer key, and also imagine that the consumer is implemented as a
> > server farms of thousands of machines. The machine receiving the response
> > is not necessarily the same machine as the machine that made the request,
> > and it response-receiver needs to know the context of the request.
>
>
> The openid.return_to parameter is already available to relay RP context
> from a request to a response. Adding second way to do the same thing does
> not help. An app can, for instance, use
> openid.return_to=https://example.com/rp?contex=26532
>
> Returning openid.oauth.consumer and openid.oauth.scope cannot help if
> apps are not doing anything with them (and the draft spec doesn't suggest
> doing anything). If a paranoid crypto geek in future finds a reason to
> return the parameters the apps built before that point will still be
> broken.
>
Reviving this thread.
I think you're right. I'm removing the consumer parameter from the response.
I have posted a new version of the spec on
http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html
Dirk.
>
>
>
> >> Is the app supposed to check that the value in the response matches the
> >> value in the request?
> >> Are there security implications of not doing the check?
> >> I suspect it can be omitted (openid.return_to is still present and
> signed
> >> if the app want to confirm the response is meant for itself).
>
> James Manger
> _______________________________________________
> 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/20090107/3845a207/attachment-0001.htm>
More information about the specs
mailing list