5
edits
Identity-inputs: Difference between revisions
no edit summary
(→use cases: added subsections for each use-case with the conceptual semantic form inputs that each tends to use) |
No edit summary |
||
| (6 intermediate revisions by 3 users not shown) | |||
| Line 5: | Line 5: | ||
This is a work-in-progress brainstorm for how to add form annotation for expressing identity to HTML5. | 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 == | == use cases == | ||
2011-168 | 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. | All of these represent common web forms / pages that web designers write markup for in typical login / e-commerce etc. sites/applications. | ||
# sign-up AKA join | # sign-up AKA join | ||
| Line 71: | Line 78: | ||
=== forgot follow-up change password === | === 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: | 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: | ||
* username (typically readonly) | * current username (typically readonly) | ||
* new password | * new password | ||
* confirm password | * confirm password | ||
Specific example URLs and/or screenshots welcome and encouraged! | 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 | |||
* <nowiki>[x]</nowiki> 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. | |||
** <nowiki>[x]</nowiki> 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 == | == history == | ||