W3C home > Mailing lists > Public > public-credentials@w3.org > March 2015

Re: Leveraging DNS and email addresses

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 22 Mar 2015 23:24:26 -0400
Message-ID: <550F876A.90005@digitalbazaar.com>
To: public-credentials@w3.org
On 03/16/2015 04:02 AM, Adrian Hope-Bailie wrote:
> 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

We've been doing quite a bit of thinking in this area for years, some
background reading on the current status of this thinking:

http://manu.sporny.org/2014/credential-based-login/
http://manu.sporny.org/2014/identity-credentials/

The rest of this post assumes you've read the blog posts above.

> 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.

+1 to using email addresses as the /keying/ mechanism used to discover
an IdP.

-1 to making the IdP the same domain as the email address. Doing that
creates a monopoly (Google for gmail.com addresses, for example).

-1 to using email addresses as the thing that you tie a credential to -
doing that leads to monopolistic behavior. Tying a credential to
anything that's not completely portable and under the recipients control
is ceding control of that credential to someone other than the recipient.

> 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.

That's the wrong way to look at it - the fact is that /both/ email
addresses and URLs are bad things to tie credentials to. Email addresses
are good as a lookup mechanism because it's been proven that people can
remember them easily. URLs are bad as a lookup mechanism, and they're
bad as a thing to tie credentials to, but they're good for hanging
machine-readable information off of.

> 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.

Yep, OpenID URLs are a bad idea.

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

Yep, exactly the question you should be asking.

> 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.

That's what Mozilla Persona was about, and it failed. The blog posts
above explain why Persona failed.

> 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 provide 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.

You've basically re-invented Persona and added a redirection mechanism,
and I don't think that'll work.

> 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.

Why would Google adopt this for gmail.com? What's in it for them? Same
question goes for all the major email providers.

> 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

I don't think people with a gmail.com address will do this.

> 2. Use an identity that is different from their primary email 
> address.

I don't think people will understand why they have to have two email
addresses.

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

Email addresses change throughout your lifetime. Tying identity to a URL
is also a bad idea. The world needs a decentralized identifier that's
portable, full stop. The blog posts go into it a bit more... the
identus.org demo is something you should look at... I'd be happy to go
through it w/ you at some point.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/
Received on Monday, 23 March 2015 03:24:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:23 UTC