RE: [security-services] draft-sstc-saml-meta-data-01.doc ;draft-sstc-schema-meta-data-01.xsd

[Scott Cantor <cantor.2@osu.edu>]

>2.1.2.1.1 and 2.1.3  (<ds:X.509Certificate> and KeyInfo, respectively)
>I think these should allow a certificate chain, leading to the root. In
>fact, it is more important to have the root than it is to have the actual
>certificate for the source site (SSL will exchange the end-entity
>certificate).

I'd suggest making this an X509Data element, which can contain a chain of X509Certificate elements, and is the standard way to send
a chain.

Should this be X509-specific, though? What about people wanting to use other mechanisms? Is this a concern? Yes, KeyInfo is wide
open, but OTOH...it's wide open...

>2.2. <DestinationSiteList>
>Have we decided that we are not going to support the notion of destination
>site communicating to the source site names of parameters that must be
>preserved during redirection (i.e., Liberty-like <RelayState>?). I know
>there have been discussions about extending the browser profiles themselves
>to communicate this type of data, but I am not convinced that we have
>resolved this.

I guess this is one way to handle this, but I think having a mechanism that doesn't need extra metadata is easier (i.e. RelayState).
A fixed parameter name (or form element in the case of POST) is much better, IMHO.

-- Scott