As far as securing RESTful services; IHE-ATNA already says how to do that – Mutually Authenticated TLS. I talk at length about this in Securing mHealth - the role of IHE profiles, specifically about the operational reality of using ATNA. IHE ATNA takes care of many risks, and does provide system authentication. Sometimes knowing the requesting system, is enough to know that you can trust that system would only ask for information that it knows the user is authorized to get. Surely using ATNA the service can trust that the client will include the user and purpose in the audit message recorded at the client side, because ATNA requires security audit logging.
What I want to address is deeper than simple HTTPS -- or even full Mutually-Authenticated-TLS. I want to address user and patient based access controls to very sensitive health information. Today RESTful is used mostly to access non-sensitive information. It might be important information, or simply might be maps, earthquakes, weather, etc. Most uses of RESTful are not trying to access as sensitive of information as healthcare information, certainly not information that can have privacy policies (Consents) that rule so finely over the data. Many are asking for RESTful to be used to access fully identified clinical information, and some are even asking that it be used to create or change this clinical information - such as the IHE Profile Proposal for a RESTful interface to XDS. These are the issues that I am trying to figure out how to equally secure RESTful vs SOAP.
In SOAP we have well defined ways to communicate the security context. IHE profiled the use of SAML assertion (XUA): who the user is, what their roles are, what they intend to use the data for, and any authorizations they hold. I cover this in the Bloginar on XUA. With SOAP based web-services this all comes along in the security layer built into SOAP, the WS-Security layer. RESTful doesn't have this layer, or at least not this well defined.
I hope to uncover the 'right' way to specify a RESTful service API for accessing highly sensitive healthcare information. I am not sure I can provide as good a security layer as is provided today with SOAP, but I am hopeful and open to suggestion. IHE will try to figure out all the possibilities, and all the operational environments. Much of the documentation I find is specific to one platform or the other.
I suspect that we will use something like OpenID + OAuth on the RESTful side, use WS-Trust to convert these tokens in the proxy service, so that on the backend we can use SAML to interact with the XDS or XCA backbone. I think this is a reasonable solution. I do expect that a RESTful API will be deployed for a specific use. It might be for the use by a large healthcare organization, or by a PHR vendor, or by a HIE; but the point is that this is an API into XDS/XCA that is hosted for a very specific purpose. Thus the very specirfic purpose can scope the security context well enough to make it easy on the Browser side, while satisfying the needs on the backend.
We could ignore the problem, but then what would "App" developers do? Guess at what they need to have implemented? Even a bad single choice is better than no choice. Even if we tell the App developers to include HTTP Basic Authentication, we will be sure that they can at least do that. Thus only hoping that they have thought beyond the minimal necessary to be compliant with the profile.
Please help. Please provide your choice. Please provide your environmental problem. The more information we have at the start, the better choices can be made.