Your proposal decouples spec from implementation more than the
placeholder approach does, which is good.
I think the CSP directive is unnecessary and makes things more
fragile. The 'protect this credential from XSS' attribute should be
a property of a stored credential, not a web site. If the site has
the correct CSP headers on 99% of its website, but then for some
reason doesn't have them on one page, that page is a potential
vector to expose the credential.
I think making input fields write-only is more powerful than we
strictly need. When a user is manually entering a password, it's
okay for the page to be able to read the value they are typing in.
If the page has been modified by an attacker at this point, it's too
late.
What we want is a mechanism to specify 'once this value is stored in
a password manager*, protect it from future JS on this page.' That's
why I feel like it's relevant to define credential management APIs
for the web.
*or credit card autofiller.
The write-only spec fully breaks XHR form submission (style C in my
earlier mail). As Brian pointed out, the placeholder approach can be
made to work with XHR if you're willing to do a little extra
inspection of arbitrary XHRs.
Also, as you pointed out, write-only breaks client-side validation.
Client-side validation is very broadly used for password strength
meters during signup and change password. I think interfering with
strength meters would make it a lot harder for implementers to adopt
the spec.
I'm curious about the use cases for protecting the password from the webserver.
One common use case for client-side crypto is removing systems from
scope in PCI (payment card industry) compliance. There's a set of
standards related to the handling of credit/debit cards that involve
auditing all systems that have card data. There are third-party
services that offer compliance by having you encrypt card data in JS
and pass it, encrypted, through all your non-compliant systems and
into their secure vault where it is decrypted.
