Thanks Yoav! We have been working with Alex and Igalia on this experiment,
but appreciate the tag anyway (cc @Rouslan Solomakhin
too)
On Tue, 6 Feb 2024 at 04:47, Yoav Weiss (@Shopify)
wrote:
> +Stephen McGruer - FYI
>
> On Fri, Feb 2, 2024 at 5:19 PM Alexander Surkov
> 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-
dea. :)
> 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.
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 wrote:
> Contact emailssmcgr...@chromium.org
>
> Expl
Contact emailssmcgr...@chromium.org
ExplainerNone
Specification
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
Google Chrome
> <https://www.google.com/chrome>
>
>
> On Wed, Nov 8, 2023 at 12:48 PM Stephen Mcgruer
> wrote:
>
>> Contact emailssmcgr...@chromium.org
>>
>> ExplainerNone
>>
>> Specification
>> https://w3c.github.io/webauthn/#publickey-credentia
Contact emailssmcgr...@chromium.org
ExplainerNone
Specification
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
Thanks Mike! We were following through on the I2S process because we did an
I2E for this feature as a way to let folks verify that the UX change
wouldn't cause regressions.
I still think that is correct as follow-through, but we could probably have
made it clearer than we hope this I2S will be a
Thanks Mustaq for your input (and API OWNERS for the ongoing LGTMs, here's
hoping for #3 :)). I agree with your points on the difficulty of making
either user activation or capability delegation work across navigation
(though I still personally think there are reasonable use-cases! :D). We're
:
> Thanks Stephen! :)
>
> On Mon, Jun 19, 2023 at 3:13 PM Stephen Mcgruer
> wrote:
>
>> Hi Yoav, thanks for the questions!
>>
>> > The PR seems to be a draft. What's preventing us from landing it? Was
>> this discussed in some public forum?
>>
>> We int
Hi Yoav, thanks for the questions!
> The PR seems to be a draft. What's preventing us from landing it? Was
this discussed in some public forum?
We intend to land the PR before shipping this feature. It has been
discussed broadly in the Web Payments WG, but I expect to raise the
specific PR for
nstead
On Thu, 5 Jan 2023 at 11:05, Stephen Mcgruer wrote:
> Contact emailssmcgr...@chromium.org
>
> ExplainerNone
>
> Specification
> https://w3c.github.io/secure-payment-confirmation/#sctn-collectedclientadditionalpaymentdata-dictionary
>
> Summary
>
> Secure Paymen
Contact emailssmcgr...@chromium.org
ExplainerNone
Specification
https://w3c.github.io/secure-payment-confirmation/#sctn-collectedclientadditionalpaymentdata-dictionary
Summary
Secure Payment Confirmation (SPC) is a Web API to support streamlined
authentication during a payment transaction. It
st changes.
On Mon, 14 Nov 2022 at 11:27, Chris Harrelson wrote:
> Reusing this thread is fine, but please update the chromestatus entry
> <https://chromestatus.com/feature/5190978431352832> to indicate the
> "shipping" stage.
>
>
> On Mon, Nov 14, 2022 at 8:02
Hi folks,
*TL;DR - we are requesting LGTM x3 to Remove this API in M111. Please let
us know if we need to send a new Intent thread for that.*
As we look at M111 coming up, we realized we made a communication error
here which we would like to correct. The original post said:
> *Estimated
If we are going to treat this like a deprecation instead (which is what a
report only mode sounds to me?), then it makes more sense to me to skip an
OT entirely. That is:
- M108 - begin deprecation period, developers get warnings
- M111 (for example) - enable behavior, start reverse origin trial
(remove in M108, to be clear - just restating from the Chromestatus entry
as Yoav asked about the timeline)
On Wed, Sept 21, 2022, 9:00 a.m. Rouslan Solomakhin
wrote:
> Due to the low uptake (< 0.00010 % page loads), we were planning to remove
> PaymentInstruments API without deprecation
Hi Blink OWNERS,
We are requesting permission to *extend this Origin Trial until M109
(inclusive) instead of M106*. We have a partner that is excited to try this
feature out, but has told us that the M104-M106 timeline is too tight.
Given the guidance
Contact emailssmcgr...@chromium.org
ExplainerNone
Specificationhttps://w3c.github.io/secure-payment-confirmation
Design docshttps://github.com/w3c/secure-payment-confirmation/issues/172
Summary
Adds an 'opt-out' flow to Secure Payment Confirmation. When the (optional)
input flag is set, the
if you or someone else are willing to split out the PR into two
> pieces, we can land the navigator.userActivation piece quickly.
>
>
>>
>>
>>> Chris
>>>
>>>
>>>> On Mon, Feb 14, 2022 at 9:51 AM Mike Taylor
>>>> wrote:
>>
challenges that might apply to
> the broader ecosystem?
>
> On 2/14/22 9:22 AM, Stephen McGruer wrote:
>
> Hey all,
>
> Unfortunately we've hit a snag in our deprecation; a partner has been
> having trouble integrating this change into their system, and though we are
> en
*, to give us more time to help solve their problem before we require
user activation. (I'm not sure how many LGTMs delaying a deprecation
requires?)
Thanks,
Stephen
On Tuesday, January 4, 2022 at 10:29:01 AM UTC-5 Stephen McGruer wrote:
> Hey folks,
>
> Following up here - we have d
> Am I correct that currently Chromium allows the Payment Request API to be
used unconditionally in iframes? Do you then intend to send another intent
to change the behavior to require activation, after a suitable period and
working with sites to migrate?
Correct. This is Intent to Deprecate and
ront.
>>
>> On Wed, Dec 1, 2021 at 6:31 PM Stephen Mcgruer
>> wrote:
>>
>>> To be clear; I think we have a good enough shot of that remaining site
>>> fixing their code 'soon' (I expect O(weeks)) that we both:
>>>
>>> 1. Shouldn't do
dit
card flow or I think PayPal IIRC).
On Wed, 1 Dec 2021 at 11:05, Yoav Weiss wrote:
>
>
> On Wed, Dec 1, 2021 at 4:43 PM Stephen Mcgruer
> wrote:
>
>> Contact emailssmcgr...@chromium.org
>>
>> Specificationhttps://www.w3.org/TR/payment-request/#show
Contact emailssmcgr...@chromium.org
Specificationhttps://www.w3.org/TR/payment-request/#show-method
Summary
Allowing PaymentRequest.show() to be triggered without a user activation
could be abused by malicious websites. To protect users, the spec was
changed to require user activation, and we
:03, Yoav Weiss wrote:
> Can you clarify what breakage may look like for sites that may rely on it?
>
> On Tuesday, September 7, 2021 at 2:34:46 PM UTC+2 Stephen McGruer wrote:
>
>> > Any usecounter stats you can share?
>>
>> Unfortunately no usecounters fo
2, 2021 at 9:19 PM Alex Russell
>> wrote:
>>
>>> LGTM1
>>>
>>> On Wednesday, September 1, 2021 at 5:49:12 PM UTC+1 Stephen McGruer
>>> wrote:
>>>
>>>> > and one which impacted
>>>> <https://twitter.com/yo
> Any usecounter stats you can share?
Unfortunately no usecounters for two reasons:
1) Payment APIs in general have very low usage when compared to 'page
loads', because the most popular sites on the web aren't merchants and so
don't use them. For example, PaymentRequest.show is at 0.001
Clarifying: this is actually an Intent to Deprecate *and Remove *basic-card,
not just deprecate it.
On Fri, 3 Sept 2021 at 10:25, Liquan (Max) Gu wrote:
> Contact emailsma...@chromium.org, payments-...@chromium.org
>
> Specificationhttps://www.w3.org/TR/payment-method-basic-card/
>
> Summary
>
ts space!
On Wed, 1 Sept 2021 at 10:26, Yoav Weiss wrote:
> Thanks for working on this! This seems like an important problem to solve.
> (and one which impacted
> <https://twitter.com/yoavweiss/status/1382050433632456711> me as a user)
>
> On Fri, Aug 27, 2021 at 4:04 PM
Writer, Chrome DevRel | jmed...@google.com |
> 816-678-7195
> *If an API's not documented it doesn't exist.*
>
>
> On Fri, Aug 27, 2021 at 7:05 AM Stephen Mcgruer
> wrote:
>
>> Contact emailsrous...@chromium.org, nbur...@chromium.org,
>> smcgr...@chromium.org, ma..
Contact emailsrous...@chromium.org, nbur...@chromium.org,
smcgr...@chromium.org, ma...@chromium.org
Explainerhttps://github.com/w3c/secure-payment-confirmation
Specificationhttps://w3c.github.io/secure-payment-confirmation/
Summary
Secure payment confirmation augments the payment
> One question that came up (and that should've been included in the
template): Will this be supported on all platforms?
FYI: This appears to be a problem with Chromestatus-generated I2Ss, I think
(as I noticed the same for SPC just now), so I
filed
34 matches
Mail list logo
