featuritis for existing form handlers (was: Sorting fields in signature generation)

[Dick Hardt]

Hi Kevin

Some background on where support for existing form handlers came from:

The use case is for registration pages to be able to accept a post  
from an IdP without being modified. The registration processing would  
of course not be performing any signature checks and would not need  
to be modified. On the registration page there would be another form  
where the user would type in their IdP/OpenId. There would need to be  
a service that would accept this post, do discovery and forward the  
request to the IdP.

This was simple to do with SXIP 1.0, a little more work with SXIP 2.0  
and a little more challenging with OpenID.

Additionally, as we have researched what is contained in registration  
forms, this use case does not look like it will be that common. Many  
forms have some site specific data, and I am now thinking that this  
is not a very useful feature.

wrt. passthrough data

Many sites preserve state between forms with hidden values. Given  
that registration on a site will likely ask the user for some site  
specific data, some sites will likely be maintaining state through  
hidden fields, and it will be easier for them to integrate OpenID if  
the RP can send values that it gets back later on. Given this is not  
explicitly in the spec, we can write it up. Would welcome feedback on  
passthrough data.

-- Dick




On 27-Sep-06, at 10:43 AM, Kevin Turner wrote:

> Re-writing all your applications every time a new technology pops  
> up is
> not a very efficient use of resources.  New technologies that can
> leverage an existing install base will likely fare better than those
> that demand a completely clean slate.  So I won't argue that existing
> applications are never an important consideration.  However, I don't
> believe the features you're proposing here (pass-through and
> multi-valued parameters) are either beneficial to OpenID or necessary
> for your OpenID application.
>
> As far as I understand it, you want these features to use "existing  
> form
> handlers."  These form handlers have not been written for OpenID.  As
> such, they must not be checking the signature of the submitted  
> data, not
> confirming that it comes from it comes from the user's designated IdP.
> You're going to have to write application-specific submission code for
> each of them, as their parameter names follow no common standard.   
> Why,
> then, should the OpenID specification describe their behavior?  Why
> should the OpenID standard be required to include this set of very
> un-standardized non-OpenID applications?
>
> Your scenario does not sound like OpenID.  It sounds like something
> called "HTML form submission."  We needn't confuse the two.
>
> These changes are not free.  If nothing else, they've cost you the  
> time
> it took to read this message.  They would require adding words to the
> specification which will not reduce its complexity.  And the
> multiple-value changes are not natural to implement in many of the
> environments in which we need to see OpenID implemented.  Granted,  
> that
> may be because PHP has a cripplingly brain-dead method of argument
> processing, but I see the options here as this:
>
> 1) Making a change for the benefit for certain legacy applications,  
> but
> one that will add complexity to all OpenID implementations in PHP,
> Rails, and others.
>
> 2) keeping OpenID practical to implement in the most popular web
> platforms, at the expense of some unknown set of applications which
> don't intend to leverage OpenID's features anyway.
>
> Barry objected when I said you're asking for this feature be "made a
> priority", but making a change to the specification that caters to  
> these
> applications at the expense of implementations in other widely- 
> deployed
> platforms is doing exactly that.
>
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>