Closed Bug 1460986 Opened 6 years ago Closed 4 months ago

Web Authentication - Enable Cross-Origin iframes via Feature-Policy


(Core :: DOM: Web Authentication, enhancement, P2)




118 Branch
Tracking Status
firefox118 --- fixed


(Reporter: jcj, Assigned: janne+mozilla)


(Blocks 2 open bugs)


(Keywords: dev-doc-complete, Whiteboard: [webauthn])


(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.
Component: DOM: Device Interfaces → DOM: Web Authentication

Just wondering if there has been any progress on the above... the iframe issue has come up in the context of payments:

Flags: needinfo?(jjones)

Upstream issue is here:

The WG is seeking expert guidance from WebAppSec on whether to use W3C Permissions [0] or W3C Feature Policy [1]. Feedback is desirable.


Flags: needinfo?(jjones)

thanks! subscribed to the GitHub bug. Will try to contribute some thoughts.

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

Cross-origin iframes can now use the Web Authentication API when the
allow="webauthn" attribute is set on the iframe.

Depends on: 1572461

Note that enough of Feature Permissions Policy has shipped to be able to make progress here, I think.

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?


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] 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

Attached patch patch.diffSplinter Review

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.

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.

Flags: needinfo?(jjones)

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?

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.

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.

Flags: needinfo?(jc) → needinfo?(bugs)
Flags: needinfo?(bugs)
Priority: P3 → P2
Severity: normal → S3
Duplicate of this bug: 1795022
Assignee: nobody → mozilla.bugzilla

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: mozilla.bugzilla → nobody

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
Credential creation is not touched since there is no specification for it yet:

Assignee: nobody → janne+mozilla
Duplicate of this bug: 1824742
Duplicate of this bug: 1841452
Attachment #9086312 - Attachment is obsolete: true
Pushed by
Implement publickey-credentials-get in pp. r=jschanck,dveditz
tests for publickey-credentials-get feature policy. r=keeler
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 118 Branch

FF118 MDN docs for this can be tracked in

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."

Flags: needinfo?(janne+mozilla)

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.

Flags: needinfo?(janne+mozilla)

Thanks John!

OK, so Feature-Policy was enabled in FF74 then disabled by default in FF77 ( by pref The intent is never to enable this, but instead to enabled Permissions-Policy header at some point in

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.

You need to log in before you can comment on or make changes to this bug.