Re: Proof of Concept: Identity Credentials Login

On 10 June 2014 06:25, 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/
>

Interesting project.  A couple of things.

1. Would it be possible to return turtle as well as JSON-LD?

2. Would it be possible to add #this to the end of the @id URL?


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