Back in March, I posted EASI ID (pt 1.5), posting a question about who owns the rights to resources within a namespace, specifically email addresses. The reason was to stimulate some braincells, about what could happen if users chose to protect personal content with a digital identity that they thought they owned, but which later they found out the didn’t (in this case their work email address).
Ariel Gordon, one of the rock stars on the Microsoft Identity Strategy team (along with Kim Cameron and others…), recently posted this comment:
Ariel Gordon said
August 7, 2009 at 2:34 pm e
Contoso owns the domain and any identifier in its realm.
Email addresses bear a claim of employment. I.e. my @contoso.com address shows (with a certain level of certainty) that I work for Contoso. Using this address after I leave the company is akin to keeping distributing business cards with the address on it.
Today, 99% websites leverage email providers’ infrastructure for user authentication: you type your email address as a login then create a password that can be reset/resend via email, effectively handing the keys to the account to anyone who controls the mailboxn including the new guy–Jerry Smith in your example.
Websites who implement authentication delegation (aka federation in the consumer sense of the term), could be informed by the IdP of user account deprovisionning and, as best practice, take action to close the account, prompt the user to create alternate credentials (if they have a fallback email address or phone #), etc.
I started to reply with a bit of the backstory in the comments, but figured I’d give this it’s own post, if for no other reason than (I think) it’s a fun look into some of the dynamics of digital identity…not to mention internal politics… So here is my response:
Thanks for replying. Yes, you’re correct, this is exactly what happens, and I agree with you.
The motivation for this post, was a series of conversations that I was in with an internal group here at Microsoft, about who "owned" the @microsoft.com namespace for user identities. Historically, the internal identity management team has owned corp.microsoft.com, but the actual microsoft.com namespace was owned by the team that supports the www.microsoft.com website. However, way back when, somebody in the Live ID team also decided that the microsoft.com namespace was theirs (in the Live ID sense)
It turns out, that today, there are approx. 2.5 million Windows Live ID’s in the @microsoft.com namespace. Obviously we haven’t had that many employees. But back in the day, there was a time when the Live ID team believed that @microsoft.com would be a good namespace for customers to use, similar to @hotmail.com or @live.com. This isn’t really as crazy as it sounds, because it’s analogous to users creating a Yahoo ID in the @yahoo.com namespace.
However many years later though, as we enter the age of federation, the challenge is that Microsoft Corporation uses @microsoft.com as our corporate namespace. In contrast, Yahoo Corporation uses @yahoo-inc.com for their corporate email addresses. So Yahoo can choose to give @yahoo.com to their customers, whereas Microsoft had a conflict.
This was a fun debate at the time, and ultimately we came to the decision that @microsoft.com is our corporate identity. The question though, of what should come to those 2.5 million user ID’s. Fortunately the Live ID team has the solution for this, and added a flag into the federation setup so that a company can choose to “evict on reserve” or “allow merge” of any existing users when they federate.
Allow Merge means that anyone with an existing user account in a namespace that’s federated, will have the option of associating their existing WLID with their new federated ID. In Live ID speak, it means they keep the same PUID. The result is that you keep anything you had access to, but you do so with your new corporate-account-backed, federated Live ID rather than your older, separate username/pw WLID.
Evict on reserve is just what it sounds like, where any user accounts which exist in a namespace when it’s reserved, will be moved into a “forced rename” state. This means that the next time the user logs on with their separate user name and password, they will be forced to change their user name (keeping the same account/PUID) to a different email address, one which is hopefully their personal address.
For Microsoft employees, we chose evict-on-reserve, and are in the process of working through the details of implementation. Our thinking behind this, is that even though they are in the @microsoft.com namespace, any existing accounts are all “personal use” accounts. Therefore, we should protect the personal data, and have a user rename their account to a personal account. When a user logs in with their “new” federated @microsoft.com account, they will be doing “business” work with an account that is backed by their corporate credentials (and which goes away when their employment ends). And yes, we’re working with the Live ID team to get some controls put in place for companies that federate, so that they can limit where corporate backed WLID’s are used.
So that’s where we’re at. Hopefully this gives other folks who are federating something to think about as well, as they integrate with service providers such as Live ID.
I’d love to hear what you, or anyone else thinks about these fun, “moving to the cloud” challenges!