- From: Brent Shambaugh <brent.shambaugh@gmail.com>
- Date: Mon, 17 Mar 2014 21:01:33 -0500
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Web Payments <public-webpayments@w3.org>
- Message-ID: <CACvcBVp33MZS9NSQZCiTNOeZ88LteMN4BYQo42NXa3HKs1QShw@mail.gmail.com>
The other link I have is about INGA:
Loser, Alexander et al., Semantic Social Overlay Networks, IEEE Journal on
Selected Areas in Communication, Vol. 25, No. 1, January 2007
On Mon, Mar 17, 2014 at 8:59 PM, Brent Shambaugh
<brent.shambaugh@gmail.com>wrote:
> 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 02:02:02 UTC