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.
link element?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.
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.