base origin has multiple apps

[jbtule]

What if there are two apps, https://example.org/appA and https://example.org/appB each with their own login system with different sets of credentials?

[staabm]

Couldnt the browser send a spec defined parameter which contains the full url on which the password form was located at the time of storing the password?

[tschoffelen]

I wonder if we need to comprimise privacy and simplicity by providing more data to the website for what I think might be an edge case.

Can you think of many apps that share the same domain but don’t share the same account system?

A solution that was mentioned on HN for these types of problems is that the website should provide a landing page where the user can choose the app they want to change their password for.

[staabm]

If you think about e.g. Cms systems which have a separate backend/frontend this is even a quite common case IMO

A solution that was mentioned on HN for these types of problems is that the website should provide a landing page where the user can choose the app they want to change their password for.

With such a page one would reveal the backend to the public (which might be intentionally be held secret)

[hober]

example.org can check for the presence of appA and/or appB cookies in the request when determining where to redirect, or it can redirect to a page prompting the user to choose which app they want to change their password in. I don't think we need to make browser behavior more complex here.

[jbtule]

@hober your supposition is incorrect. If you have apps /appA and /appB your cookie path for these apps are going to be set to /appA and /appB thus they will never exist at example.org/.

[jbtule]

So lets say for argument sake safari could store example.org/appa, or example.org/appb with the credentials or lets say a different password manager wants to use your protocol.

A simple solution that would make this protocol work would be, for https://example.org/.well-known/change-password(/)* for the general operators implementation, and have https://example.org/.well-known/change-password/appA sent by the password manager in those cases when they have a path, then the operators can redirect appropriately since they would have the path component.

I understand safari isn't an enterprise password manager, and you think it's okay to offer passwords to sites more generally to the whole domain vs what the site describes it's credentials should be via cookies, but make it more flexible enough to work for other password managers if you want it adopted. Isn't that what this incubator is about.