Request for comments: Sorting fields in signature generation

Josh Hoyt josh at
Wed Sep 27 17:39:59 UTC 2006

On 9/27/06, Johnny Bufu <johnny at> wrote:
> Section 5.2 of draft 9 seems to imply, at least, that pass-through
> parameters are allowed, and specifies how the parties involved in the
> transaction should handle the openid / non-openid parameters.

Huh? I don't see anything in that section about a requirement to echo
back parameters.

> > a) Including the pass-through arguments in the OpenID signature is not
> > necessary (or constructive!)
> That may be up to the RP to decide; if it decides that it needs to
> trust such parameters included in an indirect message, by not
> allowing it to use the already existing openid mechanism would only
> add complexity that can be avoided.

The signature on the response only allows the RP to know that the
parameters have not been altered since they left the IdP. It does not
allow them to trust that the parameters have not been altered during
the transaction. That would require a *private* (to the RP) signature
in the request to the IdP that got echoed back as well.

If you want to propose echo parameters, please write up a proposal in
a new thread.

> > b) It is quite reasonable to restrict them to only one value per
> > parameter name.
> It would also be reasonable to place the restriction only on core
> openid parameters, and leave the possibility for them for extensions
> and pass-through parameters.

The implications for implementers are the same either way. I am
arguing for the simpler solution. If the simpler solution is
reasonable, why argue it?


More information about the specs mailing list