Saving PSL matched credentials

[battre]

If a website retrieves a PSL matched credential via a user mediated get() and then calls store() on the credential, the credential can become eligible for unmediated provisioning.

Assume the user is on www.example.com and has a password stored for m.example.com. In this case, an account chooser dialog can offer the credential for m.example.com. Assume the user clicks on it and the site calls store(). Should the user be asked whether to store the credential in this case?

It may feel strange because the credential appeared to be stored already. At the same time, https://w3c.github.io/webappsec-credential-management/#user-mediated-storage prescribes that all stores need consent. Should we add an exception that PSL matched credentials may be persisted silently to https://w3c.github.io/webappsec-credential-management/#security-cross-origin-leakage ?

[vabr-g]

This is a good point.
https://w3c.github.io/webappsec-credential-management/#user-mediated-storage is being vague about the scope of the user consent. It says "Credential information must not be stored [...] without explicit user consent," and "the user agent may request a more persistent grant of consent."

Imagine that during saving the first credential, for m.example.com, the user agent asks: "Do you want to store the credentials for "username" on example.com?" If the user says yes, then the user agent may assume that the consent covers all cases when the top domain is example.com and the username is "username". Not prompting on www.example.com would still be in accordance with the spec.

I still think that making this explicit in https://w3c.github.io/webappsec-credential-management/#security-cross-origin-leakage makes sense, because it is being similarly explicit about get() already. I wonder if the spec needs more flexibility to accommodate alternative proofs of affiliation than just PSL.