- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 16 Mar 2014 01:28:22 -0400
- 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