Allow for credential creation in a cross-origin iframe #1801

stephenmcgruer · 2022-09-14T00:10:45Z

This PR adds the ability to call navigator.credentials.create() in a cross-origin
iframe (more exactly, a frame that is not same-origin with its ancestor chain),
as long as the following conditions are met:

The iframe has a publickey-credentials-create-feature permission policy
The iframe has a user activation

It has a corresponding PR on the credential management spec; see
w3c/webappsec-credential-management#209

Preview | Diff

stephenmcgruer · 2022-09-14T00:57:38Z

cc @ve7jtb , who I believe wished to make sure that this was compatible with the previous L2 discussion on what create() in a cross-origin iframe would look like (particularly the permission policy name, I believe).

stephenmcgruer · 2022-09-28T17:20:09Z

This pull request was discussed at the Sept 21st, 2022 WebAuthn WG meeting. During that meeting, we heard the following concerns from Apple (and please @pascoej , correct me if I am misrepresenting your comments!)

If a user registers a passkey in a payment flow, and later sees it in the password manager, they may be confused.
If a user registers a passkey in a payment flow, but then later the bank asks them to use that passkey to sign-in with, they may be confused.
If an iframe can trigger passkey creation, the user will not know what site it is for.
This enables the tracking concern as described here.

I'd like to start by repeating (as we said in the meeting) that these concerns are not invalid and we appreciate where you are coming from.

For 1 and 2; it is already the case today that a Relying Party could register a passkey for a purpose other than sign-in, and utilize it as so. Taking payment as an example; when visiting bank.com I could be asked to 'enroll a passkey to validate future payments when making online purchases'. Even though I was told by the Relying Party that it was for future payments only, that passkey would still show up in the password manager, and the bank could use it to do sign-in. This PR does not change that status quo.

(There is also a deeper purpose discussion here; should WebAuthn be confined to sign-in and attempt - as much as it can[0] - to force Relying Parties down that road. Or, should WebAuthn take the view that passkeys are a verification method only, and what they are verifying is out of scope.)

For 3, it is already possible today to produce a flow with pop-ups that is very close to what this PR enables. An iframe can, with user activation: open a pop-up window, immediately trigger credential.create() in that pop-up, and then close the pop-up instantly after completion. On desktop the pop-up can be made to be almost completely hidden, and on mobile the 'greying' of the screen for the passkey UX obscures the new origin in the URL bar. This demo site should demonstrate this—it has been tested on Chrome 105 and Safari 16.0 on MacOS, Chrome 105 on Android, and Safari on iOS 16.0. Given the existing situation and the ability of the browser to display additional UX for the iframe case if it wishes (see below), we do not think this PR significantly changes the status quo.

Finally, for 4, as per the issue comment we acknowledge the slight increase in risk here, but believe that a combination of:

Requiring a permission policy,
Requiring a user activation, and
The friction of a WebAuthn operation (tracking is usually near silent - WebAuthn is not!)

provides adequate defence. A browser could also, if it wished, add additional or clearer UX to warn the user that the create is occurring in an iframe.

[0] I think the only real mechanism for this is the client/authenticator UI, incidentally. I don't believe there is a feasible way at the API level to constrain to sign-in.

stephenmcgruer · 2022-11-02T18:35:40Z

Hi folks; I had hoped to bring this PR up on today's call, but since it is cancelled pinging here instead. We are still waiting on a response here from Apple, and I would love to have that for next WebAuthn WG meeting if possible (2022/11/16). If there is no answer by the 16th (or during the call), I will be interested to know how the WebAuthn WG wants to proceed at that time (i.e., what the method is to resolve this PR one way or another).

agl

I might even skip the TODO. I'm not sure that we'll be in a better place to resolve it in the future and it's clear that implementations have managed to figure out user activation in these contexts already.

stephenmcgruer · 2022-12-05T17:12:24Z

I might even skip the TODO. I'm not sure that we'll be in a better place to resolve it in the future and it's clear that implementations have managed to figure out user activation in these contexts already.

Ack - done, removed the TODO in eb32a68

rlin1 · 2022-12-05T18:32:37Z

Lgtm

stephenmcgruer · 2023-01-09T13:51:25Z

Post-vacations ping to @akshayku @timcappalli @ve7jtb - could you review this before this week's WebAuthn sync? (I.e. before the 11th). I'd like to get this merged.

timcappalli · 2023-01-09T19:17:27Z

Post-vacations ping to @akshayku @timcappalli @ve7jtb - could you review this before this week's WebAuthn sync? (I.e. before the 11th). I'd like to get this merged.

@stephenmcgruer, we may need one more WG meeting cycle due to holidays and vacations. Sorry for the delay.

ve7jtb

It looks good but I think the containing page info should probably be added to client data.

stephenmcgruer · 2023-01-12T16:09:34Z

(This PR was discussed in the Jan 11 WebAuthn WG meeting. Overall it seems good, but @timcappalli intends to add a comment to request two changes to the PR - one in line with @ve7jtb's suggestion and one additional UX 'should' advisory.)

…-origin

stephenmcgruer · 2023-01-18T19:28:54Z

@timcappalli @ve7jtb - I've gone ahead and pushed two commits to this PR that add a note on the client making it clear to the user if the credential creation is in a cross-origin iframe, and also added a topOrigin member to convey some sense of the containing page info (though one could have a chain of different origins of course, and this wouldn't be represented).

Hope this is somewhat along the lines of what you were each thinking - but if not no worries, happy to revise to whatever feedback you have :)

index.bs

stephenmcgruer

Thanks for the review!

index.bs

emlun

Thanks @stephenmcgruer!

nsatragno · 2023-03-01T16:05:51Z

(Merging as this is all green & blocking w3c/webappsec-credential-management#209 and some other work, feel free to open an issue for outstanding issues)

SHA: 3ff766e Reason: push, by nsatragno Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

index.bs

add mention and link to an informative Note a note and link w3c/webauthn#1801

…n registration #243 Add to an informative Note that WebAuthn Levels 1 and 2 do not support cross-origin registration, but level 3 is expected to, and link to pull request: w3c/webauthn#1801

As of w3c/webauthn#1801, the WebAuthn spec allows for credential creation in a cross-origin iframe, as long as the "publickey-credentials-create" permission policy is set AND there is a user activation for the call. Previously, Chrome supported this but only for 'payment' WebAuthn credentials*, which also used a different permission policy ("payment"). This CL updates Chrome to support calling credentials.create() for a publickey in a cross-origin iframe, as long as the above conditions are met. The behavior is behind a runtime-enabled flag, WebAuthnAllowCreateInCrossOriginFrame, which is currently set to "experimental". It will be set to stable once we have an approved I2S for this feature. This CL does NOT update the behavior for "payment" extension credentials, which still require the "payment" permission policy for now. crbug.com/1512605 and crbug.com/1512245 track the required changes there. * That is, credential creation calls in which the payment extension is specified. Bug: 1420639 Change-Id: Ic016f074cf0983206a4b2d5fc91e9675756cd159 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5013987 Reviewed-by: Rick Byers <rbyers@chromium.org> Commit-Queue: Stephen McGruer <smcgruer@chromium.org> Cr-Commit-Position: refs/heads/main@{#1238797}

prnk28 · 2023-12-18T23:13:51Z

LFG 🚀

See w3c/webauthn#1801

…eate(), a=testonly Automatic update from web-platform-tests [WebAuthn] Add tests for cross-origin create() (#43729) See w3c/webauthn#1801 -- wpt-commits: d46f1aec78700b30ec633165cd51af2fd90bf3b6 wpt-pr: 43729

…eate(), a=testonly Automatic update from web-platform-tests [WebAuthn] Add tests for cross-origin create() (#43729) See w3c/webauthn#1801 -- wpt-commits: d46f1aec78700b30ec633165cd51af2fd90bf3b6 wpt-pr: 43729 UltraBlame original commit: 7533e06bd4f5950829eb0eb456a416b37d06e7bf

…eate(), a=testonly Automatic update from web-platform-tests [WebAuthn] Add tests for cross-origin create() (#43729) See w3c/webauthn#1801 -- wpt-commits: d46f1aec78700b30ec633165cd51af2fd90bf3b6 wpt-pr: 43729

See w3c/webauthn#1801

This was referenced Sep 14, 2022

Add support for publickey-credentials-create permission policy w3c/webappsec-credential-management#209

Merged

Allow for credential creation in a cross-origin iframe stephenmcgruer/webauthn#1

Closed

stephenmcgruer marked this pull request as ready for review September 14, 2022 00:55

nadalin assigned stephenmcgruer Nov 16, 2022

nadalin requested review from akshayku and agl November 16, 2022 20:16

nadalin added this to the L3-WD-01 milestone Nov 16, 2022

nadalin requested review from daniel-montalvo and dveditz and removed request for daniel-montalvo November 16, 2022 20:23

nadalin requested a review from ve7jtb November 30, 2022 20:16

agl approved these changes Nov 30, 2022

View reviewed changes

timcappalli self-requested a review December 14, 2022 20:06

ve7jtb reviewed Jan 11, 2023

View reviewed changes

Allow for credential creation in a cross-origin iframe

1bdab8c

stephenmcgruer force-pushed the smcgruer/publickey-credentials-create branch from eb32a68 to 1bdab8c Compare January 18, 2023 17:46

stephenmcgruer added 2 commits January 18, 2023 14:26

Add note that clients SHOULD make it clear to the user when its cross…

f746fd2

…-origin

Add topOrigin member to client data

daefc0a

timcappalli reviewed Jan 23, 2023

View reviewed changes

index.bs Outdated Show resolved Hide resolved

timcappalli mentioned this pull request Jan 25, 2023

Add topOrigin to clientData for cross-origin GET in iframe #1842

Closed

Make topOrigin an optional member

0ba37d5

stephenmcgruer commented Feb 27, 2023

View reviewed changes

index.bs Show resolved Hide resolved

index.bs Show resolved Hide resolved

index.bs Outdated Show resolved Hide resolved

index.bs Show resolved Hide resolved

stephenmcgruer requested a review from emlun February 27, 2023 12:51

emlun approved these changes Feb 27, 2023

View reviewed changes

nsatragno merged commit 3ff766e into w3c:main Mar 1, 2023

github-actions bot added a commit that referenced this pull request Mar 1, 2023

Allow for credential creation in a cross-origin iframe (#1801)

580eb53

SHA: 3ff766e Reason: push, by nsatragno Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

ndpar reviewed Mar 8, 2023

View reviewed changes

index.bs Show resolved Hide resolved

emlun mentioned this pull request Mar 8, 2023

Update step references in RP operations #1861

Closed

timcappalli mentioned this pull request Apr 21, 2023

add topOrigin verification logic for get #1879

Merged

ianbjacobs added a commit to w3c/secure-payment-confirmation that referenced this pull request May 10, 2023

Because WebAuthn Level 3 is expected to allow cross-origin registration,

058f277

add mention and link to an informative Note a note and link w3c/webauthn#1801

ianbjacobs mentioned this pull request May 10, 2023

Editorial: Mention WebAuthn Level 3 is expected to support cross-orgin registration w3c/secure-payment-confirmation#243

Merged

stephenmcgruer deleted the smcgruer/publickey-credentials-create branch May 10, 2023 22:00

stephenmcgruer added a commit to web-platform-tests/wpt that referenced this pull request Dec 19, 2023

[WebAuthn] Add tests for cross-origin create()

f7cded0

See w3c/webauthn#1801

stephenmcgruer mentioned this pull request Dec 19, 2023

[WebAuthn] Add tests for cross-origin create() web-platform-tests/wpt#43729

Merged

stephenmcgruer added a commit to web-platform-tests/wpt that referenced this pull request Dec 20, 2023

[WebAuthn] Add tests for cross-origin create()

3763cc2

See w3c/webauthn#1801

This was referenced Jan 17, 2024

WebAuthn: Allow for credential creation in a cross-origin iframe WebKit/standards-positions#304

Open

WebAuthn: Allow for credential creation in a cross-origin iframe mozilla/standards-positions#964

Closed

stephenmcgruer added a commit to web-platform-tests/wpt that referenced this pull request Jan 18, 2024

[WebAuthn] Add tests for cross-origin create() (#43729)

d46f1ae

See w3c/webauthn#1801

stephenmcgruer mentioned this pull request Jan 26, 2024

Update SPC spec to reflect that credential create in cross-origin iframe is now allowed in WebAuthn w3c/secure-payment-confirmation#267

Open

hamishwillee mentioned this pull request Feb 6, 2024

FF123 updates for permission publickey-credentials-create mdn/content#32135

Merged

marcoscaceres pushed a commit to web-platform-tests/wpt that referenced this pull request Feb 23, 2024

[WebAuthn] Add tests for cross-origin create() (#43729)

b1e1ad9

See w3c/webauthn#1801

marcoscaceres mentioned this pull request Jul 4, 2024

Consider not running internal methods in parallel or add "consumes user activation" to registry? w3c/webappsec-credential-management#243

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow for credential creation in a cross-origin iframe #1801

Allow for credential creation in a cross-origin iframe #1801

stephenmcgruer commented Sep 14, 2022 •

edited by pr-preview bot

Loading

stephenmcgruer commented Sep 14, 2022

stephenmcgruer commented Sep 28, 2022 •

edited

Loading

stephenmcgruer commented Nov 2, 2022

agl left a comment

stephenmcgruer commented Dec 5, 2022

rlin1 commented Dec 5, 2022

stephenmcgruer commented Jan 9, 2023

timcappalli commented Jan 9, 2023

ve7jtb left a comment

stephenmcgruer commented Jan 12, 2023

stephenmcgruer commented Jan 18, 2023

stephenmcgruer left a comment

emlun left a comment

nsatragno commented Mar 1, 2023

prnk28 commented Dec 18, 2023

Allow for credential creation in a cross-origin iframe #1801

Allow for credential creation in a cross-origin iframe #1801

Conversation

stephenmcgruer commented Sep 14, 2022 • edited by pr-preview bot Loading

stephenmcgruer commented Sep 14, 2022

stephenmcgruer commented Sep 28, 2022 • edited Loading

stephenmcgruer commented Nov 2, 2022

agl left a comment

Choose a reason for hiding this comment

stephenmcgruer commented Dec 5, 2022

rlin1 commented Dec 5, 2022

stephenmcgruer commented Jan 9, 2023

timcappalli commented Jan 9, 2023

ve7jtb left a comment

Choose a reason for hiding this comment

stephenmcgruer commented Jan 12, 2023

stephenmcgruer commented Jan 18, 2023

stephenmcgruer left a comment

Choose a reason for hiding this comment

emlun left a comment

Choose a reason for hiding this comment

nsatragno commented Mar 1, 2023

prnk28 commented Dec 18, 2023

stephenmcgruer commented Sep 14, 2022 •

edited by pr-preview bot

Loading

stephenmcgruer commented Sep 28, 2022 •

edited

Loading