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

My town (Burlington, MA) has just revived the Information Systems Advisory Committee (ISAC) to assist in the alignment of the school system's and the administration's IT departments. With many high-technology companies in town, the administration has been at the forefront of the IT development, with a respectable web presence that dates back into the 90s - at a time where only few towns and cities took the web seriously.

To support the new projects, I have been appointed to a position in the ISAC, and I am looking forward to helping the town staff to decide how to move forward.

In an earlier article I talked about data ownership - or lack thereof - at a low, technical level. There are three principal technical actors: the physical custodian, the logical custodian, and the data originator. This article deals with the problem (for the data originator) to limit the powers the physical custodian has. As the owner of the physical equipment that hosts the data, the physical custodian can perform a number of undesired actions with the data he hosts, specifically: (i) copy and distribute it and (ii) disable physical access to it. In many cases, both actions are not desired by the data originator or consumer.

As a first step towards limiting the physical custodians powers, it is important to make sure that the physical custodian (PC) is not also a logical custodian (LC). By this I mean the following: the PC has access to the physical equipment that hosts the data, as well as the transport infrastructure to get access to it. By denying the PC the role of the logical custodian, he may ultimately host data, but will not be able to use or interpret the data in a meaningful way. An obvious way to achieve this, is to encrypt the data and make sure that the PC does not get access to the key. For most practical purposes, this addresses action (i).

But even if the PC cannot access the data he hosts, he still has the "power of the plug": if the PC cuts that connection to the network, or switches of the data equipment, all access to data is lost. In order to be able to address this problem, one can use the following scheme:

1. Data is stored in some atomic units like files, that can be represented as a data stream.

2. The data stream is encrypted; keys are not stored with the data.

3. The encrypted stream is chunked into at least two chunks of identical size. The number of chunks is arbitrary.

4. At least one parity chunk is computed - think RAID 5 or 6.

5. The chunks are stored on different data services. This could be a traditional data service, but also other services such as a mail service or a blog service could be used to store the chunks. The table linking the different chunks is stored separate from the data.

The effect of creating such a "Redundant Array of Independent Services" (RAIS) is obvious: not only can the physical custodians not access the data since it is encrypted and they only have a portion. Also, since there is at least one parity chunk, if one provider decides to "pull the plug", the lost data can be reconstructed from the remaining chunks. As an additional protection, users might want to mirror individual chunks on different services as well, thus improving availability.

User-centricity - often expressed in the "7 Laws of Identity" - has been a common theme in identity management for a while now. At the heart of these principles lies the desire to empower the end-users of a computer systems and enable them to negotiate with the provider of service the amount of PII data the users have to disclose for getting access. Beyond the initial authentication and authorization steps for resource access also lies an ocean of other problems such as delegation, pre-authorization, and emergency overrides. These issues play into a vast number of use cases in very different areas such as financials, health care, and social networking.

At the same time, a rather important aspect of identity has been completely ignored: the systems we interact with and their component services and devices do have identities as well, and these identities must be managed with the same details as person identities. The need for non-person identity management goes well beyond the realm of security sensitive environments such as various government services: we are getting ever more dependent on a growing number of devices and services including mundane things such as smart phones and ebook readers, but also critical items such as health monitors. In many cases, high-value or critical services rely on less valued service (such as a health monitors that use the mobile phone system for notification). Overall, we are seeing a polynomial growth of interdependencies of such services of devices.

With these problems looming, it becomes more and more urgent to extend the practices learned in identity management for persons to non-person entities. The solutions for this new class of identities will have to be significantly different, since devices and services will interact with the IdM systems in very different ways and might also have significantly different needs. For example, while privacy protection is important for end-users, devices and services and their operators will likely be more concerned with secrecy, which might borrow from some privacy best practices, but be different in other respects. 

Interestingly enough, PKI has had a notion of non-person identities already for some while. We are relying on the internet PKI for authenticating servers to users and services. At the same time, PKI has been very cumbersome to roll-out to end-users and edge devices. As such, there are some lessons that PKI can provide, so that the efficiencies and abstractions of SAML and related technologies can to go beyond simple user-centricity.

As a challenge, here are some questions that I have with regards to identity management of non-person entities:

1. What identity can devices and services have? How are these identities different from human identities?
2. What are the minimal requirements on machine identities?
3. What new and different interaction patterns are required for enabling machine identities?
4. How do concepts such as reputation translate into the machine world? 
5. When machine and human identities interact, is there a need for disclosure that one party is non-human? Or human?

Data ownership is a rather nasty topic: at a legal level, we have many rights related to data we create or that is about us: privacy regulations, intellectual property rights, copyrights and trademarks, etc. are all aspects of how society attributes ownership to immaterial goods. This practice has been in place since at least the early 19th century, but even then there were critics, among them Thomas Jefferson and James Madison.

With the advent of digitized storage, reproduction of immaterial data has become cheap and lossless. This has a significant impact on the industry: for example, the entertainment industry is currently facing the consequences of this highly disruptive technology advancement, and has yet to redesign their business model to accommodate this paradigm shift.

But this change goes far beyond the entertainment industry or any specific market: at this time, most people have started to realize that data they release about themselves will be reproduced, indexed, and made available via 3rd party search engines. Once the cat is out of the box, it it too late for restricting distribution.

This leads me to believe that we need to re-think the concept of data ownership, at least at a technology level: it does not make a lot of sense to claim ownership of data if one has no means of asserting this ownership in an effective manner. The judicial processes are too slow and too much bound to physical objects. As a result, only a small portion of data ownership infractions is dealt with by courts, and effective enforcement on a global scale is practically impossible.

As a result, it would seem appropriate to me to abandon the concept of data ownership on a technical level altogether - and replace it with concepts that are better suited to how information systems are designed in the 21st century:

• A physical custodian of data has access and control over the physical object where the data is stored. In many cases this will be effectively a system administrator that is taking care of the computer and harddrives where the data is stored. It also makes sense to consider the organization that employs the system administrator(s) to be physical custodians. The physical custodian has significant control over the data, since he can simply "pull the plug" and make data unavailable.
  
• A logical custodian can access and modify the data. A logical custodian can also grant the logical custodian role to other entities. While in many cases a physical custodian is also a logical custodian, there are important cases where this is not the case: in multi-level security systems or environments where data-at-rest is encrypted, the physical custodian might not have meaningful access to the data. The granting of this role can not be reversed: once an entity has access to data, this data can be copied to other physical systems and be re-used.
  
• The data originator is the entity that created the data. While origin may be an important factor to determine authority or validity of the data, it does not guarantee either.
  

Anything beyond these roles cannot - at least with current technology - be properly modeled without relying on concepts beyond the realm of technology. Nevertheless, even these limited roles can be used to model interesting scenarios. For example, a distributed storage system that stores encrypted and chunked data with parity (i.e. RAID 5 or 6 across different services, not disks), can practically eliminate the role of the physical custodian.

Higher level technologies (such as DRM or multi-party encryption) may be successful in restricting the significant control that a logical custodian to some extent, only external mechanisms (such as system certification, trust models, or judicial redress procedures) can limit the logical custodian.

tags: dataprivacyintellectual property

For some time I have been working with a number of folks at MITRE on a simple representation for electronic health data. Digging into the depth of various standards organizations such as HL7, HITSP, or HIMSS was interesting, painful, and enlightening at the same time. Since last week, our project is online at http://projecthdata.org/, and the hData project has announced releasing specifications, schemas, and code there soon. At this time, you can get the hData white paper, which was also presented at the recent Balisage 2009 conference in Montreal. Overall, hData's approach is very much focused on implementability and ease-of use for developers (since - quoting Mike Kay at Balisage - "As a developer I am also human.")

Interestingly enough, the combination of ODF/Jar style packaging and RESTful integration (taking a ZIP archive of hierarchically organized component documents and representing it as a collection of resources) has some folks interested. If there are more, I will suggest taking this out of hData and creating an independent specification.

tags: hDataehrhealth carehl7

I have talked manytimes before about the privacy concerns that I have about Europe's and Germany's approach to protecting privacy: on the one side citizens have - at least theoretically - a very strong position viz-a-viz non-governmental actors when it comes to data ownership and controls through the Privacy Directive and the "informationelle Selbstbestimmung". On the other hand, the state reserves the right to arbitrarily intrude people’s lives, collect PII, and use any data source – legal or illegal – for fighting so-called tax evasion. In my opinion, this approach is highly hypocritical in itself, but one might argue that different cultures and traditions may justify such laws and procedure.

However, in the current debate about sharing SWIFT financial transaction data with the CIA Germany is crossing a line: all “major German parties” are feverishly opposing the EU Commission’s proposed data sharing agreement with the US administration that would assist in combating terrorism. To get this straight: Germany happily buys stolen financial transaction data from convicted criminals and allows this data as evidence in legal proceedings against alleged “tax evaders”. No controversy ensues, since it only affects a few rich (i.e. successful) that "deserve" to be dispossed. Yet, there is public uproar and another wave of blatant anti-Americanism when the US authorities want to monitor the financing of international terrorism.

Thank you for your time - I rest my case.

tags: hypocrisygermanyprivacy

Since recently, I am involved in selecting technologies (not vendors, mind you!) for distributed systems. While highly interesting, I am now faced with the age-old issue of interoperability and claimed adherence to standards. We all know the games companies and standards organizations have been playing: loosely specified standards with too many degrees of freedom, proprietary "extensions", etc. What happens often enough is that the implementations of relatively new standards (say less than 10 years of commercially or freely available products) have significant interoperability issues. Over time, these issues disappear, but not necessarily at the speed that customers or even the industry would like. This can have significant detrimental effects, including delay in necessary technology upgrades (e.g. IPv6), market distortion  (PAC data in authZ data fields in  W2Kx), or even non-adoption.

The SAML commercial community has developed a process that is very useful to technology consumers: through Liberty, Drummond Group International operates a testing program that verifies standards compliance of SAML products against the SAML 2.0 static conformance requirements.With a rigorous testing process, the results of this process are quite helpful for source selection - if only to get a quick overview of the capabilities of the different products without having to wade through piles of marketing collateral and technical documentation. As a customer, I am particularly pleased about this process, since the vendors are paying for this process themselves. While this does not eliminate interoperability problems completely, it puts the burden of proofing interoperability on the vendor and not on the customer.

On the other hand, Microsoft and a number of other vendors have in the past performed informal cross-matrix interoperability testing in the form of the ws-builder plugfests or the OSIS InfoCard test rounds. The lack of formalism is countered here with the very low barrier to entry, so that open source projects or small companies have the opportunity to participate as well. 

Combining these two approaches would yield an useful process:having a commercial vendors and--at least some-- open source projects participate in a formalized vendor-initiated cross-matrix interoperability certification (VICMIC - this is for all the acronym lovers out there) would give enterprise architects and developers a powerful tool for source selection. The particpation of the open source projects could be sponsored through stipends that are awared by the testing organiztion based on criteria such as feature completeness, overall quality, etc.

If I had my way (yeah, I know, I will not ... still you can DREAM), all technologies wanting to be considered for public projects would have to implement such a process - that's a MUST in RFC 2119 speak. If they do not, the aquisition process should really require this.

tags: interoperabilitygovernment