Re: Leveraging DNS and email addresses

>
> 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 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> 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 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? 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 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 may not have been an explicit
decision to host anything at the 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 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> 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 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/
>
>