Shibboleth Developers

["Scott Cantor" <>]

> - What about choosing a prefix for all parameters defined in this, or
> future, specs?

Because that would break every 2.x SP I have out there. I'm trying to
standardize something that already exists. I didn't want to go through
another rename unless I had a reason.

> I don't really like the fact that with this model you
> end up with params with and without prefix as part of the spec and
> params without prefixes as not part of the spec.

If I don't, I break compatibility, so I had to make the best of it. As long
as nothing conflicts, it's annoying but not fatal.
 
> I also worry about the
> possibility of name-collisions if the endpoint is expected to transit an
> intermediary that requires a param of the same name (e.g target).  This
> seems pretty unlikely, but maybe not totally outside the realm of the
> possible.

There's no intermediary in scope, but if there was a conflict that
translation step would have to encode the necessary information.

> - For the endpoint in metadata, do you think there is any value in
> allowing child elements that describe the parameters supported by that
> particular endpoint?

I suppose, but one could make the same argument for extension support on
other endpoints. Support for the defined parameters is essentially required,
so it would probably only apply to extensions.
 
> - You should probably explicitly state the behavior of an SP receiving
> params that it does not understand.

Yes, that's true.

-- Scott