Steps to reproduce:

Tried to use the publickey-credentials-create Permissions-Policy to create a new credential in an iframe.

Actual results:

Was not allowed because the policy is ignored.

Expected results:

Should have worked.
This is pretty much the same as 1460986 but for credential creation instead of authentication.

MDN: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/publickey-credentials-create
This is from the WebAuthn Level 3 standard and extends D174108 and D186245 with cross-origin credentials.create().

https://hg.mozilla.org/mozilla-central/rev/a3fbd525f3f0

MDN docs for this can be tracked in https://github.com/mdn/content/issues/31890

I'm a little confused by this. The bug name is "Enable Cross-Origin iframes via Feature-Policy for credential creation" which implies that you could do something like this to allow WebAuthn credentials to be created in iframes with sources from the indicated subdomains:

<iframe
  src="https://example.com"
  allow="publickey-credentials-create 'self' https://a.example.com https://b.example.com">
</iframe>

However the docs here state:

In addition, get() can be used in nested browsing contexts loaded from the same origin as the top-most document;
create() on the other hand cannot be used in <iframe>s.

So

• How does this work?
• Is the note above about create() incorrect?
• Is it still the case that FF only allows feature-policy in iframe allow and not as the Feature-Policy/Permissions-Policy header?
• Should compatibility data be similar to publickey-credentials-get and say something like "Only supported through the allow attribute on <iframe> elements."?

Is there anyone else who can help answer ^^^? :jschanck I've added you to needinfo on assumption perhaps Janne is out of office.

The note about create() is incorrect. The option to allow create() through the publickey-credentials-create policy-control feature was added to the WebAuthn spec in https://github.com/w3c/webauthn/pull/1801 and to the Credential Management spec in https://github.com/w3c/webappsec-credential-management/pull/209.

By default, Firefox still only sets the policy through allow=... on the iframe, not through the header, and the compatibility data should reflect this.

Thanks @John. I've updated the compatibility data appropriately.

The docs are updated with minor changes:

• Docs said that a permission fail was a SecurityError, but it looks from spec like it is a NotAllowedError. Right?
• Further, it looks like transient activation is required on the frame if that permission is allowed by a frame at point you get or create the credential.
  • Correct? And does FF require this too.
• Fixed line about not being able to call create() in a frame. Is get() also cross origin now or is it still single origin?

The docs update is here - if you have time for a sanity check that would be much appreciated.

Thanks, Hamish.

• NotAllowedError is correct.
• The WebAuthn spec clearly requires / consumes transient activation in create(), but I believe it is not required in get(). I think there are difficulties in enforcing this when requests are conditionally mediated. I'll ask in the working group meeting tomorrow. Firefox consumes transient activation in create() (Bug 1877332).
• There is also a policy control for cross-origin get(), which is implemented in Firefox (Bug 1460986).

Transient activation is required for cross-origin create() but is not generally required, as that would have broken some existing implementations. There's more context in https://github.com/w3c/webauthn/issues/1293.

Thank you. Docs updated I have set this as dev-doc-complete, though docs/compatibility is still waiting review.