> 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. >> 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 [email protected] http://openid.net/mailman/listinfo/specs
