Re: Proof of Concept: Identity Credentials Login

I’ve not read to comprehension the below text; but rather went and had a capt. cook… (a look). 

Great work!!  V.Impressed with the architecture of the solution. 

Especially impressed that it’s in GitHub.

I’ve put up some ideas [1] around compatibility with existing RWW Solutions. 

I’ll comprehend information attached; and follow-up…  Perhaps some assumptions are incorrect, therein my notes around the issues are misaligned in someway.

I think the device credential (x509v3 cert); perhaps linking to a FQDN or other challenge - in addition to the passphrase. else, perhaps simply use a combination of credentials depending on the device profile.

IE: my personal Desktop computer (located in a relatively safe environment that no-one usually uses).

I might set my x509 cert to have a authentication sequence of 1 additional credential for basic tasks, and 2 additional for sensitive tasks - or perhaps some sort of rating system around the quality of those credentials (meaning, if your using another persons account / computer - then getting access to their email may be via the same barriers required to open the browser on their computer.) 

Whereas; a public access computer based in a library may have a device ID that can be used, for authentication.  This could be used with my account, but i might set the barriers to access higher (several challenges / additional hardware key, timeframes, etc.). 

I hope that explains things.  

FUNCTIONAL REQUIREMENTS?
- In relation to the ‘Age Verification’ - I assume your looking for a DOB? (therefore inferring the age of the person?) or are you getting a Form of AGE Rating Approve / Deny Method [2][3]? 
- In relation to ‘minors’ (meaning children or others who require a financial / medical / power of attorney or guardian); I assume a means to link identities is required.  Therefore, being able to ‘link identities’; for particular purpose.

Could be that ‘dad’ is happy to pay for his ‘daughters’ fuel / transport needs to get to/from uni (perhaps to a specified weekly / monthly limit, accrued or otherwise). 

I’ll post any issues i experience... 

Great work!!! I got my head around it quickly and easily.  

[1] https://github.com/digitalbazaar/opencred-idp/issues
[2] http://www.bbfc.co.uk/what-classification/digital-age-ratings
[3] http://www.mpaa.org/film-ratings/

On 10 Jun 2014, at 2:25 pm, Manu Sporny <msporny@digitalbazaar.com> wrote:

> 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/
> 
>