Hacker News Reader

Comment by peterwwillis | Hacker News Reader

Here is the actual spec: https://wicg.github.io/change-password-url/index.html

Presumably this is only for accounts you are already logged into and want to change the password of, since change password forms usually aren't accessible unless you are already logged in.

However, the same domain may involve multiple account types. AWS and other popular websites have multiple types of accounts, different login methods, and different change-password forms, on the same domain. If all this URL does is redirect to one single page per domain, it won't work for cases of more than one type of login.

Also, it seems that password reset is a lot more common than just changing a password, so maybe this spec could be extended to that form, too?

View on HN

Where it links would be up to the website. The password manager doesn't know if you are already logged in or not, just that the user requested an intent to change their password at example.com. The password manager should just open the URL in the user's default browser. Then it's up to the website itself to redirect to a login flow if need be (they don't have a logged in cookie on that browser), including the password reset flow if necessary.

If a website has more than one account type that the user might want to change the password for, it could add some sort of flow to ask which account was meant. If the user has more than one account at the website, that becomes up to the user to make sure they signed into the right one that they wanted to password change. If the website is aware the user may have more than one account (such as Google's account switcher), they could present the options directly then.

It seems easy enough to do the right thing in most cases, given how simple this proposal is.

If every website has to "figure out" how to "do the right thing", do you just assume they'll all do the same thing in the same way? I think they'll all come up with different ways to solve the problems, which will result in a different user experience for each site. So users will have to do something different on every site when they want to change their password.

So it'll be the same as it is now, except that there's a button to start the process of doing the non-standard thing. I think a little bit of extra work on the standard could result in a more standard experience, and less work for the user.

They already do things the way they want. TFA doesn't change that. This kind of spec doesn't and shouldn't specify UX. It's simply "where do your users go to change passwords?" with a simple reply of "Here: $URL".

Right, the web has never figured out how to scale password UX. There are reasons websites don't intentionally use HTTP Basic/Digest Auth in 2018, beyond the basic implementation details that Basic/Digest aren't particularly secure. Most websites don't want a consistent user interface for password input. Login interfaces are important places to put branding, and include security theater to help users feel safe. The login page is the welcome mat of the web, and every site has a different idea of how it should be experienced, partly because that's a differentiator they want.

It's actually only relevant to UX. It's not useful as an API call. You can't feed it any data, and it doesn't provide anything but a single URL redirect. It will just become a big "Change Password" button on a password manager.

In order to change the password, you have to be logged in. So the website will have to redirect the user to a log-in form, passing along the change-password form URL when authentication succeeds. Then the user can put in the old password and new password, go through an optional MFA hokey-pokey, and get it changed.

If the intent is to speed up password changes, a few optional additions would be faster than the above. The spec could optionally allow (1) the account ID, (2) the user ID, (3) the old password, and (4) the new password. The response could be a challenge and consent request for the user, which the user could then affirm and submit.

The website could still dictate how this works, but the idea is that the password manager would pass along all relevant data in the initial request, eliminating the need for the user to enter it all manually, and eliminating extra page loads. But it requires no site-specific state on the client-side, because all requests would be exactly the same, to this generic URL. Whatever implements the spec URL on the server-side would perform the login and present the password reset challenge, pre-populated for the user.

I think you are confusing the applicable scope of what the proposal implements with something else you'd like to see implemented.

This is not even an API. It is merely a proposal that wherever your change-password form lives, people should be able to get to it via this specific path, too. Perhaps this whole thing is a terrible idea, but either way the problem they're trying to solve is different than the problem you're trying to solve.

I wonder if URLs like /.well-known/login and /.well-known/logout would be a good idea, and should belong to a similar spec. Maybe even /.well-known/register, too.

Once the Web Authentication API becomes reliable usable this would make quite a lot of sense.

At last wrt. login and register for doing the "first" auth which is then stored in the authenticator, e.g. a username/password login).

Why not use simple HTTP authentication?

A lot of site design requirements won't fit well with simple HTTP auth. If the company wants to display a password recovery link or display pricing information to potential customers it's incompatible with using HTTP auth without a lot of extra bells and whistles.

These are all relatively common business requirements.

It doesn't support things like SSO / federated authentication, multiple password fields for 2FA, multiple username fields for realm/domain and individual account, etc.

The web already has a perfectly good solution for arbitrary forms, and has had it for decades. Just use that.

Also .well-known/change-profile and .well-known/post-comment and .well-known/add-to-cart.

change-profile is usually a single URL that operates on the current user. Which resource would post-comment and add-to-cart act on?

There is, kind of, https://openid.net/specs/openid-connect-frontchannel-1_0.htm...

Usually the place where you realize you forgot your password is the login form. So the 'standard' link/button/whatever below/next to/in proximity of the login form works quite well for this.

Since the spec is intended for password managers and other user agents, it makes sense to have a standard location to access such functionality.

Also the page could be anything (i.e. doesn't have to be a redirect) so theoretically AWS could set up an account chooser that has links to all the appropriate places for your accounts

This is being tracked by https://github.com/WICG/change-password-url/issues/4

Reply on news.ycombinator.com