W3C home > Mailing lists > Public > public-webpayments@w3.org > March 2014

A Proposal for Credential-based Login

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 16 Mar 2014 01:28:22 -0400
Message-ID: <53253676.1010004@digitalbazaar.com>
To: Web Payments <public-webpayments@w3.org>
This blog post outlines some thoughts on how we could use the Identity
Credentials specification to also do Persona-like login for the Web. The
same mechanism would be used to login to websites and also deliver
verified credentials (such as government issued ID, shipping address
information):

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

The full-text of the blog post is included below for archival purposes
at W3C.

-----------------------------------------------------------------------
A Proposal for Credential-based Login

   Mozilla [1]Persona allows you to sign in to web sites using any
   of your existing email addresses without needing to create a new
   username and password on each website. It was a really promising
   solution for the password-based security nightmare that is login
   on the Web today.

   Unfortunately, all the paid engineers for Mozilla Persona have
   been [2]transitioned off of the project. While Mozilla is going to
   continue to support Persona into the foreseeable future, it isn't
   going to directly put any more resources into improving Persona.
   Mozilla had [3]very good reasons for doing this. That doesn't mean
   that the recent events aren't frustrating or sad. The Persona
   developers made a heroic effort. If you find yourself in the
   presence of Lloyd, Ben, Dan, Jed, Shane, Austin, or Jared (sorry
   if I missed someone!) be sure to thank them for their part in
   moving the Web forward.

If Not Persona, Then What?

   At the moment, the Web's future with respect to a better login
   experience is unclear. The current option seems to be OpenID
   Connect which, while implemented across millions of sites, is
   still not seeing the sort of adoption that you'd need for a
   general Web-based login. It's also [4]really complex, so complex
   that the lead editor of the foundation OpenID is built on left the
   work a long time ago in frustration.

   Somewhere else on the Internet, the [5]Web Payments Community
   Group is working on technology to build payments into the core
   architecture of the Web. Login and identity are a big part of
   payments. We need a solution that allows someone to login to a
   website and transmit their payment preferences at the same time. A
   single authorized click by you would provide your email address,
   shipping address, and preferred payment provider. Another
   authorized click by you would buy an item and have it shipped to
   your preferred address. There will be no need to fill out credit
   card information, shipping, or billing addresses and no need to
   create an email address and password for every site to which you
   want to send money. Persona was going to be this login solution
   for us, but that doesn't seem achievable at this point.

What Persona Got Right

   The [6]Persona after-action review that Mozilla put together is
   useful. If you care about identity and login, you should read it.
   Persona did four groundbreaking things:
    1. It was intended to be fully decentralized, being integrated
       into the browser eventually.
    2. It focused on privacy, ensuring that your identity provider
       couldn't track the sites that you were logging in to.
    3. It used an email address as your login ID, which is a proven
       approach to login on the Web.
    4. It was simple.

   It failed for at least three important reasons that were not
   specific to Mozilla:
    1. It required email providers to buy into the protocol.
    2. It had a temporary, centralized solution that required a
       costly engineering team to keep it up and running.
    3. If your identity provider goes down, you can't login to any
       website.

   Finally, the Persona solution did one thing well. It provided a
   verified email credential, but is that enough for the Web?

The Need for Verifiable Credentials

   There is a growing need for digitally verifiable credentials on
   the Web. Being able to prove that you are who you say you are is
   important when paying or receiving payment. It's also important
   when trying to prove that you are a citizen of a particular
   country, of a particular age, licensed to perform a specific task
   (like designing a house), or have achieved a particular goal (like
   completing a training course). In all of these cases, it requires
   the ability for you to collect digitally signed credentials from a
   third party, like a university, and store it somewhere on the Web
   in an interoperable way.

   The Web Payments group is working on just such a technology. It's
   called the [7]Identity Credentials specification.

   We had somewhat of an epiphany a few weeks ago when it became
   clear that Persona was in trouble. An email address is just
   another type of credential. The process for transmitting a
   verified email address to a website should be the same as
   transmitting address information or your payment provider
   preference. Could we apply this concept and solve the login on the
   web problem as well as the transmission of verified credentials
   problem? It turns out that the answer is: most likely, yes.

Verified Credential-based Web Login

   The process for credential-based login on the Web would more or
   less work like this:
    1. You get an account with an identity provider, or run one
       yourself. Not everyone wants to run one themselves, but it's
       the Web, you should be able to easily do so if you want to.
    2. You show up at a website, it asks you to login by typing in
       your email address. No password is requested.
    3. The website then kick-starts a login process via
       navigator.id.login() that will be driven by a Javascript
       polyfill in the beginning, but will be integrated into the
       browser in time.
    4. A dialog is presented to you (that the website has no control
       over or visibility into) that asks you to login to your
       identity provider. Your identity provider doesn't have to be
       your email provider. This step is skipped if you've logged in
       previously and your session with your identity provider is
       still active.
    5. A digitally signed assertion that you control your email
       address is given by your identity provider to the browser,
       which is then relayed on to the website you're logging in to.

   Details of how this process works can be found in the section
   titled [8]Credential-based Login in the Identity Credentials
   specification. The important thing to note about this approach is
   that it takes all the best parts of Persona while overcoming key
   things that caused its demise. Namely:
     * Using an innovative new technology called [9]Telehash, it is
       fully decentralized from day one.
     * It doesn't require browser buy-in, but is implemented in such
       a way that allows it to be integrated into the browser
       eventually.
     * It is focused on privacy, ensuring that your identity provider
       can't track the sites that you are logging into.
     * It uses an email address as your login ID, which is a proven
       approach to login on the Web.
     * It is simple, requiring far fewer web developer gymnastics
       than OpenID to implement. It's just one Javascript library and
       one navigator.id.login() call.
     * It doesn't require email providers to buy into the protocol
       like Persona did. Any party that the relying party website
       trusts can digitally sign a verified email credential.
     * If your identity provider goes down, there is still hope that
       you can login by storing your email credentials in a
       password-protected decentralized hash table on the Internet.

Why Telehash?

   There is a part of this protocol that requires the system to map
   your email address to an identity provider. The way Persona did it
   was to query to see if your email provider was a Persona Identity
   Provider (decentralized), and if not, the system would fall back
   to Mozilla's email-based verification system (centralized).
   Unfortunately, if Persona's verification system was down, you
   couldn't log into a website at all. This rarely happened, but that
   was more because Mozilla's team was excellent at keeping the site
   up and there weren't any serious attempts to attack the site. It
   was still a centralized solution.

   The Identity Credentials specification takes a different approach
   to the problem. It allows any identity provider to claim an email
   address. This means that you no longer need buy-in from email
   providers. You just need buy-in from identity providers, and there
   are a ton of them out there that would be happy to claim and
   verify addresses like john.doe@gmail.com, or
   alice.smith@ymail.com. Unfortunately, this approach means that
   either you need browser support, or you need some sort of mapping
   mechanism that maps email addresses to identity providers. Enter
   [10]Telehash.

   Telehash is an Internet-wide distributed hashtable (DHT) based on
   the proven [11]Kademlia protocol used by BitTorrent and Gnutella.
   All communication is fully encrypted. It allows you to
   store-and-replicate things like the following JSON document:

{
  "email": "john.doe@gmail.com",
  "identityService": "https://identity.example.com/identities"
}

   If you want to find out who john.doe@gmail.com's identity provider
   is, you just query the Telehash network. The more astute readers
   among you see the obvious problem in this solution, though. There
   are massive trust, privacy, and distributed denial of service
   attack concerns here.

Attacks on the Distributed Mapping Protocol

   There are four problems with the system described in the previous
   section.

   The first is that you can find out which email addresses are
   associated with which identity providers; that leaks information.
   Finding out that john.doe@gmail.com is associated with the
   https://identity.example.com/ identity provider is a problem.
   Finding out that they're also associated with the
   https://public.cyberwarfare.usairforce.mil/ identity provider outs
   them as military personnel, which turns a regular privacy problem
   into a national security issue.

   The second is that anyone on the network can claim to be an
   identity provider for that email address, which means that there
   is a big phishing risk. A nefarious identity provider need only
   put an entry for john.doe@gmail.com in the DHT pointing to their
   corrupt identity provider service and watch the personal data
   start pouring in.

   The third is that a website wouldn't know which digital signature
   on a email to trust. Which verified credential is trustworthy and
   which one isn't?

   The fourth is that you can easily harvest all of the email
   addresses on the network and spam them.

Attack Mitigation on the Distributed Mapping Protocol

   There are ways to mitigate the problems raised in the previous
   section. For example, replacing the email field with a hash of the
   email address and passphrase would prevent attackers from both
   spamming an email address and figuring out how it maps to an
   identity provider. It would also lower the desire for attackers to
   put fake data into the DHT because only the proper email +
   passphrase would end up returning a useful result to a query. The
   identity service would also need to be encrypted with the
   passphrase to ensure that injecting bogus data into the network
   wouldn't result in an entry collision.

   In addition to these three mitigations, the network would employ a
   high CPU/memory [12]proof-of-work to put a mapping into the DHT so
   the network couldn't get flooded by bogus mappings. Keep in mind
   that the proof-of-work doesn't stop bad data from getting into the
   DHT, it just slows its injection into the network.

   Finally, figuring out which verified email credential is valid is
   tricky. One could easily anoint 10 non-profit email verification
   services that the network would trust, or something like the
   certificate-authority framework, but that could be argued as
   over-centralization. In the end, this is more of a policy decision
   because you would want to make sure email verification services
   are legally bound to do the proper steps to verify an email while
   ensuring that people aren't gouged for the service. We don't have
   a good solution to this problem yet, but we're working on it.

   With the modifications above, the actual data uploaded to the DHT
   will probably look more like this:

{
  // SHA256 hash of john.doe@gmail.com + >15 character passphrase
  "id": "c8e52c34a306fe1d487a6b60b10d452bcbe268d37b0",
  // Proof of work for email to identity service mapping
  "proofOfWork": "000000000000f7322e6add42",
  // Passphrase-encrypted identity provider service URL
  "identityService": "GZtJR2B5uyH79QXCJ...s8N2B5utJR2B54m0Lt"
}

   To query the network, the customer must provide both an email
   address and a passphrase which are hashed together. If the hash
   doesn't exist on the network, then nothing is returned by
   Telehash.

   Also note that this entire Telehash-based mapping mechanism goes
   away once the technology is built into the browser. The telehash
   solution is merely a stop-gap measure until the identity
   credential solution is built into browsers.

The Far Future

   In the far future, browsers would communicate with your identity
   providers to retrieve data that are requested by websites. When
   you attempt to login to a website, the website would request a set
   of credentials. Your browser would either provide the credentials
   directly if it has cached them, or it would fetch them from your
   identity provider. This system has all of the advantages of
   Persona and provides realistic solutions to a number of the
   scalability issues that Persona suffers from.

   The greatest challenges ahead will entail getting a number of
   things right. Some of them include:
     * Mitigate the attack vectors for the Telehash +
       Javascript-based login solution. Even though the
       Telehash-based solution is temporary, it must be solid until
       browser implementations become the norm.
     * Ensure that there is buy-in from large companies wanting to
       provide credentials for people on the Web. We have a few major
       players in the pipeline at the moment, but we need more to
       achieve success.
     * Clearly communicate the benefits of this approach over OpenID
       and Persona.
     * Make sure that setting up your own credential-based identity
       provider is as simple as dropping a PHP file into your
       website.
     * Make it clear that this is intended to be a W3C standard by
       [13]creating a specification that could be taken
       standards-track within a year.
     * Get buy-in from web developers and websites, which is going to
       be the hardest part.

References

   1. http://www.mozilla.org/en-US/persona/
   2.
http://identity.mozilla.com/post/78873831485/transitioning-persona-to-community-ownership
   3. https://news.ycombinator.com/item?id=7362613
   4. http://hueniverse.com/2012/07/on-leaving-oauth/
   5. https://web-payments.org/
   6. https://wiki.mozilla.org/Identity/Persona_AAR
   7. https://web-payments.org/specs/source/identity-credentials/
   8.
https://web-payments.org/specs/source/identity-credentials/#web-credential-based-login
   9. http://telehash.org/
  10. http://telehash.org/
  11. http://en.wikipedia.org/wiki/Kademlia
  12. http://en.wikipedia.org/wiki/Proof_of_work
  13. https://web-payments.org/specs/source/identity-credentials/


-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Worlds First Web Payments Workshop
http://www.w3.org/2013/10/payments/
Received on Sunday, 16 March 2014 05:28:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:28 UTC