Re: Proof of Concept: Identity Credentials Login

RE: single sign-on demo

I’m not sure using an email address (which is primarily an email address) is the best path.  Often those who struggle with using internet (and computers) remember their email and password as a pair.  IMHO, this is due in-part to people having a single email address, and some of the language used on sign-up forms, which would be confusing if you didn’t know it didn’t want your password to your email account...

With the ‘single sign-on demo’ i appreciate the lack of centralisation, means the address should associate with a persons IdP.  In some cases, this may be linked to the users own personal domain (ideally) or alternatively, to some other address that’s hosted in relation to the user.  

Secondly; it seems quite important to me; that given parallel development activities surrounding RWW[1], LDP, etc. (often using FOAF documents to describe persona / agent - sometimes in ways i hope this will resolve / narrow - at least in my mind) the ability to present personalised credentials is likely an important factor.

Existing web portals (social network silos[2]) result in organisationally fragmenting personal identities.  Users should be provided the opportunity to fragment their own identity also, to suit their own terms / preferences.   Often devices, operating systems, log-in systems - all desire you to have a single social-network silo (i SNS Account per ‘brand’); hopefully future systems will become more flexible in how social-groups, memberships and related systems, interrelate, systemically - or per the preferences defined organisationally whether mandated, or made burdonsomly more complicated when selecting not to comply with ’tradition’ / UX / UI / traditional Social Network workflows.. 

Put simply; I’d like the choice to fragment my own identity structures; which still need to be verifiable for fiduciary purposes; but otherwise, ideally decided far more by me, than by what service providers i choose/need to use, to participate fully in life.  This in-turn results in a requirement to create secondary persona, which may be handled well by FOAF?   

Some instances of use-cases might include;

- Loyalty Cards;  A Persona reference that states ‘i’m just getting my receipt’ without providing additional credentials, beyond what is necessary to perform the transaction.  A user may decide to migrate the ‘loyalty relationship’ at a latter time, to a specified persona. 
- Work Expenses; an employer might pay for specified expenses.  these expenses could be allocated to an ‘employee orientated’ persona.
- ‘family account’;  might have the credentials shared / used to perform family related functions
- ‘kids pocket money’; might provide a means to give funds to the kids to catch a taxi, bus, buy lunch, etc.

oh; and,

- ‘medical credentials’ - which has privacy requirements, whilst also supporting limitations on pharmacy shopping, or other forms of medicare funding abuse...
- ‘porn account’ - "it’s all above board, and it’s private."  Not for browsing on the TV without a bunch of passwords.

Some of these area of work fits better into RWW / LDP - However, given the belief that the structure of identity credentials as displayed by this demo - has enormous merit already; I figured the URI structure of what would be used as a ‘userid’ (with passphrase/password) is something to be considered, along with possible linkages to how to express a ‘persona’ (or as Kingsley puts it - an ‘agent’); with, or without a users domain.

Perhaps a URI scheme [3] and therein, perhaps the ‘acct’ format[4] (as i’ve seen also just pop-up in WebID), might provide something that could work any FQDN.

EG: 
- accn:facebook@home.dad.myknowledgebankdomain.id 
- accn:Facebook@home.myaccount.bigknowledgebank.com

or,
- deposits@233887645656122277338476.swissbitbanking.io

(NB: didn’t check to see if any of those domains exists; used for example purposes only)

therein; i consider that whilst the scheme of an email address may be used; it is not an email-address necessarily.  The record contained within the ACCN record; might have an email address notated in it. 


Finally; in terms of AUTH Sequence; I think the ability to call additional procedures, is important…  What is likely more important, is the application of x509v3 certs to machines - which then provides a grounding platform, to assert rules relating to auth-sequences (perhaps preferences around what sort of device is being used for what sort of action; and, other data might be used, like GIS location. SMS verification codes may not work in all areas, those kinds issues).  

A site might start by seeking the identity credentials as noted by an address / passphrase - but then ideally; the user can be sent additional 'barriers to entry'; whether that be a hardware key, the use of a multitude of credentials / pass phrases; etc.  

Once successful can complete their task; understanding of course, that the ‘barriers’ may have two influencing factors; those required by a party with fiduciary duty; and the end-user. 

[1] http://www.w3.org/DesignIssues/ReadWriteLinkedData.html
[2] http://www.w3.org/DesignIssues/CloudStorage.html
[3] http://en.wikipedia.org/wiki/URI_scheme
[4] http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-07


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