Re: Leveraging DNS and email addresses

On 03/26/2015 02:47 AM, Adrian Hope-Bailie wrote:
> 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.

I think there's a fair bit of miscommunication going on here. I think we
agree far more than you think. :)

Fundamentally, here's where we agree:

1. Use an email-like identifier to look up an identity document and/or
   IdP.
2. Possibly provide a primary method and a fallback for that discovery.

Here's where I disagree w/ what I think you're saying:

1. People don't have a problem creating a new email-like identifier for
   their identity (and remembering the difference between that and
   their email address).
2. Super providers won't abuse the fact that the first step in the
   process is to check w/ them if an email-like identifier maps to
   a user in their system.

More below...

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

That's the argument that OpenID Connect uses...the approach hasn't been
a run-away success.

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

Persona failed because the incentives were not aligned between Mozilla
and the email providers. With Persona, Mozilla placed themselves in the
position of competing w/ the email providers when they should have
placed the email providers in the position of competing w/ each other
/and/ all the other IdPs. You do this by enabling /any/ IdP to claim an
email address-like identifier (given authorization by the owner of the
email address). They didn't create a level playing field and that's what
resulted in the failure.

> 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 you do that, you place the email providers in charge again. If
WebFinger-like discovery is the first step in the process,
Google/Yahoo/etc. just respond back w/ a "false positive" to halt the
discovery process.

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

I think this is the primary approach - decentralized system first, then
you can fall back to WebFinger-like discovery approaches.

Don't let the super providers control the very first step in the process.

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

I'm challenging this assertion. There are ways to just as easily manage
that mapping outside of that domain. The identus demo is proof of 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.

I don't think anyone is saying we should prevent this.

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

I was with you up until "therefore". There are fairly simple ways of
enabling the company to manage elements of the identity w/o the company
having to be in control of the identity document.

For example, the company can issue signed credentials to the identity
document, and revoke those credentials when it sees fit to do so. There
is no need to have it live on the same domain for that to work.

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

I don't think anyone is arguing against "email style" identifiers for
certain things (like discovering the actual identifier).

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

Why do you think we're prescribing that they can have only one?

> I'd like the discovery process that came out of any standard we put 
> together to allow both.

Easy to do... although I don't think the "Please type your identity
document URL into the text box" approach is going to be used very often,
do you? Or are you saying something different?

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

I think that's where we're headed...

> BUT it should ALSO prescribe ways that the resource at that URL can 
> link to further identity information (linked data seems the obvious 
> answer)

Yep, also what we're doing right now in the Identity Credentials spec.

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

Yep, also covered by the identus demo.

I think the problem here is that the blog posts aren't getting the
fundamentals across. Do you have time to chat on the phone about this at
some point next week?

> I think the OpenId Connect Discovery protocol has great potential but
> both that protocol and WebFinger are incomplete.

Why do you think they have great potential?

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

I don't understand how this solves the "Internet Cafe" use case. Someone
walks in off of the street into an Internet Cafe w/ nothing but the
clothes on their back, and they need to login to a site using a
credential. If TOTP is used, don't they need to be carrying their mobile
phone as 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.

In the current model, we're expecting that site to use another
username/password for auth, w/ optional alternative 2FAs to protect
login from nefarious parties.

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

Just to be clear, at no point will all data in an identity document be
available to the general Web/Internet. The only bits of information that
are public are the ones that the owner of the identity document says are
public, which in most cases, won't be much at all.

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

It definitely is worth trying again with some changes. That's what
identus is. Why shouldn't the decentralized DB be the primary lookup
service?

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

It won't work because you're putting the same organizations that killed
it the first time in the critical path again.

If you address the reasons it failed, it's worth trying. I'm just
pointing out that I don't think you're actually addressing the reasons
it failed. I could very well be missing something important, so looking
forward to your more detailed response. :)

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

Persona wasn't proprietary, and Mozilla is a very close Google ally
(80%+ of their revenue comes from Google). There are many W3C standards
that have failed because they got the incentives wrong.

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

Agree that most people won't setup an alternate IdP. I also assert that
most people won't change email addresses and Google will most likely not
voluntarily support anything that move people away from Google services
or creates competition.

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

People don't like changing email providers, some will do what you're
saying, but most will not.

I don't think the solution is "get people to change their email-like
identifier". The solution is "let other large companies claim an
email-like identifier, forcing super providers to compete w/ them".

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

I didn't say that. We give them the choice, I just don't think many
people are going to do it.

> So we build a standard on the premise that users are too stupid to 
> understand the difference between an email address and an identity

I didn't say anyone in this ecosystem was stupid. I'm saying that most
people only have so much mental bandwidth and using an email-like
identifier that is not a person's email address is going to strain that
bandwidth right into "this is confusing, I'm not going to use it"
territory.

For example, which one is my email address and which one is my identifier:

msporny@digitalbazaar.com
manu@sporny.org

I doubt I could explain the difference to the less tech-savvy folks in
my family.

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

We're not trying to cut anyone out. We're trying to create a level
playing field. It's a forcing function. For every large super-provider,
there are 20 that want to be in that position, and the proposal that's
being put forward enables those 20 organizations to compete w/ the super
provider. That forces the super provider's hand and they have no choice
but to implement the standard to keep the other 20 organizations at bay.
This is what I mean wrt. aligning incentives; everyone wins in this
scenario.

1. The super providers onboard hundreds of millions of people overnight
   and make login on the Web actually work the way it should work.
2. Smaller providers are given the opportunity to compete on a level
   playing field w/ the super providers.
3. People can just use their email addresses w/o having to create yet
   another identifier.

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

They're familiar w/ the idea of having multiple email addresses, not
having bob@example.com being their email address and bob@example.org
being their "online identity".

You don't need two, you only need one.

> 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 completely. Why do you think we're asking the world to abandon
an email style identifier? Why do you think there is no bridge to
something truly decentralized?

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

I'm not as convinced that we'll see more people owning their own domains
in the next decade. For example, the Social Web WG is just getting off
of the ground... OpenStack isn't nearly where it needs to be to have
truly portable cloud VMs that you can move from one provider to the
next... domains are still expensive to own, etc.

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

That's not the problem w/ changing email addresses. I think there's a
conflation of issues here. There are at least two issues that are being
discussed simultaneously:

1. Should we use email-like identifiers to look up identity documents?
2. Does an email address changing cause a problem w/ Identity
   Credentials?

The answer to #1 is "yes, we should".

The answer to #2 is "if the only thing you tie a credential to is an
email address, horrible things happen when people move away from that
email address... like, none of their credentials are provably theirs
anymore".

I was talking about #2 when I said that "email addresses change all the
time and that's bad for credentials", and I think you may have been
talking about #1.

> I have an email address at a domain I own. I plan to use it for my 
> whole life.

+1, no issue there.

> I trust my ability to host my own IdP more than some decentralised 
> system controlled by entities I don't know.

... but that's not how the protocol works. You run the IdP, and your
decentralized document is served by /your/ IdP. You stay in complete
control if you want to.

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

You just use the email address you use 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?

We are saying that it's hard to update your particular identity document
mapping/entry in DNS. As Glen has pointed out, that is changing w/
DANE/DNSSEC... and if the granularity is small enough, then we can
re-use DNS.

I hope all that helps clarify what the current thought process is around
Identity Credentials and the Telehash/WebDHT stuff. I think you and I
agree far more than you think we do due to a few key misunderstandings
on what's being proposed and how we expect the protocol to be built over
the next year or two.

-- 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 Friday, 27 March 2015 05:29:29 UTC