A Well-Known URL for Changing Passwords
Table of Contents
Currently, if the user of a password manager would like to change their password on example.com, basically all the password manager can do is load example.com in a browser tab and hope the user can figure out how to update their password themselves.
The goal of this specification is to do the simplest possible thing to improve this situation, by defining the /.well-known/change-password well-known resource.
Proposal
example.com provides a /.well-known/change-password resource which redirects to their change password form, wherever it happens to already be.
Password managers check for the existence of /.well-known/change-password on https://example.com.
If it's there (the response code is 2xx or 3xx), the password manager can cause the user's browser to navigate there when the user indicates they'd like to change their password.
That's it, really. It's a pretty simple idea.
Frequently Asked Questions
Why not allow sites to override this location with an HTTP Link header or an HTML link element?
Implementation complexity. (This would require keeping site-specific state client-side, verifying & invalidating said state periodically, etc.)
Why not serve a JSON resource with links to other account management functions?
Specification complexity. If we determine we need other account management well-known resources in the future, we can specify them then.
What tools have implemented this feature?
- iCloud Keychain on iOS 12
- Safari 12
- 1Password (1Password 8 and 1Password for Chrome, Firefox, Edge and macOS Safari)
- Chrome 86
- Backdrop CMS, via the Well-known module.
What about servers whose HTTP response codes are unreliable?
Sometimes, HTTP servers are configured to respond 200 OK for resources that really aren't there. The Detecting the reliability of HTTP status codes draft attempts to address this problem.