LGTM3
On 1/24/24 11:24 AM, Yoav Weiss (@Shopify) wrote:
LGTM2
On Tuesday, January 23, 2024 at 4:40:55 PM UTC+1 Rick Byers wrote:
It would be great to get an official response from WebKit and
Mozilla to make sure we understand their position, but I don't
think we should block further on it. I understand why they might
have concerns given their engine's preference for embeds being
anonymous. In Chromium we've been consistent in working to
preserve personalized / authenticated embeds (and so the rich
composition of web pages) where we can ensure it doesn't conflict
with our privacy goals around clear user transparency and control
over sharing of information (fenced frames
<https://developers.google.com/privacy-sandbox/relevance/fenced-frame>
being the most obvious example). We know that avoiding popups and
redirects helps reduce drop-off in any authentication or commerce
flow, and combined with Stripe's public statement of support, I'm
convinced this is a valuable capability.
Everything else looks great to me, so LGTM1
On Tue, Jan 23, 2024 at 10:23 AM Stephen McGruer
<smcgr...@chromium.org> wrote:
Fyi; I've retargeted this launch to M123 since it seems clear
it won't get the necessary Blink approvals in time for M122
(which has already branched).
On Wednesday, January 17, 2024 at 11:07:56 AM UTC-5 Stephen
McGruer wrote:
Sounds great:
https://github.com/WebKit/standards-positions/issues/304
<https://github.com/WebKit/standards-positions/issues/304>
https://github.com/mozilla/standards-positions/issues/964
<https://github.com/mozilla/standards-positions/issues/964>
Will update if we get any reply :)
On Wed, 17 Jan 2024 at 10:25, Mike Taylor
<miketa...@chromium.org> wrote:
I think erring on the side of requesting a signal here
is a good idea. :)
On 1/17/24 8:33 AM, Stephen Mcgruer wrote:
API owners: It wasn't clear to me if I should still
be formally requesting signals from WebKit and Gecko
in the case of a change to an API (WebAuthn) where
the change has been ratified + landed by the
associated Working Group. The change is in some ways
'minor', but in other ways it is significant new
behavior (allowing use of part of the API in
cross-origin iframes, where it wasn't allowed before)
and so perhaps requesting signals is warranted? Let
me know please :D
On Wed, 17 Jan 2024 at 08:31, Stephen Mcgruer
<smcgr...@chromium.org> wrote:
Contact emails
smcgr...@chromium.org
Explainer
None
Specification
https://w3c.github.io/webauthn/#publickey-credentials-create-feature
<https://w3c.github.io/webauthn/#publickey-credentials-create-feature>
Summary
This feature allows web developers to create
WebAuthn[0] credentials (that is, "publickey"
credentials, aka passkeys) in cross-origin
iframes. Two conditions are required for this new
ability: 1. The iframe has a
publickey-credentials-create-feature permission
policy. 2. The iframe has transient user
activation. This will allow developers to create
passkeys in embedded scenarios, such as after an
identity step-up flow where the Relying Party is
providing a federated identity experience. [0]:
https://w3c.github.io/webauthn/
<https://w3c.github.io/webauthn/>
Blink component
Blink>WebAuthentication
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebAuthentication>
TAG review
None
TAG review status
Not applicable
Risks
Interoperability and Compatibility
There is only minor interoperability risk if
other browsers do not adopt this change. In a
browser that does not support credential creation
inside a cross-origin iframe, attempting to call
navigator.credentials.create results in an
asynchronous-but-immediate error message
indicating that creation cannot happen. This
means that a developer can create a fallback flow
of: 1. Have some button for the user, e.g.
"register passkey", in the iframe 2. When the
user clicks it, attempt to create a credential 3.
If it fails due to an incompatible browser,
instead use the click to open a pop-up window in
which one *can* do the registration - a much
poorer user flow but one that works.
/Gecko/: No signal
/WebKit/: No signal No formal signal, but note
that folks from Apple were against the proposal
when discussed in the WebAuthn WG
/Web developers/: Positive developer feedback on
https://github.com/w3c/webauthn/issues/1656
<https://github.com/w3c/webauthn/issues/1656> (one
example -
https://github.com/w3c/webauthn/issues/1656#issuecomment-890819845
<https://github.com/w3c/webauthn/issues/1656#issuecomment-890819845>).
No known negative developer feedback
/Other signals/:
Security
To avoid malicious iframes from creating
credentials (attempting to trick the user in some
way), this feature requires both (a) a new
permission policy set on the frame, and (b) a
user gesture (so the user must click or interact
with the iframe in some way).
WebView application risks
Does this intent deprecate or change behavior of
existing APIs, such that it has potentially high
risk for Android WebView-based applications?
None
Debuggability
Existing devtools support suffices for this feature
Will this feature be supported on all six
Blink platforms (Windows, Mac, Linux,
ChromeOS, Android, and Android WebView)?
Yes
Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yes
In review:
https://github.com/web-platform-tests/wpt/pull/43729
<https://github.com/web-platform-tests/wpt/pull/43729>
(Chrome Dev passes 5/5 added tests)
Flag name on chrome://flags
None
Finch feature name
WebAuthAllowCreateInCrossOriginFrame
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1420639
<https://bugs.chromium.org/p/chromium/issues/detail?id=1420639>
Estimated milestones
Shipping on desktop 122
DevTrial on desktop 122
Shipping on Android 122
DevTrial on Android 122
Anticipated spec changes
Already landed in the spec, no remaining changes
expected.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5175677674586112
<https://chromestatus.com/feature/5175677674586112>
Links to previous Intent discussions
Intent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Maf7EmNUH1zYSi7DimKd5NfddYY3navNx3-ELPyeqHpPMw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Maf7EmNUH1zYSi7DimKd5NfddYY3navNx3-ELPyeqHpPMw%40mail.gmail.com>
This intent message was generated by Chrome
Platform Status <https://chromestatus.com/>.
--
You received this message because you are subscribed
to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving
emails from it, send an email to
blink-dev+unsubscr...@chromium.org
<mailto:blink-dev+unsubscr...@chromium.org>.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MaeX7OPn44HzmaTraBj%3DYEaosz4Y-aYdDr4Y%2BT7mkm9A0Q%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MaeX7OPn44HzmaTraBj%3DYEaosz4Y-aYdDr4Y%2BT7mkm9A0Q%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the
Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to blink-dev+unsubscr...@chromium.org
<mailto:blink-dev+unsubscr...@chromium.org>.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b090cb3c-ac2a-4080-a583-6d77f60e5d79n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b090cb3c-ac2a-4080-a583-6d77f60e5d79n%40chromium.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/af8dff23-6c95-4dae-9a57-24a5cca69f10%40chromium.org.