Re: Leveraging DNS and email addresses

Since DNS is my particular favorite hammer I am biased toward seeing everything as a nail shaped to fit it :)

The answer to your question lies in what we need in the infrastructure and how we can best address those needs.  In my mind the most important thing that DNS (via DNSSEC and DANE) brings to the table is a currently implemented infrastructure that delivers a very strongly protected trust anchor AND a robust, cryptographically strong chain of trust with the means for terminal points in that chain of trust to safely manage their cryptological assets.

I think the right way to answer your question is to do our best to combine what we understand we need in the infrastructure with pieces of infrastructure that get us as close as possible to meeting those needs with the least effort.

--
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917

A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A

From: Erik Ros <mail@erikros.me<mailto:mail@erikros.me>>
Date: Thursday, March 26, 2015 at 3:20 AM
To: Adrian Hope-Bailie <adrian@hopebailie.com<mailto:adrian@hopebailie.com>>, Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>
Cc: W3C Credentials Community Group <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: Leveraging DNS and email addresses
Resent-From: <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Resent-Date: Thursday, March 26, 2015 at 3:21 AM

Hi everyone,

if this decentralized hash table technology was used, would it still be necessary to use DNS?
I think we might want to consider looking into vouching more ..

kind regards,

Erik

On 26-03-15 06:47, Adrian Hope-Bailie wrote:
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.


I have read both blog posts but thanks, it was worth re-reading them :)

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

I am not proposing that we use email addresses but rather "identifiers that follow the same form".
It's a familiar and sensible format for an identifier.

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

Yes and no.
As I said in my original email, if users wish to have an identity that is not controlled by their email provider they can get one that is controlled by an IdP they trust or one they control.

I have a problem with excluding the large proportion of people that do own or trust an IdP and would like to adopt this standard but are excluded on the basis that many others don't.

Persona failed because the email providers wouldn't play along but that's because the fallback defined by the protocol depended on a centralised service.

I am still an advocate for a WebFinger-like discovery step as the first step in the process of dereferencing an "email style" identifier to an identity document.
If the outcome is a 404 because the domain owner doesn't support WebFinger or 403 because the client needs authorisation then fall back to option 2 (maybe Telehash or some other decentralised system like Namecoin) or prompt the user for some credential that gives access to the protected resource.

The reality is that if I have an identifier in a specific namespace it is much easier and more secure to manage that identifier using systems in that domain.
And many users will choose to do this.

We also need to consider that a standard should also have use case applicability in the enterprise space.
Enterprises that control their domain should be able to offer their employees the capability of having an identity in their namespace.

As a user I expect to have multiple online identities that I can use in different contexts.
One may be my personal identity and another may be my company identity.
My company should have the ability to manage elements of the identity they have issued me therefor the domain system as a mechanism for namespaces identities makes a lot of sense.


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

I am not advocating that "email style" identifiers are the only option but they should be well supported.

Users have the choice between portability and ease-of-use. A standard shouldn't prescribe that they can only have one.


> 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'd like the discovery process that came out of any standard we put together to allow both.
I see the identity process as having many steps and what we are figuring out here is just the discovery of the IdP.
I would be in favour of a standard that prescribed how to de-reference an identifier (in a variety of forms) into a URL that points to an existing resource where the identity information can be found.
BUT it should ALSO prescribe ways that the resource at that URL can link to further identity information (linked data seems the obvious answer)
BUT it should ALSO prescribe ways that the resource at that URL can be protected and how the user interactions should work to provide access to that resource (OAuth2 or similar?).


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

I think the OpenId Connect Discovery protocol has great potential but both that protocol and WebFinger are incomplete.
They need to handle the use case where even the discovery process fails without some form of security step (like the hashed password proposal in the Credentials spec) to prevent harvesting identifiers.

An idea:
Implement a Time-based One Time Password (http://www.wikiwand.com/en/Time-based_One-time_Password_Algorithm) to protect the resource discovered from the identity.
i.e. WebFinger with TOTP to protect the resources at the well-known URL.
The protocol is used today for many 2FA systems is, standardised and works well.

A 403 response from the service hosting the identity information (or linked data document directing the client to it) should indicate what authorisation, if any, is required.
The standard should support a variety of these that support use cases for:

  *   Preregistered clients of the IdP
  *   Prompting the user for some secret (as above)
  *   Providing a proof-of-work (if avoiding harvesting of data is all that the IdP wishes to achieve as opposed to identity holder authorisation)

> So how do we help the user that has an email address @gmail.com<http://gmail.com/>
> <http://gmail.com<http://gmail.com/>> or @hotmail.com<http://hotmail.com/> <http://hotmail.com<http://hotmail.com/>> or @yahoo.com<http://yahoo.com/>
> <http://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 disagree that this means it's not worth trying again with some changes.
The back-up option shouldn't be a centralised service but I also don't think a de-centralised DB should be the primary look-up service.


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

Why? If it's based purely on the fact that it didn't work before then addressing the reasons why should be enough to make it work the second time.

> 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<http://gmail.com/>? What's in it for them? Same
question goes for all the major email providers.

Because it's a W3C standard not a proprietary one developed by one of their competitors.
Because a lot of people won't bother to setup an alternate IdP and so Google still benefits from the linkability of the identities they host.
Because if I get an id somewhere else and Google refuse to support at least linking to it then eventually that might become my new email account and so Google loses me completely.


> 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<http://gmail.com/> address will do this.

So we don't give them the choice?


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

So we build a standard on the premise that users are too stupid to understand the difference between an email address and an identity and instead of giving them choice we promote a standard that we know out of the gates some of the largest tech providers will ignore because we have explicitly tried to cut them out?

My point around enterprise use cases applies here too.
Many people do have multiple email addresses. They are already familiar with the idea of having multiple online identities.

Getting an email address at @gmail.com<http://gmail.com/> may not have been an explicit decision to host anything at the gmail.com<http://gmail.com/> domain but if I register a domain and setup an email account at that domain it is.
I have made an explicit decision to register a namespace on the internet that I can control, why wouldn't I want all of my identity information to sit under that namespace?


> 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<http://identus.org/> demo is something you should look at... I'd be happy to go
through it w/ you at some point.


I have been through the blog-posts and the demo some time ago but I'm afraid I think asking the world to abandon the email style identifier with no bridge from that system to something truly decentralised is doomed.
I agree that a decentralised system is the end-goal and as time goes by more and more people will begin to own their own domains and be able to control the services that reside on them.

Remember, the email system is already decentralised, the issue you are talking about is the large proportion of people who have got their email addresses form specific providers.
You have already stated that email addresses change all the time so you can't then argue against a system where users have the choice of a different IdP by... changing their email address.

I have an email address at a domain I own. I plan to use it for my whole life.
I trust my ability to host my own IdP more than some decentralised system controlled by entities I don't know.
Is this standard going to force me to enter in some URL when I want to share my identity online or can I just use my email address as I already do today?

I am worried that there is an obsession with decentralisation here ignoring the fact that the Web is decentralised and at the core of that DNS.
Are we saying that DNS is not decentralised enough for our needs?
If so why would this standard be developed under the banner of the W3C at all?

On 23 March 2015 at 05:24, Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:
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<http://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>
> <http://gmail.com> or @hotmail.com<http://hotmail.com> <http://hotmail.com> or @yahoo.com<http://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<http://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<http://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<http://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/




--
=========================
--  Erik Ros           --
--  +447979090626      --
--  mail@erikros.me<mailto:mail@erikros.me>    --
--  http://erikros.me  --
--  @erikros_me        --
--  +ErikRos_ejfrme    --
=========================