Digital+Signatures+-+Open+Issues+and+Questions


 * ** Priority ** || ** Issue/Question Description  ** || **Resolution** || ** Type of Issue ** || ** Identified By ** || **Research and Discussion** || **Owner(s)** || **Resolution** || ** Resolution Date ** ||
 * || Is digital signing of SAML assertion required by WS-I? ||  || Research || Tom D ||  In-Progress ||   || TBD || TBD ||
 * || Given the NHIN use of SAML assertions (which are embedded in each request), what are the implications, policy and otherwise, for a replying party trying to verify the identity of an asserting party? ||  || Research || Jamie F ||   ||   ||   ||   ||
 * || What is the NHIN Exchange policy for sun-setting of services? (May be in the DURSA.) ||  || Elevation || Eric H || Closed || Jackie Key || Resolved || 6/25/2010 ||
 * || Is XML-DSig required by any lower level specs or standards for the Timestamp element? ||  || Research || Eric H || In-Progress ||   || TBD || TBD ||
 * || Where should the research findings be documented so that future implementers and NHIN participants can avoid conducting this research? ||  || Discussion || Tom D || In-Progress ||   || TBD || TBD ||
 * || If use of SAML is a policy issue, then how will that impact the current specifications which mandate the use of SAML? ||  || Research || Eric H || Not-Started ||   || TBD || TBD ||
 * || If we drop the use of XML-DSig, or make it optional, then what are the backward compatibility implications? ||  || Research || Tom D || In-Progress ||   || TBD || TBD ||
 * || Can vendor stacks ignore XML-DSig if it is supplied? ||  || Research || Tom D || In-Process ||   || TBD || TBD ||
 * || Should CONNECT's statement declaring the use of WS-Addressing be added to the messaging specification? ||  || Discussion || Tom D || Not-Started ||   || TBD || TBD ||
 * || There are a couple of Metro specific statements for the CONNECT applications Keystore and Truststore access. These are specific to CONNECT and should NOT be included in Messaging platform specification. Need to discuss and determine if there is any disagreement on this assertion? ||  || Discussion || Tom D || Not-Started ||   || TBD || TBD ||
 * || The CONNECT application includes a Wss11 policy statement with 3 options identified (MustSupportRefKeyIdentifier, MustSupportRefIssuerSerial, RequireSignatureConfirmation). The Wss11 policy statement is NOT part of the Messaging platform specification. I believe the specification should be amended to include the statement, however, the use of ALL of the options may want to be discussed. ||  || Discussion || Tom D || Not-Started ||   || TBD || TBD ||
 * || It is possible to support, HoK and SV per the SAML Token Profile specification, but this introduces optionality, and the applicability varies based on the Trust model. Research topic. ||  || Research || Tom D || Not-Started ||   || TBD || TBD ||
 * || Should the NHIN specs be limited to HoK? This represents a divergence from the SAML specifications. Currently the NHIN specs only use HoK. ||  || Discussion || Eric H || In-Process ||   || TBD || TBD ||
 * || Is the SSL with 2-way Mutual Authentication sufficient as far as a trust model? ||  || Discussion || Tom D ||   ||   || TBD || TBD ||
 * || What are our requirements in terms of trust? Are the original security requirements complete and do they reflect our current environment? ||  || Discussion || Tom D ||   ||   || TBD || TBD ||
 * || Complete initial subjectConfirmation comparison/contrast table. ||  || Discussion || Eric H || In-Process || Eric H ||   ||   ||
 * || Obtain the original security requirements document and post on this wiki ||  || Action || Eric H || Complete || Jackie K || 2010-06-25 || 2010-06-25 ||