The other side of this is that even if a user identity was provided it would be about the user that is right-now connecting. If this is a request from a clinical system (e.g. EHR) the result will be stored and others on the clinical system will gain access. So although the initial connection could be access controlled, the other future accesses within the EHR must be trusted to do the right thing. I worry that people see the user assertion and end up with a false sense that all accesses are singular accesses back to the original system. Thus there is a false sense of security, rather than a healthy-suspicion that doesn’t let the whole-system connect at all until the downstream workflows are checked out too. There are other transactional complexities that simply adding an assertion doesn’t help. But there are also applications other than an EHR that can operate on single-read-only-use (more on this later in this post)..
If we look at an EHR today, it has user authentication and access controls that have been built up over time to meet the requirements of being an EHR. The user authentication likely is highly flexible to support some rather strange workflows. One of the strange workflows is the exam room, where an administrative person walks the patient to an exam room and sets up the exam-room-terminal with the right patient then ‘locks the screen’. Next the nurse comes in to take complaints and vitals logs in, enters them, and logs out. Next the doctor comes in for the exam, again logs in to enter data and logs out. Each of these people are authenticating, but the workflow on the desktop is all about the patient. These authentication methods and authorization methods are sufficient to protect the PHI that is maintained inside that EHR. It is possible that an organization has gone to an enterprise class authentication system like Active Directory or more generically Kerberos or LDAP, but this is not required.
Lets look at interacting with an HIE or other organization that requires a SAML assertion. A SAML assertion is issued by an Identity Provider that supports SAML. This Identity Provider is configured to understand specific targets of the SAML assertions (known in SAML terms as an ‘audience’). The configuration will include mapping tables that indicate that when creating a SAML assertion for use within a specific HIE that some list of attributes need to be added to the assertion. One likely attribute is the HIE-role values which is assigned based on the Role or attributes within the Identity Provider. Thus if I am known as a Physician in my local LDAP Directory, but the HIE wants the role to come from a different valueSet where my role within the HIE would be “Care Giver” then it is up to the Identity Provider to do this mapping. This is a common thing for Identity Providers to do, as role vocabulary is not stable within any organization (not just healthcare) nor is it likely to be stable inside the HIE. What is important to recognize is that the SAML assertion is issued by an Identity Provider that does this mapping. The native user directory does not need to have the HIE-roles. When this SAML assertion is received by the Service Provider it is validated which checks that it was issued by an identity provider that is on the trusted-identity-provider-list. This allows the Service Provider to support many different Identity Providers, likely one for each clinic and hospital connecting to the HIE. Given that all of those identity providers have normalized their roles to the HIE-role vocabulary it is clear what permissions the user should have in the context of this transaction in the HIE. 
This may work long-term, but likely enterprises will choose to go to an enterprise class user-authentication system to gain all of the advantages of single-sign-on and much quicker user provisioning and de-provisioning. But once this transition is done, then that enterprise class user-authentication system should be specified as a cross-enterprise class user-authentication system. The WS-Trust protocol would then be used to get SAML assertions issued.
Now is when I must add the exception to the rule. The above discussion was around clinical access to an HIE by an EHR. I think this is the most important HIE access and the one that brings the biggest benefit while being most simple. I think the same can be said about a PHR, although I have less sympathy for a PHR as they are generally less constrained on workflows (exam room) and are also rather newly designed. So a PHR could more easily provide user assertions, still I am not sure why that assertion is specifically useful. But there are other parties that are being connected to the HIE. I think these other parties may be more likely candidates for getting benefit from requiring assertions….
