[PROPOSAL] Removing SIGNALL From Draft 10

[Recordon, David]

While I know this was added in draft 9, I'd like to readdress it as I'm
concerned from a technical perspective.  My understanding of the
motivation was to allow a Relying Party pass arbitrary key/value pairs
to an IdP and have them passed back in the signature.  I believe that
this, minus the parameters in the response being signed, can be achieved
via the "return_to" parameter.  This is a URL generated by the Relying
Party for where the Identity Provider should redirect the End User upon
authentication.  It thus can be used by the Relying Party to maintain
state between requests.

My concerns:
1. There is no manifest for the fields that get signed, which makes it
more vulnerable to certain kinds of attacks, if weaknesses are found in
the MAC generation algorithm.  This could be corrected by using a signed
list that used full keys instead of leaving off the "openid.", but see
(2).

2. The entire query becomes part of the OpenID message, rather than just
the prefixed fields. As I remember it, the original motivation for using
prefixed parameters was to avoid collision with existing parameters of
any applications. Signing these parameters mixes them in with the
authentication request or response. One of the nice things about OpenID
1.x is that it's really clear which parts of the HTTP messages are
OpenID-specific; I'd like to preserve that.

Thoughts?

--David