- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Tue, 10 Jun 2014 07:49:44 +0200
- To: public-webid <public-webid@w3.org>, public-rww <public-rww@w3.org>
- Message-ID: <CAKaEYhL8WRDpz5C4EaiNpRKZYrRrsfBtvdYnH72TKofbckZw6A@mail.gmail.com>
FYI
---------- Forwarded message ----------
From: Manu Sporny <msporny@digitalbazaar.com>
Date: 10 June 2014 06:25
Subject: Proof of Concept: Identity Credentials Login
To: Web Payments CG <public-webpayments@w3.org>
TL;DR: There is now an open source demo of credential-based login
for the Web. We think it’s better than Persona, WebID+TLS, and
OpenID Connect. If we can build enough support for Identity
Credentials over the next year, we’d like to standardize it via
the W3C.
This is a text-only version of the original blog post, which can be found
here:
http://manu.sporny.org/2014/identity-credentials/
Identity Credentials and Web Login
In a [1]previous blog post, I outlined the need for a better login
solution for the Web and why Mozilla Persona, WebID+TLS, and
OpenID Connect currently don’t address important use cases that
we’re considering in the Web Payments Community Group. The blog
post contained a proposal for a new login mechanism for the Web
that was simultaneously more decentralized, more extensible,
enabled a level playing field, and was more privacy-aware than the
previously mentioned solutions.
In the private conversations we have had with companies large and
small, the proposal was met with a healthy dose of skepticism and
excitement. There was enough excitement generated to push us to
build a proof-of-concept of the technology. We are releasing this
proof-of-concept to the Web today so that other technologists can
take a look at it. It’s by no means done, there are plenty of bugs
and security issues that we plan to fix in the next several weeks,
but the core of the idea is there and you can try it out.
The Demo
The demonstration that we’re releasing today is a proof-of-concept
asserting that we can have a unified, secure identity and login
solution for the Web. The technology is capable of storing and
transmitting your identity credentials (email address, payment
processor, shipping address, driver’s license, passport, etc.)
while also protecting your privacy from those that would want to
track and sell your online browsing behavior. It is in the same
realm of technology as Mozilla Persona, WebID+TLS, and OpenID
Connect. Benefits of using this technology include:
* Solving the [2]NASCAR login problem in a way that greatly
increases identity provider competition.
* Removing the need for usernames and passwords when logging
into 99.99% of the websites that you use today.
* Auto-filling information that you have to repeat over and over
again (shipping address, name, email, etc.).
* Solving the NASCAR payments problem in a way that greatly
increases payment processor competition.
* Storage and transmission of credentials, such as email
addresses, driver’s licenses, and digital passports, via the
Web that cryptographically prove that you are who you say you
are.
The demonstration is based on the [3]Identity Credentials
technology being developed by the [4]Web Payments Community Group
at the [5]World Wide Web Consortium. It consists of an ecosystem
of four example websites. The purpose of each website is explained
below:
Identity Provider (identus.org)
The Identity Provider stores your identity document and any
information about you including any credentials that other sites
may issue to you. This site is used to accomplish several things
during the demo:
* Create an identity.
* Register your identity with the Login Hub.
* Generate a verified email credential and store it in your
identity.
Login Hub (login-hub.com)
This site helps other websites discover your identity provider in
a way that protects your privacy from both the website you’re
logging into as well as your identity provider. Eventually the
functionality of this website will be implemented directly in
browsers, but until that happens, it is used to bootstrap the
discovery of and login/credential transmission process for the
identity provider. This site is used to do the following things
during the demo:
* Register your identity, creating an association between your
identity provider and the email address and passphrase you use
on the login hub.
* Login to a website.
Credential Issuer (credential.club)
This site is responsible for verifying information about you like
your home address, driver’s license, and passport information.
Once the site has verified some information about you, it can
issue a credential to you. For the purposes of the demonstration,
all verifications are simulated and you will immediately be given
a credential when you ask for one. All credentials are digitally
signed by the issuer which means their validity can be proven
without the need to contact the issuer (or be online). This site
is used to do the following things during the demo:
* Login using an email credential.
* Issue other credentials to yourself like a business address,
proof of age, driver’s license, and digital passport.
Single Sign-On Demo
The single sign-on website, while not implemented yet, will be
used to demonstrate the simplicity of credential-based login. The
sign-on process requires you to click a login button, enter your
email and passphrase on the Login Hub, and then verify that you
would like to transmit the requested credential to the single
sign-on website. This website will allow you to do the following
in a future demo:
* Present various credentials to log in.
How it Works
The demo is split into four distinct parts. Each part will be
explained in detail in the rest of this post. Before you try the
demo, it is important that you understand that this is a
proof-of-concept. The demo is pretty easy to break because we
haven’t spent any time polishing it. It’ll be useful for
technologists that understand how the Web works. It has only been
tested in Google Chrome, versions 31 – 35. There are glaring
security issues with the demo that have solutions which have not
been implemented yet due to time constraints. We wanted to publish
our work as quickly as possible so others could critique it early
rather than sitting on it until it was “done”. With those caveats
clearly stated up front, let’s dive in to the demo.
Creating an Identity
The first part of the demo requires you to [6]create an identity
for yourself. Do so by clicking the link in the previous sentence.
Your short name can be something simple like your first name or a
handle you use online. The passphrase should be something long and
memorable that is specific to you. When you click the Create
button, you will be redirected to your new identity page.
Note the text displayed in the middle of the screen. This is your
raw identity data in [7]JSON-LD format. It is a machine-readable
representation of your credentials. There are only three pieces of
information in it in the beginning. The first is the JSON-LD
@context value, https://w3id.org/identity/v1, which tells machines
how to interpret the information in the document. The second is
the id value, which is the location of this particular identity on
the Web. The third is the sysPasswordHash, which is just a bcrypt
hash of your login password to the identity website.
Global Web Login Network
Now that you have an identity, you need to register it with the
global Web login network. The purpose of this network is to help
map your preferred email address to your identity provider. Keep
in mind that in the future, the piece of software that will do
this mapping will be your web browser. However, until this
technology is built into the browser, we will need to bootstrap
the email to identity document mapping in another way.
The way that both Mozilla Persona and OpenID do it is fairly
similar. OpenID assumes that your email address maps to your
identity provider. So, an OpenID login name of joe@gmail.com
assumes that gmail.com is your identity provider. Mozilla Persona
went a step further by saying that if gmail.com wouldn’t vouch for
your email address, that they would. So Persona would first check
to see if gmail.com spoke the Persona protocol, and if it didn’t,
the burden of validating the email address would fall back to
Mozilla. This approach put Mozilla in the unenviable position of
running a lot of infrastructure to make sure this entire system
stayed up and running.
The Identity Credentials solution goes a step further than Mozilla
Persona and states that you are the one that decides which
identity provider your email address maps to. So, if you have an
email address like bob@gmail.com, you can use yahoo.com as your
identity provider. You can probably imagine that this makes the
large identity providers nervous because it means that they’re now
going to have to compete for your business. You have the choice of
who is going to be your identity provider regardless of what your
email address is.
So, let’s register your new identity on the global web login
network. Click the text on the screen that says “Click here to
register”. That will take you to a site called login-hub.com. This
website serves two purposes. The first is to map your preferred
email address to your identity provider. The second is to protect
your privacy as you send information from your identity provider
and send it to other websites on the Internet (more on this
later).
You should be presented with a screen that asks you for three
pieces of information. Your preferred email address, a passphrase,
and a verification of that passphrase. When you enter this
information, it will be used to do a number of things. The first
thing that will happen is that a public/private keypair will be
generated for the device that you’re using (your web browser, for
instance). This key will be used as a second factor of
authentication in later steps in this process. The second thing
that will happen is that your email address and passphrase will be
used to generate a query token, which will be later used to query
the decentralized [8]Telehash-based identity network. The third
thing that will happen is that your query token to identity
document mapping will be encrypted and placed onto the Telehash
network.
The Decentralized Database (Telehash)
We could spend an entire blog post itself on Telehash, but the
important thing to understand about it is that it provides a
mechanism to store data in a decentralized database and query that
database at a later time for the data. By storing this query token
and query response in the decentralized database, it allows us to
find your identity provider mapping regardless of which device
you’re using to access the Web and independent of who your email
provider is.
In fact, note that I said that you use your “preferred email
address” above? It doesn’t need to be an email address, it could
be a simple string like “Bob” and a unique passphrase. Even though
there are many “Bob”s in the world, the likelyhood that they’d use
the same 20+ character passphrase is unlikely and therefore one
could use just a first name and a complex passphrase. That said,
we’re suggesting that most non-technical people use a preferred
email address because most people won’t understand the dangers of
SHA-256 collisions on username+passphrase combinations like
sha256(“Bob” + “password”). In addition to this aside, the
decentralized database solution doesn’t need to be Telehash. It
could just as easily be a decentralized ledger like Namecoin or
Ripple.
Once you have filled out your preferred email address and
passphrase, click the Register button. You will be sent back to
your identity provider and will see two new pieces of information.
The first piece of information is sysIdpMapping, which is the
decentralized database query token (query) and
passphrase-encrypted mapping (queryResponse). The second piece of
information is sysDeviceKeys, which is the public key associated
with the device that you registered your identity through and
which will be used as a second factor of authentication in later
versions of the demo. The third piece of information is
sysRegistered, which is an indicator that the identity has been
registered with the decentralized database.
Acquiring an Email Credential
At this point, you can’t really do much with your identity since
it doesn’t have any useful credential information associated with
it. So, the next step is to put something useful into your
identity. When you create an account on most websites, the first
thing the website asks you for is an email address. It uses this
email address to communicate with you. The website will typically
verify that it can send and receive an email to that address
before fully activating your account. You typically have to go
through this process over and over again, once for each new site
that you join. It would be nice if an identity solution designed
for the Web would take care of this email registration process for
you. For those of you familiar with Mozilla Persona, this approach
should sound very familiar to you.
The Identity Credentials technology is a bit different from
Mozilla Persona in that it enables a larger number of
organizations to verify your email address than just your email
provider or Mozilla. In fact, we see a future where there could be
tens, if not hundreds, of organizations that could provide email
verification. For the purposes of the demo, the Identity Provider
will provide a “simulated verification” (aka fake) of your email
address. To get this credential, click on the text that says
“Click here to get one”.
You will be presented with a single input field for your email
address. Any email address will do, but you may want to use the
preferred one you entered earlier. Once you have entered your
email address, click “Issue Email Credential”. You will be sent
back to your identity page and you should see your first
credential listed in your JSON-LD identity document beside the
credential key. Let’s take a closer look at what constitutes a
credential in the system.
The EmailCredential is a statement that a 3rd party has done an
email verification on your account. Any credential that conforms
to the Identity Credentials specification is composed of a set of
claims and a signature value. The claims tie the information that
the 3rd party is asserting, such as an email address, to the
identity. The signature is composed of a number of fields that can
be used to cryptographically prove that only the issuer of the
credential was capable of issuing this specific credential. The
details of how the signature is constructed can be found in the
[9]Secure Messaging specification.
Now that you have an email credential, you can use it to log into
a website. The next demonstration will use the email credential to
log into a credential issuer website.
Credential-based Login
Most websites will only require an email credential to log in.
There are other sites, such as ecommerce sites or high-security
websites, that will require a few more credentials to successfully
log in or use their services. For example, a ecommerce site might
require your payment processor and shipping address to send you
the goods you purchased. A website that sells local wines might
request that you provide a credential proving that you are above
the required drinking age in your locality. A travel website might
request your digital passport to ease your security clearing
process if you are traveling internationally. There are many more
types of speciality credentials that one may issue and use via the
Identity Credentials technology. The next demo will entail issuing
some of these credentials to yourself. However, before we do that,
we have to login to the credential issuer website using our newly
acquired email credential.
Go to the [10]credential.club website and click on the “Login”
button. This will immediately send you to the login hub website
where you had previously registered your identity. The request
sent to the login hub by credential.club will effectively be a
request for your email credential. Once you’re on login-hub.com,
enter your preferred email address and passphrase and then click
“Login”.
While you were entering your email address and passphrase, the
login-hub.com page connected to the Telehash network and readied
itself to send a query. When you click “Login”, your email address
and passphrase are SHA-256′d and sent as a query to the Telehash
network. Your identity provider will receive the request and
respond to the query with an encrypted message that will then be
decrypted using your passphrase. The contents of that message will
tell the login hub where your identity provider is holding your
identity. The request for the email credential is then forwarded
to your identity provider. Note that at this point your identity
provider has no idea where the request for your email credential
is coming from because it is masked by the login hub website. This
masking process protects your privacy.
Once the request for your email credential is received by your
identity provider, a response is packaged up and sent back to
login-hub.com, which then relays that information back to
credential.club. Once credential.club recieves your email
credential, it will log you into the website. Note at this point
that you didn’t have to enter a single password on the
credential.club website, all you needed was an email credential to
log in. Now that you have logged in, you can start issuing
additional credentials to yourself.
Issuing Additional Credentials
The previous section introduced the notion that you can issue many
different types of credentials. Once you have logged into the
credential.club website, you may now issue a few of these
credentials to yourself. Since this is a demonstration, no attempt
will be made to verify those credentials by a 3rd party. The
credentials that you can issue to yourself include a business
address, proof of age, payment processor, driver’s license, and
passport. You many specify any information that you’d like to
specify in the input fields to see how the credential would look
if it held real data.
Once you have filled out the various fields, click the blue button
to issue the credential. The credential will be digitally signed
and sent to your identity provider, which will then show you the
credential that was issued to you. You have a choice to accept or
reject the credential. If you accept the credential, it is written
to your identity.
You may repeat this process as many times as you would like. Note
that on the passport credential how there is an issued on date as
well as an expiration date to demonstrate that credentials can
have a time limit associated with them.
Known Issues
As mentioned throughout this post, this demonstration has a number
of shortcomings and areas that need improvement, among them are:
* Due to a lack of time, we didn’t setup our own HTTPS Telehash
seed. Since we didn’t setup the HTTPS Telehash seed, we
couldn’t run login-hub.com secured by TLS due to security
settings in most web browsers related to WebSocket
connections. Not using TLS results in a gigantic
man-in-the-middle attack possibility. A future version will,
of course, use both TLS and HSTS on the login-hub.com website.
* The Telehash query/response database isn’t decentralized yet.
There are a number of complexities associated with creating a
decentralized storage/query network, and we haven’t decided on
what the proper approach should be. There is no reason why the
decentralized database couldn’t be NameCoin or Ripple-based,
and it would probably be good if we had multiple backend
databases that supported the same query/response protocol.
* We don’t check digital signatures yet, but will soon. We were
focused on the flow of data first and ensuring security
parameters were correct second. Clearly, you would never want
to run such a system in production, but we will improve it
such that all digital signatures are verified.
* We do not use the public/private keypair generated in the
browser to limit the domain and validity length of credentials
yet. When the system is productionized, implementing this will
be a requirement and will protect you even if your credentials
are stolen through a phishing attack on login-hub.com.
* We expect there to be many more security vulnerabilities that
we haven’t detected yet. That said, we do believe that there
are no major design flaws in the system and are releasing the
proof-of-concept, along with [11]source code, to the general
public for feedback.
Feedback and Future Work
If you have any questions or concerns about this particular demo,
please leave them as comments on this blog post or send them as
comments to the [12]public-web-payments@w3.org mailing list.
Just as you logged in to the credential.club website using your
email credential, you may also use other credentials such as your
driver’s license or passport to log in to websites. Future work on
this demo will add functionality to demonstrate the use of other
forms of credentials to perform logins while also addressing the
security issues outlined in the previous section.
References
1. http://manu.sporny.org/2014/credential-based-login/
2. http://indiewebcamp.com/NASCAR_problem
3. http://manu.sporny.org/2014/credential-based-login/
4. https://web-payments.org/
5. http://www.w3.org/Consortium/
6. https://identus.org/create
7. https://www.youtube.com/watch?v=vioCbTo3C-4
8. http://telehash.org/
9. https://web-payments.org/specs/source/secure-messaging/
10. https://credential.club/
11. https://github.com/digitalbazaar/opencred-idp
12. http://lists.w3.org/Archives/Public/public-webpayments/
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Identity Credentials and Web Login
http://manu.sporny.org/2014/identity-credentials/
Received on Tuesday, 10 June 2014 05:50:14 UTC