• Who has implemented a successfully chained service, with some propagation of identity?
  
• If you have, what architectural approach/technology stack have you used?
  
• How are you propagating identity - "sender vouches", "holder of key", "just trust me"?
• How complex is the chain? Single step, multiple steps, complex orchestration?

Who does not know and dread the recurring discussion of a topic long thought dead? The most egregious one lately was a discussion about the applicability of RFC 2119 to a particular standard I was working on (to protect the innocent I will not disclose the name of the SDO) - the last time I had a discussion about the meaning of "SHOULD" was about 11 years ago... sigh!

But this is not the reason for my current urge to vent - a bug long thought dead is reappearing once more: the old discussion about REST vs. SOAP. It is really annoying for two reasons. Firstly, it is settled - both have their place, and pitting them against each other is pointless. But secondly, posing the question of "Is SOAP or REST better?" is - to paraphrase Mona Lisa Vito - a bu****it question.

Representational State Transfer (REST) is an architectural style, i.e. a general approach on how to design distributed computing architecture. While it was initially described by Roy Fielding using HTTP, and also uses constraints familiar from the web, it is not tied to a particular technology.

The Simple Object Access Protocol (SOAP) is - in contrast - a specific technology; more precisely an XML based protocol designed to transport data across a variety of different underlying transports. In real-world deployments it often uses HTTP (actually almost exclusively its POST method) as underlying transport for the SOAP Infoset. The architectural style used by many (if not most) SOAP designs is best captured by describing it as remote procedure call (RPC) oriented [1]. 

So a correct (in the sense of "apples to apples") comparison would align itself along the lines of comparing HTTP web service using an RESTful architectural style with SOAP web services using an RPC-based architectural style. A simple, incomplete table might look like this:

That's it - rant over.

[1] Note that while SOAP operates typically in two different modes (rpc/encoded and doc/literal), these have nothing to do with the architectural style of the distributed design.

Last night, Emdeon and MITRE went public with our collaboration on hData. This as been in the works for quite a while, and I am very glad that we were able to get as far as we have come. The work with Emdeon has been great so far, and the team has learned quite a bit about operational aspects that we were able to use in the future design of the product. Here are some quotes form the press release:

"In the era of meaningful use, the electronic exchange of clinical data will be essential. Because providers use disparate healthcare information technology solutions, an easy method of mapping and exchanging clinical data between and among systems is required. hData provides a way for the industry to map clinical data from any electronic health record (EHR) system and creates interoperability," said Miriam Paramore, senior vice president of clinical and government services for Emdeon.

and

"As the industry strives for simple, direct, secure and scalable transportation of health information over the Internet and between known participants in support of meaningful use, hData lowers the barrier to healthcare IT integration by focusing on ease of implementation," said Joy Keeler, healthcare IT program manager at MITRE. "Our work with Emdeon lays the foundation for more efficient healthcare information exchange, and further analysis of the pilot will provide us with important insights on reference implementation and standards in the months to come."

Health Data Management is also running a short story here. Meanwhile, here are the final ITS-WG specs:

Service chaining is - in my mind - somewhat underappreciated as use case is identity management. It is being paid some lip service, but often put off as too hard to solve. Yet, many of the issues I face in the mapping of complex business processes to a set of decomposed services involves service chaining. For the purpose of this article, here is a simplistic definition (made up by myself):

"Service chaining occurs when a service must invoke another service to complete a transaction."

In other words, a user invokes a service A. That starts working on the problem, but figures that it needs information from service B. Now, service B is being invoked, but there needs to be good understanding on who is invoking service B to perform a satisfying access control decision. Service B should ideally know the identity of the user and the invocation path (in this case just service A) to perform an access control decision.

Interestingly enough, this process can be decomposed into two important steps: the final access control decision by service B, and a reverse authorization decision by the user. For the following steps, strong cryptographic identification through public/private key pairs is assumed:

Step 1: The user invokes service A (authentication and authorization occurs somehow).

Step 2: Service A decides that it needs to invoke service B for completing the operation and tries to access.

Step 3: Service B challenges the access request with a signed statement (access request statement - ARS) that documents:

• Its identity by including an identifier (such as e.g. a URI) and its public key
• The operation service A is trying to perform
• The identity of service A, again through e.g. a URI and public key.

Step 4: Service A receives the ARS and forwards it to the user. The user evaluates the request, andauthorizes the ASR by signing it.

Step 5: Service A forwards the signed ARS to service B. Service B verifies the signature and returns service A the required information.

It is obvious that this process it WAY to expensive to implement in large systems, but these are the steps that are - explicitly or implicitly - taking place in any service chaining scenario. It gets a little more complicated once you allow delegation of authorization, i.e. service A might have permission to authorize access on behalf of the user for service B trying to access yet another service C.

The two major performance impacts in this model are: (i) signature creation and verification, especially over XML constructs, and (ii) ASR parsing and policy evaluation.

Today, we released the hData technical specifications: hData Record Format and hData Packaging and Network Transport. This is the mail that went out to the mailing lists:

Today we are releasing the first public version of the hData specification for the record format and the packaging and network transport (REST API). They are available here:

http://www.projecthdata.org/documents.html

We will be making some changes to the documents in the next few days to add a simple meta data model and streamline certain elements. Once this is complete, we are planning on moving the specification to a wiki and open up the process of editing. Until this is done, we would like to ask you sending your comments to hdata-general@googlegroups.com

At this time we are also exploring how the hData specifications can be licensed in an open source friendly way. Possible options include an OASIS style non-assertion covenant – please contact us if you have suggestions.

So far, this covers the core data and exchange architecture, but we have started to work on a RESTful security architecture, as well. The scenario we are trying to solve is outline in a recent presentation at NIST's IT Security Automation Conference. In support of this I have come up with a meta data schema, which I will put into the v0.8 version of the hData Record Format specification. Hopefully, I can upload that new version some time next week.

We are very much looking for comments and suggestions. 

tags: hDataehrhealth carehl7hitsp

Marc just made my day by sending me the link to the official submission of WADL to the W3C. Quick background: WADL (Web Application Description Language) is a simple interface definition language, specifically targeted at RESTful applications. It is significantly easier than WSDL 2.0 (or WSDL 1.x for that matter), and has some good tooling support through the Jersey implementation of JAX-RS.

tags: wadlrestweb services

IBAC, RBAC, ABAC ... a lot of folks in identity land are currently investigating authorization models with a little more scrutiny. Mark Dixon has a nice piece up on his blog, covering some of the current trends in the commercial sector.

I would like to make interested folks aware of an extension to the existing approaches to access control, that take it beyond ta simple binary decision: in the Risk Adaptive Access Control (RAdAC) model, the authorization decision is not simply based on pre-defined mandatory and discretionary rules, but instead includes environmental policies such as Security Risk and Operational Need. As such, the authorization decision depends not only on traditional factors such as resource meta data, access control policy, or user attributes, but also factors such as access decision histoy, IT computing platform trustworthiness, or general situational awareness.

RAdAC is not a technology, but instead a more uncconvetional model for making an authorization decision. It will be interesting to see how a model like this can actually be implemented.

Our effort to improve electronic health data exchange is starting to pick up some steam: After a very successful rounds of discussions at the HL7 General Plenary in Atlanta in late September (kudos to Andy Gregorowicz for covering this one) and a pretty warm reception, I presented last week at the NIH in Bethesda during the Tao of Attributes workshop on hData and our plans for the identity management and access control piece. I got some really great feedback, and I am hopeful that the idea of using a set of technologies that is know to scale (RESTful architecture style) can address the needs of a complex health data exchange.

Going forward, we would really like to start building a community around hData and L32. To this effect, we have created a couple of email aliases (see here for details) for starting a dialogue. 

hData ehr health care identity

I liked Bob Blakey's recent article on privacy, along with the paper he and Ian Glazer published. One direction that might need some additional coverage at some time is the “privacy of organizations”. Organizational sensitive data (such as trade secrets or classified material) follows a similar pattern of what Bob and Ian are laying out for PII: it is disclosed to a trusted group (as such it would not fall under their definition of secrecy), and a legal instrument (such as a NDA) is used to ensure that this data is not released to non-authorized parties. 

In my own world, I have seen privacy and secrecy as very closely related: to some extend, secrecy was to me privacy with a solid logging/auditing system, so that secrecy is really only preserved operationally, and full access to the audit trail would restore the identity (oh dear *that* loaded term again) of all actors. Bob and Ian obviously use a different definition of privacy, which has much stronger implications for the meta-data architecture, including sensitivity markings or IRM controls.

In order to draw a more precise distinction between different concepts of privacy, it might be relevant to examine the origin of the data about me (the data subject): 

• The first bucket is data for which I am the originator (source).
  
• The next bucket is data that someone I interact with directly collects about me, so they are the originator. This may include web server access logs, shopping profiles, etc.
  
• The final bucket is data that a third party collects about me, without me interacting with them. In many cases they are not the originator of that data, but instead collect other party's data (including myself). Note that data in this bucket gets particularly interesting when aggregated.
  

privacysecrecy