IHE - Privacy and Security Profiles - Introduction

Update: The recording of the webinar is now available.

This summer I will be presenting the IHE (Integrating the Healthcare Enterprise) Security and Privacy Profiles. I have been putting together the slide deck for the Privacy and Security Overview. The purpose of the webinars is not to educate an engineer on the technical details, but rather to give an overview of the profile and what it can do. I now have version 6 up for the committee review, so I figure now is a good time to 'practice' giving the webinar. So, I will give the presentation on my blog, well kind of. This will take almost a dozen posts, so be patient and you might see all of the presentation. I also hope that while doing this I will uncover problems with the slides, so please feel free to ask questions so that I can help you understand and make the presentation better.

When I finished the first draft of the presentation, keeping just to overview material, I had well over 60 slides. Given that webinars typically have 45 minutes of material and 15 minutes of Q&A; we decided to break this into two parts. Part 1 covers basic security, while Part 2 covers advanced topics and privacy controls. In this blog post I will stick only to the "Overall Security and Privacy Controls"; which is an introduction to the space of Security and Privacy.

IHE produces Interoperability Profiles, they don't produce service specifications, application functional specifications, system design, organizational plans, or physical controls. This means that the scope of what one will find in an IHE profile is very limited to the kinds of things that are needed to (a) Enable Interoperability, and (b) Protect that Interoperability mechanism from Security Risks. The result is that you will not find any advice from IHE on things like: user interface, anti-virus, patch-management, door locks, room layout, spam protection, or Policies. These things are very important, they just are outside the scope of IHE.

Before any technology can be applied to enforcing Security or Privacy, an organization must define the Security and Privacy Policies that they are going to need to enforce. The Profiles from IHE are designed to be policy agnostic, meaning they can enforce almost any policy. In this way there is no constraint to implement a single policy.

These policies are built up of many layers of external policies. Starting with the highest level policies in the International community, such as the Organization for Economic and Co-operation and Development (OECD). This highest layer should also respect human rights, ethics, and norms.

The next layer down are those of the country, such as HIPAA in the USA, EC95/46 in Europe, and Act 57 in Japan. The next layer is those policies from the specific industry domain, in this case Healthcare. Some of the sources for this layer comes from the country, but they also come from medical professional societies. And finally the Enterprise needs to consider good organizational policies such as backup and recovery policies. Recognize that these different policies up-down and side-by-side can conflict with each other.

This is clearly an overview of all the potential influences on policies, but the important thing to take away is that policies must be created and written before technology is discussed. This is not to ignore the very fact that sometimes technology limits the policies, such as we will get into later in this presentation around Privacy Consents.

Security is best approached using a Risk Assessment model. That is to determine the risks to security; that is risks to Confidentiality, Integrity and Availability. As part of a Risk Assessment the Risk level is measured in terms of a combination of the likelihood of occurrence (probability) and degree of impact (positive or negative) of an anticipated event. Imagine a “hole in the roof” scenario, the risk is that weather (the threat) could cause damage to components inside the building as well as the building itself. As long as the weather report shows that there is little chance of precipitation, our risk level is low. However, this risk increases as the likelihood of precipitation increases. Since we cannot control the threat of precipitation, we mitigate our risk by changing the vulnerability; we fix the hole in the roof. The cost of fixing the vulnerability is much less, in this case, than the damage rain or snow would cause.

a)Examples of Threats -- natural disaster, random accident, disgruntled employee, employee snooping, external indiscriminate hacker, external motivated hacker, external highly motivated and highly funded)
b)Examples of Vulnerabilities – access without user identification, access without user authentication, user accessing data that they don’t need to know for their job, open network interface,

• Likelihood is an assessment of how likely that threat is going to exploit that vulnerability. Typically a gross assessment of High, Medium, and Low 
• Impact is an assessment of how much damage (harm) would result if that threat exploited that vulnerability (regardless of how unlikely). Typically a gross estimate of High, Medium, Low 
• Prioritization uses the combination of Likelihood and Impact to assure that the most important things are addressed first and that appropriate resources are applied (e.g. make sure the remedy matches the risk)

Another thing that varies from organization to organization is the policy they apply to accountability. There are two different types of accountability models that usually are mixed.

In the Access Control Model the users are simply prevented from doing anything that they should not do.

In the Audit Control Model the user is empowered to go beyond what they are minimally to do for their job, because there are situations where they may be called upon to do more.

For example where doctors should only access the patients records that they are assigned to, but are given access to all patients so that they can more quickly assist with a consult, urgent care, or even an emergency.

In healthcare there is typically a mixture that is more Audit Controls centric. In all models, the janitor is still prevented from seeing clinical data as there is no reasonable expectation that the janitor will ever need to. It is this flexibility that drives standards to be capable of handling either extreme as standards must function in any of these environments.

This table is going to be used across the presentation, it shows how the IHE Security and Privacy Profiles affect the security and privacy domain. Where a check-mark is shown there is a strong contribution by the Profile and a dot represents a minor contribution (or supporting relationship).

Most of these Profiles will be further discussed in this presentation. PWP and HPD are discussed in a different webinar. Document Encryption is not yet final so is not yet discussed in the webinar series.

• Which profiles should we use to prevent the wrong people from looking at PHI? 
• Which profiles would you use in an investigation of a potential incident? 
• Which profile would give you strong assurances that a document hasn't been modified? 
• Which profiles would inform an accounting of disclosures

Back links

This is part of a blog presentation of the IHE Privacy and Security Profiles Overview:

• Introduction to IHE impact on Meaningful Use
• This Page
• IHE - Privacy and Security Profiles - Consistent Time
• IHE - Privacy and Security Profiles - Audit Trail and Node Authentication
• IHE - Privacy and Security Profiles - Enterprise User Authentication
• IHE - Privacy and Security Profiles - Cross-Enterprise User Assertion
• IHE - Privacy and Security Profiles - Document Digital Signature
• IHE - Privacy and Security Profiles - Basic Patient Privacy Consents
• IHE - Privacy and Security Profiles - Document Encryption
• IHE - Privacy and Security Profiles - Access Control
• IHE - Privacy and Security Profiles - Miscellaneous
• IHE - Privacy and Security Profiles - Conclusion

The recording of the webinar is available too

Introduction to IHE impact on Meaningful Use

I was asked to present at the 12^th International HL7 Interoperability Conference. All of the final presentations and papers are now available on the HL7 Web site. The topic I was asked to cover is to introduce IHE (Integrating the Healthcare Enterprise) and provide input on how IHE contributes to Meaningful Use. The simplified message is quite easy:

1. Profiling (documentation that focuses on a use-case, specifying the standards to use and the constraints on the standards)  is an International need that IHE and Continua are addressing: 
2. IHE is increasingly adopted world-wide (see Where in the World is XDS and CDA implemented)
3. In the context of the stage 1 choices there is consistency in many area. Going forward, in Stage 2, IHE is consistent with DIRECT and can bring the most robust and already implemented solution that address the needed use cases deployed approach to point-to-point, HIE and NHIN Exchange.

A slide that I spent a good bit of time on, as many don't realize how formal the IHE process is.

1. Use-cases are submitted from any interested party. These must be justified and go through a priortization process to pick the few that will be worked on
2. The use-cases are then decomposed into the abstract actors and abstract transactions, and available standards are identified. This results in the Public Comment
3. After Public Comment the Profile is further developed into the technical specification that goes out for Trial Implementation.
4. Trial Implementations are used by developers that bring their solutions to the Connectathon. This tests both the software implementation, which must show interoperability with two other independently implemented solutions. The result tends to also uncover issues with the Profile text, what IHE calls a Change Proposal. Once a Profile has been proven at Connectathon, then it gets frozen in the Final Text phase. No breaking changes are allowed once a Profile enters Final Text. This is also when the Profile gets translated into the formal documentation publication form of the Technical Framework.
5. Those products that pass Connectathon are allowed into some form of trade show demonstration, with HIMSS being the big one for the IHE ITI committee. These demonstrations leverage the capabilities provided by the Profiles implemented in as close to a real world setting as possible.
6. Products are expected to publish an IHE Integration Profile as a statement of their products capabilities. This is a binding statement that they are expected to back through fixing any issues of non-conformance found.
7. The result of this is that products are available in the market space that are easy to identify their capabilities through the IHE Integration Statement, and have proven them-selves at Connectathon
8. Ultimately the result for everyone is better Interoperability. The Providers participate through offering up problems to solve, and by agreeing that they want the solutions. The Vendors participate through working through a solution and implementing it because they have assurances that the solution is desired. Both sides win.

The other slide that I think really says a great story in pictures is the one showing the Health Information Exchange Transport options. The message here is that there are 5 different patterns to a Health Information Exchange, shown across the bottom:

1. e-mail Push of a document without metadata
2. e-mail Push of documents with metadata to enable automated processing (XDM)
3. Web-Services Push of documents with metadata between automated systems (XDR)
4. A Community Exchange using Publication and Discover/Retrieve (XDS)
5. Multiple Communities Exchanging using Discover and Retrieve (could be XDS or proprietary source)

In each of these there is a richer and richer capability, but there is also a common use of Documents as the objects and a common definition of metadata to describe these Document objects.

This was a fun experience and I really enjoyed the other presentations. I encourage everyone to review all the presentations and papers that are now published on the HL7 site.

A broadly usable HIE Directory

The HIT Standards Privacy and Security committee was given the task to pick 'standards' that would support the use-cases of an Entity Level Provider Directory (ELPD). This is a directory that has information about a healthcare organization, entity. We knew that a Individual Level Provider Directory (ILPD) is going to be needed, and asked for directly following the completion of the ELPD. Thus we considered the ILPD while evaluating the ELPD. It seems this forward looking was a bad idea in the minds of the larger HIT Standards Committee. I can't stop thinking about sunday's Dilbert, replace "Lawyer" with "Systems Engineer".

John Halamka has presented  A Strawman HIE Directory Solution. I see many problems with this approach, and it seems that this approach includes things that add no value. The problems are not security, or trust. These issues are inherit in the X.509 Digital Certificate system. Digital Certificates can be distributed by any means, they don't need to be restricted. The HIT Standards P&S committee was asked to select a standard, what the HIT Standards committee did was reject it on operational deployment concerns. Concerns that are only half true.

Here is my alternative. The HIT Standards committee has already recommended to HHS/ONC that there would be great value to Healthcare exchanges (both direct and discovery/retrieve) if the certificates used were issued off of a Certificate Authority that is bridged to the Federal PKI. This advantage is two fold, first it is required for the federal healthcare (VA, DoD, IHS, etc), second it will force a specific level of assurance that everyone really would like to know they have. I will assert that this would result in a small number of Certificate Authorities.  This is the good part of the John Halamka step #2 plan, but there is no need for a new healthcare specific top-level-domain (TLD) or restrictions on query.

What I would augment is part #3 of the John Halamka plan, very simply with adding that these Certificate Authorities are recognized as the ELPD suppliers and would be compelled to publish using BOTH the DNS model and the LDAP model recommended by the HIT Standards P&S committee. Given that there is only a few of these ELPDs, they surely could work out LDAP federation between them.

Please note, I am not against the DNS model as an alternative, I am just against a model that is not supported by off-the-shelf solutions. The community must understand that the DNS model for certificate distribution is not working perfectly for the Direct Project, and has well known issues. This DNS model for certificate distribution is NOT supported by off-the-shelf software (aka e-Mail systems); nor by any e-Mail service provider. This DNS distribution of certificates is not even supported by widely used DNS services. It is totally restricted to the Direct Project reference implementation and a few open-source tools.

I am very worried about John Halamka's approach to discoverability through faith in internet search engines. This proposal is not any different than what we have today (http://www.bidmc.org/ContactUs.aspx), and I can't find reliable provider contact information. A program surely couldn't find reliable provider contact information from this page. I fail to see how this can be called 'standards' based. Putting our faith in internet search engines is NOT a standard.

I simply suggest that as we move from ELPD to ILPD, and from minimal support of the Direct Project to a richer set of use-cases; we will need the power of a real directory. DNS is a wonderful tool, but it is a hammer and the problem before us is not a nail.

(added this after first publication)
Note that DNS 'SRV' records are used to discover the address of an LDAP directory for a given domain. Thus it is not hard to find a LDAP directory, one uses DNS. This is a correct use of DNS, to find a Network Service.


(added this 5/27/2011)
Wes Richel has provided a solution to the part missing from John Halamka's blog. He has indicated that the web page that a provider would publish would use microformat, pretty graphical things. This ultimately is
useful as the microformat which for contacts is hCard which is a way to display vCard formatted information on a web page. Where vCard is a format that holds X.500 directory schema information. This is a potentially good idea and not inconsistent with what I have been recommending. The main difference is that Wes proposes this new flashy graphic format as the method of distribution on a web page (is there an app for that?). The microformat is just a distribution method, what are you distributing?

Ultimately we need a directory schema that meets the use-case needs. This is where the IHE HPD project spent most of their time. Trying to determine what are the attributes and how would they be encoded. This schema is nothing more than an X.500 directory schema, which can absolutely be distributed by vCard encoded in hCard microformat. The nice part is that this is very much along the right trajectory.

So what we have is the IHE HPD directory schema as a common schema and various distribution methods including: hCard, vCard, LDAP, DSML, etc. Sounds like a useful 'profile' that the S&I Framework could define for the US Realm.

My concern, that simply needs some research, is to what level does off-the-shelf e-mail support this? It is all nice that there is an app for an iPhone to view the hCard information; but if it can’t get that hCard information into the e-mail system for use then it isn’t really a useable solution (this is the same problem I see with the DNS model).

Note: The use of extended-validation-certificates would not be necessary on the web page. The digital certificate must it-self validate to a trusted root, so the trust is self-described. Digital Certificates do not need a trusted distribution method.

Prior Blog/Resources: 

• Healthcare Provider Discoverability and building Trust
• Healthcare Provider Directories Profile
• Healthcare Provider Directories -- Lets be Careful
• Authentication and Level of Assurance
• Healthcare use of Identity Federation
• Federated ID is not a universal ID

There is No Security Pixie Dust

At IHE, HL7, DICOM, and elsewhere those writing a Profile or Standard turn to the security-geeks in the room and ask them to fill out the now highly recommended "Security Considerations" section, or ask us which other Profile they can cut-and-paste from. The security-geeks respond with "There is no security pixie dust".

Within IHE the security-geeks have published a process the "Security Considerations Cookbook" that is intended to be used by the writers of Profiles, a process that 'considers' 'security'.  The reason why we came up with the Security Considerations Cookbook is exactly because each profile is different, and that security must really be 'considered' by the profile authors. There really is no short-circuit of the process with a cut-and-paste from another profile. There is no magic security pixie-dust.    

The profiles in the Final Text were published well before we came up with the cookbook, so they are not a good example (BPPC and XDS are good, but not simple profiles). It turns out that the Profiles where we have spent significant effort using the "Security Considerations Cookbook" have  not gone to final text yet. This is why you don't find a really good example of Security Considerations in the Final  Text Technical Framework. For good examples of Security Considerations one needs to look at the Trial Implementation supplements, But having a 'really good example' is impossible. Let me explain by example:

SVS

• This is a really good example of a profile that has explicitly declared that ATNA is not mandatory, but if one decides to group them in their application, then the encoding of the audit message is specified.
• The wording is not perfect, we always find some text that likely needs changing. The volume 2 stuff should actually be more clear about the 'if a developer does group with ATNA, this is the encoding'
• But this  profile has the advantage that it is just operating on vocabulary, and thus no identifiers or clinical data.

XCPD

• This is also a really good example, especially for Vol 1.

RFD

• This is a good example of Vol 1, and that is all that this one identifies. This is because the actual content carried by the Vol 2 transactions is unknown.

HPD

• This is a good example of something totally different
• This one might have the best wording in Vol 2...

But in ALL cases, you can see the influence of the RISK ASSESSMENT.

• It is only after the risk assessment that we know if a mandatory grouping with ATNA is the right thing to do.
• It is only after the risk assessment that we know if other things should be done, or should be explicitly NOT done.
• Etc...

So, you MUST actually 'consider' security, through following the process defined in the Cookbook_for_Security_Considerations. There is no magic security pixie-dust.  

Note: The same is  true in the HL7 Security Considerations Cookbook 

HIT Standards - PCAST analysis against Standards

I missed the HIT Standards committee meeting last week, but when I looked at the presentations and the minutes I was EXCITED. They took my advice, well they have done what I really wanted them to do. They extracted the PCAST principles and evaluated the current standards against them. Well, they contracted out to Mitre, who did a really good job.

However I do have some corrections or additional insight that I would like to provide the committee members, Mitre, and my blog readers.

Page 4: I really hope that when they say "Bias towards false negatives", they really mean "Bias AWAY FROM false negatives". A false negative will result in an inappropriate disclosure. It is true that the user should notice when they are working with the wrong patient, but not all use-cases have a user interact with whole documents. I would hope that the Doctor never needs to 'browse', but rather has the data gathered, collated and analyzed for her.

I know that we have an aversion to creating federal patient identities. I think this is misguided. I want to see real discussion on the reasons for and against. One thing that we MUST do is make sure that what ever identity that is given is simply an identity. These identities should be PUBLIC. If they are designed to be public, then we will not improperly use them as a secret. If we had this, we would NOT NEED to have all that other demographics such as Address, Phone Numbers, Zip Code...

Page 5: And I would suggest that although the IHE XDS Metadata contains the values that Mitre considered critical Patient Matching; that the more important thing is that IHE has the service interfaces for Lookup (PDQ), Cross-Reference (PIX), Updating (PAM), and Community Discovery (XCPD). The other alternatives don't have these service interfaces.

Page 6 & 7: Provenance is nicely introduced although the conclusion "Start with shallow provenance, increase over time" is a great conclusion, there is so much that is not said by this statement. Provenance is a very tough topic especially when there are so many different documents to cover, this is why IHE duplicates some of the provenance aspects found in CDA and puts them into the XDS metadata (including XDM, XDR, and XCA). What this does is allow for some level of provenance to be maintained in the XDS Metadata even when the document is a simple text document, PDF, or other.

So I would say that the assessment for both XDS as well as CDA on Chain-Of-Custody are wrong. For XDS it is simplistic, but CDA includes the recording of the custodian of the original electronic document (the originator of the information), as well as the source of it (through the informant participation), and if you wanted to go further, you could.  The exact way to do it simply isn’t specified, mostly because nobody have ever had a convincing use case for it.

Each CDA document is documentation of a specific encounter, by including both author and informant, it allows the chain of custody of information to be discovered.  Information going into the record does so only after a healthcare provider makes a clinical judgment that the information is both accurate and relevant (needs to be recorded).  It actually becomes a new piece of information:  Provider X (the author) thinks that this Act should be documented as part of the encounter.  The information may have been in fact received from multiple sources (other providers, the patient, a family member, a lab result, et cetera).  What is the chain of custody for a diagnosis and how is it intended to be used?  Is it to discover the source of errors in transmission of information?  Is it to deal with redisclosures?  These are interesting issues to discuss.  I don’t necessarily accept it as a requirement in the communication, but I can accept a requirement that it be discoverable.

In CDA, if you want to record credentials associated with an Information Recipient in CDA, you can certainly do so.  The element contains which allows any number of license identifiers to be recorded, including NPI, state license identifier, DEA number, et cetera.

And to add cryptographic assurances one simply Digitally Signs each document using the IHE DSG profile. 

Slide 8: We then get to Consent, I like their diagram  where we see that there is "Data Elements with Content Metadata". What is not shown and gets confused is that this Metadata in this case includes a set of metadata that would enable the "Policy: Assembled from Modular Components" to act upon. That is that it is the Metadata tags on the Clinical data that is used by the Policy. There is also conflating of the security/privacy context of a request to access the clinical data, which is the domain of the security context. Thus there are three concepts that need to be analyzed against existing standards.  

Slide 9: They do actually show the three concepts, they just lump them against one standard. The items they have identified as "Request Metadata" are the characteristics of the User Context that are provided by system requesting access to some clinical information. This information is is NOT included in BPPC, but is FULLY included in XUA. 

Then then include the "Content Metadata", which I will agree is NOT covered by BPPC, because this is metadata on all the OTHER documents, so it belongs to those documents. The Content:Datatype, and Content:Sensitivity are fully supported by the XDS metadata; thus are fully available regardless of the document type or transport type (XDS, XCA, XDM, XDR). Further these two metadata values are common in DICOM transports and available for HL7 transports; ALL with common vocabulary. The third value "Content:Coverage" is something that is very much not the domain of clinical documents, although I do agree that CDA covers it. 

The last value is the domain of Consent (and authorization), actually there is far more that should be listed here including Duration of the Consent (needed by many states), Organizations that are a party to the consent (needed for authorizations too), Digital Signature of the Consent, ability to capture the signing ceremony. These are covered by BPPC, even if complex consent rules are not covered.

Conclusion:

I am very excited that this work was done, and I applaud the great work of the Mitre team. I challenge them to take this information and enhance the work. Especially on the Consent portion. I realize that higher-executives want you to speak of these as one thing, but they need to understand the separation of these will create a more powerful solution, and does not diminish the analysis. The last observation it seems while looking across all the solutions analyzed that there is a tendency to say "N" when the standard does not mandate the capability. It is unusual for a standard to mandate something, what should be assessed is if the standard supports through specifying the mechanism. Mandates are the domain of Policy, not Technology.

So, Please look at:

• PUSH HIE: XDM, XDR, ATNA
• Regional HIE: XDS, PDQ, PIX, PAM, XUA, ATNA, BPPC
• Nationwide Federation of HIN: XCA, XCPD, XUA, ATNA, BPPC.

There are others that can be used including DSG, XDS-SD, SVS, etc...

Not - ANSI Initiative to Examine Financial Impact and Harm of Breached Patient Information

I reported back in March that I was going to 'jump on' the ANSI and Shared Assessments Launch Initiative to Examine Financial Impact and Harm of Breached Patient Information. Well, I attended what they said would be their kickoff "MEETING", but it was much more of a "WEBINAR". There was no discussion, just well polished presentations by Lawyers, Security-Product Vendors, and Consultants. I suspect this group has been awaken by HHS Breach Notifications and are looking for a way to add opportunities.

The following press release was issued this week: Internet Security Alliance Partners with ANSI and Shared Assessments for Launch of Project on Financial Impact of Breached Protected Health Information.

Optimistically they seem to be taking a holistic view of healthcare, although one question about clinical research left them without an answer. I have heard from some of my peers that they too are worried that this group does not understand Healthcare and the special sensitivities, including how sensitive the data is but also how critical patient safety and treatment is. The stated goals would produce much needed clarity to a market space that doesn’t have much experience with healthcare.

They have a very short timeframe, they want to research and create opinions this summer with a clear press spread in July when they also indicate they will be presenting ‘on the hill’. Because of the holistic view they are not likely to get into details.

This seems to be far more an opportunity for Lawyers, Security-Product Vendors and Consultants to make a case for their business. Thus I am not going to further participate.

Separation of Layers: Security Error Codes

This is going to be a deep technical article. In short: To those profiling a use-case, Please don't combine behaviors of the different architecture layers: that is keep Security separate from Transport separate from Session separate from Application behaviors. 

There are many projects that are looking to use IHE XDR to enable workflows. These projects are building on top of existing NwHIN Exchange and IHE profiles for very specific use-cases. It is not unusual to profile a higher level workflow on another Profile, for example IHE does this them-selves in projects like XDS-I from the IHE Radiology Domain. These projects try really hard to profile everything, which is a good thing. The mistake that often happens is that they start to mix the different OSI layers. That is they over specify application needs on transport or security layer.

XUA is a profile of SAML that is specific to Transactions that use SOAP. So the XUA assertion can be added to  XDR, but also QED, XDS, XCA, XDS-I.b, etc... The big advantage of using XUA (or SAML in general) is that the receiver of the transaction has information that they can use to further enable access controls on the service side. These access controls would either allow the transaction to continue, for which the security layer gets out of the way and lets the next layers to process the request; or could have found some reason to deny the transaction, an error case. 

In all cases of an error due to the SAML assertion must follow the SOAP and WS-Security specifications. This is recognizing that the SAML assertion is part of the security layer and not part of the application layer. 

IHE XUA Profile, covers this in section IHE ITI TF Vol 2b:3.40.4.1.3 "Expected Actions"

3.40.4.1.3 "Expected Actions"

The X-Service Provider shall validate the Identity Assertion by processing the Web-Services

Security header in accordance with the Web-Services Security Standard, and SAML 2.0 

Standard processing rules (e.g., check the digital signature is valid and chains to an X-Identity

Provider that is configured as trusted). If this validation fails, then the grouped Actor's associated

transaction shall return with an error code as described in WS-Security core specification section

12 (Error Handling, using the SOAP Fault mechanism), and the ATNA Audit event for

Authentication Failure shall be recorded according to ATNA rules.

The XUA Profile references the SOAP, WS-Security, and WS-I Basic Security Profile. The SOAP fault is specialized in the WS-Security specification section 12 "Error Handling"

This section explains why faults are not mandated, because policy may choose to provide no response at all so as to be more robust to attacks

The is also emphasized by WS-I Basic Security Profile – R5814

R5814 Where the normal outcome of processing a SECURE_ENVELOPE would have resulted in the transmission of a SOAP Response, but rather a fault is generated instead, a RECEIVER MAY transmit a fault or silently discard the message.

In the WS-Security specification defines that the fault mechanism is to be used.

12 "Error Handling"

…

If a failure is returned to a producer then the failure MUST be reported using the SOAP Fault

mechanism.  The following tables outline the predefined security fault codes.  The "unsupported"

classes of errors are as follows.  …

There are 8 fault values defined, I am not going to list them here as for SAML assertions there is more specialization.  The WS-Security specification has a profile for SAML assertions that further explain a reason for 5 of the fault values.

Reformatted from Table from Section 3.6 "Error Codes"

• wsse:SecurityTokenUnavailable - A referenced SAML assertion could not be retrieved.
• wsse:UnsupportedSecurityToken - An assertion contains a element that the receiver does not understand. or The receiver does not support the SAML version of a referenced or included assertion.
• wsse:FailedCheck - A signature within an assertion or referencing an assertion is invalid.                                                          
• wsse:InvalidSecurityToken -The issuer of an assertion is not acceptable to the receiver.
• wsse:UnsupportedSecurityToken - The receiver does not understand the extension schema used in an assertion.

Conclusion

So, any reason for rejecting the transaction because of the content of the WS-Security header, including the SAML assertion, is represented by SOAP Faults. The reason is not further differentiated beyond these reasons is for good-security-practice reasons. First one expects that a good-partner in a transaction does understand the Policies and Requirements; thus any further reason code would not help a good-partner but would clearly help a malicious individual. Note that the service could certainly log in their audit log a very detailed reason for the failure. A good-partner, upon getting a WS-Security fault, can ask for assistance in understanding the requirements and policies using other channels (e.g. Phone). There can also be exceptions to this rule during provisioning, for example during early provisioning of a relationship with a good-partner one could be more expressive, but once the relationship goes into production these expressive errors are turned off. I would recommend against this as it is common for these debugging-modes to be left enabled by accident thus exposing the operational environment. The audit log with phone call is a far more secure mechanism.