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