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: wadl rest web 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.
  

In an ideal world, I (as a person or organization) would have full control over all three buckets, and could determine how the data about me flows. Unfortunately, the world is not ideal. In most cases I can only control the release (!) of data in the first bucket, but once that data is out in the wild, it will inevitably land in the third bucket, which I have least control over. Attempts at controlling that third bucket through regulatory measures are fairly ineffective, as can be seen by the many identity data releases and losses, even in relatively strict privacy regimes.

privacy secrecy