Web Authentication - Enable Cross-Origin iframes via Feature-Policy for credential creation
Categories
(Core :: DOM: Web Authentication, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox123 | --- | fixed |
People
(Reporter: janne+mozilla, Assigned: janne+mozilla)
Details
(Keywords: dev-doc-complete)
Attachments
(1 file)
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().
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 3•1 year ago
|
||
| bugherder | ||
Comment 4•1 year ago
|
||
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
allowand not as the Feature-Policy/Permissions-Policy header? - Should compatibility data be similar to
publickey-credentials-getand say something like "Only supported through the allow attribute on<iframe>elements."?
Comment 5•1 year ago
|
||
Is there anyone else who can help answer ^^^? :jschanck I've added you to needinfo on assumption perhaps Janne is out of office.
Comment 6•1 year ago
|
||
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.
Comment 7•1 year ago
•
|
||
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 aNotAllowedError. 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. Isget()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.
Comment 8•1 year ago
|
||
Thanks, Hamish.
NotAllowedErroris correct.- The WebAuthn spec clearly requires / consumes transient activation in
create(), but I believe it is not required inget(). 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 increate()(Bug 1877332). - There is also a policy control for cross-origin
get(), which is implemented in Firefox (Bug 1460986).
Comment 9•1 year ago
|
||
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.
Comment 10•1 year ago
|
||
Thank you. Docs updated I have set this as dev-doc-complete, though docs/compatibility is still waiting review.
Description
•