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.

Nicholas Allen shot a photo of Kirill and myself during our chalk talk yesterday.



Nice to have you met in person and thanks for the photo, Nicholas!

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.