Shibboleth Developers

[Chad La Joie <>]

Hey Scott, a few comments:

- What about choosing a prefix for all parameters defined in this, or
future, specs?  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.  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.

- 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?

- You should probably explicitly state the behavior of an SP receiving
params that it does not understand.

On 3/8/10 10:05 PM, Scott Cantor wrote:
> I've been threatening to write this up for a couple of years, finally got
> around to it.
> 
> http://wiki.oasis-open.org/security/RequestInitProtProf
> 
> I renamed it from Session to Request in order to avoid arguments about the
> issue of sessions at an SP, which are generally not part of SSO standards.
> 
> I've included only the most critical parameter options that tend to be
> widely used and are less specific to SAML 2, but designed the proposal's
> extension rules to make the existing Shibboleth implementation conformant.
> 
> -- Scott
> 
> 

-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered