SAML+Subject+Usage+inside+Evidence+and+Advice+Elements

toc =Issue: **Is a SAML  required inside  and  elements?**=

From Tom: What do other SOAP stacks do in this regard? Do they "agree" with the Microsoft WIF approach or not? Vassil: AFAIK there is no implementation that prevents the proper inclusion of the  element inside  and . Please refer to [|this discussion] on the SAML developers mailing list for a response regarding the requirement to have a  element inside any and every assertion.

.NET - Requires embedded  for their WIF. Does it generate embedded ? When generating an AuthzDecisionStatement, WIF provides the mechanism to add the appropriate Subject. OpenSAML - Does not require embedded . It does not generate them. Does it provide a mechanism to add them? BEA - VA may be using, Tom will check with Tony IBM WebSphere - Eric will ping Karen Metro - Seems not to require or generate embedded subjects. Needs more resh. Tom may be able to help. Apache CXF - RI based initial implementation on CXF. Ann will have the RI team check. JBoss? - One of the feds.

**Sponsor(s)**
S&I Framework Testing Team

**Problem Statement**
The ONC S&I Framework Testing Team has issued a request to the Nationwide Health Information Network Exchange Security and Privacy Team for guidance on a specific use of a SAML  element.

Their question is [authfw-4] "Section 3.3.3.1, Authorization Decision Statement Content, appears to fully prescribe the contents of this element, including an Assertion element. It does not call for a Subject element within the Assertion (although I guess it doesn't rule it out either). In saml-core-2.0-os, lines 1167-1168 say "Assertions containing elements MUST contain a  element". Is this an oversight, or are the rules different for Assertions in this context?"

**Impact**
This is impacting the ability of at least one Nationwide Health Information Network Exchange candidate to pass validation testing. Specifically, the candidate is using .NET and the Windows Identity Framework (WIF) and the WIF is failing because it apparently requires a element below an  statement. The CONNECT implementation is not sending an element.

**Status**
Pending technical review by Microsoft

**Proposed Solution**
TBD

**Proposed Specification Text**
TBD

- Preserves .NET WIF compatibility. || - Would likely require an upgrade of CONNECT and other Nationwide Health Information Network participants. - May be a breaking change for other Nationwide Health Information Network participants. - Will disable the use of assertion references. - May be an additional constraint on SAML. ||  ||
 * === Approach Number (in no particular order) === || === Brief Description === || === Detailed Description === || === Pros === || === Cons === || === Ranking === ||
 * 1 || Modify Nationwide Health Information Network Specs to require the  inside \ and \ elements. || Clarify the specs to make the <Assertion> element required under the <Evidence> and <Advice> attributes. An optional aspect of this proposal is that it may be implemented, potentially, by having CONNECT and other implementations just copy the root <Assertion> / <Subject> element to the <Advice> \ <Assertion> \ <Subject> and <Evidence> \ <Assertion> \ <Subject> elements. || - No changes needed by participant's implementation.
 * 2 || Modify WIF to not require the <Subject> ||  ||   ||   ||   ||
 * 3 || Modify implementation to not use WIF ||  ||   ||   ||   ||

**Next Steps**

 * 1) Review research as noted above.
 * 2) Get Sec and Privacy WG and Spec Factory agreement on the official secondary port to be used for Nationwide Health Information Network Exchange traffic.
 * 3) Revise the messaging platform spec with requested/supported ports.
 * 4) Begin the change process for the revised spec.

**OASIS Communication**
The following letter will be sent to the OASIS Technical Committee responsible for SAML. //*vp Edited to represent the actual issue we (Epic) are seeing. If there is another issue of which I am not aware, please separate it from the one below.//

code All,

As you may be aware, the Nationwide Health Information Network (NHIN) Exchange project has adopted the OASIS SAML 2.0 standard. A question has been brought forth regarding an apparently ambiguous statement in the SAML Core 2.0 specification found at http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf. Prior to asking this question, several of us did extensive research including re-reading every line of the standard, reviewing the mailing list archive, and looking for non-normative clarifying statements from OASIS. Finding none, we are reaching out to you for clarification.

Please note: This is not a theoretical issue: Two organizations have implemented the relevant logic in two different (and incompatible) ways.

Issue: In the SAML Core standard, lines 1167-1168 state "Assertions containing elements MUST contain a element".

Interpretation A (Only one <Subject> element is required): One interpretation is that a SAML Assertion with an <AttributeStatement> element does not need a <Subject> element -inside- any child <Assertion> elements containing the <AttributeStatement>, but that such a SAML Assertion does require a <Subject> element at the root <Assertion>/<Subject> level.

Example:

<Assertion> <Subject> <AttributeStatement> ...  </AttributeStatement> <AuthzDecisionStatement> <Evidence> <Assertion> <AttributeStatement> ...  </AttributeStatement> <AuthzDecisionStatement> <Evidence> <Assertion> <Subject> <saml2:Subject> <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">UID=kskagerb</saml2:NameID> <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"> <saml2:SubjectConfirmationData> <ds:KeyInfo>\ <ds:KeyValue>\ <ds:RSAKeyValue> <ds:Modulus>2TtR9WqJfzbG8oHt9Xq/io6BhwY/dC2rdH3Kp6CBMuaYEw94Ezk1hhGglaBMP+c3MazEMCqNe+qBKvDZWovNavEEJ7tpo4SxY5qPPi6bHMQYExukyiTheMDp3CohSJKQ58IrN7OfQ4nrgZxoSCYi5VLUR7zMqX/zfnjdc81WqJk=</ds:Modulus> <ds:Exponent>AQAB</ds:Exponent> </ds:RSAKeyValue>\ </ds:KeyValue>\ </ds:KeyInfo> </saml2:SubjectConfirmationData> </saml2:SubjectConfirmation> </saml2:Subject> <saml2:AuthnStatement AuthnInstant="2009-04-16T13:15:39.000Z" SessionIndex="987"> <saml2:SubjectLocality Address="158.147.185.168" DNSName="cs.myharris.net" /> <saml2:AuthnContext> <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:X509</saml2:AuthnContextClassRef> </saml2:AuthnContext> </saml2:AuthnStatement> <saml2:AttributeStatement> <saml2:Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:subject-id"> <saml2:AttributeValue xmlns:ns6="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns7="http://www.w3.org/2001/XMLSchema" ns6:type="ns7:string">Karl S Skagerberg</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:organization"> <saml2:AttributeValue xmlns:ns6="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns7="http://www.w3.org/2001/XMLSchema" ns6:type="ns7:string">5am Conformance One - 2.4.8</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:organization-id"> <saml2:AttributeValue xmlns:ns6="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns7="http://www.w3.org/2001/XMLSchema" ns6:type="ns7:string">2.16.840.1.113883.3.596</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute Name="urn:nhin:names:saml:homeCommunityId"> <saml2:AttributeValue xmlns:ns6="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns7="http://www.w3.org/2001/XMLSchema" ns6:type="ns7:string">2.16.840.1.113883.3.596</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute Name="urn:oasis:names:tc:xacml:2.0:subject:role"> <saml2:AttributeValue> <hl7:Role xmlns:hl7="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" code="307969004" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED_CT" displayName="Public Health" xsi:type="hl7:CE" /> </saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:purposeofuse"> <saml2:AttributeValue> <hl7:PurposeForUse xmlns:hl7="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" code="PUBLICHEALTH" codeSystem="2.16.840.1.113883.3.18.7.1" codeSystemName="nhin-purpose" displayName="Use or disclosure of Psychotherapy Notes" xsi:type="hl7:CE" /> </saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute Name="urn:oasis:names:tc:xacml:2.0:resource:resource-id"> <saml2:AttributeValue xmlns:ns6="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns7="http://www.w3.org/2001/XMLSchema" ns6:type="ns7:string">500000000^^^&amp;1.1&amp;ISO</saml2:AttributeValue> </saml2:Attribute> </saml2:AttributeStatement> <saml2:AuthzDecisionStatement Decision="Permit" Resource="https://nhindev.ochin.org/interconnect-dev-ce/wcf/epic.community.hie/xcpdrespondinggatewaysync.svc"> <saml2:Action Namespace="urn:oasis:names:tc:SAML:1.0:action:rwedc">Execute</saml2:Action> <saml2:Evidence> <saml2:Assertion ID="q47df7c0a-ff3e-4b26-baeb-f2910f6d05a9" IssueInstant="2009-04-16T13:10:39.093Z" Version="2.0"> <saml2:Issuer Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">CN=SAML User,OU=Harris,O=HITS,L=Melbourne,ST=FL,C=US</saml2:Issuer>

<saml2:Conditions NotBefore="2009-04-16T13:10:39.093Z" NotOnOrAfter="2009-12-31T12:00:00.000Z" /> <saml2:AttributeStatement> <saml2:Attribute Name="AccessConsentPolicy" NameFormat="http://www.hhs.gov/healthit/nhin"> <saml2:AttributeValue xmlns:ns6="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns7="http://www.w3.org/2001/XMLSchema" ns6:type="ns7:string">urn:oid:1.2.3.4</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute Name="InstanceAccessConsentPolicy" NameFormat="http://www.hhs.gov/healthit/nhin"> <saml2:AttributeValue xmlns:ns6="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns7="http://www.w3.org/2001/XMLSchema" ns6:type="ns7:string">urn:oid:1.2.3.4.123456789</saml2:AttributeValue> </saml2:Attribute> </saml2:AttributeStatement> </saml2:Assertion> </saml2:Evidence> </saml2:AuthzDecisionStatement> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <ds:Reference URI="#3a4edd62-458e-4c3f-adc0-a9b505cb6284"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <ds:DigestValue>KElC8xKgWPsC44A0gYevSMxXT1A=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>jC5anw7eDUZgNVG3JxxdxcMOQheYPhtJPHHceAcYOOserWV45jlblHXeqsL4MGsJl2no+JVKavL+\ cinn6+tubeJD4cpWhDHbXsOc2u1cpYTbCe+Hd1JzHpnBTr+heT/gaJV8CrwPHFXp6MojrqFrCtKA\ XpUnxkP6pKPZqfB50/E=</ds:SignatureValue> <ds:KeyInfo> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus>2TtR9WqJfzbG8oHt9Xq/io6BhwY/dC2rdH3Kp6CBMuaYEw94Ezk1hhGglaBMP+c3MazEMCqNe+qB\ KvDZWovNavEEJ7tpo4SxY5qPPi6bHMQYExukyiTheMDp3CohSJKQ58IrN7OfQ4nrgZxoSCYi5VLU\ R7zMqX/zfnjdc81WqJk=</ds:Modulus> <ds:Exponent>AQAB</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue> </ds:KeyInfo> </ds:Signature> </saml2:Assertion> <ds:Signature xmlns:ns17="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" xmlns:ns16="http://schemas.xmlsoap.org/soap/envelope/" Id="_2"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <exc14n:InclusiveNamespaces PrefixList="wsse S" /> </ds:CanonicalizationMethod> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <ds:Reference URI="#_1"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <exc14n:InclusiveNamespaces PrefixList="wsu wsse S" /> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <ds:DigestValue>Nhen2R5LULNX2vPaft7QdfcTNaA=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>XGckyz/m5882yot6dkPDPC1MHcJyYjF1kd41pFXwKvRzvkx8A9euTgurvxyXwTpvfwCG4dB89J45aC20gvqdcEGoPzhjDFZAJFnsABobTTYivgNgPdc3aKlzQOhsKzrl5r7lTZBzLp/6lcR9PDqObP1bTw4RsVXsnKT+BhpfSYQ=</ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference wsse11:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"> <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID">3a4edd62-458e-4c3f-adc0-a9b505cb6284</wsse:KeyIdentifier> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </S:Header> <S:Body> <PRPA_IN201305UV02 xmlns="urn:hl7-org:v3" xmlns:ns2="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:ns3="urn:gov:hhs:fha:nhinc:common:nhinccommon" xmlns:ns4="urn:gov:hhs:fha:nhinc:common:patientcorrelationfacade" ITSVersion="XML_1.0"> <id extension="-5a3e95b1:11d1fa33d45:-7f9b" root="1.1"/> <creationTime value="20101450084800"/> <interactionId extension="PRPA_IN201305UV02" root="2.16.840.1.113883.1.6"/> <processingCode code="T"/> <processingModeCode code="I"/> <acceptAckCode code="AL"/> <receiver typeCode="RCV"> <device determinerCode="INSTANCE" classCode=""> <id root="1.2.345.678.999"/> <asAgent classCode="AGNT"> <representedOrganization determinerCode="INSTANCE" classCode="ORG"> <id root="2.16.840.1.113883.3.346"/> </representedOrganization> </asAgent> <sender typeCode="SND"> <device determinerCode="INSTANCE" classCode="DEV"> <id root="2.16.840.1.113883.3.596"/> <asAgent classCode="AGNT"> <representedOrganization determinerCode="INSTANCE" classCode="ORG"> <id root="2.16.840.1.113883.3.596"/> </representedOrganization> </asAgent> <controlActProcess moodCode="EVN" classCode="CACT"> <authorOrPerformer typeCode="AUT"> <assignedDevice classCode=""> <id root="2.16.840.1.113883.3.596"/> </assignedDevice> </authorOrPerformer> <queryByParameter> <queryId extension="-abd3453dcd24wkkks545" root="2.2"/> <statusCode code="new"/> <responseModalityCode code="R"/> <responsePriorityCode code="I"/> <parameterList> <livingSubjectAdministrativeGender> <value code="M"/> <semanticsText representation="TXT"/> </livingSubjectAdministrativeGender> <livingSubjectBirthTime> <value operator="I" value="19600210"/> <semanticsText representation="TXT"/> </livingSubjectBirthTime> <livingSubjectId> <value assigningAuthorityName="" extension="N600002" root="2.16.840.1.113883.3.596"/> <semanticsText representation="TXT"/> </livingSubjectId> <livingSubjectName> <given partType="GIV">Robert <given partType="GIV">M <family partType="FAM">Carson \ <semanticsText representation="TXT"/> </livingSubjectName> </parameterList> </queryByParameter> </controlActProcess> </PRPA_IN201305UV02> </S:Body> </S:Envelope>

Longer Example of Interpretation B

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <s:Header> <a:Action s:mustUnderstand="1" >urn:hl7-org:v3:PRPA_IN201305UV02:CrossGatewayPatientDiscovery</a:Action> <a:MessageID>urn:uuid:fbf307ad-a89a-4a6e-87fc-19c054d945ca</a:MessageID> <a:ReplyTo> <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address> </a:ReplyTo> <a:To s:mustUnderstand="1" >https://vs-proxytest.epicsys.com/interconnect-ic-neo-sydney/wcf/epic.community.hie/xcpdrespondinggatewaysync.svc</a:To> <a:From a:IsReferenceParameter="true"> <a:Address>urn:epic:cec.iu77qa</a:Address> </a:From> <o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> <u:Timestamp u:Id="_0"> <u:Created>2011-01-04T20:54:35.846Z</u:Created> <u:Expires>2011-01-04T20:59:35.846Z</u:Expires> </u:Timestamp> <Assertion ID="_25ce5d60-f5cb-45f5-9d63-62216752a828" IssueInstant="2011-01-04T20:54:35.768Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion"> <Issuer>EpicSTS</Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#_25ce5d60-f5cb-45f5-9d63-62216752a828"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:DigestValue>laMFGDQ2S4bKqbCxqSMhWlIkno8=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>vnIVr85jneVo5G3zeKVYlMci4QiLZPcdqy7hsW/EeoPyT/PB8brT0Xn39R6cL4jCOn/6oTomWREfdx4q4m+gYaLMQu0vdyRYbY5roW0Q/rWugabQ4qH/r8CTZ7j8vWwb2zd0iDOFJADNeMbdg+1/IBY/MAQeci+OIsZfMI0Rrkg=</ds:SignatureValue> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <X509Data> <X509Certificate>MIICvTCCAaWgAwIBAgICAUYwDQYJKoZIhvcNAQEFBQAwPTELMAkGA1UEBhMCVVMxEDAOBgNVBAMMB25oaW4tY24xDTALBgNVBAoMBE5ISU4xDTALBgNVBAsMBG5oaW4wHhcNMDkwMTAxMDAwMDAwWhcNMTcxMjIxMDAwMDAwWjCBiTELMAkGA1UEBhMCVVMxEjAQBgNVBAgTCVdpc2NvbnNpbjEPMA0GA1UEBxMGVmVyb25hMQ0wCwYDVQQKEwRFcGljMQwwCgYDVQQLEwNFREkxGDAWBgNVBAMTD0p1c3RpbiBTdGF1ZmZlcjEeMBwGCSqGSIb3DQEJARYPanVzdGluQGVwaWMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDJ7WKd30y5JV8NL1icPVt3YU0lNQ8UeXLCoFxPAB5ky/WEl1V55GJFSlKusUjdegDKzjujClH3DA7cqZXYjfU7KHqxBz+OItozspFBx9sW5EHw2ziF+gDfAj6iEvw/QF1TfciKa5zYUZtXer3BFI+i2hkeEprXnLVazdy3njX43wIDAQABMA0GCSqGSIb3DQEBBQUAA4IBAQA25oNy2d7t+8MQoFERBVSGoekwy5TG4+KOITZfKP3YA8qZ1OMYOTpkYR6Ee72usZuIuZxvphV4a6uC/1vCoyHfCj38hl6QOhKQoeo7dmtC4h5ttqfQAStXP+ljc1nV50y4pbJdbITd9INGu+KuT9ZYNqnwGSv87XCkLOsI3xPXNUn5Afr/phimZGAyIC6zsczoPt2GwaX66FqOU41ivA5mDusLBW3O66yPd/oJgD52YxutRVk4TaeUrcVtWfrLP/eLqnbEwNwOBp1lyoTVSQBjvrHeVE7PrbMehxkON6oemS+sJIOE2ws0xeCHVCe1NTU45V4U05Usw8TKHTtPyAQ4</X509Certificate> </X509Data> </KeyInfo> </ds:Signature> <Subject> <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"> <SubjectConfirmationData a:type="KeyInfoConfirmationDataType" xmlns:a="http://www.w3.org/2001/XMLSchema-instance"> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <trust:BinarySecret xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512" >VTIiZlUDXDM1znF1Aameb4GVLIlcBuxK2MAQB+BUq/M=</trust:BinarySecret> </KeyInfo> </SubjectConfirmationData> </SubjectConfirmation> </Subject> <Conditions NotBefore="2011-01-04T20:54:34.362Z" NotOnOrAfter="2011-01-04T21:54:34.362Z"> <AudienceRestriction> <Audience>https://vs-proxytest.epicsys.com/interconnect-ic-neo-sydney/wcf/epic.community.hie/xcpdrespondinggatewaysync.svc</Audience> </AudienceRestriction> </Conditions> <AttributeStatement> <Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:subject-id" a:OriginalIssuer="EpicSTS" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue>Epic User</AttributeValue> </Attribute> <Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:organization" a:OriginalIssuer="EpicSTS" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue>Summer 09 IU/SU QA Community</AttributeValue> </Attribute> <Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:organization-id" a:OriginalIssuer="EpicSTS" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue>urn:epic:cec.iu77qa</AttributeValue> </Attribute> <Attribute Name="urn:nhin:names:saml:homeCommunityId" a:OriginalIssuer="EpicSTS" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue>urn:epic:cec.iu77qa</AttributeValue> </Attribute> <Attribute Name="urn:oasis:names:tc:xacml:2.0:subject:role" a:OriginalIssuer="EpicSTS" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue> <Role code="PHYSICIAN" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"/> </AttributeValue> </Attribute> <Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:purposeofuse" a:OriginalIssuer="EpicSTS" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue> <PurposeForUse code="TREATMENT" codeSystem="2.16.840.1.113883.3.18.7.1" codeSystemName="nhin-purpose" displayName="Treatment" xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"/> </AttributeValue> </Attribute> <Attribute Name="urn:oasis:names:tc:xacml:2.0:resource:resource-id" a:OriginalIssuer="EpicSTS" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue>SD90108500^^^&amp;1.2.840.114350.1.13.77&amp;ISO</AttributeValue> </Attribute> <Attribute Name="urn:oasis:names:tc:xspa:2.0:subject:npi" a:OriginalIssuer="EpicSTS" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue/> </Attribute> <Attribute Name="http://www.hhs.gov/healthit/nhin:InstanceAccessConsentPolicy" a:OriginalIssuer="EpicSTS" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue>EPICTESTINSTANCEACCESSCONSENTPOLICY</AttributeValue> </Attribute> </AttributeStatement> <AuthzDecisionStatement Decision="Permit" Resource="http://localhost/test"> <Action Namespace="http://epic.com/saml2actions/test">FullControl</Action> <Evidence> <Assertion ID="_f541cab-19fd-4657-8643-12fffc1e6059" IssueInstant="2011-01-04T20:54:35.768Z" Version="2.0"> <Issuer Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">E=justin@epic.com, CN=Justin Stauffer, OU=EDI, O=Epic, L=Verona,S=Wisconsin, C=US</Issuer>

<Subject> <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">CN=MAP</NameID> </Subject> <AttributeStatement> <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/thumbprint" a:OriginalIssuer="STS_EPIC9802" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue b:type="tn:base64Binary" xmlns:b="http://www.w3.org/2001/XMLSchema-instance" xmlns:tn="http://www.w3.org/2001/XMLSchema" >1FYgmPGsiQbZ2JDg1h8U9lA5qgs=</AttributeValue> </Attribute> <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/x500distinguishedname" a:OriginalIssuer="STS_EPIC9802" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue>E=justin@epic.com, CN=Justin Stauffer, OU=EDI, O=Epic, L=Verona, S=Wisconsin, C=US</AttributeValue> </Attribute> <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dns" a:OriginalIssuer="STS_EPIC9802" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue>Justin Stauffer</AttributeValue> </Attribute> <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" a:OriginalIssuer="STS_EPIC9802" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue>Justin Stauffer</AttributeValue> </Attribute> <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" a:OriginalIssuer="STS_EPIC9802" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue>justin@epic.com</AttributeValue> </Attribute> <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/rsa" a:OriginalIssuer="STS_EPIC9802" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue b:type="tn:RSAKeyValue" xmlns:b="http://www.w3.org/2001/XMLSchema-instance" xmlns:tn="http://www.w3.org/2000/09/xmldsig"> <RSAKeyValue xmlns=""> <Modulus>ye1ind9MuSVfDS9YnD1bd2FNJTUPFHlywqBcTwAeZMv1hJdVeeRiRUpSrrFI3XoAys47owpR9wwO3KmV2I31Oyh6sQc/jiLaM7KRQcfbFuRB8Ns4hfoA3wI+ohL8P0BdU33Iimuc2FGbV3q9wRSPotoZHhKa15y1Ws3ct541+N8=</Modulus> <Exponent>AQAB</Exponent> </RSAKeyValue> </AttributeValue> </Attribute> <Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/serialnumber" a:OriginalIssuer="STS_EPIC9802" xmlns:a="http://schemas.xmlsoap.org/ws/2009/09/identity/claims"> <AttributeValue>0146</AttributeValue> </Attribute> </AttributeStatement> </Assertion> </Evidence> </AuthzDecisionStatement> </Assertion> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/> <Reference URI="#_0"> <Transforms> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>fZcN06d4n5WcevXPfpUAWs4Jmwk=</DigestValue> </Reference> </SignedInfo> <SignatureValue>2KiiBu81iQU08dh+A17ceeLITrM=</SignatureValue> <KeyInfo> <o:SecurityTokenReference k:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0" xmlns:k="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"> <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID" >_25ce5d60-f5cb-45f5-9d63-62216752a828</o:KeyIdentifier> </o:SecurityTokenReference> </KeyInfo> </Signature> </o:Security> </s:Header> <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <PRPA_IN201305UV02 xmlns="urn:hl7-org:v3"> <id root="1.2.840.114350.1.13.77002.1.7.2.696777" extension="71699"/> <creationTime value="20110104145429-0600"/> <interactionId root="2.16.840.1.113883.1.6" extension="PRPA_IN201305UV02"/> <processingCode code="P"/> <processingModeCode code="T"/> <acceptAckCode code="NE"/> <receiver typeCode="RCV"> <device classCode="DEV" determinerCode="INSTANCE"> <id root="1.2.840.114350.1.13.77002.1.7.2.688879" extension="841"/> <sender typeCode="SND"> <device classCode="DEV" determinerCode="INSTANCE"> <id root="1.2.840.114350.1.13.77002.1.7.2.688879" extension="900"/> <asAgent classCode="AGNT"> <representedOrganization classCode="ORG" determinerCode="INSTANCE"> <id root="urn:epic:cec.iu77qa"/> </representedOrganization> </asAgent> <controlActProcess classCode="CACT" moodCode="EVN"> <authorOrPerformer typeCode="AUT"> <assignedDevice> <id root="urn:epic:cec.iu77qa"/> </assignedDevice> </authorOrPerformer> <queryByParameter> <queryId root="d230ac58-1844-11e0-b20c-002481e4b4aa"/> <responseModalityCode code="R"/> <responsePriorityCode code="I"/> <parameterList> <livingSubjectName> Sydney One Jjs <semanticsText>LivingSubject.Name</semanticsText> </livingSubjectName> <livingSubjectAdministrativeGender> <value code="M"/> <semanticsText>LivingSubject.administrativeGender</semanticsText> </livingSubjectAdministrativeGender> <livingSubjectBirthTime> <semanticsText>LivingSubject.birthTime</semanticsText> </livingSubjectBirthTime> <patientAddress> <streetAddressLine>2910 Riverbend Trail</streetAddressLine> MADISON WI                                <postalCode>53719</postalCode> US                            <semanticsText>Patient.addr</semanticsText> </patientAddress> <livingSubjectId> <value root="2.16.840.1.113883.4.1" extension="439-28-4932"/> <semanticsText>LivingSubject.id</semanticsText> </livingSubjectId> <patientTelecom> <value use="HP">tel:608-271-9999 <semanticsText>Patient.telecom</semanticsText> </patientTelecom> </parameterList> </queryByParameter> </controlActProcess> </PRPA_IN201305UV02> </s:Body> </s:Envelope>

code

**Annotated References**
http://cs.metrostate.edu/~ics625s913/p52-saklikar.pdf http://markmail.org/message/oszdnbmxhaqlhni4 http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf http://www.oasis-open.org/committees/security/docs/draft-sstc-core-discussion-00.doc

http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd http://saml.xml.org/saml-2-0-enhancements

To Do
More research needs to be done on the SAML token profiles and the Nationwide Health Information Network AF to make sure it doesn't introduce any additional constraints. Need sample messages (positive and negative) Confirm that this is a defect in WIF

Tentative Conclusion
The <Subject> element is not required inside the optional <Assertion> element inside an <Advice> or an <Evidence> element.

Alternative Conclusion
The OASIS specification is vague in the textual description. It has been interpreted that indeed a <Subject> element is required below any <Assertion> element that contains one of <AuthnStatement>, <AuthzDecisionStatement>, or <AttributeStatement>.

Research
Referencing: http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

There must be exactly one subject (the "Principal" which is the person or system about which assertions are being made) that should be referenced for the entire SAML <Assertion>. However, the <Subject> -element- can indeed occur multiple times, all optionally, in the same SAML <Assertion>. However, this should not be construed to mean that there is more than one principal of the assertion. There only can ever be a single principal of a single SAML assertion. The alternative <Subject> elements, which are allowed in <Assertion> elements inside the <Evidence> and <Advice> elements, are intended to suffice as evidence for the justification for the reason the SAML provider elected to create this specific <Assertion>, they are not intended to to provide alternate principals for the assertion. These elements, are optional. Thus the conclusion is that the <Subject> is indeed allowed at three different XPath locations inside a single <Assertion> however all three of these uses of a <Subject> element are optional as per the schema, and the rationale below.

Paragraphs below starting with a number, are direct quotes from the above OASIS specification. Paragraphs starting with an "ejh" are my comments.

code 223 The Security Assertion Markup Language (SAML) defines the syntax and processing semantics of assertions made about a subject by a system entity. In the course of making, or relying upon such assertions, SAML system entities may use other protocols to communicate either regarding an assertion itself, or the subject of an assertion. code

ejh: Note that "subject" is used in the singular form implying that there is only a single subject of an assertion.

code 346 SAML assertions are usually made about a subject, represented by the <Subject> element. However, the <Subject> element is optional, and other specifications and profiles may utilize the SAML assertion structure to make similar statements without specifying a subject, or possibly specifying the subject in an alternate way. code

ejh: Note that <Subject> element is optional (this allows a subject to be identified via other mechanisms). This is the reason that lines 1277 state <Subject> is required, conditionally, if an <AuthzDecisionStatement> is used.

code 547 2.3.3 Element <Assertion> The <Assertion> element is of the AssertionType complex type. This type specifies the basic information that is common to all assertions, including the following elements and attributes: code

ejh: I interpret this to mean that the <Assertion> element contains information that is applicable to all subsequent statements in the same SAML assertion.

code 567 <Subject> [Optional] The subject of the statement(s) in the assertion. code

ejh: A <Subject> is only allowed directly under an <Assertion> element. Also, the root <Assertion>\<Subject> element it is used to provide the single subject of ALL statements in the assertion.

code 588 Otherwise <Subject>, if present, identifies the subject of all of the statements in the assertion. If <Subject> is omitted, then the statements in the assertion apply to a subject or subjects identified in an application- or profile-specific manner. code

ejh: Note that the Nationwide Health Information Network doesn't use any profiles to change the use of <Subject>. Thus this statement in the OASIS spec conclusively indicates that there is one <Subject> and it applies to all statements in the assertion.

code 607 The following schema fragment defines the <Assertion> element and its AssertionType complex type: code

code format="xml" <element name="Assertion" type="saml:AssertionType"/>

<complexType name="AssertionType"> <element ref="saml:Issuer"/> <element ref="ds:Signature" minOccurs="0"/> <element ref="saml:Subject" minOccurs="0"/> <element ref="saml:Conditions" minOccurs="0"/> <element ref="saml:Advice" minOccurs="0"/> <choice minOccurs="0" maxOccurs="unbounded"> <element ref="saml:Statement"/> <element ref="saml:AuthnStatement"/> <element ref="saml:AuthzDecisionStatement"/> <element ref="saml:AttributeStatement"/> <attribute name="Version" type="string" use="required"/> <attribute name="ID" type="ID" use="required"/> <attribute name="IssueInstant" type="dateTime" use="required"/> </complexType> code

ejh: This is the only place in the SAML 2.0 schema allowing the <Subject> element. Further, and consistent, evidence that a <Subject> element is allowed only inside a <Assertion> element.

code 647 2.4.1 Element <Subject> The optional <Subject> element specifies the principal that is the subject of all of the (zero or more) statements in the assertion. code

ejh: More text indicating that only a single principal <Subject> is expected.

code 664 A <Subject> element SHOULD NOT identify more than one principal. code

ejh: Not definitive, but indicates that there should only be a single principal <Subject>.

code 1277 The <AuthzDecisionStatement> element describes a statement by the SAML authority asserting that a request for access by the assertion subject to the specified resource has resulted in the specified authorization decision on the basis of some optionally specified evidence. Assertions containing <AuthzDecisionStatement> elements MUST contain a <Subject> element. code

ejh: This does not mean that <Subject> is a sub element of <AuthzDecisionStatement>, just that, as per the schema, the SAML assertion <Assertion><Subject> element must occur if <AuthzDecisionStatement> is used. The topic of the sentence is the SAML <Assertion>, NOT the <AuthzDecisionStatement>s.

code 1318 The following schema fragment defines the <AuthzDecisionStatement> element and its AuthzDecisionStatementType complex type: code

code format="xml" <element name="AuthzDecisionStatement" type="saml:AuthzDecisionStatementType"/>

<complexType name="AuthzDecisionStatementType"> <complexContent> <extension base="saml:StatementAbstractType"> <element ref="saml:Action" maxOccurs="unbounded"/> <element ref="saml:Evidence" minOccurs="0"/> <attribute name="Resource" type="anyURI" use="required"/> <attribute name="Decision" type="saml:DecisionType" use="required"/> </complexContent> </complexType> code

ejh: Note that <Subject> is not allowed directly within <AuthzDecisionStatement> elements as per the above schema, but an <Evidence> element is allowed. And, an <Assertion> or assertion reference is allowed directly under the <Evidence> element. If an <Assertion> is used under an <Evidence> element, then that <Assertion> is allowed to have a <Subject>.

ejh: The above citations from the authoritative text on the subject clearly establish that: 1) there is a single principal <Subject> of a SAML <Assertion>. 2) The <Subject> is optional. 3) If the <Subject> is used, it must only exist inside the <Assertion> element. 4) If an optional <AuthzDecisionStatement> is used, then the <Subject> may be also specified.

ejh: Putting this all together allows us to issue a statement that for Nationwide Health Information Network Exchange SAML purposes, that "if the optional <AuthzDecisionStatement> element is used and an optional <AuthzDecisionStatement>\<Evidence> element is used, and the <AuthzDecisionStatement>\<Evidence>\<Assertion> element is used, then the <Subject> SHOULD be also specified inside the <AuthzDecisionStatement>\<Evidence>\<Assertion> element."

From the schema found at:

http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd

code format="xml" <complexType name="AdviceType"> <choice minOccurs="0" maxOccurs="unbounded"> <element ref="saml:AssertionIDRef"/> <element ref="saml:AssertionURIRef"/> <element ref="saml:Assertion"/> <element ref="saml:EncryptedAssertion"/> <any namespace="##other" processContents="lax"/> </complexType> code

and

code format="xml" <complexType name="EvidenceType"> <choice maxOccurs="unbounded"> <element ref="saml:AssertionIDRef"/> <element ref="saml:AssertionURIRef"/> <element ref="saml:Assertion"/> <element ref="saml:EncryptedAssertion"/> </complexType> code

ejh: You'll note that the saml:Assertion element is allowed, recursively, inside both of these elements.

code 1021 Following are some potential uses of the <Advice> element: • Include evidence supporting the assertion claims to be cited, either directly (through incorporating the claims) or indirectly (by reference to the supporting assertions). code

ejh: Thus the <Advice> element can contain a nested <Assertion>.

code 1026 The following schema fragment defines the <Advice> element and its AdviceType complex type: code

code format="xml" <element name="Advice" type="saml:AdviceType"/>

<complexType name="AdviceType"> <choice minOccurs="0" maxOccurs="unbounded"> <element ref="saml:AssertionIDRef"/> <element ref="saml:AssertionURIRef"/> <element ref="saml:Assertion"/> <element ref="saml:EncryptedAssertion"/> <any namespace="##other" processContents="lax"/> </complexType> code

code 1373 2.7.4.3 Element <Evidence> The <Evidence> element contains one or more assertions or assertion references that the SAML authority relied on in issuing the authorization decision. It has the EvidenceType complex type. It contains a mixture of one or more of the following elements: <AssertionIDRef> [Any number] Specifies an assertion by reference to the value of the assertion’s ID attribute. <AssertionURIRef> [Any number] Specifies an assertion by means of a URI reference. <Assertion> [Any number] Specifies an assertion by value. <EncryptedAssertion> [Any number] Specifies an encrypted assertion by value. code

ejh: The <Evidence> element may contain a nested (recursive) <Assertion>.

code 1390 The following schema fragment defines the <Evidence> element and its EvidenceType complex type: code

code format="xml" <element name="Evidence" type="saml:EvidenceType"/>

<complexType name="EvidenceType"> <choice maxOccurs="unbounded"> <element ref="saml:AssertionIDRef"/> <element ref="saml:AssertionURIRef"/> <element ref="saml:Assertion"/> <element ref="saml:EncryptedAssertion"/> </complexType> code

ejh: This establishes that the <Evidence> and <Advice> elements can indeed contain nested <Assertions> as per SAML core.

code 1166 The <AttributeStatement> element describes a statement by the SAML authority asserting that the assertion subject is associated with the specified attributes. Assertions containing <AttributeStatement> elements MUST contain a <Subject> element. code

jl/ejh/td: This is the crux of the problem. It is ambiguous, and thus people have interpreted this in different ways. Interpretation 1) An <AttributeStatement> must have a <Subject> element **within** the <AttributeStatement>. Interpretation 2) Use of an <AttributeStatement> requires that a root-level <Assertion>\<Subject> element must be specified.

vp: Disagree that the statement starting at line 1166 is ambiguous in any way. The <AttributeStatement> element is part of only one assertion, as it can only occur within an assertion. I can't find any language about inheritance of subjects within an assertion, and I think the explicit language (which is also repeated for AuthnStatement and AuthzDecisionStatement) is intended to remove any ambiguity, rather than cause it.

jl: (Content needs to be integrated into the above. ) My alternate reading is based on how an implementer would read it: 1. The schema defines the AttributeStatement element and Subject element as optional child elements of Assertion. 2. SAML core Section 2.7.3: Element <AttributeStatement> provides semantics and further constraints for this element, effectively defining a type. By that I mean this definition should hold wherever AttributeStatement occurs, unless there is an explicit redefinition somewhere. This allows implementers to easily code up all constraints. 3. Lines 1167-8: "Assertions containing <AttributeStatement> elements MUST contain a <Subject> element" means: - If Assertion/AttributeStatement is present - Then Assertion/Subject must be present 4. As this defines a type, the below would follow: - If Assertion/AuthzDecisionStatement/Evidence/Assertion/AttributeStatement is present - Then Assertion/AuthzDecisionStatement/Evidence/Assertion/Subject must be present

In my opinion, the Tentative Conclusion rests entirely on tackling SAML core lines 1167-8. I see two possible ways: 1. Cite an explicit redefinition that removes the constraint in lines 1167-8 for some conditions that the Nationwide Health Information Network Exchange usage satisfies. 2. Assert that lines 1167-8 can be interpreted more flexibly, e.g. - If Assertion/AuthzDecisionStatement/Evidence/Assertion/AttributeStatement is present - Then Assertion/Subject or Assertion/AuthzDecisionStatement/Evidence/Assertion/Subject (either/or because they represent the same identity) must be present

**Intent (Soft Factors)**
Some have made the argument that it may have been the intent of OASIS to require a <Subject> element below <Advice> and <Evidence> elements. To this point, I reviewed OASIS discussions on the topic, and a wide variety industry and academic papers, discussions, and documentation. All of this empirical research clearly stated that the <Advice> and <Evidence> elements are optional and can carry either an assertion, or an assertion reference.

__Academic Sources__

See Section 5.1 in this representative academic paper, where the author group explicitly mentions than they expect an <Evidence>\<Assertion> either being a direct assertion, or an assertion reference.

http://cs.metrostate.edu/~ics625s913/p52-saklikar.pdf

"In addition to the existing elements, it proposes the presence of an EvidenceType element, which enables carrying a set of Assertions or Assertion references. Thus, the AP can validate the Assertions presented as Evidence and based on that issue an appropriate Assertion, in response to the AssertionRequest"

and

"The SAML-Advice element already allows carrying Assertion or references, as an evidence of claims which are cited. Thus, this element is most appropriate for carrying the Assertions (or their reference) which were presented in the AssertionRequest. Based on the presence or absence of the AuthnStatement as well as the Advice element, the RP can conclude on what basis (Authentication or another set of Assertions) this Assertion was issued."

__From OASIS Discussions__

An OASIS email archived discussion at http://markmail.org/message/oszdnbmxhaqlhni4 Establishes that the intent for a <Advice> or <Evidence> is to be a ref to a complete assertion, or the assertion itself. HOWEVER, both are optional.

A very early OASIS draft schema document http://www.oasis-open.org/committees/security/docs/draft-sstc-core-discussion-00.doc states:

229 "The optional <Advice> element is an “any” container. Basically you can put any number of arbitrary well-formed XML documents into this container."

and an example on line 605 shows that <Evidence> elements doesn't need a <Subject>.

<span style="background-color: #ffff99; border: 1pt solid windowtext; display: block; margin: 0px; padding: 0px;"><Evidence> <span style="background-color: #ffff99; border: 1pt solid windowtext; display: block; margin: 0px; padding: 0px;"><AssertionID>{EE52CAF4-3452-4ebe-84D3-4D372C892A5D}</AssertionID> <span style="background-color: #ffff99; border: 1pt solid windowtext; display: block; margin: 0px; padding: 0px;"></Evidence> <span style="background-color: #ffff99; border: 1pt solid windowtext; display: block; margin: 0px; padding: 0px;"></Assertion>

This demonstrates that a <Subject> is not required below <Advice> or <Evidence> elements as per interpretation by both OASIS and the broader industry. As mentioned above, the SAML schema clearly allows a <Subject> element to be omitted in <Assertion>, <Advice> and <Evidence> elements.

__Microsoft Windows Identity Framework Interpretation (Added by SKathol - Epic)__ skathol: The error message below is generated in the context of reading the SAML2 Assertion element:

--ID4119: The SAML2:AuthenticationStatement, AttributeStatement, and AuthorizationDecisionStatement require a SAML2:Subject. at Microsoft.IdentityModel.Tokens.Saml2.Saml2SecurityTokenHandler.ReadAssertion(XmlReader reader) at Microsoft.IdentityModel.Tokens.Saml2.Saml2SecurityTokenHandler.ReadEvidence(XmlReader  reader) at Microsoft.IdentityModel.Tokens.Saml2.Saml2SecurityTokenHandler.ReadAuthorizationDecisionStatement(XmlReader  reader) at Epic.RelyingPartyTokenHandler.EpicSaml2SecurityTokenHandler.ReadAuthorizationDecisionStatement(XmlReader  reader)

In my opinion, the error does not provide enough information to fully diagnose the error, but it does make sense in the context of line 1166-1168 of the OASIS SAML2 specs: code 1166 The <AttributeStatement> element describes a statement by the SAML authority asserting that the assertion subject is associated with the specified attributes. Assertions containing <AttributeStatement> elements MUST contain a <Subject> element. code

Per our discussions with Abhuday from Microsoft, WIF does not have flexibility to ignore this requirement. The only alternative is to code SAML security checks directly into our WCF service.

To do: Need to see if Nationwide Health Information Network or SAML profiles like holder-of-key constrain it further.

To do: What does .NET offer in terms of flexibility on this topic? --- Addressed above.

http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd http://saml.xml.org/saml-2-0-enhancements see attribute profiles UUID Attribute Profile
 * Nationwide Health Information Network needs to specify the attribute profile
 * **Nationwide Health Information Network need to express SAML metadata**

Sample Messages
Provided by 5am Solutions. These samples show the current behavior of CONNECT, and do not have the nested <Subject> element. Need to confirm that these messages fail Windows Identity Framework validation.

XCPD message from CONNECT test gateway to OCHIN:



Corresponding response from OCHIN to the test CONNECT gateway:



Provided by OCHIN, for the XCPD query exchange.

<span style="color: #17365d; font-family: Calibri,sans-serif; font-size: 10pt;">Request (from ONC) <span style="color: #17365d; font-family: Calibri,sans-serif; font-size: 10pt;">Response (to ONC) <span style="color: #17365d; font-family: Calibri,sans-serif;">(//based on our latest attempt to validate without WIF)//
 * <span style="color: #17365d; font-family: Calibri,sans-serif; font-size: 10pt;">Query from ONC -> OCHIN **

<span style="color: #17365d; font-family: Calibri,sans-serif; font-size: 10pt;">Request (from OCHIN).txt <span style="color: #17365d; font-family: Calibri,sans-serif; font-size: 10pt;">Response (to OCHIN).txt
 * <span style="color: #17365d; font-family: Calibri,sans-serif; font-size: 10pt;">Query from OCHIN -> ONC **

**Contributors To This Page**
Tom Davidson Joe Lamy Vassil Peytchev Michael Hunter Eric Heflin