[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] draft-sstc-saml-meta-data-01.doc ;draft-sstc-schema-meta-data-01.xsd
>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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC