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:

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

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.

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

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

The U.S. Patent and Trademark Office (USPTO) is considering to invalidate many (if not most) software patents and significantly restrict the issuance of new process patents. No doubt, intellectual property does deserve decent protection, and I think that this move by the USPTO will in fact result in better protection of property: copyright law provides ample protection against IPR theft while not getting in the way of real innovations.

To draw a technical comparison, process patent law protects the API, while copyright law protects the implementation. Although it takes a lot of thought to come up with a good API, it should be the implementation that is at the heart of the competition to not harm the end-user.

In this sense, the new direction of the USPTO will benefit the end-users (consumer as well as application developers) by allowing the concrete implementation of ideas to compete while keeping interoperability at the idea-level intact. In the end, the entire market will benefit including the vendors by lowering the barrier for interoperability significantly. 

tags: internet lawIPRpatents

• Interoperability with SOAP based web services is progressing: I was part of a panel on interoperability, moderated by Chris Haddad. It was a fairly diverse panel, with speakers from Microsoft, WSO2, Tibco, and Sun. While there was general agreement on the usefulness of the more basic WS-* specifications like WS-Security, opinions differed on where the future lies and how it can be achieved. In my opinion, the relatively high fidelity of interoperability within the WS-SX family of specifications is a direct result of the proper standardization process at OASIS that these specs were subjected to, comparable to that of ebXML or SAML 2.0. Thus, it is my expectation that the WS-RX and WS-TX protocol families will eventually yield similarly good interoperability.
• For the "Demo that almost made it (TM)", we made some serious progress: After talking to Greg Leake of Microsoft and Jonathan Marsh of WSO2, I am quite optimistinc that we can get easily inject a Metro based STS and/or OpenSSO with WS-Trust and CardSpace support into the StockTrader sample application to allow authentication through a SAML token. At the same time, I think that this demo application in particular lends itself quite nicely to showcase the strength of the Liberty framework for web services: you have a web application that needs to interact with the Business Services and the Order Processing Service. Identity has to be preserved across these different tiers, yet privacy protection would be highly desirable.
  
• It was very interesting to see that Microsoft is continuing on the path of interoperability in the systems management area. Three years after we demonstrated MOM 2005 managing and monitoring a Sun v40z with Solaris, Microsofts System Center beta features an open source Solaris management adapter. An interesting question is where this code will be hosted ...

It took quite a while, but by now it is out. Please welcome the Windows CardSpace Information Card extensions for OpenSSO:

https://opensso.dev.java.net/source/browse/opensso/extensions/authnicip/

When I started working on this last spring, I was not even hoping to see this released in open source and part of the OpenSSO extensions family in less than a year. It took the goodwill and talent of quite a few people to get this off the ground, but with the public release of this code and the upcoming OSIS interop during the RSA onference, OpenSSO is now "speaking ISIP" ...

tag: CardSpace, OpenSSO, InfoCards

This is seriously groundbreaking: Clemens (also here) just finished an example of a Metro client accessing Microsoft's BizTalk Services (aka Internet Service Bus). "Well", you might ask, "what is so groundbreaking about this? Isn't this what this whole web services thingy was supposed to achieve? Interoperability?!"

Yes, indeed. However, this is the first time ever (to my knowledge) that Microsoft is releasing JEE code, built with Metro within NetBeans, as part of an SDK. Getting there took quite a while, and was largely enabled by Sun and Microsoft working very closely together in a series of interop-plugfests. The latest installment of these got (especially) WS-Trust interoperability to a point where you can now use the client implementation in Metro to access the STS provided by the .NET Framework.

Congrats to Clemens, but also the Metro team (namely Jiandong and Harold).

tag: Interoperability, WS-Trust, Metro, BizTalk Services

tag:Interoperability, Identity, CardSpace

Not about SCUBA this time: we are right now visting in Redmond so we can test our implementation of a Windows CardSpace compatible IdP against Microsoft's implementation. Eventually, we will (hopefully) make this code available to the OpenSSO community through an OpenSSO Extension.

At the core of the integration, we (Paul, Jiandong,Mrudul, and I) have integrated the Metro/WSIT WS-Trust STS into OpenFM and created a simple cardfactory to produce CRD files (a big thank you to Chuck from here for letting us use some of his Openinfocard code). While we are not quite done as of yet, we have made some very significant progress towards full interoperability while supporting the username/password token, as well as X.509 client authentication.

Overall, this project has already helped quite a bit to improve interoperability between the underlying technologies (i.e. WSIT and the subset of WCF that is being used by CardSpace) and I expect that we will be pretty much done with the core code base in the RSA 2008 time frame.

Many thanks from here go to Mike Jones, Nigel Watling and the entire Microsoft CardSpace team.

tag: CardSpace, OpenSSO, Interoperability, Identity

• Noemax FastInfoset.NET - I have been talking to them from very early on.
  
• Liquid XML Compression - a relatively new (at least to me) implementation that supports .NET 2.0 and the Compact Framework.
  

tag:FastInfoset, .NET

Through Nico Williams a real interoperability story:

Alan Wright reports that the Solaris team recently completed the Solaris kernel CIFS service. That's right: CIFS (i.e. Windows networking) is now on par with NFS and other kernel-level system services. To be able to achieve this goal, the Solaris folks had to create some really innovative pieces of technology:

• To allow Windows style SIDs in the process credentials, they are now allowing negative and ephemeral UIDs and GIDs.
  
• ZFS now supports all kinds of DOS attributes and full NTFS ACLs, i.e. ordered ACEs with SIDs.
  

All persistent data (like filesystem records) are dealing with actual SIDs, while non-persistent kernel and memory objects are using the ephemeral negative UIDs. The later are not stable across a reboot, but an ID mapping daemon performs the necessary translation between the SID and its UID.

With this new technology on the horizon, my new home project on a Solaris storage appliance for the basement ("Codename Filer") looks brighter than ever ...

tag: interoperability, cifs, solaris

PS: Welcome in the blogosphere, Paul!

tag:saml, identity, higgins, liberty

[1] Paul Madsen made some interesting remarks about that name...

Well, this is over ... and on to the next.

The last week was quite busy since Mrudul Uchil (from the OpenSSO team), Jiandong Guo (from Metro) and I were scrambling to teach OpenSSO to issue InfoCards for Windows CardSpace and respond correctly to WS-Trust STRs. Overall, it went quite ok and this excercise uncovered a few issues that will help us make the product better. The idea is to make this code accessible to the general public as soon as we can - but please bear in mind that we had to make changes to WSIT/Metro and OpenSSO, and some of these are not (yet) considered critical for the products. Nevertheless, I will be working towards a release for the IIW 2007b timeframe, so that we can progress.

Eve posted a couple of thoughts and some nice pictures of the interop session ... go check it out.

tag: identity, interoperability, InfoCard, opensso

Kim writes about the recent Beta announcement^[1] at Windows Live! about them accepting Windows CardSpace InfoCards for authentication. Having gone through rolling out an extensive public new and experimental Identity System deployment myself (Lauren is currently writing about that), I can appreciate the work that Kim and his colleagues are putting in.

In the interest of distilling use cases for Project Concordia and other venues it seems worth pointing out that - in this deployment - Windows CardSpace is being used solely as an authentication system: You can associate any Windows CardSpace card (only PPID is required) with your account - all other attributes are still being handled by the backend systems of Windows Live!. Any additional attributes that your Windows CardSpace card can provide will not be used for authentication or authorization.

This is very much in line with my description of the "glorified HTTP Redirect" use case of Windows CardSpace: here the secure UI on the client can actually help in preventing phishing attacks. The biggest competitor for this use case is OpenID which offers (roughly) the same features, but employs a radically different approach at solving the authentication problem. With PAPE it is somewhat more phishing resistant, but at this point, the CardSpace-based identity systems have - from my perspective - a clear lead in this area over OpenID.

Both authentication technologies face however that same issues: they allow delegation of responsibility for authentication and a rudimentary attribute exchange mechanism. But they do not address the need of service providers to maintain ownership of attributes about their users, except in trivial cases. For these - business driven - issues you need a framework that allows advanced models of federation and account linking and  - most importantly - goes beyond protocols and addresses the non-technical aspects of identity management as well.

I think it will be quite interesting which authentication technology (OpenID and Windows CardSpace) will get how much market space. OpenID has a head start as far as IdPs and community acceptance goes, but Windows CardSpace has the backing of Microsoft and - starting with Windows Server 2008 - a REALLY large number of relying parties.

tag: identity, OpenID, WCS, interoperability

[1] The service has been available for some time now.

Just to satisfy myself that the Solaris 10 U4 iSCSI target is working well, I fired up a few file system stress test processes to see if the Solaris machine (and the iSCSI initiator) hold up.

For the test itself, I took an old but reasonably reliable SQL Server hard drive test (can be downloaded e.g. from here). I took the default parameters with medium workload (100MB files), especially since my test drive was a virtual machine on my laptop. Write caching was off. The purpose of this test was not to create a performance evaluation or a real stress test, but much more a proof-of-concept that the two systems would work together.

Here is the final result:

The next step would be a full stress test, preferably with at least 3 or 4 high-powered drivers. That might take some time, though. Meanwhile: happy SAN building.

tag: windows, iSCSI, Solaris

... but it seems that the marketeers at Microsoft are finally getting interoperability:Dino Chiesa blogs about how SCA is an endorsement for WCF. That in itself might be a questionable statement, but he makes a very good point about what makes interoperability a reality:

"The WS-* work the industry has pursued since 1999 shows that we (vendors, customers, developers, pretty much everybody0 recognized that protocols were the sine-qua-non for interop. PROTOCOLS people, not programming models. Protocols, Protocols, Protocols, Protocols, Protocols, Protocols!

And let 1000 flowers bloom! Given a standard protocol, the world can support a myriad of programming models, and they can look like anything they want. As long as each implementation produces the same on-the-wire protocol, they can all intercommunicate. Glory be!"

One is tempted to say: "Finally!" or "Words of wisdom!" or even "Took 'em while, but they finally got there." Yes, Dino: I could not agree more. To enable full interoperability between particular software components running on different machines (and perhaps even operating system - and I mean to go beyond Windows 98, 2000, XP, 2003, Vista, CE, and mobile) you need full protocol disclosure. And just to clarify: this would mean syntax and semantics of all network communications between two systems that are meant to be interoperable.

So, if we are talking about OS level interoperability like "samba" or "PC NetLink" (yes, I've been that long at Sun) and "NT-SAM" or "Active Directory", this would also apply, correct? Can we expect a gesture towards the samba community in the near future?

Hoping for a positive answer on this one ...

tag: interoperability, interchangeability, WCF, J2EE

Here is a really nice add-on that got shipped with Solaris 10 update 4 (08/07): starting with this OS release, Solaris supports iSCSI targets. Together with the Microsoft iSCSI initiator for 2000/XP/2003, this allows building a very comprehensive and compelling SAN (Storage Area Network). Here is a screenshot:

Now, in order to get this to work, you need to do the following things:

1. Install Solaris 10 08/07 (update 4)

2. Install Windows and the Microsoft iSCSI initiator 2.05 build 3392

3. Follows these guidelines to configure a target

4. Read up on the MS initiator on how to discover and mount an iSCSI target

Overall, this procedure is not very difficult and you will have a system running within a few minutes. 

Please note that I did not (yet) test CHAP authentication or Vista compatibility, but - given some time - I will try this later.

tag: windows, iSCSI, Solaris

There has been quite a bit of discussion about SXIP's recent OpenID Infocard token profile: Johnny Bufu, Peter Williams, and I had some email exchanges, Eve commented on Eric's blog, and Dick made some comments about his view on the IPR status.

All this is great, exciting, or anything else you might want to use for describing conditions of euphoria. And I do acknowledge the work that Dick, Johnny, and Mike put into this effort. However, the big questions that are still unanswered (at least for me) is: who cares? And: are we hurting ourselves?

The Bigger Picture

If I take a look at the deployment rate of new-identity-protocol relying parties, i.e. mostly OpenID and Infocard, the picture is rather sobering: there is little activity^[1] and currently also few signs that this might change. One of the interesting results of the recent OpenID project at Sun was that successful web property owners have little or no interest in outsourcing their identity system, or even only the authentication part of it (which is the only established role of OpenID or Infocards at this time).

The same kind of behavior can also be seen on a larger scale where the big application and service providers like Google, Facebook, or Yahoo! have little or no real interest in a truly federated/distributed internet-wide identity system, since it is not compatible with their respective business models^[2].

So overall, it seems safe to assume that any effort directed at convincing web property owners to adopt a particular identity system is an uphill battle. Especially, if they have to invest time and money into equipping their web server with a compatible relying party.

OpenID Tokens, Anyone?

Now, what would be required to use the OpenID Infocard token profile? In addition to the entire OpenID infrastructure (OpenID Auth 2.0 et al.), you would also need a - more or less - complete Infocard infrastructure. In addition, you would need to make sure that the respective parts are tightly synchronized ^[3].

In addition, none of the OpenID specifications have passed extensive peer review in an open standards process, have IPR issues plastered all over them, and are - pretty much - all in beta (or pre-alpha) at this time.While these issues have been discussed in the past, it still seems reasonable to point out in this context.

Rolling out a complete and fully supported Infocard infrastructure is somewhat easier, since Microsoft is providing de facto reference implementations for the card selector and the relying party. Also, the IPR situation is less confusing, since the OSP covers - as far as I can see at this time - a pretty large chunk of the complete Infocard identity system.

Who cares now?

For a potential deployer, the question is now: "If I have an (almost) shrink-wrap identity called Windows CardSpace, why should I start to dabble with the deployment and replace the built-in SAML tokens with OpenID tokens?" Besides the technical difficulties, there is also the issue that an OpenID token based Infocard deployment only allow what is called "auditing mode". Add to that, that most clients will probaby not have Infocards with the OpenID tokens installed, my initial questions come up again: who cares? And: are we hurting ourselves?

Most end-users do not care at all. In an Infocard-world, they just want to use the Windows CardSpace selector to login. If a given site does not support self-signed cards or a managed card they already have, chances are that they will simply go away.

The relying parties do not care either: most of them want to attract users to their sites. If there is a simple SSO/identity system they can deploy and buy support for, they probably will as long as it fits their business model. Many successful Liberty deployments attest to that. If it involves unreleased or unsupportable technology, potential patent disputes, or simply a lot of additional work, they will likely shy away from such a solution.

There are also no benefits to the IdPs: having to run a combined OpenID/Infocard infrastructure might attribute only to a little administrative overhead, but it does not really add a lot of additional benefits either.

Are We Hurting Ourselves?

My answer to this would be a decisive: "yes". While the OpenID Infocard token replaces the HTTP redirect with the much more phishing resistant Infocard scheme, it will lead to some significant confusion in the marketplace. Educating customers and end-users might help to some extent, but explaining the differences between auditing and non-auditing mode is going to be very difficult. This is why Kim is rather careful about not advocating it: it breaks his own 7 laws.

At the end of the day, relying parties will have to decide what they want to do - and it seems to me that the decision for or against a particular identity system (such as Liberty, Infocard, or OpenID) will not be based on tokens, but rather on the entire package, including vendor support, reachable customers, and overall acceptance.

tag: identity, OpenID, Liberty Alliance, SSO, InfoCard

[1] Especially when comparing this with the rate of IdP rollouts for these protocols.

[2] In fact, I would argue that the interoperability debates of the 90s - WindowsNT/Active Directory, eDirectory, LDAP, etc. - were focused on the same issue of identity. At that time, it was the software suppliers fighting over identity WITHIN the enterprise, since control over the user database was the key to influence a lot of strategic decisions.

[3] To be fair, this is true for all complex interoperability scenarios.

tag:identity, opensource, opensso, ws-trust

During last week's Project Concordia call, we had an interesting discussion about cross-protocol identity use cases and scenarios. Ashish made a very good observation during this call: many times when we are discussing identity protocol transitions or cross-protocol use cases, we are not so much dealing with protocol interoperability, but rather with a protocol mashup.

Proper interoperability - in this definition - requires the ability to interpret foreign protocols and have full access to the semantical content. I have sometime referred to this level of interoperability as interchangeability. An example of such high level of interoperability would be the ability to extract authorization data from a Microsoft Kerberos ticket and use the NT-PAC data to create a SAML attribute statement.

A protocol mashup on the other hand would only require very limited knowledge about the semantics of another protocol, but instead it simply profiles the use of one protocol (or in this case: identity system) with another. A simple example would be the use of self-signed InfoCards to authenticate to an OpenID Provider.

tag: interoperability, identity, Liberty Alliance, OpenID, InfoCard

"The interop participants accomplished in two months of concentrated effort what it would probably have taken them a year to do working independently without the looming deadline provided by the Catalyst demo."

"While it is still fair to say that user-centric identity technology is in its infancy, if progress continues at this rate the technology should be ready for enterprise adoption within a year."

Today, we (pre)-announced at the IIW 2007 a non-assertion covenant (NAC) for OpenID. What does this mean?

First, the NAC is a short (three paragraphs) legally binding document that licenses all of Sun's patents (and not only necessary claims) to anybody for the purpose of implementing OpenID 1.1 Auth and Simple Reg 1.0 ... in perpetuity ... royalty-free. This license will only be withdrawn, if someone decides to sue Sun over this technology.As far as I know, this is the first covenant like this around OpenID.

Sun has issued already some of these - one on ODF and another one on SAML. Everytime, this prompted similar licenses and promises from other companies. Note that this move is so far totally unilateral - we (Sun) clear the way for the OpenID community as much as we can. Now it is up to other companies to do the same thing and show their commitment to the open source community.

The official announcement of this NAC will appear soon on the "On the Record" marketing blog at blogs.sun.com.

Finally, here is a picture by David showing Eve, Bill and myself making the announcement:

tag: OpenID, sunopenid, IIW2007, opensource

tag:AJAX, jMaki, Silverlight, Interoperability

After that, Phil is inviting again to IIW 2007 which will certainly be interesting and entertaining. I promise to post frequent updates on what is going on there, as well.

tag:iiw2007, javaone, Identity, Open Source

This morning (PST), Roger Sullivan announced Lberty's new project called openLiberty.org. This community oriented website aims at providing developers and architects with open source implementations of Liberty's suite of identity protocols. I am really looking forward to seeing a lot of dicussion happening there.

tag: Liberty Alliance, Identity, Open Source

Now - here is something quite interesting about Java directions: I was only remotely aware of JSR 277 - Java Modules - and took really no big interest in it. However, this effort might solve some of the self-inflicted problems that I had to deal with regarding OSGi bundles.

JSR 277 (which is currently in early draft) aims at provinding a simple class versioning mechanism that allows some of the features of OSGi bundles. Stanley Ho has written some explanatory material on this JSR - from what I could gather, it should be - at least principally - not too hard for OSGi to deal with Java Modules. Now if we only could get it working the other way round ...

James McGovern asks whether federated identity might require (at least sometimes) federated authorization. I think this is a pretty good question and one that is not easy to answer. My initial take on this would be that federated identity should not require federated authorization, assuming that I understand correctly what federated authorization really is.

For simplicity's sake, let identity be just a bag full of attributes (e.g. e-mail address, names, phone number, etc.). An indentity provider is then nothing more than a service that asserts that certain attributes have a particular value for a given digital identity. A relying party (i.e. a service provider like e.g. AmazingBookStore) can choose to trust such an assertion - either in full, or just certain parts of it. At the end of the day, the relying party will have to determine the level of access based on the type of assertion and the content of the "attribute bag". As such, in this case authorization is local.

If authorization is to be delegated to another point (as in e.g. the XACML model), the relying party forwards it to a policy decision point, where the contained attribute information and additional attributes the PDP might obtain are evaluated according to a set of policies.

Now what is federated authorization? If I understand it correctly, it would be a scenario where you trust access level decisions to your resources to a third party (e.g. you would let YahaPortals.COM decide whether or not a user can get access to data you own). I am tempted to say that the risk that YahaPortals has about a false negative or false positive decision is quite substantial, particularly in our age of increased liability.

While there might be some use cases that do (or will) require such a model, I would argue that XACML provides a pretty substantial technology base for a federated authorization system, should the need arise. Some additional elements for such a system (e.g. trust establishment, crypto, etc.) could be either profiled or application specific.

UPDATE: As usual (at least in the last couple of weeks), I am quite behind things. James apparendly commented on quite a few blogs (hmm, was that related to IIW tagging ... noooo, can't be) and got some pretty substantial answers from Pat, Conor, and Paul.

Today I sent a mail to OSIS-General on using OpenSSO for the Identity System/Selector that we are trying to build:

We at Sun would like to offer/suggest OpenSSO (
http://opensso.dev.java.net/) as a open
source project within the OSIS

framework. I believe OSIS could benefit from the technologies that are

either already implemented within OpenSSO or 'very soon to be released',

including SAML 1.x, SAML 2.0, ID-* etc. For additional information on

OpenSSO, please take a look at Pat Paterson's blog at: 

http://blogs.sun.com/superpat/entry/recently_asked_questions_on_opensso

and 

http://blogs.sun.com/superpat/entry/first_multi_protocol_federated_ident

ity. 

Given the existing large code base of OpenSSO (and still growing), we should be a significant step ahead in the goal of creating a OSIS. 

Here is my mail to Mike Jones on the OSP:

Hello Mike - 



First of all this is most excellent news - and I am looking forward to

seeing those protocols being implemented by a large number of market

participants. 



However, I do have a few questions that you might be able to clarify: 



1. For the purposes of OSIS, there are some components in the WCS that

do no seem to be covered, in particular the InfoCard specifications,

including schema and the visual components for the card selector UI.

Will this be covered by a separate covenant?


2. Also, the language of the OSP mentions that only Necessary Claims,

i.e. those REQUIRED in the specs are covered. What about OPTIONAL, etc.

portions of the specs?


Thanks a lot, 



Gerald Beuchelt 

At this point I would like to thank Mike and also Kim for their work on getting the WS-* protocolsl into the OSP and - hopefully - all the other specifications that will follow ;-)

Microsoft today announced their "Open Specifications Promise", essentially a non-assertion covenant for a huge chunk of WS-* protocols. This OSP means (as fas as I can tell - and I am NOT a lawyer ;-)) that people can start implementing WS-* specifications without having to fear any action from Microsoft, as long as they do not sue Microsoft over these specs - duh!

This is quite good news for a number of reasons:

1. All existing implementations of WS-* technology are safe from any legal harassment from Microsoft. Not that they would do this necessarily, but this covenant gives peace of mind.
   
2. Since pretty much all security specs are out, OSIS and Higgins are now in a much better position to implement a WCS compatible InfoCard selector.
3. The best thing about this is the fundamental mindshift at Microsoft. A couple of years ago this would have been unthinkable. Now it is real. This is really major change in the way Microsoft deals with the open source community. It can be hoped that this OSP is just the beginning of a much more open discussion with Microsoft.
   

Higgins

Bandit

As you might know, Sun is shutting down their operations during the 4th of July week, so my bloggin will be fairly light over the next couple of days. A few thinks that I intend to spend some thoughts on over this break include:

• Is user-centric identity - as implemented by CardSpace - truly useful for interoperable and privacy-encouraging identity? The obvious interoperability limitation is the somewhat artificial restriction of WCS to WS-Trust. But I think there are other problems with WCS as well: will it be "just another box we have to click away"? If identity information about a user can be transmitted with a single click (by releasing an InfoCard), users might get lured into giving away personal information more easily, effectively having a negative impact on privacy. A good example is the AutoFill function of the Google toolbar: since I am using it, I am a lot less careful about giving away PII - when I still had to enter everything by hand, I was always thinking twice about releasing information.

• How can a CardSpace-like model play well with REST/POX web services? The whole question of lightweight identity enabled web services and application is still quite open.

• Will Germany make it to the Finals? THAT question will be answered on July 4.

Microsoft's Atlas framework for AJaX got some harsh comments from Microsoft's partner Wintellect about the lack of cross-browser interoperability. At the end of the day, AJaX really came up because tht different component frameworks and client capabilities are so disjoints, that for a long time there was no way you could build a rich Web UI. With Atlas only supporting IE (for the interesteing parts, at the very least), the benefits of AJaX go away.

So if Microsoft is truley serious about making Atlas a usable AJaX framework, they will have to support Firefox and Safari, at the very least.

This is really good news for all SAML fans: Sun released a non-assertion covenant (NAC) for SAML v2, similar to the one that covers the Open Document Format since last year. This means that the last (and as far as I know) only hurdle for vendors (like e.g. Microsoft) to implement SAML v2 is gone. It will be really interesting to see when and - more importantly - who will pick up on this offer.

Kirill's and my chalk talk session this afternoon went prretty well: we had an interested (and interesting) audience of about 20 people that attended. Kirill started off with introducing the Sun/Microsoft relationship and some of the achievements of the past year.

I then gave a fairly technical introduction of FIFI and a detailed code demo. Kirill finished with the WSIT/WCF interoperability scenario from JavaOne, including a demo.

I will post the slides here soon.

CONTLC37 - Enterprise Web Services Interoperability between .NET and Java Using WCF and Sun's GlassFish

Connected Systems Theater 2, Blue Arena in TLC, Wed June 14th, 14:00 - 15:15

Here is the link for the Chalk Talk sessions at TechEd:

http://wcf.netfx3.com/content/TechEd2006ChalkTalkSchedule.aspx

Note the FIFI session at about two-thirds of the page: it is on Wednesday at 2pm in theater CON2.

David Chappell made some interesting remarks on Java and NetFX during his TechEd session and on his blog. He compares the creation of SCA by IBM, BEA and some others to the creation of the .NET Framework in 2000.

I would put this somewhat differently: .NET in 2000 was a (somewhat late) reaction to the success of the Java platform. As .NET evolved, itwent - essentially - through the same issues as Java: 1.0 was essentially unusuable, 1.1 kinda worked, and 2.0 (or 1.2 in Java) is/was the first truely usable platform. In this sense, SCA is comparable to the announcement of the Longhorn pillars, at best.

In his TechEd session this morning, David was trying to compare SCA with WCF. He noted that while WCF is in its final beta stages, SCA is just starting with the definition. This is certainly true. However, there are other simplifying APIs (such as EJB3, JBI/OpenESB, WSIT) that have a similar architectural scope as WCF and are in final beta as well. I strongly recommend reading the comment section of David's blog article as well, since it contains a lot of interesting pointers.

I have finally come around to summarize some of the architectural ideas around FastInfoset For Indigo. You can find the initial version on my Wiki.

I will continue to update this article and also put the various presentations there. This should be a good primer for my Chalk Talk next week at TechEd in Boston.

At this time, most of you have probably heard about the Web Services Interoperability Toolkit for Java (a.k.a. Project Tango), which enables maximal interoperability between the upcoming Windows Communication Foundation on .NET and the Java world. If not, go see http://wsit.dev.java.net/ ASAP.

WSIT will be tightly integrated with the Glassfish Sun Application Server, which also features full FastInoset support. In fact, Glassfish will - based on the HTTP header content type - automatically switch between text+xml and application/fastinfoset.

Now, with the WCF integration that FIFI will deliver, you will be able to configure an Indigo client at deploy time (or even after) to use the by far more efficient FI encoding. And this (re)configuration will only take a change in a single line in the .config file of that client (assuming that you are using a CustomBinding in the first place ;-)).

So, at the end of the day, you can start you deployment of SOAP and RESTful Web Services with angle brackets and as soon as you need a more efficient encoding, you switch to FI by simply setting the right config parameter in the WCF client. Can it be less painful?