W3C home > Mailing lists > Public > public-webid@w3.org > June 2014

Fwd: Proof of Concept: Identity Credentials Login

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Tue, 10 Jun 2014 07:49:44 +0200
Message-ID: <CAKaEYhL8WRDpz5C4EaiNpRKZYrRrsfBtvdYnH72TKofbckZw6A@mail.gmail.com>
To: public-webid <public-webid@w3.org>, public-rww <public-rww@w3.org>
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:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:55 UTC