Re: Leveraging DNS and email addresses

On 2015-03-28 08:15, Adrian Hope-Bailie wrote:
> In most respects we seem to all be in agreement.
>
> Let's assume we produce a standard that describes how to use an identifier to discover an IdP service AND that standard specifies more than one way to do this (DNS service discovery, telehash, WebFinger)
> In this scenario I see only one major point of contention, the order in which the client executes these different discovery methods.
>
> The factors that would influence how the standard prioritised these are various and tied to the more minor points of contention you have discussed below.
>
> ITO your fundamental points:
>
>     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). 
>
>
> This comes back to the user's understanding of what this identifier actually is (even an email address is just an identifier, in this case for a mailbox).
> To fundamentally change the way identity works online (move to a decentralised system outside the control of super-providers) is going to require a massive re-education of online users no matter how the system is ultimately designed.

This is IMHO a an uninteresting goal unless the services people access also become distributed.  Since it is services that "drives the market", I think it simply has to start there.  The super-providers won't accept third-party identities or providers.


>
> Maybe it's time to consider building that system from the ground up with the express purpose of being a decentralised identity store?
> Is Telehash the right technology or just the best one available right now?

I would be very surprised if Telehash will become the norm.  It may if the web remains in its current deadlocked state where NOBODY except Google really can add anything to browsers and succeed making it a standard.  This is IMO the #1 web project, making enhancements to the web architecture in reach for third-parties.   For that to happen we need an extension mechanism.

With a web extension system, there will be many alternatives, possibly including a resurrected Information Card scheme which is what I'm personally more attached to than Telehash and similar lookup schemes.


> It is a corner-stone technology for the credentials CG work but it is nowhere near being defined as a standard itself.
> Are we engaging with the core developer to make this happen or will we simply adopt the tech and take responsibility for defining and standardising it at the W3C or IETF?
>
>     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.
>
>
> I'd say headlines like "Google are stealing your identity" would be a pretty good deterrent if a standard exists and they are intentionally abusing it?
>
> I'm happy to concede that a decentralised system like Telehash should be the primary method of discovery before depending on domain-dependant protocols like WebFinger and DNS SD but I think we need to then put a lot of effort and emphasis on that underlying protocol. We can't simply give it a one line reference in the spec and point to the GitHub project. At a minimum I'd suggest it needs to be an IETF standards track RFC or do you disagree?
>
> It's worth considering that if a system like Telehash has the backing of the IETF and/or W3C what other super-provider controlled systems may start to leverage it.
> Do we see a day where SMTP vNext looks up my email exchange via a web DHT instead of DNS MX records?
>
> The next question is, if we start to build the Web's new identity system on the technology is it sufficiently hardened to be such a pivotal piece of the Web?
>
> A lot of questions here but I guess they boil down to a key point we disagreed on.
> DNS and systems built on the technology are mature and trusted.
> It's for that reason that I would trust an identity system built on those foundations ahead of one built on a experimental decentralised technology... today.
>
> NOTE on TOTP:
> I am simply proposing this as a means of protecting identity scraping.
> i.e. The IdP doesn't even verify that they have a record for an identity unless the client provides an OTP.
>
> This could be an optional protection provided by the IdP.
> Example: It's something that could be used to protect the communication between the Login Hub and Identity Provider in the existing proposed stack.
>
> On 27 March 2015 at 07:29, Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>> wrote:
>
>     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> <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> <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 <mailto:msporny@digitalbazaar.com>
>     manu@sporny.org <mailto: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 <mailto:bob@example.com> being their email address and bob@example.org <mailto: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/
>
>