Leveraging DNS and email addresses

I have been thinking lately about the challenge of keying an identity in a
way that:

   - Is easy to transfer and remember (even for humans)
   - Can be normalised in a standard way and used as part of a standardised
   discovery process by a client to discover the Identity Provider (IdP) for
   that identity

*ASIDE: It's worth mentioning that while we strive for a fully
decentralised identity system this will likely be a federated set of IdPs
and for a client to traverse this web they need a starting point or primary
IdP for an identity. When I talk about the IdP for an identity I am not
implying there will be only 1 but that that the key/label for the identity
should allow a client to resolve/discover this primary IdP and then from
there discover further identity claims as required.*


To my mind the obvious solution is to use the email address format as this
is already a well-known standard which user's understand.

It seems to me that the only argument against an email address format is
that the domain part is often not under the control of the identity owner.
I don't see that is a good enough reason to force users to try and change
their thinking and use URIs as their identifiers.

I don't have statistics to back this up (perhaps somebody does) but I
consider the relative obscurity of OpenID as a login option as evidence
that this is a bad idea.

So how do we help the user that has an email address @gmail.com or @
hotmail.com or @yahoo.com but wishes to host their identity themselves or
at a different IdP?

First, we define a mechanism or standard algorithm/protocol for translating
their email address into a service discovery process that may start with
their home domain but ultimately result in the client accessing the
identity somewhere else. Then we pressure the large email providers to
abide by this standard. I acknowledge that this may be difficult but I
would say it is not impossible.

I imagine the user experience being something like the following:

   1. I log in to my account with this email provider, go to my account
   settings and prpvode the URL of my IdP.
   2. When I use my identity online the client executes the service
   discovery protocol as defined, contacts my email provider and is given the
   URL I have configured as part of this process.
   3. The client negotiates with my IdP of choice to get my identity
   information.

If we have designed the protocol correctly (very close to what is already
in place today) my email provider only knows who my IdP is but nothing more
about the identity I have defined their unless I choose to share it.

Where a user has a primary email address with a provider who is not
following the standard the user has two choices:


   1. Change email providers
   2. Use an identity that is different from their primary email address.


Option 2 can be easily facilitated by any IdP who wishes to play in this
space. In conjunction with offering an IdP service they could also allow
their identity key (email address) to be used as an email address by the
subscriber but simply forward all emails to that address on to the primary
email address of the subscriber.

I think the Discovery protocol of OpenID Connect (
http://openid.net/specs/openid-connect-discovery-1_0.html) is a good
reference of how an email address could be used to discover the user's IdP
however I'd be more in favour of leveraging the DNS service discovery
protocol (RFC 6763 - http://www.dns-sd.org/).

Is there a compelling case for using a URI as an identity key as opposed to
the familar form of an email address?

Adrian