Backwards compatibility

Dick Hardt dick at
Mon Sep 25 09:20:22 UTC 2006

On 21-Sep-06, at 11:15 PM, Johannes Ernst wrote:

> Just one specific question:
> On Sep 21, 2006, at 17:22, Dick Hardt wrote:
>> Also, I thought OpenID 2.0 was moving to POST instead of GET, so that
>> will likely cause some incompatibilities.
> I heard this before somewhere, but so far I could not discern the  
> reasoning for it, nor who actually proposes (and agrees with) it.  
> Could you enlighten me?
> So far, I think it would be a very bad idea if OpenID only worked  
> in the context of one of the HTTP REST verbs (of which there are 4,  
> or more if you count WebDAV and other HTTP verbs such as OPTIONS).  
> Admittedly, the OpenID spec so far only talked about GET, but there  
> was nothing to prevent to use it with POST, PUT or DELETE as well.  
> Or any other verbs in HTTP extensions such as WebDAV.
> Is there a proposal on the table to restrict OpenID to be only  
> usable for POST? And if so, what would be the rationale? In the  
> times of AJAX and rich client apps, I think if anything, we should  
> be extending OpenID to cover more verbs, not fewer?
> Confused, as usual ;-)

This was discussed in one of the meetings at VeriSign. Joaquin was  
there, but you were not.

GET of course limits the amount of data that can be transported. POST  
does not have the same payload size constraints. This is needed to do  
attribute exchange as the payloads could get quite large. Switching  
to POST allows the RP and IdP to encode information as parameters in  
the URL and avoid conflicts with protocol parameters. Using one verb  
simplifies development as no logic is needed to decide if GET or POST  
is to be used.

I am not sure what advantage there is to using other verbs. Would you  
elaborate on the advantages? 

More information about the specs mailing list