Web Authentication - Enable Cross-Origin iframes via Feature-Policy
Categories
(Core :: DOM: Web Authentication, enhancement, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox118 | --- | fixed |
People
(Reporter: jcj, Assigned: janne+mozilla)
References
(Blocks 2 open bugs)
Details
(Keywords: dev-doc-complete, Whiteboard: [webauthn])
Attachments
(3 files, 1 obsolete file)
The WebAuthn WG has all but decided that use of WebAuthn in cross-origin iframes will be permitted only if the top level webpage permits it via feature-policy. The exact mechanism for use of WebAuthn via feature-policy is not yet specified. This bug is to implement that, when specified, to permit specifically-authorized cross-origin iframes to use WebAuthn features.
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Comment 1•5 years ago
|
||
Just wondering if there has been any progress on the above... the iframe issue has come up in the context of payments:
https://lists.w3.org/Archives/Public/public-payments-wg/2019Mar/0024.html
Reporter | ||
Comment 2•5 years ago
|
||
Upstream issue is here: https://github.com/w3c/webauthn/issues/911
The WG is seeking expert guidance from WebAppSec on whether to use W3C Permissions [0] or W3C Feature Policy [1]. Feedback is desirable.
[0] https://www.w3.org/TR/permissions/
[1] https://w3c.github.io/webappsec-feature-policy/
Comment 3•5 years ago
|
||
thanks! subscribed to the GitHub bug. Will try to contribute some thoughts.
Comment 4•4 years ago
|
||
This change changes the IsSameOriginWithAncestors check into a check
that instead checks the Feature Policy for webauthn. This value is set
by default to self, which matches the existing same-origin check
behavior.
Cross-origin iframes can now use the Web Authentication API when the
allow="webauthn" attribute is set on the iframe.
Comment 5•3 years ago
|
||
Note that enough of Feature Permissions Policy has shipped to be able to make progress here, I think.
Comment 6•3 years ago
|
||
I just encountered this issue while trying to implement WebAuthn support for the Firefox extension Bitwarden (password manager). We currently supports U2F for 2FA, which is implemented using an iframe to a https website. Unfortunately while porting our implementation to WebAuthn I ran into this bug/feature request.
Chromium recently added support for the feature policy publickey-credentials-get [0], which seems to be the new name for the webauthn feature policy. And since this is currently blocking our migration to WebAuthn I wanted to check if anyone knows if this is being worked on or if there are any workarounds.
If not, are :mutantmonkey suggested patch a potential solution, once the review comments have been resolved?
[0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy/publickey-credentials-get
Reporter | ||
Comment 7•3 years ago
|
||
I think that patch just needs to update the name and add tests or update the name and wait on my WebDriver work [0] to enable the new-form WebAuthn Web Platform Tests, which might be a few more weeks.
[0] https://github.com/mozilla/authenticator-rs/pull/127 landed, but I need to still 1) wire it up to Firefox, and 2) implement minimally the U2F test token, which I hope to get back to later this week
Comment 8•3 years ago
|
||
I've attached an updated version of :mutantmonkey patch, which has been updated to the latest Working Draft.
The main difference is that the policy has been renamed to publickey-credentials-get, it only applies on getting credentials not creating, lastly clang issues should now be resolved.
Unfortunately I haven't had any success in creating tests since the existing tests seems to fail on my machine which made it difficult figuring out how to write the proper tests. With that said, let me know if there is anything else that needs to be done.
Reporter | ||
Comment 9•3 years ago
|
||
Thanks hinton! I'm setting myself a needinfo to look at this as soon as practical, though at this point probably around the first of November -- I'm busy wiring up the WebDriver infra now that Bug 1666701 landed.
Comment 10•3 years ago
|
||
Just wanted to check in now that everything to my knowledge has been wired up. What would the next step be J.C? And is there anything I can assist with to help things move along?
Comment 11•3 years ago
|
||
Going forward, this is going to need some Fission tests to show that this works with OOP iframes, if feature policy is supposed to be able to permit that.
Updated•2 years ago
|
Comment 12•2 years ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:rmf, since the bug has recent activity, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•1 year ago
|
Updated•1 year ago
|
Updated•9 months ago
|
Comment 14•8 months ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Assignee | ||
Comment 15•8 months ago
|
||
This implements publickey-credentials-get in Permissions-Policy. This allows for cross-origin
credentials.get() which is currently only possible in Chrome. This is similar to D42445 but
uses the correct name from https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy#directives
Credential creation is not touched since there is no specification for it yet:
https://github.com/w3c/webauthn/issues/1656
Updated•8 months ago
|
Updated•8 months ago
|
Comment 18•4 months ago
|
||
Depends on D174108
Updated•4 months ago
|
Comment 19•4 months ago
|
||
Pushed by jschanck@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/13963add1a62 Implement publickey-credentials-get in pp. r=jschanck,dveditz https://hg.mozilla.org/integration/autoland/rev/b4d4ce532484 tests for publickey-credentials-get feature policy. r=keeler
Comment 20•4 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/13963add1a62
https://hg.mozilla.org/mozilla-central/rev/b4d4ce532484
Comment 21•3 months ago
|
||
FF118 MDN docs for this can be tracked in https://github.com/mdn/content/issues/28848#issuecomment-1720615209
Can you confirm this implements Permissions-Policy: publickey-credentials-get
(as Feature-Policy: publickey-credentials-get
) but not Permissions-Policy: publickey-credentials-create
?
In the browser compatibility data most firefox entries have the following comment. Is this true also for publickey-credentials-get
? (I did not know it could be used in any other way).
"Only supported through the
allow
attribute on<iframe>
elements."
Comment 22•3 months ago
|
||
Yes, this is just Permissions-Policy: publickey-credentials-get
and it's only supported through allow
.
(I did not know it could be used in any other way)
You can also set these policies with HTTP headers. That's implemented, but it's only available under a pref.
Comment 23•3 months ago
|
||
Thanks John!
OK, so Feature-Policy
was enabled in FF74 then disabled by default in FF77 (https://bugzilla.mozilla.org/show_bug.cgi?id=1627890) by pref dom.security.featurePolicy.header.enabled
. The intent is never to enable this, but instead to enabled Permissions-Policy
header at some point in https://bugzilla.mozilla.org/show_bug.cgi?id=1694922.
The data compatibility for the Permissions-Policy was confusing in that it does say "Only supported through the allow attribute on <iframe>
elements." but is also applied to the header, which made me thing this might sent. I'll improve that. Thank you.
Description
•