Discovery by Email, Domain, or entityID

[Nate Klingenstein]

> Email domain or URL-based discovery is the dominant pattern in the world, though.

We just recently bemoaned the inconsistency in discovery as deployed by services and the trouble that causes for adoption of federated identity.  If there is a pattern that is naturally emerging as dominant("what is your email" for users and "what is your domain/metadata URL" for administrators), then not only do we have a potential common discovery mechanism that can be combined with local logins in a single form, but the market-selected one that is the most likely to continue to proliferate.

It might not be the one we most prefer or worked hardest on, but it might be the best chance for consistency, and early user surveys and studies on discovery indicated that even a repetitive experience that was a little clunky was preferable to "figure out how this SP does it."

The problem is mapping from domains to metadata, and without a standardized way to do that, we're going to end up with inconsistency again, hence my continued thinking about DNS.  Office 365 does it with a fun PowerShell experience and stores the mappings locally, and most other services are probably doing a similar thing.

I otherwise concur with everything Peter wrote, but I don't think we're going to be able to teach users how to type in a URL, whereas they naturally use their email address as their username even on consumer sites now.  It's more pain for us as administrators, but focusing on the form of discovery that has naturally become the dominant pattern would bolster the case for federated identity in general.

I'm not strongly advocating this or putting it at the top of any priority lists, but it is definitely salient and I think worth at least watching.

Take care,
Nate.