Credential Management Level 1

[annevk]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Credential Management Level 1
• Specification or proposal URL: https://w3c.github.io/webappsec-credential-management/
• Caniuse.com URL (optional):
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=1156047, https://bugzilla.mozilla.org/show_bug.cgi?id=1429196
• Mozillians who can provide input (optional): @jcjones @ckerschb @mnoorenberghe

We ended up implementing this partially due to Web Authentication (see #163) taking a dependency.

There are some important tradeoffs here between pushing on APIs or pushing more declarative solutions. #152 seems very much related.

[marcoscaceres]

This needs UI input for user selection/credential part, as that's where this API really provides user value. Further, this API becomes much more compelling if we have auto-generated passwords in the browser. There is definitely overlap with #152, specially if there is some kind of external identity/password provider and the federated credentials part of the API.

Longer term, we obviously want passwords to die... but I wonder if there is a world where Web Authn and federated credentials live happily together: I authenticate with GitHub using WebAuthn and then, on a different device, Credential Management API surfaces "You last signed in with Github on this site. Sign in GitHub again?".... that's quite helpful and doesn't involve any passwords.

[marcoscaceres]

Adding @mnoorenberghe for front-end/password generation opinions.

[jcjones]

When last I looked at this specification, the password portions seemed to lack a rationale for why applications would implement. However, the federated-side was very interesting, needed only the SSO providers to comply, and could dramatically improve usability of those sorts of sign-ons. However, the improvements would depend on browser UX, so it'd be a large investment.

The federated side of the spec also didn't seem to cover all common SSO systems, particularly enterprise ones, though I haven't analyzed the changes in the spec to see if that's improved.

My standing (dated) opinion is that the spec had good potential, needed design investment, and would require considerable investment to implement.

[annevk]

Tentatively "defer", unless prioritized by Product.

[marcoscaceres]

When last I looked at this specification, the password portions seemed to lack a rationale for why applications would implement.

My understanding is that it's for handling different profiles. But a clever password manager (again, looking at Safari/KeyChain integration), elegantly handles this, including biometric authentication:

the federated-side was very interesting, needed only the SSO providers to comply, and could dramatically improve usability of those sorts of sign-ons. However, the improvements would depend on browser UX, so it'd be a large investment.

For Federated credential management, I don't think this is the case: the investment is in the browser sync aspect, not the browser UI. In fact, I think it can be done with no browser UI at all - and I think that's also how Chrome does the Federated part: It's up to the Website to surface which login was last used for SSO, not the browser. The browser, via the API, just tells the website: "the user last logged in using [SSO Service]" and that's it.

However, for traditional passwords aspect of the API, yes... there is much investment needed on the UX side. Thought it just needs to handle selecting amongst different "accounts"... and showing an icon, so it's not the most complicated UI (say, compared to Web Payment for instance).

[jcjones]

Thanks for that, Marcos. The only point I'd like to reply to is when I was saying

"When last I looked at this specification, the password portions seemed to lack a rationale for why applications would implement."
I meant why a relying party would change their authentication flow to make calls through navigator.credentials.get() when we have so many problems with websites disabling, say, the paste functionality.

The Federated Credential has more obvious benefit to the SSO providers, as does WebAuthn. I worry that Password would be generally un-utilized.

[marcoscaceres]

I worry that Password would be generally un-utilized.

I agree. If at some point in the future we choose to move forward, we can ping our friends at Google to find out usage stats and if any big properties on the web are using Password. You never know :)