[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