consider exposing credentials.get() but only when mediation is set to "silent"

[wanderview]

Please see this mailing list message:

https://lists.w3.org/Archives/Public/public-whatwg-archive/2017Nov/0009.html

Richard points out that credentials.get() allows a "silent" mediation value which, by design, does not require any browser UX to be shown to the user.

Should we allow this to be used from a service worker when there are no windows open? @mikewest, what do you think?

[mikewest]

https://lists.w3.org/Archives/Public/public-whatwg-archive/2017Nov/0009.html

For the use-case in question, I wonder whether a scheme like that proposed in https://developers.google.com/web/updates/2016/06/2-cookie-handoff would be more suitable? The basic idea is that the service worker would hold a long-lived token, which could be exchanged on a regular basis for a short-lived authentication cookie (similar conceptually to OAuth).

Richard points out that credentials.get() allows a "silent" mediation value which, by design, does not require any browser UX to be shown to the user.

This isn't entirely true. mediation: "silent" allows credentials to be distributed without user interaction, but we do want to inform users that credentials were requested and handed over. See item 3 in https://w3c.github.io/webappsec-credential-management/#user-mediation-requirement.

We avoided exposing navigator.credentials to workers of any sort because we didn't know how to do so while keeping the user in the loop. shrug I can imagine, though, that there are credential types for which the API could be useful. See related conversations in w3c/webappsec-credential-management#87 and w3c/webauthn#199. I'm not opposed to exposing the general framework to workers, but I think we'd need to think carefully about the risk of exposing either PasswordCredential, FederatedCredential, or PublicKeyCredential objects in those contexts.