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

Interesting news this week: Microsoft, SAP, and Siemens have been awarded the SAML interoperable certification for their SAML 2.0 products for the first time. From a customer perspective this excellent news - cross-vendor certifications by independent third parties are a good decisions tools for selecting products. While even a comprehensive test suite cannot guarantee perfect interoperability, it puts the responsibility for debugging the most blatant problem into the court of the vendors.

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.

The obvious open questions are crypto key and chunk table management, especially since these become high-value targets. Master key techniques and independent RAIS systems can address some of these issues through best practices.

tags: data privacy intellectual 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: hData ehr health care hl7

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: interoperability government

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 law IPR patents

During TechEd 2008, I participated in a Panel discussion on Web Services Interoperability. Microsoft just put up the tape on their TechNet Library site. They also have a WMV video feed, and a MP3 audio-only feed.

Just back from Orlando, here are some takeaways from this year's TechEd 2008 for IT-pros:

• 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

Eve was kind enough to link to my earlier article on our CardSpace Deep Dive. In that post she mentions our whiteboard notes, that I took at picture of, after all:

Cards based on X.509 authentication are almost working ... there is still a small issue with identifying the right certs based on the thumbprint. Overall, a fairly good result, I'd say

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

Here is a small update on available .NET FastInfoset (X.891) libraries:

• 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.
  

There is a trial available from both vendors.

If there is still interest in the community, I would be happy to revisit my FIFI code and release it publicly. Please send me a message if this was important to you.

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

Paul Trevithick just announced that Higgins will start developing a SAML 2.0 compliant card selector, that will - in addition to Windows CardSpace compatible i-cards - support SAML 2.0 compatible "s-cards"^[1]. This will be quite interesting to follow, in particular if Higgins really supports the SAML 2.0 protocol (not only the token format). In that case it would really step up to be part of the identity meta system (actually: the Aleph 0 Identity System ).

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.

Just a quick update: OpenSSO is now using the WSIT/Metro STS for WS-Trust protocol transactions. Congratulations to the team (and especially Mrudul) for getting this done!

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

Both Paul and Robin beat me to this ...

The recently published report by Burton's Bob Blakley summarizes the result of an interoperability testing fest at the Burton Catalyst conference earlier this year. This venue was a great success for the Windows CardSpace identity system, since it was the second OSIS event where a variety of open source projects and closed source commercial products demonstrated a significant level of interoperability. Given the early and evolving state of the InfoCard system, this is a great success for all parties involved.

However, Bob is somewhat mistaken in parts of his article:

"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."

This is not quite correct - the Catalyst interop fest was the second such event organized by OSIS. The first one was held earlier at the Internet Identity Workshop 2007. Results and blog reports on this can be found all over. Having been a member of OSIS for some time now, I find it a little unfair that this interesting (un)organization - that certainly had its ups and downs - is not given the credit it deserves.

"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."

I am surprised to see such a bold statement, especially since even some of the core developers and architects not quite happy with the term "user-centric identity". Let's just step back and start to count how many glossaries, lexicons, and lists-of-used-terms define digital identity, identity system, user, and user-centric in different ways with sometimes completely different semantics. Predicting enterprise adoption within a year seems a little overly optimistic to me, especially if we consider that there are still a number of significant issues even within the reference implementation of the InfoCard identity system.

As Mark Wahl has pointed out earlier, most of the issues encountered during the second OSIS interoperability fest are related to the lack of proper schema management for attributes and their semantics [1]. The only project in the Infocard system currently working on these issues is Higgins, with their use of OWL (although some people might argue that this is technological overkill).

Outside of the InfoCard system, there have been other efforts to get to at least some standardization of attribute interpretation (SAML attribute profiles, which work nicely with LDAP/X.500 and XACML and other likely sources) and work is being taken up by Liberty to standardize identity attribute sharing rules (e.g. the IGF/IDG work, based on CARML/AAPML).

At the end of the day (closing the loop and coming back to Paul's and Robin's point): Even though there have been a number of different products and projects that successfully worked together, this technology is a far cry from being an identity meta-system. Multiple-protocol interop on the wire would be a true metasystem, and is a goal that various systems -- Liberty, OpenID, and Windows CardSpace included -- would need to work on together. Concordia is (probably more than) a first step towards this goal.

tag: identity, IIW2007, interoperability, InfoCard, WCS
 
[1] Obviously a lesson well learned through the LDAP and - even worse - LDUP discussions.

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

Marina Fisher and I will be presenting on AJAX interoperability here at JavaOne on Thursday at 5:30pm in Esplanade 302. We will be covering jMaki, WCF, Silverlight/ASP.NET AJAX and Java REST API interoperability. For more details, go here. 

tag: AJAX, jMaki, Silverlight, Interoperability

Here is a nice short article by Scott Hanselman on what is currently happening in .NET land - especially at MIX07. I find his graphic on the evolution of the various .NET technologies quite interesting and helpful. A couple of interesting take aways and comments:

- Silverlight 1.1 alpha, along with the "CoreCLR" will be interesting to disect. According to Scott, there is nothing "micro or tiny" about this runtime, only sane refactoring. That might be so, but the Base Class Library amounts to somthing of a Micro/Mobile edition ...?!

- The Dynamic Language Runtime is interesting - but I am not quite so optimistic to believe that the Microsoft Permissve License will really win the "hearts and minds" of the hardcore open source community...

- The JavaScript/CLR (in process?) integration sound *really* interesting.

Ultimately, the success of Silverlight and the CoreCLR program will probably depends on platform support. And as Sun has learned very painfully, sufficent platform support can only be achieved with truely open source software.

The next two weeks (three weeks really) are going to be interesting: first I will present at JavaOne on AJAX interop, together with Marina Fisher. This JavaOne should get really exciting for a whole number of reasons, especially for the open source identity community ... stay tuned.

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 ...

tag: JSR 277, OSGi

WS-Federation 1.1 is out... and skipping through the TOC, I have this strange feeling of deja vu.

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.
   

Here are the architectural overview pages for Project Higgins and Project Bandit:

Higgins

Overview: http://spwiki.editme.com/HigginsIntroduction

Presentation: http://spwiki.editme.com/HigginsOverview2

Bandit

Architecture: http://www.bandit-project.org/index.php/Architecture_and_Design

Roadmap: http://www.bandit-project.org/index.php/Roadmap

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.

Kirill posted his session schedule for TechEd. Just as a final reminder, FIFI s on:

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

 

The FIFI segment of his talk should be particularly interesting for you if you want to learn more about writing your own MessageEncoder and XmlWriter and XmlReader. There will be some discussion on the architecture of the encoding layer and the serialization as well.
We will also talk about WS-ReliableMessaging interoperability and Infocard identity interoperability between the NetFX stack and Java.

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.

So, I am deep in FIFI right now. There will be two presentations on the project in the next couple of weeks:

SunLabs Open House 2006
June 1-2, 2006, Sun Menlo Park Campus, Bldg. 16
Track: 6
Room: 1281
Title: Project FIFI
Abstract: Fast Infoset is a ITU-T/ISO standard for effricient XML encoding. It is available for Java through the JWSDP and the Java.Net open source project. FIFI provides an implementation on Microsoft's .NET platform.
Time: June 1, 2:30-3:00pm PST


Microsoft TechEd 2006
June 11-16, 2006, Boston Convention Center
Track: Connected Systems
Code: CON-TLC307
Title: Enterprise WebServices interoperability between .Net and Java using WCF and Sun's GlassFish
Abstract: Web Services matured to address enterprise needs.
Interoperability between Java and .Net on Secure, Reliable and Binary messaging is a reality. Come and see .Net and Java interoperating in a real world enterprise scenario using Microsoft's Windows Communication Foundation and Sun's GlassFish web services stacks
Time: Breakout 13, CON Theatre 2; Wed, 14 Jun, 2:00 - 3:15 (Eastern)

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?

Finally, with a lot of help from sgen.exe and a number of very talented inidividuals, I got the complex types to work this morning. The biggest issue was the way WCF compares Strings:
Java does sttring interning, .NET does not do this by default (this is why (object) string1 == (object) string2 is without further consideration a bad idea). Within the XML serialization framework however, WCF uses a NameTable to "atomize" (i.e. intern) strings. The Reader must return interned versions of the name, localName, namespace, etc. or the string comparisons in the generated classes will fail. Here is a sample from the generated code:

while (Reader.NodeType != System.Xml.XmlNodeType.EndElement &&
        Reader.NodeType != System.Xml.XmlNodeType.None) {

    if (Reader.NodeType == System.Xml.XmlNodeType.Element) {
        if (!paramsRead[0] && ((object) Reader.LocalName ==  (object)id4_agedHelloResponse &&
                (object) Reader.NamespaceURI == (object)id2_Item)) {
            o.@agedHelloResponse = Read4_agedHelloResponse(false, true);
            paramsRead[0] = true;
        }
        else {
            UnknownNode((object)o, @":agedHelloResponse");
        }
    }
    else {
        UnknownNode((object)o, @":agedHelloResponse");
    }
}

After fixing the Properties on XmlFiReader, it can now deserialize complex objects, and - as such - also use doc/lit in addition to rpc.

Here are the slides for the BOF.

FIFI-BOF-2535.pdf (424.64 KB)

There is the obvious question on why FastInfoset and - more importantly for me at this time - why on Indigo (WCF)?

A lot of customers - particularly in the financial industry - have expressed their concern about XML and its 'bloatiness': it is simply to verbose to be useful in 10M, 100M or even Gigabyte sized transactions. This makes a lot of sense and thus, FastInfoset (and similar efficent XML initiatives) were born out of this need.

Sun has been behind FastInfoset from its inception and the current JWSDP and the Glassfish application server fully support FI. It has been a clearly stated goal that we see FI as our strategic binary Infoset representation scheme and we would like to achieve ubiquity.

To achieve such ubiquity, it is mandatory to cover as much server and client platforms as possible. With FI being available for the Java platform - supported and open source - this goal is actually achievable. But in order to be truely successful, it is also necessary to enable non-Java platforms to exchange messages in FI. FIFI aims at just that: to enable FI processing for .NET 2.0 and FI message exchange for WCF.

Reminder: the FIFI BOF at JavaONE is tomorrow, May 17, at 9:30pm in Hall E.

Huh? How are these two things related at all?

Well ... On last Friday I had a terrible Hard Drive crash, eliminating about 10 days worth of FIFI coding. That resulted - obviously - a lot of unhappy coding over the weekend. Fortunately, I was able to redo pretty much all code loss by Monday morning... which shows that trying to get a completely new MessageEncoder working with WCF is a lot of reengineering and much less actual coding (thank the gods of Redmond Kobol for stop and continue in Visual Studio).

Anyway, with some substantial help from Paul and my rejuvenated FIFI code, we got RPC/encoded working.

As for doc/lit: the deserialization framework in .NET 2.0 is quite complex. Having said that, here is a little question for anybody knowledgable about the XmlFormatter (and/or DataContractSerializer et al.):

How does WCF deserialize the SOAP message Body exactly?

If you know the answer, please let me know.

Coming back to the original question: a hard drive crash prompted me to recode portions of FIFI, enabling me essentially to dig a little deeper into the WCF stack. And the glass is half-full.

You might know that StAX (JSR 173) and the System.Xml.XmlReader/Writer classes are quite similar, at the very least in scope. A very interesting difference (that gave me a lot of grief in porting/implementing these APIs) is the way namespace attributes are being treated.

In StAX, namespace attributes are typically dealt with through different calls than those used for 'normal' attributes. This special treatment also comes with a table, where defined namespaces can be stored and referenced. In .NET, a namespace attribute is just another attribute, but they also have an XML namespace table, managing prefixes and scope.

While the differences are only significant on layer 8 and 9 of the ISO stack (politics and religion), porting from one to the other API is quite interesting and - at times - forces you to think about the infoset in new ways.

WCF can be quite annoying - that is, it sometimes does thing in a way I personally don't like.

While happily coding FIFI (the Fast Infoset implementation for WCF that will be demoed on JavaOne), I noticed that the System.ServiceModel.Message.Write(XmlWriter) method does not use WriteStartDocument and WriteEndDocument. This is quite annoying, since nodes in FI need to be properly terminated. Sigh ...

If you are at all interested in non-SOAPy web services, you might want to take a close  look at WADL, the Web Application (!) Description Language. It is an XML based language that can be used to describe general HTTP-based service APIs that can not be described reasonably in other meta-description frameworks, such as WSDL.

Ultimately, this technology will allow web service providers (such as Amazon, Ebay, Google, Yahoo!) to focus on providing their respective services, and not on creating new APIs in a variety of languages to use these services.

After an interesting panel discussion yesterday at the Network Security 2006Conference, I started to think about security protocols in general again. One comment from a gentleman in the audience struck me in particular: PKI (and other authentication systems) are hard to setup and control, because every time you create a new authentication service you have to fill in all kind of attributes for the user at hand, e.g. name, employee id, group membership etc.

As we all know, directories are great, but they are not exactly capable of solving this problem. Instead, this problem could be solved by separating authentication and autorization data, keeping the authZ data in a common format [1]. SAML (in particular attribute statements) might be a good solution for the authZ data format, since it is well undestood, extensible and has good privacy features. But obviously, there might be other good, open authZ languages, as well.

If the authentication mechanism are now capable of carrying the authZ data (such as the in the SAML TLS proposal, or in GSS-SAML), then a few requirements of a good authorization model are fullfilled:

1. The authorization data is described by an open language.
   
2. The authorization language is stable across different authentication mechanisms.
3. It can be carried directly within the framework of the authentication protocol, - or -
   it can be left on the authorization server an only be referrenced.
   
4. It provides at least for pseudonymity, if properly properly profiled also for anonymous authorization.
   

[1] I am assuming here that a bag of attributes is sufficient to enable authZ decisions.

On May 17, 2006 at 9:30pm Paul, Santiago and I will host a BOF on "Project FIFI - Bridging the Interoperability Chasm". FIFI (Fast Infoset For Indigo) is a prototype project that aims at bringing the Fast Infoset ITU-T/ISO standard to the .NET 2.0 platform and furthermore integrating it with the upcoming Windows Communication Framework (WCF - aka Indigo).

BOF 2535: Project FIFI - Bridging the Interoperability Chasm
Track: Web Tier
Room: Hall E 135
Date: 17-MAY-06
Start Time: 21:30

Stay tuned for more.

Fresh from Washington state: Indigo to support POX in TextEncoder

Combine this with Marc Hadley's adventures with REST in JAX-WS, and you might actually get something interoperable ..

In an earlier article, I showed how to make a system dual-boot Windows Vista and Debian Linux through GRUB. This was fairly straightforward, even with the new boot loader (BCD) that ships with the latest Vista builds. All of that happened in a reasonably simple environment - I used Microsoft Virtual PC 2004 SP1 to run Vista build 5342 and Debian.

This time, things are bound to get a little bit more interesting: I am installing Vista build 5342 on a Sun Ultra 40 AMD workstation. The other OS is - obviously - Solaris 10 01/06 (Update 1).

The overall procedure is very similar to what I have described before:

1. Install Windows Vista

2. Install Solaris and edit /boot/grub/menu.lst as described here.

STOP: Solaris is not quite as smart about the boot loaders as GRUB and does some strange things to the MBR - OR - Vista x64 has a different behavior about writing its boot records. At this point, I could start Solaris by default. Vista did NOT boot for me - it was complaining about \Windows\System32\Winload.exe missing.

As such, I ran the System Recovery option from the Vista boot DVD, which reinstalled the Vista boot loaders. To be sure, I ran the bootsect.exe with switch /nt60 on the SYS volume.

For the restore options it is very important that you decline to have the boot problems fixed automatically .Just say "No" and click "Next" and you will be taken to a menu where you can get a full Windows shell - this is MUCH better than the recovery console.

3. Reboot into the Windows shell on the Vista Install DVD.

4. bcdedit /set {default} device partition=c:

5. bcdedit /set {default} osdevice partition=c:

6. Run d:\boot\bootsect /nt60 c:

You should be all set.

If you screw up GRUB

Now back into booting Solaris by throwing the Solaris install DVD into the drive, going to the command prompt of grub and specifying

	root (hd0,1,a)
        kernel /platform/i86pc/multiboot
        module /platform/i86pc/boot_archive

Great. Solaris boots. Now run installgrub(1M) with the following arguments:

installgrub /boot/grub/stage1 -m /boot/grub/stage2 /dev/rdsk/(this is the char device for your root slice)

NOTE: After you re-install GRUB, you will need to go back to the Vista Recovery console.

Erwin Tenhumberg made some remarks on his blog that I would like to comment.

Microsoft trying to support their legacy products with an open standard is not an oxymoron. It would certainly be a lofty goal and would find my full support.

The problem that they are facing however, is that this goal is not only lofty, but extremely hard to achieve within a reasonable time frame. The old MS Office file formats are not trivial and they support OLE objects. To come up with a truely open format to support this and many other features, some of which haev been created by their 3rd party ISV's, is very hard.

If you consider now the time and market pressure, Microsoft was in need of choosing between a truely open format and a somewhat documented proprietary format. They chose the later for business reasons (I guess). One issue with a truely open format would have been the problem that public stewartship of the protocol would have further delayed either Office 12 or the implementation of that format in Office 12.

The fact that they are now trying to sell the 'OpenXML' format as open is somewhat dubious. Even worse is the proposed ECMA seal-of-approval for a subset of the output of Office 12 [1] and its submission to ISO/ITU-T for consideration as an international standard. 'Open' means much more that RAND - see e.g. the Minnesota house draft.

[1] The OpenXML specification does not include the full specifications for OPC. While straightforward (I am tempted to say 'copied from Star/OpenOffice' ...), Microsoft could potentially stall, delay and/or deter implementations for OPC through legal means. Office 12 creates OpenXML documents that are contained in OPC files. See here for some more discussions on this.

Once more, I am trying if dasBlog and JRoller are finaly cooperating. This is the first entry to be cross posted. Let's see if this works. Since I am using dasBlog as my Main blog, here are the settings for crossposting to http://blogs.sun.com/roller/page/beuchelt:

Profile Name
Host Name		Port
Username		(set)
Password		Repeat
Endpoint		API Type	Blogger

Windows Vista introduces a new 'Network Level Authentication' mechanism to RDP. It will be intereting to find out what they are doing there exactly, but meanwhile you might want to be able to use your legacy RDP clients to access your Vista desktop. Here is how you do this:

To configure Vista for the old RDP clients, go to Control Panel -> System -> Advanced System Settings. Select the "Remote" tab and then "Allow connections from computers running any version of Remote Desktop". That works - at the very least - good for mstsc.exe on Windows.

Here is a screen shot (Build 5342):

Now, the interesting thing would be to get this to work with rdesktop(1) and similar non-Windows RDP clients as well. Unfortunately, the latest Build 5342 is very uncooperative here. rdesktop fails miserably. Compare the TCP streams (upper one is rdesktop, lower one is mstsc.exe on Windows XP SP2):

Again through ConsortiumInfo: Minnesota is introducing a bill that will require the state CIO to chose products that support open standards over those that feature proprietary ones. This is definitvely good news, particularly when looking at the extensive definition of "open" in the text (H.F. 3971, 1.1 (f)):

(f) "Open standards" means specifications for the encoding and transfer of computer 
data that: 
(1) is free for all to implement and use in perpetuity, with no royalty or fee; 
(2) has no restrictions on the use of data stored in the format; 
(3) has no restrictions on the creation of software that stores, transmits, receives, or 
accesses data codified in such way; 
(4) has a specification available for all to read, in a human-readable format, written 
in commonly accepted technical language; 
(5) is documented, so that anyone can write software that can read and interpret the 
complete semantics of any data file stored in the data format; 
(6) if it allows extensions, ensures that all extensions of the data format are 
themselves documented and have the other characteristics of an open data format; 
(7) allows any file written in that format to be identified as adhering or not adhering 
to the format; 
(8) if it includes any use of encryption, provides that the encryption algorithm is 
usable on a royalty-free, nondiscriminatory manner in perpetuity, and is documented 
so that anyone in possession of the appropriate encryption key or keys is able to write 
software to unencrypt the data.

Wow - this goes definitively far beyond RAND and comes pretty close to my understanding of what 'open' really means.

It seems noteworthy that as per provision (6) in this list, the 'openness' of a data format is quite viral in the sense that it requires all descendants to be 'open' as well. One problem that I have with this provision is that the standard itself cannot gurantee that any descendants will be open - if there is an extension point, any implementator could choose to extend without documenting. This should be clarified in the text, maybe to the extend that it should reference the implementation, not the standard.

Since Vista features the new boot loader system, multi-boot is not quite so trivial. There are various guides and FAQs on how to do XP/Vista dual boot (see e.g. here or here), but getting a GRUB based OS (such as Solaris 10 U1 or Debian Linux 3.1) dual booted is not very well documented.

I used the 5342 build of Vista, which ships with the bootsect.exe command in the \boot directory of the installation medium (in my case a DVD ISO image). Ths utility is only needed if you want to go back to the original Vista boot loader by running: bootsect.exe /nt60 ALL

I first installed Vista on my system with all defaults on my first hard drive (IDE 0:0). The new boot loader was in place on the MBR for that drive.

Now I installed Debian and agreed that GRUB should take over the MBR for the IDE 0:0 drive (/dev/hda). After that, Vista became invisible and Debian booted just fine from /dev/hdb (IDE 0:1).

Now, in Debian, you have to edit the /boot/grub/menu.lst that configures grub at run time. I simply added an entry for Vista:

title	Windows Vista (Build 5342)
root	(hd0,0)
makeactive
chainloader	+1

Then you simply reboot and - voila: it should offer you a menu item for Vista. If you select that, the Vista boot loader takes over and the Windows OS comes up.

Some notes:

• I was using Virtual PC 2004 SP1 for this experiment. That is also the reason why I did not use Solaris 10, since VPC and Solaris are not really a happy couple. Since Solaris 10 U1 also uses GRUB, there should be no difference.
  
• For some strange reason I am getting a "Boot Failure" prompt now, right after the BIOS check. After hitting the <any> Key, I get to the GRUB menu.
• I have no idea if this will work similar on AMD x86 machines.
  

Marc is working on a nice and *clean* web application description language (WADL) that can be used for non-SOAP web services as well.

For an introduction to RESTful web services with JAX-WS, please take a look at his recent post. It might be an interesting excercise to get this to work with Clemens' RESTful extension for WCF.

There are a couple of quite interesting developments in the office document formats discussion. One if them being that the Australian National Archive is now moving their entire content to ODF. This can be considered a major victory for ODF on the long road to broad government adoption.

A little mixed is the current situation at SC 34 of ISO regarding the formal standardization of ODF through ISO/ITU-T: since Microsoft recently joined the sub-committee working on this, there is the possibility that they are trying to stall the process, until their OpenXML formats make ECMA and thus go head to head with ODF.

Microsoft on the other side is now also sponsoring a community dedicated to working with their XML office formats. There is nothing about the binary formats (yet?), but it hosts a few interesting articles and links, including a high-level introduction to the packaging model.

Pat found this interesting article by Chuck. It is on a Java implementation of the InfoCard protocol.

Tags: InfoCard, Interoperability, Java, Identity

Now that I have less time than ususal, it might be a good time to restart some of my GSS-SAML efforts. If you are interested, I suggest you subscribe to saml-mechanism@washington.edu and/or check the archives.

To get something for the Montreal IETF meeting, I will coordinate writing a draft. Please let me know if you are interested.

Tags: GSS-SAML, SAML

Interoperability is probably one of the most misused terms in the IT industry in these days. In a former job, I was confronted with actually defining Interoperability or finding an established definition for it. If you search for definitions for Interoperability (e.g. in Google, you will probably run into the IEEE definition). While this definition is useful as a starter, it certainly does not take you all the way of capturing what Interoperability really is.

A better and more complete definition of Interoperability can be found in the NATO Handbook and the U.S. Federal Standard 1037C. In these definitions (which are the same), there are essentially four levels of interoperability, namely:

• compatibility: 1.Capability of two or more items or components of equipment or material to exist or function in the same system or environment without mutual interference. [JP1] (188) 2. In computing, the ability to execute a given program on different types of computers without modification of the program or the computers. 3. The capability that allows the substitution of one subsystem (storage facility), or of one functional unit (e.g. , hardware , software), for the originally designated system or functional unit in a relatively transparent manner, without loss of information and without the introduction of errors.

• interoperability: 1. The ability of systems, units, or forces to provide services to and accept services from other systems, units or forces and to use the services so exchanged to enable them to operate effectively together. [JP1] 2. The condition achieved among communications-electronics systems or items of communications-electronics equipment when information or services can be exchanged directly and satisfactorily between them and/or their users. The degree of interoperability should be defined when referring to specific cases. [JP1] (188)

• interchangeability: A condition which exists when two or more items possess such functional and physical characteristics as to be equivalent in performance and durability, and are capable of being exchanged one for the other without alteration of the items themselves, or of adjoining items, except for adjustment, and without selection for fit and performance. [JP1]

• commonality: 1. A quality that applies to materiel or systems: (a) possessing like and interchangeable characteristics enabling each to be utilized, or operated and maintained by personnel trained on the others without additional specialized training; (b) having interchangeable repair parts and/or components; (c) applying to consumable items interchangeably equivalent without adjustment. 2. Pertaining to equipment or systems that have the quality of one entity possessing like and interchangeable parts with another equipment or system entity. (188) 3. Pertaining to system design in which a given part can be used in more than one place in the system, i.e., subsystems and components have parts in common. Note: Examples of commonality include the use of a firing pin that fits in many different weapons and the use of a light source that fits in many different types of fiber optic transmitters. 

Now, on different layers in the network and application stack there are typically different levels of Interoperability: 

• Ethernet has - by now, for all practical purposes - achieved commonality.
• The TCP/UDP/IP stack is - at the least - highly interchangable, if not better.
• Application protocols, such as NFS or HTTP, are at the least highly interoperable, if not interchangeable.
• HTML is probably mostly interoperable, but there are definitively areas where we do not get past compatibility.

There is a tendency to achieve lower levels of interoperability the higher you go up in the network and application stack. The question of why this general rule applies is quite interesting. I personally think that creating a two-dimensional matrix of levels of interoperability and layers in the network stack are quite helpful when trying to improve interoperability at higher levels.

When looking at higher level protocols, one has to recognize that they typically carry a lot more semantics than lower level ones. Protocols - as they are currently created - are quite capable of capturing syntax, but not quite so much semantics. E.g., there is virtually no semantics in the header of an Ethernet or even an IP packet, but there is a lot of semantics in how to interpret HTML tags. There is however a tendency that - eventually - the level of interoperability on a given level increases, as time passes by the different implementation of a syntax-centric protocol converge.

It would be quite interesting to develop an approach that would allow to speed up the settling on semantic terms.

Interesting timing: just as ATOM 1.0 is finally becoming an IETF/W3C standard, Microsoft publishes her extension to RSS 2.0 here. While the Microsoft extensions are licensed under the Creative Commons ShareAlike license and Microsoft also seems to pledge to not apply royalties to implementors, RSS 2.0 is still under copyright from Harvard and cannot be changed at this point.

It will be interesting what Sam Ruby and Tim Bray will have to say about this. Meanwhile, you can take a look at Sam's RSS to ATOM comparison.

...contains a nice collection of articles and factoids on the Open Document Format debate. Please take a look at it here.

My recent GSS-SAML musings lead me to think about the relation of security, applications and platforms. My firm belief until recently was that security should be handled low in the stack: in the network protocol layer, the operating system, etc. The benefit is quite obvious: by securing the transport, OS, etc., the applications and their developers can be fairly ignorant about security (which they mostly are anyways) and yet build a reasonably save solution.

Now, there is one problem with this model. In order to be really secure, the network and OS developer tend to put fairly restrictive security system in place. This in turn inconveniences the application developer whose first reaction to a security problem will be to simply shut security off. The results can be seen all over the internet ...

The security stack

I better solution - I think - would be to start formalizing a full security stack. By that I mean essentially the same as when talking about a network stack. A security stack should define clear security layers, with well-defined boundaries of security domain.

Such layers should be isolated, yet permeable for permissable security information. One example would be the public key of a specific identity for message integrity and confidentiality. The associated name and other attributes are not strictly required for this operation and should - as such - not be permitted to pass through the security layers.

A possible arrangement of the security stack could be modeled along the ISO network layer model (lowest to highet layer):

1. physical network security - This would include very low level protocols, such as e.g. EAP/802.1x
2. network transport security - I would put protocols such as IPSec into this layer
3. platform security - Here, GSS-API, Kerberos, and maybe SASL would be located
4. application transport security - Within this layer, we could find things like HTTP authentication
5. application security - This layer might justify another division, but probably not horizontally, but vertically in different silos, such as web services and applications (Liberty, SAML, WS-Security), databases, etc.

In today's world, many of the different protocols are not capable of easily passing security information through the different layers of this stack (although there are some notable exceptions).

It should also be noted that while some security protocols do provide for the inclusion of authentication and authorization data, many do not.

What would we gain, if we had such a stack?

A clearly defined stack could serve as a framework for classifying, combining, and architecting new security protocols. Features available in different layers of the stack could then percolate up and down. An example would be the privacy features in SAML that - when profiled properly - could then be available at lower levels, effectively allowing anonymous (or psedonymous), yet authenticated access to resources.

Once more, Microsoft is targeting ECMA as the consortium to sign of on their technology. Just as a few years ago, when they submitted parts of the CLR and C#. This time it is the Office '12' formats, which have become quite a burden under the current plans of the Commonwealth of Massachusetts, the E.U. and the Country of Denmark: All these three governmental bodies decided to require an open file format for all future forms and documents.

For the longest time, the license that came with the Office XML formats was far less than open - bottomline was: you can look, but you cannot really implement.

Now Microsoft promises that this will change under the ECMA process.

The open document discussion is also raging within the halls of the European institutions. Please see for a report and some industry responses here.

On that page, you will also find a letter from Jonathan Schwartz of Sun Microssystems, Inc. on the report by the Commision.

Living in Massachusetts, I strongly support the state's move to migrate their publications and documents to a truely open format (i.e. OASIS Open Document).

Now I recently ran across a public petition to the German Parliament to enact a similar regulation for the German authorities.

Now: if you are German and feel like this is a good idea, please go here: http://itc.napier.ac.uk/e-Petition/bundestag/view_petition.asp?PetitionID=11

Due to very limited internet connection, I have to be brief. Here are some of the result of my trip to IETF 64:

• There is definitively a fairly broad interest in using SAML within the GSS-API framework.
• A small group is currently discussing feasibility and scope of such a approach

Originally, we proposed three major modes of combining SAML with GSS:

• An internal decoration approach: SAML assertions could be used WITHIN existing mechanisms (such as e.g. Kerberos) to carry addtional attributes associated with the principal.
• An external decoration approach: Similar, but instead of using pre-existing extension points, use the stackable mechnism approach instead (see www.ietf.org, kitten WG). This approach would have the clear benefit of being composable with mechnisms that do not have extension points (e.g. Username/Password).
• A native mechnanism: A SAML AuthN statement is exclusively used. While - IMHO - most promising, this approch will be technically most challenging: first, there is no key exchange defined, second, the only crypto related XML standards (XMLDSig, XMLEnc) are - at best - poor

I will post more after XML 2005.

It's a little geeky and doesn't carry much importance, but I just liked it from a political point of view...

NetBeans 5.0 Beta on Windows Vista September 2005 CTP:

I used the 1.5.0 update 5 JDK (from http://java.sun.com/) and the recently released NB installer ... worked like a charm and even the bugs are the same as under 2003 and XP. The icons in the file chooser dialog were also matched to the new Vista UI .. looked nice.

The new NetBeans web services client is quite nice. It is now almost as easy as with Visual Studio to integrate a web service into your application: After pointing the IDE to the WSDL, it generates the necessary proxies and you can then integrate them by right clicking your methods in the source editor and add web operations:

This works right out of the box with ASP.NET 2.0 web services, although it has some issues with complex types (like e.g. an ArrayList). Those get deserialized as SOAPElements which is workable, but requires some SOAP DOM coding.

Indigo (WCF) web services seem to have more issues - I guess this is related to Microsoft splitting up the WSDL into some smaller files (wsdl1, xsd0, etc.)

Simon Guest and Kirill Gavrylyuk gave the .NET/Java Interoperability session on PDC this year. They didn't present any new groundbreaking technology, mostly the stuff we have already seen on JavaOne, but instead show RM, MTOM and Security. The format was quite funny, Simon playing a nervous patient, Kirill playing "Dr. WCF" collaborating with his peer "Dr. Java". Unfortunetely, they chose Apache Axis and WebLogic as their J2EE platforms, but well...

The patient doctor team:

Dr. WCF:

Didn't you also find it somewhat remarkable that the "pillars" of "Longhorn" have been supiciously missing from the recent Beta and CTP releases, including the PDC release? What is Microsoft doing here - are they planning to release Avalon and Indigo as a companion download to Vista or release an option pack?

While support for WCF and WPF for Win2003 and WinXP will proably accerelate adoption of these technologies, keeping them out of the retail box for Vista would certainly slow down adoption considerably. This would be most unfortunate, since WCF offers a much better interoperability and extensibility model than classic ASMX or WSE.

This was definitively fun. Although the turnout was not very high (hey, what do you expect at 9:30 on the day *before* the actual conference with 3 days of notice to the audience), we had a few really good an interesting discussions:

We talk a lot about interoperability through web services, in particular on WS-Adressing in JWSDP, WS-Security, Attachments (yes, MTOM is on the right way) and reliable messaging. Simon Guest talked about his efforts to get secure WS-RM interoperable and gave some insight into the current mindset at Microsoft ("It's all about implementation right now.")

Michael Preadovic of Intrinsync talked about their interoperability story, which allows Java containers to talk to .NET Remoting systems and also .NET systems to speak RMI. He also noted that their IIOP for .NET implementation get a lot of customer attention.