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

Re: A Proposal for Credential-based Login

From: Brent Shambaugh <brent.shambaugh@gmail.com>
Date: Mon, 17 Mar 2014 20:59:10 -0500
Message-ID: <CACvcBVo8H5qnZQbLckOeQYAKSM0e9qcH6u3wOCL-8VKojarmtQ@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: Web Payments <public-webpayments@w3.org>
Manu,

Have you ever heard of Tribler (1)? It takes advantage of semantic
information to improve the performance DHT. Does Telehash have these
problems?

(1) http://iptps06.cs.ucsb.edu/papers/Pouw-Tribler06.pdf


On Sun, Mar 16, 2014 at 12:28 AM, Manu Sporny <msporny@digitalbazaar.com>wrote:

> 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 Tuesday, 18 March 2014 01:59:39 UTC

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