Modular+Specs+Soap+Feedback

include component="page" wikiName="siframework" page="ModularSpecTabs" This page is where ONC and Pilot Team members will respond to comments on the final artifacts posted from Modular Specification Pilot Phase 1.

Please note: If viewing this page using Internet Explorer you may need to go to the bottom on the page to scroll left and right to view the last two columns on the right.

ONC Specification Modularization Team ||  || "FOR YOUR INFORMATION: The Underlying Specification List in the Transport and Security Specification document includes the following standards that have not been adopted by the Department of Defense (DoD) or included in the DoD Information Technology Standards Registry (DISR): (XSPA) Profile of Security Assertion Markup Language (SAML) for Healthcare, WS-I Basic Profile v2.0, WS-Policy Attachments, WS-Policy Framework, WS-Reliable Messaging, x.509 Token Profile. || Recommendation: Further coordination needed with the DoD Level Security and Information Assurance Technical Working Group to determine the status of these standards and the implication of the adopting this profile with such standards on DoD Medical IT Systems. ||   || Out of Scope || The basis of the Specifications were Exchange Specifications that have been used by NHIN Exchange trial implementations. Individual organizational policies may necessitate further customization of the specification as needed || ONC Specification Modularization Team ||  || Simple Object Access Protocol (SOAP) is listed, however the various parts of the SOAP standard are not specified. || Please update the underlying specification list with the parts of SOAP that are applicable to this specification. ||  || Under Consideration || Will take this under consideration and anlyze further. || ONC Specification Modularization Team ||  || The underlying specification recommends TLS v 1.0, however TLS v 1.0 is obsolete. || Please update to reflect IETF RFC, 4346 TLS v 1.1. Also specify IETF RFC 5246 TLS v 1.2. ||  || Out of Scope || The versions are currently used by the NHIN Exchange trial implementations. Future versions of these Specification will take this under consideration. || ONC Specification Modularization Team ||  || SAML v1.1 and v2.0 has backward compatibility issues. || Ensure a transition plan is in place and referenced. ||  || Out of Scope || Each organization may need to do their own transition plan to comply with the specifications. || ONC Specification Modularization Team ||  || HITSP constructs are listed and refer to HL7 v2.x and HL7 v3.0 and recommends the implementation of both HL7 v2.x and HL7 v3.0. HL7 v2.x and HL7 v3.0 were not adopted as part of the Standards and Specifications for Meaningful Use. Likewise, there are compatibility issues between these two standards. || Determine which version of the HL7 should be promulgated in the guidance for message formats. ||  || Under Consideration || This will be taken under consideration and anlaysed further. || ONC Specification Modularization Team ||  || Para. 3.3.2.3 indicates AES 128 should be used for x.509 implementation, however X.509 implementation requires the use of FIPS Pub 197. || Update underlying specification list to include FIPS Pub 197. ||  || Accepted || Will be reflected in future versions of the specification. || The transport binding is only enough to declare that the client must use a certificate to authenticate. This requirement can be achieved without Security Policy. Since all signatures are bound to the transport binding, there is only one certificate protecting the transmission. Normally there are two certificates in play, one for transport security and one for message level security (integrity and confidentiality). ||  || Other || Valid comment, but decision made (by collaborative process) to only use transport level certificates. || Underscore prefix requirement for SAML Assertion ID is documented in text, but most examples do not have the underscore prefix. Permalink ||  || Other || Underscores can be added to Assertion ID examples. Examples affected are for Req #s 68, 134, 135, 136, 137, 138, 139, 140, and 215 || a. The Modular Transport identifies potential adaptors to include SMTP, but it is important to know whether the intent is to create a Direct SMTP adaptor to receive and send direct messages and provide an interoperability bridge. b. It is not clear whether the Gateway’s request and deferred request/response services are intended to be interoperable with Connect 2.5.1. c. It is not clear what types of organizations would implement and operate one of these gateway nodes. CDC can conjecture, for example, that it would be useful and logical to have one or several instances operating for the purpose of servicing health departments, and that the public health community should therefore seek to develop and implement these instances. More specificity with respect to the certification criteria and certification process would be very helpful in resolving this question. || Other || a. Adapters can be written to receive and send direct messages to the Gateway and the Gateway to Gateway communication is based on web services. One of the design goals was to provide flexibility to enable the integration of DIRECT with exchange. b. Connect was not in the scope. c.The reference implementation was developed to be independent of any platform or organization type. || MDNs provide a notification of the "disposition" of a message - indicating, for example, whether it is read by a recipient, discarded before being read, etc. However for privacy reasons, and also for backward compatibility, requests for MDNs are entirely advisory in nature - i.e. recipients are free to ignore such requests. The format and usage MDNs are specified in RFC 3798. Therefore, DIRECT can only guarantee that the message has been delivered from HISP to HISP only. The recipient can ignore the request for the read receipt. This question is more relevant to a CONNECT/NwHIN deployment. The XSPA standards are what the VA is heavily involved with and concerns XACML and SAML policies. DIRECT does not use either technology. DIRECT uses signed certificates exchanged between HISPs. The DIRECT community recently approved a certificate policy: http://wiki.directproject.org/Direct+Ecosystem+Community+X.509+Certificate+Policy The Message Disposition Notification (MDN) is the standard that DIRECT uses. It is up to the HISPs to ensure identity and authenticity of users via DIRECT eMail and signed certificates. ||
 * = Comment Submission ||||= ONC Resolution ||
 * = Number ||= Date ||= Artifact ||= Artifact Chapter ||= Existing Wording ||= Proposed Wording ||= Comment ||= Disposition ||= Disposition Comment ||
 * 1 || 8/17/11 || Transport and Security Specification - Version 1.0 - 7/12/2011; Prepared by:
 * 2 || 8/17/11 || Transport and Security Specification - Version 1.0 - 7/12/2011; Prepared by:
 * 3 || 8/17/11 || Transport and Security Specification - Version 1.0 - 7/12/2011; Prepared by:
 * 4 || 8/17/11 || Transport and Security Specification - Version 1.0 - 7/12/2011; Prepared by:
 * 5 || 8/17/11 || Transport and Security Specification - Version 1.0 - 7/12/2011; Prepared by:
 * 6 || 8/17/11 || Transport and Security Specification - Version 1.0 - 7/12/2011; Prepared by:
 * 7 || 9/1/11 || 2. Problem Statement, 2.1 Description ||  ||   || This document helps, but it's not understanding the specs that remains an issue. The SAML token profile seems to be implemented differently in various technology stacks. We had to write "interceptors" in our stack to pull the client certificate up, re-write the incoming message's KeyInfo elements such that they include the entire certificate (as long as the public key matches). We had to do this on our incoming and outgoing NHIN connectors.
 * 8 || 9/1/11 || RTM || Req #44 ||  || Doc referenced WS-Addressing. After checking we found that RelatesTo is a repeating element (thus you could reply to multiple messages simultaneously). We have never seen a web-services stack's support for such a thing. Has this been tested in any web-services stacks yet? ||   || Other || This is an implementation question and not related to specification. ||
 * 9 || 9/1/11 || RTM || Req #48 ||  || This sounds like both requests and responses. It states elsewhere that the SAML will only be in the request. ||   || Other || Will require further analysis. ||
 * 10 || 9/1/11 || RTM || Req #67 Sample ||  || "implementers SHOULD construct this identifier by prepending an underscore character ("_") to a UUID value"
 * 11 || 9/1/11 || Certificate Usage for Transport and Message Layer Security ||  ||   ||   || Certificate for TLS should be different from the ones used for digital signatures and XML encryption. || Other || This is an operational/best practices suggestion, and will be added to Implementation Guidance. ||
 * 12 || 9/1/11 || RTM ||  ||   || Notaion ("Should", "Must", "May") reference. || As in other spec, maybe need to add a statement: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in IETF RFC 2119 [RFC2119].http://tools.ietf.org/html/rfc2119 || Other || Can be added to Section 2.3: Assumptions. Will include in future phases of Modular Specification artifacts as well. ||
 * 13 || 9/15/11 || CDC Response to ONC Modular Transport Gateway # 1 ||  ||   ||   || There isn’t a clear articulation of business context for this Modular Transport Gateway – e.g. what organizations would use it, how they would use it, what use cases drive it. The intent may be that various communities are to develop their own business contexts and map their own use cases to this framework. If that is the case, CDC is interested in helping to lead such an effort within the public health community. || Other || The technical team will be available if there are questions regarding the Transport and Security Reference Implementation. ||
 * 14 || 9/15/11 || CDC Response to ONC Modular Transport Gateway # 2 ||  ||   ||   || CDC very much endorses the overall concept and technical direction. This type of approach and this set of technologies are well suited to the message transport problem domain as experienced by public health and in broad outline is consistent with the direction that CDC and public health departments have proposed. || Other || The technical Team will be available if there are questions regarding the Transport and Security Reference Implementation. ||
 * 15 || 9/15/11 || CDC Response to ONC Modular Transport Gateway # 3 ||  ||   ||   || CDC would have interest in engaging in a pilot effort with one or several health departments, health institutes, HIEs, or other organization types to experiment with this approach and assess how it might be applied in the context of public health messaging use cases. || Other || The technical Team will be available if there are questions regarding the Transport and Security Reference Implementation. ||
 * 16 || 9/15/11 || CDC Response to ONC Modular Transport Gateway # 4 ||  ||   ||   || It is important to more clearly articulate the vision for how this Modular Transport Gateway fits with Connect and Direct. For many groups and organizations, it is very difficult to decide where and how to invest without an understanding of whether and how the various transport methods that have been proposed will work in tandem. Some examples:
 * 17 || 9/15/11 || CDC Response to ONC Modular Transport Gateway # 5 ||  ||   ||   || The XSPA standard points toward NIST 800-63 and Liberty Identity Access Framework (LIAF) standards for ensuring the identity and authenticity of users and organizational deployments. A key issue that needs to be decided is whether there will be an entity responsible for assessing and certifying all nodes’ implementations of these standards, so that nodes can trust each other on the basis of this certification. Or alternatively, whether it will be up to each node to individually establish trust with every other node. || Other || Message Disposition Notifications (MDN)
 * 18 || 9/15/11 || CDC Response to ONC Modular Transport Gateway # 6 ||  ||   ||   || The Connect 2.5 Architecture model represents a Remote Gateway to connect Public Health Systems (Local, State, and National (CDC)) to the Nationwide Health Information Network Connect implementation. Is the Modular Transport envisioned as an implementation of this Remote Gateway? If this is the case, are public health agencies responsible for creating the Pseudonymized Data Warehouse represented on this model. || Other || Yes, Modular Transport also provides a Remote Gateway to connect PHS to the NwHIN. The reference implementation did not develop anything in connection with a data warehouse. ||
 * 19 || 9/15/11 || CDC Response to ONC Modular Transport Gateway # 7 ||  ||   ||   || It is not clear how UDDI and WS-Addressing, within the scope of the Modular Pilot documentation, will provide the interoperability information to exchange requests with other NwHIN Gateways. Will UDDI define the types of content a gateway supports and the specific web service interface to invoke as the initiator of the request, deferred request, or deferred response? It may be that this is well defined in the Connect specifications, in which case specific links to this would be very helpful. || Other || UDDI provides the information about each gateway and the services that it provides, including their endpoints for the Requestors to discover and send requests. ||
 * 20 || 9/15/11 || CDC Response to ONC Modular Transport Gateway # 8 ||  ||   ||   || If multiple Certificate Authorities are anticipated in the future, it would be extremely useful from the government’s point of view if these CAs were cross-certified with the federal PKI Bridge. || Other || Yes, this will be considered in future enhancements of the specification and reference implemenation. ||