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

Kevin Turner kevin at janrain.com
Wed Sep 27 17:43:53 UTC 2006


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.





More information about the specs mailing list