Hacker News new | past | comments | ask | show | jobs | submit login

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.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact