BPuhl’s Blog

A little bit of everything without actually being much of anything

EASI ID (pt. 2)

Posted by BPuhl on August 7, 2009

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:


Hi Ariel!

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!



One Response to “EASI ID (pt. 2)”

  1. I found your post to be most insightful considering problems faced by consultants. I wish that I had had this information three years ago when my company decided to commit to Live ID. It would have made a difference in our deployment and our business methods. What is needed is practical “use case” discussions. Documentation tends to be superficial which leads to dramatic mistakes in implementation.
    To further the federated concept there needs to be a DNS record that is universally accepted that indicates that a domain is federated. CNAME records could then (as Microsoft Live Custom Domains does) be used to discover the federating authorities that the domain may subscribe.
    For a concrete example within Microsoft universe, Live Custom Domains and OfficeLive don’t both treat the ownership equally. Live Custom Domains requires the owner demonstrate authority by creating the CNAME record or MX record in DNS while OfficeLive really nothing. But here is where the conflict becomes apparent in the Live ID system. A domain created in OfficeLive is “automatically” accepted by Live Services UNLESS is exists in Live Custom Domains in which case it is prevented from being created. That seems logical it should only exist ONCE in the Live Services system. But in fact Microsoft is keeping two different stores. OfficeLive checks against Live Custom Domains but Live Custom Domains does not check against OfficeLive before creating an identity. You can see from the different rationales why this is the case but the effect is that individuals are prevented from associating their email accounts to Live ID identities when the domain is “reserved” by Live Services.
    I completely agree that companies and organizations want control over their domain names and the use of those outside the company borders. Live Services issues an error to users who try and use an email address in a domain that is in either Live Custom Domains or OfficeLive. The error message is useless to the user as is its associated Help message content because it does not explain the nature of the error. The error is a legitimate business policy issue e.g., the company has not “issued” an account to the user under Live Custom Domains or OfficeLive and therefore the user is not allowed to create the account.
    As I said above having these insights earlier would have prevented many mistakes. So I offer a few facts and suggestions.
    To Live ID users: If your desire to use a service that accepts Live ID or any other federated identity (OpenID, etc.) is of personal nature outside your business then create an identity in the domain of the federated service. For example if using Live ID then create an identity at one of their domains such as Live.com and use that for all your personal sites. If you feel the need to separate personal business from social interest then create separate identities for these. I don’t think that we will ever get to the magical single-sign-on because of the divergent needs of individuals. We can however cut down on number of identities which significantly reduces our identity threat attack surface.
    To domain holders: You must ask yourself does my business need to allow individuals outside the corporate structure to have email addresses at the company? It very well may, take for example a home-based business franchise structure with independent representatives that market your products. Depending on how “close” you want to keep the business you might consider a second domain for corporate infrastructure that you can keep control of on an account level. In most cases the domain and the business are common. However if your domain represents your product and not your company then get a domain name for the company and put it on your business materials and market your product/domain in which case every person who uses your product/domain is marketing for you.
    Practical Usage of Live Services:
    1. A Live ID once created will exist forever. The email name attached to a Live ID may be canceled. If it is canceled the Live ID still exists with all the attached content. That content will continue for a period time then will be deleted. The content is unreachable after the Live ID is canceled.

    Suggestion, only delete a Live ID after you have successfully backed-up all content. If you are a corporate administrator and the account is in a Live Custom or OfficeLive domain then change the password on the account and back-up the content before removing the account.
    2. Setting up corporate Live Services domains. Fact, businesses are bought, sold, and have name changes as a matter of course so plan for it. The human response is to create this global account that will persist for a lifetime. That is well and good but doesn’t address reality. Even in the local bar establishment the owners decide to divorce, what happens to the domains that they may own.

    Suggestion, create a Live Services account for each domain that is a corporate domain. Further each domain should have a dedicated Administrator account that has no other function and is in the domain of the Live Services provider. For example, “domain.com” is added to a Live Custom Domain. The Administrator at the time the domain is being added should select to create a new identity in Live.com (not in the domain itself). This way the administrator account exists as a “superuser” account to the domain with an email address that is outside the account. It will always be accessible. This simply means that on your cheat-sheet (we all know everybody has one) you list your administrative account information for this new domain account.
    3. Setting up corporate user accounts for Live domains. An important fact to understand that many miss, any user account established in Live Custom Domains or in OfficeLive “ARE” Live ID accounts. They don’t have to be added as Live ID accounts later, in fact you will get an error if you try to add the account to Live ID.

    Suggestion, administrators should add accounts to the corporate Live Services account only as needed. When adding the administrator must assign a password. I suggest that you use a password generator and check the box that forces the user to change the password on first use. Administrators should remove the accounts of individuals that leave the company and at least set the password to expire on a regular interval.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: