proposal: consistent message format

Brad Fitzpatrick brad at
Wed Sep 20 20:05:42 UTC 2006

I don't think it's confusing right now.  URL parameters, where it's
possible to have a namespace collision (mixing with the IdP/RP's existing
URL parameters), are required to have openid. to be polite and step out of
the namespace.  But things that are purely OpenID-related (the direct
POSTs between parties), don't because it's implicit.

If this was proposed from 0.9 to 1.0, sure, it'd be worth fixing because
there were 3 users.  But there's enough 1.1 users now and compatibility
with 1.1 is one of the major goals of 2.0, so I think you're introducing
more complexity by having to document the differences and history between
1.1 and 2.0 in the 2.0 spec (requiring users to do both) than the
complexity you save by unifiying this.  Or you run the risk of people not
understanding the old way, which is perfectly fine, and breaking

In the end I think this is a nitpick that causes too much pain long term,
for way too little gain.

I don't want to be mean and -1 this without discussion, but that's the way
I'm leaning at this point.  I've gotten private mails from others
concerned about this, so I'm speaking up now.

 On Mon, 18 Sep 2006, Dick Hardt wrote:

> Problem:
> Direct and indirect messages have different formats. This adds
> complexity for the developer. Specifically:
> 	- some messages have parameters start with "openid.", others are
> bare keywords.
> 	- some messages have the namespace parameter, and others don't
> 		openid.ns=""
> Proposal:
> 	= All openid protocol parameters start with "openid."
> 	= All messages have the parameter
> 		openid.ns=""
> Benefits:
> 	+ consistent for developers
> 	+ all messages are versioned
> Drawbacks:
> 	- code changes
> _______________________________________________
> specs mailing list
> specs at

More information about the specs mailing list