[PROPOSAL] Removing SIGNALL From Draft 10

Brad Fitzpatrick brad at danga.com
Fri Sep 29 18:45:29 UTC 2006


+1

Reading the 1.1 -> 2.0 spec, the SIGNALL stuff confused me and got in the
way, I thought.


On Fri, 29 Sep 2006, Recordon, David wrote:

> 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
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>



More information about the specs mailing list