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@openid.net
http://openid.net/mailman/listinfo/specs
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
