5
edits
Identity-inputs: Difference between revisions
→issue 1
(add section for open issues) |
|||
| Line 114: | Line 114: | ||
Open issues regarding the above brainstorm proposal. Please add new issues as === subheads. | Open issues regarding the above brainstorm proposal. Please add new issues as === subheads. | ||
=== issue 1 === | === issue 1: tracking the relevant realms and identities as well === | ||
... | |||
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"? | |||
== history == | == history == | ||