I read an interesting blog post about Google "Profiles" this weekend. Here's the nut of the problem:
In the early days of Google Apps the only way to sign up was by linking to an existing Google Account, in the format of email@example.com. If you have one of those accounts, there is no way to tell Google that you are now firstname.lastname@example.org. This means that Google Apps think of your original @gmail and new, @domain identities and two different ones. You can directly access (via URL) your own Calendar, Docs, Groups ..etc. all under your own domain, however, programs that need to access those apps only find the other version, attached to your @gmail.com account. A simple example is trying to save an event from Upcoming.org, Zvents, or any other services: there’s no way to use them with your own domain.
Even the Google Groups is messed up: when I am logged in as email@example.com, Groups that I am a member of won’t recognize me. I actually have to have duplicate identities created in Google Groups: one to be able to send email (my own domain) and one to be able to access Group’s other features via the browser (@gmail format).
I'm not positive about this but I wonder if a federation-based solution using something like Microsoft's CardSpace on the front-end would help. That said, the bigger issue is the Google "namespace" on the back-end. I wonder if their directory supports aliasing? I think the ability for an end-user to have multiple aliases might solve the problem - user provisioned, of course. I'm sure Google isn't using Active Directory as their back-end server. Good thing because it doesn't support the concept of aliases. If Google wants to enable federation for their customers they have to solve this problem.
Of course, there is another alternative: Don't solve the problem. Hopefully, this option is not on the table.
Active Directory, Microsoft, Google, federation, CardSpace