I like the general idea of defining protocols that can help password managers work more seamlessly. But this seems too low level. Most online services run HTT

I like the general idea of defining protocols that can help password managers work more seamlessly. But this seems too low level. Most online services run HTTP services, and afaict, this protocol wants to run on TCP/TLS (though it doesn't specify); seems like it would be more sane to define it as a HTTPS/JSON api for password rotation, given all the online account providers generally have https servers and could easily add a new https endpoint. But I think the more interesting problem, which this totally ignores, is how to plug in to account creation. If I'm a normal user, and a page presents me with a sign up form, I want to autofill the choose / confirm password fields; if I don't I'm probably going to choose a weak password - or worse, one I'll forget entirely. I suppose you could say "just tell your password manager about the account later and let it choose a better password" but the proposed protocol doesn't work at all if your password manager doesn't know about the account (or doesn't know the password). Whereas if you can plug into the creation flow - possibly via some html / js api - the password manager can be like "hey I see a account creation form that wants you to create a new password, want me to do that for you"? And boom, you are always generating strong passwords. And ideally we'd have a similar standard for login pages so password managers could slurp up your existing logins as you use them. 1Password does decently at this, but every once in awhile I encounter a bank or some other service that decides to ask verification questions or have a two-page login flow, that 1Password just can't deal with.