Identity-inputs

From MozillaWiki
Jump to: navigation, search

Identity-inputs is an Identity related brainstorm towards adding to HTML5 and perhaps other standards.

summary

Better form annotation for expressing identity related interactions was a common theme discussed at the 2011 W3C workshop on Identity in the Browser (#idbrowser).

This is a work-in-progress brainstorm for how to add form annotation for expressing identity to HTML5.

goals and non-goals

This proposal is aiming to be a series of small, tightly-constrained, incremental improvements to the existing web with the hope that it will (a) allow password managers to work more reliably, and (b) move us closer to the goal of having the browser be involved in (and mediate) the interactions. It must be clear how whatever is proposed in this document will achieve these goals.

Completely redesigning the login experience and require service providers or users to adopt new forms of identification and authentication are explicitly off the table.

use cases

Updated 2011-168.

All of these represent common web forms / pages that web designers write markup for in typical login / e-commerce etc. sites/applications.

  1. sign-up AKA join
  2. sign-in AKA login
  3. challenge sign-in (e.g. when you do something on a site that makes it ask you to login again, e.g. when going to your shopping cart / checking-out on Amazon, or when a sign-in expires, e.g. Yahoo authentication, and you try to do something and get prompted to sign-in again)
  4. change password
  5. change id
  6. challenge change id
  7. forgot password
  8. forgot username
  9. forgot follow-up change password

sign-up

Typical sign-up forms have at a minimum the following semantic form inputs:

  • new username/email
  • new password
  • confirm password

Some sign-up forms have:

  • 2nd factor authentication

Specific example URLs and/or screenshots welcome and encouraged!

sign-in

Typical sign-in forms have:

  • current username (might be text, email, or a URL e.g. OpenID/RelMeAuth)
  • current password
  • [x] Remember me

Specific example URLs and/or screenshots welcome and encouraged!

challenge sign-in

  • current username (might be readonly)
  • current password
  • [x] Remember me

Specific example URLs and/or screenshots welcome and encouraged!

change password

  • current password
  • new password
  • confirm password

Specific example URLs and/or screenshots welcome and encouraged!

change id

  • current username
  • new username (might be the same form field, e.g. Twitter id change field)
  • (Save) button

Specific example URLs and/or screenshots welcome and encouraged!

challenge change id

  • current username
  • new username (might be the same form field)
  • current password ?

Not sure about this one (as a real world use-casek, can't think of a site that does this off the top of my head).

Specific example URLs and/or screenshots welcome and encouraged!

forgot password

  • current username

Specific example URLs and/or screenshots welcome and encouraged!

forgot username

  • current email - used to look up username, or just submit a forgot password form.

Specific example URLs and/or screenshots welcome and encouraged!

forgot follow-up change password

When you receive a "forgot password" email, typically it has a link which when clicked takes you to a one-time form on the site which then makes you change your password with some form fields like:

  • current username (typically readonly)
  • new password
  • confirm password

Specific example URLs and/or screenshots welcome and encouraged!

common semantic form inputs

From the above use-cases, we can derive the following list of discrete common semantic form inputs

  • new username (variants: might be text, email, or URL id)
  • current username (same variants, with possible readonly option)
  • new password
  • current password
  • confirm password
  • [x] Remember me (possibly readonly)
  • 2nd factor authentication

brainstorm markup

Current HTML5 related form inputs:

  • input type="text"
  • input type="email"
  • input type="url"
  • input type="password"
  • input type="checkbox"

Additional strawman attribute proposals to express semantics as noted above:

  • 'userid' binary attribute - noting that an input is semantically being used as a userid, e.g.:
    • username: input type="text" userid="userid"
    • userid email: input type="email" userid="userid"
    • userid URL: input type="url" userid="userid"
    • note: not sure if we need to distinguish userid="new" or userid="current" but that might be useful per the above use-cases.
  • 'pwtype' attribute with values 'new' (create, sign-up), 'current' (sign-in), 'confirm' (verify) e.g.
    • new password: input type="password" pwtype="new"
    • current password: input type="password" pwtype="current"
    • confirm password: input type="password" pwtype="confirm"
  • 'rememberme' binary attribute - noting that a checkbox means "Remember me", e.g.
    • [x] Remember me: input type="checkbox" rememberme="rememberme"

Feel free to bikeshed / suggest alternate names / terms for 'userid', 'new', 'current', 'pwtype', 'new', 'current', 'confirm', 'rememberme' - these were all made up based on first thoughts and there is no particularly partiality towards them.

  • ...

open issues

Open issues regarding the above brainstorm proposal. Please add new issues as === subheads.

issue 1: Do we need to be able to identify the relevant realms and identities in each use case? If so, how will we do that?

For many of the use cases, in order for a password manager to know how to fill out the form correctly, it needs to know not only which elements of the form are relevant and how they are being used, but some amount of currently active state. In particular, we probably need to know which "realm" is relevant for the form, and if an active identity is required, which one is currently active.

For example, the "change password" form and the "sign in" form are almost certainly on different URLs. How do we know that they should be used for the same identity? It's not sufficient to assume that if they are part of the same origin, they should be correlated (existing password managers have lots of heuristics to try and figure out when to apply credentials saved on one URL to another).

Another example: if I'm running through the forgot flow and I click on a link in an email that takes me to a URL, if the password manager has stored multiple sets of credentials for that realm, how does it find out which set to use to fill out the "old password"?

issue 2: What is the "win" of each proposed change?

For each change we're proposing, we should be clear about whether or not it actually will make password managers more reliable or useful, or whether it depends on other things happening as well. Can each change be adopted individually? Do any of them require other changes as well?

history

Moving stuff here as it happens / gets iterated on.

informal brainstorming meeting 2011-06-17

Iterated on use-cases from 2011-05-25 presentation, came up with a few more use-cases, which implied a set of input semantics, which were then turned into iterations of straw proposals.

idbrowser workshop 2011-05-25

Straw proposal from Tantek presented at the 2011-05-25 W3C workshop on Identity in the Browser event.

  • input type="identity-url"
    • alternately: input type="url" identity
  • input type="identity-email"
    • alternately: input type="email" identity
  • input type="identity-username"
    • alternately: input type="text" identity
  • input type="password" pwtype="sign-in"
  • input type="password" pwtype="create"
  • input type="password" pwtype="confirm"
  • input type="checkbox" rememberme

related

possibly related

Retrieved from "https://wiki.mozilla.org/index.php?title=Identity-inputs&oldid=322699"