Running+History+of+This+Issue

This contains a running historical log of this issue as it is being resolved. Link back to Digital Signatures main page.

2010-07-01: Telephone Meeting. Participants in the call were: Tom Davidson (SSA/Lockheed Martin), Jackie Key (ONC/Deloitte), Wendy Laposata (NCHICA), Tony Mallia (VA/Edmond Scientific Company), John Moehrke (GE/IHE), Jeff Peacock (Kaiser Permanente), David Roberts (Wright State University), Scott Robertson (Kaiser Permanente), Bob Yencha (Alschuler Associates), and Eric Heflin (workgroup lead/Medicity/IHE)

We reviewed and updated the following table (started on the last call). This is still work in process and should not be considered final at this time.

Action Items: 1) Invite the CONNECT team to review the table below to add their knowledge.

(Informative) The NHIN Exchange is currently using SAML to convey identity, and facts about the subject (the subject is the user in this context). Assumption that the requester has performed access control to ensure the end-user or system to confirm that the request is legitimate and authorized from the perspective of the requester. This should not be considered a substitute for an access control decision by the responding gateway or service provider. SAML is being used to convey info, but we are not stating that this is a substitute for a access control decision. In the future we may want to convey the federation of access control decision making. An example of this model is the SSA.

We are asserting the following information, but we are not blindly assuming it will be accepted.


 * **Method** || **Holder-of-Key** || **Sender-Vouches** || **Bearer** ||
 * Complexity of Implementation || High || Moderate || Lowest ||
 * Supports separate IDP from the requesting service || Yes || No (but probably can force it) || Yes ||
 * Allows the use of unsigned SAML assertion || No || Yes || Yes ||
 * Behavior over secure transport || Must sign the timestamp || TBD || TBD ||
 * Behavior of insecure transport || Must sign the entire message || TBD || TBD ||
 * Identity trust relationship || Receiving gateway and asserting authority which can be external to the receiving gateway. || The relying party has a trust relationship with the requester of the service. || Between an IDP and the responding service. ||
 * CONNECT implementation || Claims to support but may not || Actually supports || May be supported ||
 * Supported by NHIN Jan 2010 Production Specs || Implied || Silent || Silent ||
 * Stack support (of SAML 2.0 Assertions) || Yes || May be limits || May be limits ||
 * - Metro support || Yes (low effort?) || Yes (high?) || Yes (high?) ||
 * - Apache Axis2 || No (high effort) || No (high effort) || No (high effort) ||
 * - .NET ||  ||   ||   ||
 * - CrossFire (Metro) ||  ||   ||   ||
 * - Oracle Stack Weblogic ||  ||   ||   ||
 * - IBM WebSphere (Axis2?) ||  ||   ||   ||

2010-06-22: Eric Heflin: Added Tom Davidson's latest research, paraphrased, to this page (immediately below).

The underlying WS-SecurityPolicy and WS-Trust specifications seem to state that XML-DSig is required on SAML Assertion elements for the SAML Holder-Of-Key token profile. This restriction, if confirmed, will likely prevent the NHIN specifications from being modified to remove XML-DSig. It also seems at this point as if WS-Trust requires the support of SAML Holder-Of-Key. One possible option is to add explicit NHIN Exchange support for other SAML profiles that don't apparently require the use of XML-DSig. However, since the NHIN E uses WS-Trust, and WS-Trust requires Holder-Of-Key, that doesnt' achieve the objective of simplifying the NHIN Exchange specifications by eliminating the need for XML-DSig of the SAML Assertion.

A thought has been advanced of removing SAML entirely, and use other means to express SAML-like content, but since that is inconsistent with the NHIN Exchange goal of leveraging applicable standards, this thought will probably not be considered further at this time.

2010-06-25 Eric Heflin/Tom Davidson

Should the NHIN Exchange pick one profile, where the SAML specs state that both should be supported. John M suggests that we should make a distinction between an operation environment and the underlying specifications. The goal of the specs is to enable interoperability. Suggests that we can legitimately constrain the NHIN Exchange to only use one subjectConfirmation method.

Tom D thinks Bearer subjectConfirmation method may be of value.

Holder-of-Key is current NHIN Exchange implied subjectConfirmation method. Most complex model. Attesting for the presence of another certificate. Outstanding issues: Is the cert of the IDP, the gateway, or the subject? When you have individual identities, such as a PIV card, the SAML Token Service can be the card itself. Or, it could be a central authority, or a distributed authority, such as smart cards. A smart card has a private key, and can go to the issuing authority of the smart card that ultimately signs the smart card's token, and the smart card singes the assertion. They key may not come from a single authority, but it ultimately chains to the central authority. This implies that the client would obtain the SAML content, and validate the trust of the IDP and the integrity of the key. One is ultimately validating the signature of the SAML token, and then using PKI to validate that the signature is trust able. In addition, HoK supports Kerberos keys, and other keys besides x.509.

IHE recommends using Bearer as the primary method, and then next Holder-of-Key.

Sender-Vouches: In the SAML assertion, is a 'subject' which is different that the client. The gateway can server as the client, which is the attesting entity, vouches for the subject. Moderately complex.

Bearer: Trust is implicit in the statement. There is an external means that the systems are known to trust each other. Least complex.


 * **Method** || **Holder-of-Key** || **Sender-Vouches** || **Bearer** ||
 * Complexity of Implementation || High || Moderate || Lowest ||
 * Supports separate IDP from the requesting service || Yes || No (but probably can force it) || Yes ||
 * Allows the use of unsigned SAML assertion || No || Yes || Yes ||
 * Behavior over secure transport || Must sign the timestamp || TBD || TBD ||
 * Behavior of insecure transport || Must sign the entire message || TBD || TBD ||

In the presence of a secure transport, Bearer is similar to S-V. With S-V, the assertion was created by the requester of the services. S-V is very close to the current NHIN Exchange model. S-V allows use as Bearer, but also allows for 3rd party ID Provider that creates the assertions.

2010-06-16 Eric Heflin added the following from Tom Davidson, lightly edited.

Regarding CONNECT: Tom reviewed the CONNECT WSDL Policy statements for the PatientDiscovery transaction. For the most part, these align with the messaging specification.

Differences in the CONNECT policy statements:

1) CONNECT has a statement to declare the use of WS-Addressing. This is not in the messaging specification, but it seems reasonable to include it.

2) 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 < is there any disagreement on this point ?>.

3) 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.

The first two policy statements are probably are okay (MustSupportRefKeyIdentifier and MustSupportRefIssuerSerial), it is the third one (RequireSignatureConfirmation), that we may want to talk about. This is an optional policy statement, but when specified, REQUIRES the server to confirm a digital signature back to the client. The interesting thing to note, is that the presence of this policy statement does not appear to influence the digital signature verification step on the server side. At least it doesn't for Axis2. Axis2 will verify all digital signatures in a message, which was one of the items we had a question about. (i.e. - Can a client include a digital signature, without it being declared, and if present will the service/server verify the signature). While I haven't tested the other stacks, as I've been digging into this, I believe this is going to be a yes.

Regarding the declaration of the SubjectConfirmation token type WSDL security statement declaration (holder-of-key, sender-vouches, and bearer): As the production Messaging platform specification reads today, the NHIN has limited the token type to 'holder-of-key' (HoK). This was done by the EndorsingSupportingToken WSDL policy declaration statement in section 3.4.1 of the Messaging Platform specification. Ironically, it is the support of HoK that requires us to digitally sign the Timestamp element in the SOAP Header. Endorsing-Supporting-Tokens are supposed to sign the entire message, however, in the presence of a secure transport (HTTPS), they are supposed to sign the Timestamp element. (This is a requirement, see WS-SecurityPolicy 1.3, Section 8.3, line 2386).

Additional information: - Bearer tokens are considered to be Supporting Tokens, and - Sender Vouches (SV) tokens are Signed Supporting Tokens, where the behavior differs based on the presence of a secure transport.

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.

Additionally, it appears that WS-Trust explicitly contains support for HoK and Bearer. It is also likely to also support SV.

Finally, Tom and Eric both believe that the above, once finalized, should be documented so that future groups understand the justification for various decisions we are making now.

2010-06-07 Eric Heflin added the following thoughts, paraphrased from Tom Davidson:

Tom has proposed that the sub-section on digital assertions needs to be extracted into its own section as guidance on signing the SAML assertion, and that the section on Policy Definition should be promoted into its own section.