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.
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.
Implementation complexity. (This would require keeping site-specific state client-side, verifying & invalidating said state periodically, etc.)
Specification complexity. If we determine we need other account management well-known resources in the future, we can specify them then.
- 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.
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.