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.

This is a interesting research project at Microsoft: Phoenix is the framework for all upcoming compiler and JITer optimizations for the Microsofts platforms. Their goal is to unify opmizations and execuction imrpovements for both managed (i.e. .NET) and unmanaged (i.e. Win32) code. Conceptually it uses a three stage optimization and code generation process, with the Phoenix C2.EXE C++ back end compiler being the centerpiece:

A very nice effect of this research program is that it will allow developers to come up with their very own development language and still use the platform optimizations provided by Phoenix.

The research development kit can be found here.

Here is a way to ruin your day: watch this movie about a simulation of a 500km rock hitting earth (most unfortunately only in Japanese, but the pictures are excellent).

Well - it seems that WinFS returned to the undead for at least another 1-2 operating system releases: Quentin Clark writes in the WinFS group blog, that WinFS is canceled for Vista and XP. They are now moving those parts that are stable enough for productization into SQL server and ADO.NET.

This article effectively ends Microsoft's second push to move to a relational file system. The infamous Cairo OO-OS in 1991 that was supposed to be built on NT, and then WinFS, as one of the pillars of Longhorn in 2002.

My guess is that this whole thing will be completely tabled until after Windows Vienna ships - this would probably make it 2010 until it comes up, add 5-10 years development efforts, so you might have a chance seeing this by 2015.

Well, if Microsoft wants to update their NTFS file system, they can certainly take a look at Solaris' ZFS. Maybe ... ahh, I am dreaming now.

Since last Thursday, I am a happy owner of a Cingular 2125 (HTC Farady) with Windows Mobile 5.0 Smartphone Edition. I have to admit that since my first step with Windows CE (Pocket PC 2002 on an iPaq 3850) they have made some great improvements. Networking is MUCH easier now, and with the EDGE capabilities I get easily about 100+ kbps in my area. This is good enough to listen to a stereo audio stream, which means that I can now listen to my favorite radio stations from Germany (DLF) whereever I am.

Another great feature is the VPN capabilities of the phone itself. Really useful though is the Bluefire Security VPN client that allows me to dial into my corporate network using a SecurID card.

The next steps will - obviously - to start dabbeling with the Mobile 5.0 SDK and the Mobile extensions for NetBeans.

SAML could be used for performing anonymous (more precisely pseudonymous) authorization in the following way:

1. A user contacts a relying party for a particular service.
2. The RP returns a request for a set of attributes that it requires to allow access.
3. The user agent formulates a request to its SAML IdP for a signed attribute statement about that set of attributes.
4. The IdP returns that statement, signed with its key.
5. The client forwards that statement to the RP.
6. The RP verifies the signature against the public key of the issuer.

In this scenario, the IdP does not know anything about the RP, and can not associate the particular user request with the public key request from the RP (unless the IdP is really obscure and serves only a very few users). The RP only knows about the attributes that were asserted in the statement.

The obvious drawback is that the IdP has a lot of knowledge about the user. This issue can be mediated by putting a user trusted-broker between the user and the IdP and the user.

One of the issues (it seems) around identity is that there is a lack of highly trusted digital identity sources. Do I trust a (fairly anonymous) Yahoo ID or don't I?

I would like to argue that if we had a reliable way of transfering real-world identity claims (like e.g. a Passport, a credit card, or a driver's license) to the digital world, the trust in these identity sources would be fairly high. So the problem gets down to the point of transfering the real-world identity to the virtual world - with user consent. The technologies are pretty much all available: for example, a driver's license authority could easily offer a web site that allows to generate a digital token (like a cert or a SAML assertion) based on information that is typically associated with the real-world token which would include the name, address, license number and SSN. The same place could also be used to revoke a particular token.

What would this do for the digital identity landscape? We would get a number of highly trusted "dTokens" that could easily be used for the same type of transactions that the corresponding real-world tokens are typically used for: dPassports (digital Passports) for aquiring Visas, dCreditCards for purchases and dDriversLicenses for age verification. With a user centric store for these dTokens, the users would be empowered to perform the same things in their digital life that tehy are accustomed to in the real world.

The Bandit Project is the latest in a wave of Identity Metasystems (components?) to attract the interest of the community. It is deeply tied into the Higgins Identity API system, and could (will?) use Liberty and Windows CardSpace as providers.

What I am struggeling with so far (not having immersed myself in Bandit) is the benefit it offers over Higgins.

The DIX identity protocol in its latest draft form now uses parts of the SAML 2.0 token format. Ah, interesting times...

Microsoft Live has a STS for Windows Live ID (aka Passport) running here. Now this is really interesting, particularly in the context of Microsoft's recent move to get the Infocard selector to many platforms. So what is the rationale behind this? Here is my take on this:

ADFS will be the Microsoft implementation of the Enterprise STS. If it advertises iteself now as a ADFS Federation Partner (i.e. a 'trustable' resource for your enterprise AD), you will be able to provide SSO for your customers to log into your extranet. Now the really interesting question is: will Microsoft allow the Passport STS (by explicit business contract) to trust ADFS deployments (maybe for really large cutomers only), thus enabling your enterprise users to SSO into Passport sites?

I talked about Atlas pains in the last entry - here is an innovative approach how to get this across to the developers at Microsoft. Kudos to those who can make fun of themselves. Enjoy!

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.