proposal: consistent message format

Dick Hardt dick at
Fri Sep 22 00:37:13 UTC 2006

Hey Brad, thanks for bringing this part of the discussion our on the  

Sorry to come across nit picky, I'm actually trying to make the spec  
simpler for the average developer to understand by having all  
messages be consistent. These are not critical changs, my view was  
that they made things clearer. To clarify the specifics:

In Draft 9:

	Within Direct communication, there is inconsistency.
	Direct requests start with 'openid.', but do not have the  
'openid.ns' parameter.
	Direct responses don't start with 'openid.'

	Indirect requests and responses both have the namespace 'openid.ns'  

The namespace parameter essentially does versioning for us, making it  
easy for the same entry point to understand multiple message schemas.

Of course you can version later on by adding a 'openid.ns' state to  
direct communication so that a later version of software can detect  
the message, but it makes it harder for an older version to detect it  
has gotten an incorrect message version.

I would not see the OpenID 2.0 spec needing to include the  
differences, would that not be a separate document as it is now?

-- Dick

On 20-Sep-06, at 1:05 PM, Brad Fitzpatrick wrote:

> 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
> compatibility.
> 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