Re: [blink-dev] Intent to Implement and Ship: Remove Payment Request User Activation Requirement

[Stephen Mcgruer]

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 discussion as well. (Though note that at the current point,
I believe Chrome is the only active browser vendor in that WG. Apple have
stated interest in rejoining it, but are waiting for an in-progress charter
change first.)

> I'm having a hard time imagining the use case for activation-less
payments. Is there a concrete example you can share?

Fair question, and I apologize - we should have motivated this more clearly
externally. The core use-cases are based around redirect payment flows,
which are fairly common in payments. Two coarse examples we have heard are:

1. A merchant-aggregator page showing products from many different
merchants. If a user decides to buy something with a given payment method,
the aggregator page redirects to the specific merchant. The merchant then
wants to trigger payment, without requiring the user to click again on
their chosen payment method.

2. A redirect-based payment flow, where the payment method wants to trigger
a natively installed experience (via Payment Handler) without the user
having to click again. (E.g., user is on merchant.example, chooses to pay
with FooPay. The merchant site redirects to foopay.example. FooPay then
wants to trigger its natively installed app on the phone, if available, but
doesn't want to require the user to click again.

We are cognizant that this may be a risky change, and have consulted
internal security folks on it in detail. From that, there are mitigations
laid out in the design doc, and we are also intending to monitor for
potential misuse.

> While I agree that a signal specifically for this seems like an overkill,
could you maybe comment with this on past position requests, to see if
Gecko or WebKit have an opinion on this issue?

Ack, we will follow up on this. Note that Gecko does not implement Payment
Request currently.

Thanks,
Stephen

On Wed, Jun 14, 2023, 3:28 a.m. Yoav Weiss  wrote:

>
>
> On Tue, Jun 13, 2023 at 8:54 PM Nick Burris  wrote:
>
>> Contact emailsnbur...@chromium.org, smcgr...@chromium.org,
>> i...@chromium.org
>>
>> Specificationhttps://github.com/w3c/payment-request/pull/1009
>>
>
> The PR seems to be a draft. What's preventing us from landing it?
> Was this discussed in some public forum?
>
>
>>
>>
>> Design docs
>> https://docs.google.com/document/d/16DHqqPWe5oM6Rucnn6Y1llhJ-DoEeLtTWFldJFg4iqA/edit#heading=h.w5782xqp7ab4
>>
>> Summary
>>
>> To help developers reduce friction in Payment Request flows, we are
>> removing the user activation requirement for PaymentRequest.show(). Spam
>> and clickjacking mitigations are put in place to mitigate security and
>> privacy risks with this change (see design doc
>> 
>> ).
>>
>
> I'm having a hard time imagining the use case for activation-less
> payments. Is there a concrete example you can share?
>
>
>>
>>
>> Blink componentBlink>Payments
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility*Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>
> While I agree that a signal specifically for this seems like an overkill,
> could you maybe comment with this on past position requests, to see if
> Gecko or WebKit have an opinion on this issue?
>
>
>>
>> *Web developers*: We've received direct feedback from web developers
>> that they would be able to reduce friction in their redirect-based payment
>> flows if PaymentRequest.show() could be initiated without a user activation.
>>
>> *Other signals*:
>>
>> 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 debuggability for PaymentRequest; e.g. a specific SecurityError
>> is thrown when an activationless show() call is not allowed.
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>> Flag name--enable-blink-features=PaymentRequestActivationlessShow
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1454204
>>
>> Estimated milestones
>> DevTrial on desktop 117
>> DevTrial on Android 117
>>
>> Anticipated spec changes
>> https://github.com/w3c/payment-request/pull/1009
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/4

Re: [blink-dev] Intent to Implement and Ship: Remove Payment Request User Activation Requirement

[Stephen Mcgruer]

> Have y'all considered passing along the user activation from the
redirector page to the redirected page? (maybe with an explicit opt-in from
the redirector)

We looked at that approach early, and discussed it with mustaq@ (cc'd) who
has worked on a lot of user activation V2. Specifically, the idea was to
extend Capability Delegation <https://github.com/WICG/capability-delegation> to
navigation as well. However I believe Mustaq had a few concerns with that
idea: there may not be an obvious API surface (needs a new API on
window.location?), there were complexities around how to measure 'time
passing' cross navigation (i.e., when to stop and when to start the user
activation timer, especially also with multiple redirect hops), and finally
I think he had some philosophical concerns about whether activation should
be able to 'follow' a navigation. This led us to revisit the broader
question of "do we think user activation is necessary for Payment Request",
and we came to the conclusion that it was safe to drop.

Mustaq - please correct me if I'm wrong on any of this, or if we should
revisit the discussion!

On Mon, 19 Jun 2023 at 09:32, Yoav Weiss  wrote:

> 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 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 discussion as well. (Though note that at the current point,
>> I believe Chrome is the only active browser vendor in that WG. Apple have
>> stated interest in rejoining it, but are waiting for an in-progress charter
>> change first.)
>>
>> > I'm having a hard time imagining the use case for activation-less
>> payments. Is there a concrete example you can share?
>>
>> Fair question, and I apologize - we should have motivated this more
>> clearly externally. The core use-cases are based around redirect payment
>> flows, which are fairly common in payments. Two coarse examples we have
>> heard are:
>>
>> 1. A merchant-aggregator page showing products from many different
>> merchants. If a user decides to buy something with a given payment method,
>> the aggregator page redirects to the specific merchant. The merchant then
>> wants to trigger payment, without requiring the user to click again on
>> their chosen payment method.
>>
>> 2. A redirect-based payment flow, where the payment method wants to
>> trigger a natively installed experience (via Payment Handler) without the
>> user having to click again. (E.g., user is on merchant.example, chooses to
>> pay with FooPay. The merchant site redirects to foopay.example. FooPay then
>> wants to trigger its natively installed app on the phone, if available, but
>> doesn't want to require the user to click again.
>>
>> We are cognizant that this may be a risky change, and have consulted
>> internal security folks on it in detail. From that, there are mitigations
>> laid out in the design doc, and we are also intending to monitor for
>> potential misuse.
>>
>
> Have y'all considered passing along the user activation from the
> redirector page to the redirected page? (maybe with an explicit opt-in from
> the redirector)
>
>
>>
>> > While I agree that a signal specifically for this seems like an
>> overkill, could you maybe comment with this on past position requests, to
>> see if Gecko or WebKit have an opinion on this issue?
>>
>> Ack, we will follow up on this. Note that Gecko does not implement
>> Payment Request currently.
>>
>> Thanks,
>> Stephen
>>
>> On Wed, Jun 14, 2023, 3:28 a.m. Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Tue, Jun 13, 2023 at 8:54 PM Nick Burris 
>>> wrote:
>>>
>>>> Contact emailsnbur...@chromium.org, smcgr...@chromium.org,
>>>> i...@chromium.org
>>>>
>>>> Specificationhttps://github.com/w3c/payment-request/pull/1009
>>>>
>>>
>>> The PR seems to be a draft. What's preventing us from landing it?
>>> Was this discussed in some public forum?
>>>
>>>
>>>>
>>>>
>>>> Design docs
>>>> https://docs.google.com/document/d/16DHqqPWe5oM6Rucnn6Y1llhJ-DoEeLtTWFldJFg4iqA/edit#heading=h.w5782xqp7ab4
>>>>
>>>> Summary
>>>>
>>>> To help develope

Re: [blink-dev] Intent to Implement and Ship: Remove Payment Request User Activation Requirement

[Stephen Mcgruer]

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
definitely paying attention to potential abuse scenarios here, though we do
agree with Rick's take that getting user activation is unfortunately a
fairly weak protection today already.

Wrt the PR status - yes, the WG has now endorsed it, but we will definitely
be landing the PR before trying to ship this. We've re-targeted the launch
from M116 to M117.

On Tue, 27 Jun 2023 at 03:52, Yoav Weiss  wrote:

> LGTM2 conditional on the PR landing
>
> On Mon, Jun 26, 2023 at 5:02 PM Rick Byers  wrote:
>
>> This makes good sense to me. Obviously there's so much risk and potential
>> for abuse around payments, getting the user to click seems like a very weak
>> mitigation anyway (eg. the prevalence of "click to read more" buttons). +1
>> to waiting for the PR to land, but it looks like the WG has now approved
>> it, so proactive LGTM1 for when the PR actually lands.
>>
>> It's too bad Apple isn't currently a member of the WG, so we're not
>> likely to get their thoughts on this in time to influence our launch
>> decision. But I also don't think it's a substantial interop risk - Payment
>> Request is already very different on Apple browsers due to the tight
>> coupling only with Apple Pay.
>>
>> Rick
>>
>> On Tue, Jun 13, 2023 at 2:54 PM Nick Burris  wrote:
>>
>>> Contact emailsnbur...@chromium.org, smcgr...@chromium.org,
>>> i...@chromium.org
>>>
>>> Specificationhttps://github.com/w3c/payment-request/pull/1009
>>>
>>> Design docs
>>> https://docs.google.com/document/d/16DHqqPWe5oM6Rucnn6Y1llhJ-DoEeLtTWFldJFg4iqA/edit#heading=h.w5782xqp7ab4
>>>
>>> Summary
>>>
>>> To help developers reduce friction in Payment Request flows, we are
>>> removing the user activation requirement for PaymentRequest.show(). Spam
>>> and clickjacking mitigations are put in place to mitigate security and
>>> privacy risks with this change (see design doc
>>> 
>>> ).
>>>
>>>
>>> Blink componentBlink>Payments
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility*Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: We've received direct feedback from web developers
>>> that they would be able to reduce friction in their redirect-based payment
>>> flows if PaymentRequest.show() could be initiated without a user activation.
>>>
>>> *Other signals*:
>>>
>>> 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 debuggability for PaymentRequest; e.g. a specific SecurityError
>>> is thrown when an activationless show() call is not allowed.
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes
>>>
>>> Flag name--enable-blink-features=PaymentRequestActivationlessShow
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1454204
>>>
>>> Estimated milestones
>>> DevTrial on desktop 117
>>> DevTrial on Android 117
>>>
>>> Anticipated spec changes
>>> https://github.com/w3c/payment-request/pull/1009
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/4879115349393408
>>>
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>>
>>> --
>>> 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/CADvKJHOuA%2BEMEWO7heQJeZkr%2BU%2BtndoVuXenCeC7xQ_ENXy9RQ%40mail.gmail.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.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_7ZCW3

Re: [blink-dev] Intent to Ship: Payment handler minimal header UX

[Stephen Mcgruer]

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 rubber stamp for API
owners. (Or... maybe we should have just sent a PSA? Anyhow, we are here
now).


On Wed, Sep 13, 2023, 4:46 p.m. Mike Taylor  wrote:

> LGTM1 (I'm not sure you need our approvals to ship this UX change, but you
> can have mine).
> On 9/8/23 7:09 PM, Rouslan Solomakhin wrote:
>
>
> *Contact emails *nbur...@chromium.org
>
> *Explainer*
> https://crbug.com/1385136 - see comment 14 for screenshot
>
> *Specification*
> Not applicable
>
> *Design docs*
> (Google internal only, sorry):
> https://docs.google.com/document/d/1hCIzyBALzpFPuHQ_xCNvIpSrMThq8PA6Qgi0M2iF9vk/edit?resourcekey=0-VMUV90L2bb2OqlrBVepW4A#heading=h.bat9awopsp53
>
> *Summary*
> This is a refresh of the browser UI associated with the Payment Handler
> API. There are no API changes. The origin trial is concluding and we'd like
> to ship this feature in M119. See R2E
> 
> for more details.
>
> *Blink component*
> Blink>Payments
> 
>
> *TAG review*
> Not applicable
>
> *TAG review status*
> Not applicable
>
> *Risks*
>
> *Interoperability and Compatibility*
> None.
>
> *Gecko: N/A*
> *WebKit: N/A*
>
> *Web developers: No signals*
>
> *Other signals: No signals*
>
>
> *WebView application risks*
>
> *None*
>
>
> *Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?*
> No
>
> *Debuggability*
> N/A because it is a UI-only change.
>
> *Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?*
> No. Only desktop platforms - Windows, Mac, Linux, Chrome OS.
>
> *Is this feature fully tested by web-platform-tests?*
> No, because this is a UI-only change.
>
> *Flag name*
> PaymentHandlerMinimalHeaderUX
>
> *Finch feature name*
> None
>
> *Non-finch justification*
> None
>
> *Requires code in //chrome?*
> True
>
> *Estimated milestones*
> Shipping on desktop: 119
>
> *Anticipated spec changes*
> N/A, because there is no spec for a UI-only change.
>
> *Link to entry on the Chrome Platform Status*
> https://chromestatus.com/feature/5079275637571584
>
> *Links to previous Intent discussions*
> Intent to Experiment:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/NQ-WLvfmPs8/m/hDKJNnmOBgAJ
>
> This intent message was generated by Chrome Platform Status.
> --
> 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/CAMMzaWEp6JQOKeYBjkhGa_w%3DQvDuEOPZu590FrDLj3%2Bg2eWQWQ%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MaebhFbQuF5SF4NbzXS0Gbc3vb3SCgmc%3DE9KKKQ7VGG1Uw%40mail.gmail.com.

[blink-dev] Intent to Prototype: Allow for WebAuthn credential creation in a cross-origin iframe

[Stephen Mcgruer]

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
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/

Blink componentBlink>WebAuthentication



TAG reviewNone

TAG review statusNot applicable

Risks

Interoperability and Compatibility

None

*Gecko*: No signal

*WebKit*: No signal

*Web developers*: No signals

*Other signals*:

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

Will be debuggable by usual devtools tooling for JavaScript.


Is this feature fully tested by web-platform-tests

?N/A (Not yet implemented)

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5175677674586112

-- 
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/CADY3Maf7EmNUH1zYSi7DimKd5NfddYY3navNx3-ELPyeqHpPMw%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: Allow for WebAuthn credential creation in a cross-origin iframe

[Stephen Mcgruer]

To clarify - WebAuthn credentials are already available for reading in a
cross-origin iframe, as long the "publickey-credentials-get" permission
policy is set. So the question probably stands for WebAuthn in general,
rather than just this change to allow creation as well?

I'm cc-ing agl@ as the expert here, but my understanding is that WebAuthn
credentials (aka passkeys) are unpartitioned, but require sufficient user
interaction/consent that they are considered compatible with the
deprecation of third-party cookies and unpartitioned storage. A frame on
origin A embedded under origin B can request (via credentials.get()) its
unpartitioned passkey, but the user will at minimum* see and have to
confirm a UI that indicates that they are identifying themselves to origin
A, and will usually have to interact with an authenticator flow (e.g.,
TouchID, or a password prompt) as well.

* At minimum because WebAuthn always requires something called 'user
presence' which might just have a UI where the user can click to confirm,
but almost always is used with the stronger 'user verification' which does
an authentication flow.

On Thu, 9 Nov 2023 at 12:39, Reilly Grant  wrote:

> Is this proposal compatible with the deprecation of third-party cookies
> and partitioned storage? Since credentials are origin-bound, what
> credentials are available to a frame on origin A embedded under origin B?
> Reilly Grant | Software Engineer | reil...@chromium.org | 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-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/
>>
>> Blink componentBlink>WebAuthentication
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebAuthentication>
>>
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> None
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> 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
>>
>> Will be debuggable by usual devtools tooling for JavaScript.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?N/A (Not yet implemented)
>>
>> Flag name on chrome://flagsNone
>>
>> Finch feature nameNone
>>
>> Non-finch justificationNone
>>
>> Requires code in //chrome?False
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5175677674586112
>>
>> --
>> 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/CADY3Maf7EmNUH1zYSi7DimKd5NfddYY3navNx3-ELPyeqHpPMw%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Maf7EmNUH1zYSi7DimKd5NfddYY3navNx3-ELPyeqHpPMw%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.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Mae12e1MvWouhD5qZRCQsRaG_h_bXjC%2B0yeUfB4uHX4xww%40mail.gmail.com.

[blink-dev] Intent to Ship: Allow for WebAuthn credential creation in a cross-origin iframe

[Stephen Mcgruer]

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
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/

Blink componentBlink>WebAuthentication


TAG reviewNone

TAG review statusNot 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 (one example -
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

?Yes

In review: https://github.com/web-platform-tests/wpt/pull/43729 (Chrome Dev
passes 5/5 added tests)

Flag name on chrome://flagsNone

Finch feature nameWebAuthAllowCreateInCrossOriginFrame

Requires code in //chrome?False

Tracking bughttps://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

Links to previous Intent discussionsIntent to prototype:
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
.

-- 
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/CADY3MacSSuysQWizFRwJv95%2BV9epzBDtyX-nf08RR-872TBPnQ%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Allow for WebAuthn credential creation in a cross-origin iframe

[Stephen Mcgruer]

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  wrote:

> 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
> 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/
>
> Blink componentBlink>WebAuthentication
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebAuthentication>
>
> TAG reviewNone
>
> TAG review statusNot 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 (one example -
> 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 (Chrome
> Dev passes 5/5 added tests)
>
> Flag name on chrome://flagsNone
>
> Finch feature nameWebAuthAllowCreateInCrossOriginFrame
>
> Requires code in //chrome?False
>
> Tracking bughttps://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
>
> Links to previous Intent discussionsIntent to prototype:
> 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.
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.

Re: [blink-dev] Re: Intent to Ship: Allow for WebAuthn credential creation in a cross-origin iframe

[Stephen Mcgruer]

Sounds great:

https://github.com/WebKit/standards-positions/issues/304
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  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 
> wrote:
>
>> Contact emails smcgr...@chromium.org
>>
>> Explainer None
>>
>> 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 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/
>>
>> 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 (one example -
>> 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 (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
>>
>> Estimated milestones
>> Shipping on desktop 122
>> DevTrial on desktop 122
>> Shipping on Android 122
>> DevTrial on Android 122
>> Anticipated spec

Re: [blink-dev] Re: Intent to Ship: Allow for WebAuthn credential creation in a cross-origin iframe

[Stephen McGruer]

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/mozilla/standards-positions/issues/964
>
> Will update if we get any reply :)
>
> On Wed, 17 Jan 2024 at 10:25, Mike Taylor  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  
>> wrote:
>>
>>> Contact emails smcgr...@chromium.org
>>>
>>> Explainer None
>>>
>>> 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 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/
>>>
>>> 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 (one example - 
>>> 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/c

Re: [blink-dev] Intent to Prototype: Web Monetization

[Stephen Mcgruer]

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:
>
>> Contact emails
>>
>> asur...@igalia.com
>>
>> Explainer
>>
>> https://webmonetization.org/docs
>>
>> High Level Overview
>>
>> High Level Web Monetization Overview
>> <https://docs.google.com/document/d/1TXXnoRNhlkVjeMX434ajUVQW3AB3k-iuznJTJbNdlis/edit?usp=sharing>
>> Specification
>>
>> https://webmonetization.org/specification/
>>
>> Summary
>>
>> Implement the Web Monetization spec. Web Monetization is a web technology
>> that enables website owners to receive micro payments from users as they
>> interact with their content. It provides a way for content creators and
>> website owners to be compensated for their work without relying solely on
>> ads or subscriptions. Notably, Web Monetization offers two unique
>> features—small payments and no user interaction—users are paying/tipping
>> for the content while they consume it. It extends the HTML  element
>> by introducing rel="monetization". When this element is incorporated into a
>> web page, it signifies the website's support for web monetization. If a
>> user has their wallet set up for a particular website, their browser will
>> automatically start a web monetization session, enabling direct payments
>> from the user to the website.
>>
>>
>> Blink component
>>
>> Blink>Payments
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EPayments&can=2>
>>
>> Motivation
>>
>> Web monetization offers a new revenue model for content creators and
>> website owners, allowing them to earn from their work while users consume
>> their content. It also facilitates voluntary user contributions, such as
>> tips, directly rewarding the creators for the value their content provides.
>>
>> Initial public proposal
>>
>> None
>> TAG review
>>
>> None
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> Gecko: No signal
>>
>> WebKit: No signal
>>
>> Web developers: a fraction of a percent of all web pages have already
>> been configured to use the feature in anticipation of web/browser support,
>> according to metrics
>> <https://chromestatus.com/metrics/feature/timeline/popularity/3120>.
>> There used to be a different way to set up web monetization on a web site
>> by using HTML:meta tag, which achieved 0.03% adoption
>> <https://chromestatus.com/metrics/feature/timeline/popularity/3119> on
>> the web.
>>
>> Other signals:
>>
>> 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
>>
>> None
>>
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?
>>
>> No
>>
>> Flag name on chrome://flags
>>
>> WebMonetization in runtime_enabled_features.json5.
>>
>> Finch feature name
>>
>> None
>>
>> Non-finch justification
>>
>> None
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Estimated milestones
>>
>> M127 <https://chromiumdash.appspot.com/schedule>
>>
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/4917148755689472
>>
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d91487a5-108c-46e7-accd-d44b734a0b34%40igalia.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d91487a5-108c-46e7-accd-d44b734a0b34%40igalia.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.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MaeTmpf1T96vDmsA7HJxDY%2BXaijps%3Djiyo2qSOwwZd7nrQ%40mail.gmail.com.

[blink-dev] Re: Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Stephen Mcgruer]

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
>
> Deprecate the "basic-card" payment method from PaymentRequest API.
>
> Blink componentBlink>Payments
> 
>
> Motivation
>
> * Its usage is low and declining, underperforms other payment methods in
> time-to-checkout and completion rate and does not have improvement
> potential. * W3C's interest in it has waned. 6 participants supported the
> deprecation and no objection[1], and W3C has deprecated the spec[2]. [1]
> https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0038.html
> [2] https://github.com/w3c/payment-method-basic-card/pull/90/files
>
>
> Interoperability and Compatibility
> * Chrome is the only implementer of basic-card, so the basic-card removal
> from Chrome will increase interoperability.
> * Since no other browser implements basic-card, web developers already
> need workarounds to support other browsers.
> * Whether basic-card is supported can be detected via canMakePayment
> . Web
> developers normally use this to decide whether to fallback to other methods.
> * We have checked the few top sites via UKM - they all appear to work
> with basic-card disabled because they fallback to other methods to get
> payment info.
>
> Tracking bughttps://crbug.com/1209835
>
> Estimated milestonesM96
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/573005107056
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "payments-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to payments-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/payments-dev/CAEWPi2sswphwqEnCGgwwNOr_F5j8V%3Dc5ZQ7Kz6h2gK%2Bki2A6aw%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MaeGabEJBE985vfS%3DmMR4OWafy%2B6TU3D7iM6L4Yh_jjYVw%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Stephen Mcgruer]

> 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
.
They're still very important, so we have to measure usage other ways :)

2) In particular for basic-card, it's actually just a method-type of
PaymentRequest, so our top-level usecounters don't show it.

We have internal stats that I can't share publicly due to sensitivity
(Googlers, feel free to ping me for a link), but I can share that of
transactions using PaymentRequest, basic-card is ~2% of all transactions
and <1% of completed transactions. So it's a very niche feature that also
performs poorly.

Max has also done an analysis of the top 10 sites from UKM data that use
basic-card. For 4, he couldn't get to the payments page or couldn't get it
to trigger basic-card at all (possibly geographically gated), but for the
remaining 6 he confirmed that all 6 function properly in a version of
Chrome that has basic-card disabled (falling back to the same behavior they
use for Firefox + Safari).

On Mon, 6 Sept 2021 at 03:26, Yoav Weiss  wrote:

>
>
> On Fri, Sep 3, 2021 at 4:25 PM Liquan (Max) Gu  wrote:
>
>> Contact emailsma...@chromium.org, payments-...@chromium.org
>>
>> Specificationhttps://www.w3.org/TR/payment-method-basic-card/
>>
>> Summary
>>
>> Deprecate the "basic-card" payment method from PaymentRequest API.
>>
>> Blink componentBlink>Payments
>> 
>>
>> Motivation
>>
>> * Its usage is low and declining, underperforms other payment methods in
>> time-to-checkout and completion rate and does not have improvement
>> potential.
>>
>
> Any usecounter stats you can share?
>
>> * W3C's interest in it has waned. 6 participants supported the
>> deprecation and no objection[1], and W3C has deprecated the spec[2]. [1]
>> https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0038.html
>> [2] https://github.com/w3c/payment-method-basic-card/pull/90/files
>>
>>
>> Interoperability and Compatibility
>> * Chrome is the only implementer of basic-card, so the basic-card removal
>> from Chrome will increase interoperability.
>> * Since no other browser implements basic-card, web developers already
>> need workarounds to support other browsers.
>> * Whether basic-card is supported can be detected via canMakePayment
>> . Web
>> developers normally use this to decide whether to fallback to other methods.
>> * We have checked the few top sites via UKM - they all appear to work
>> with basic-card disabled because they fallback to other methods to get
>> payment info.
>>
>> Tracking bughttps://crbug.com/1209835
>>
>> Estimated milestonesM96
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/573005107056
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> 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/CAEWPi2sswphwqEnCGgwwNOr_F5j8V%3Dc5ZQ7Kz6h2gK%2Bki2A6aw%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "payments-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to payments-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/payments-dev/CAL5BFfUaHsXJEEwN3JO2MSGw9WHsVt5nszPPscKh9mBrRt5U1g%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Mac986%2BtzwvcQfnmxBe%2BU8bgiJ%3DmW-NjptpgLZTdLYqH0A%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Secure Payment Confirmation

[Stephen Mcgruer]

Thank you all for the LGTMs (all four of them ;)).

One additional piece of business; having discussed with our partners, *we
would like to request a 'gapless' transition for our ongoing Origin Trial*
(that is, skip the required breaking period) to allow an uninterrupted
availability for partners. We believe we meet the bar: the API changed
significantly from M93, to M94, to M95, such that code written solely for
M93-M94 will not work on M95. (So we definitely haven't been avoiding
breaking changes!).

On Thu, 2 Sept 2021 at 15:25, Yoav Weiss  wrote:

> LGTM3
>
> On Thursday, September 2, 2021 at 9:25:14 PM UTC+2 Mike West wrote:
>
>> LGTM2. This has been approved via internal security and privacy review,
>> has gotten substantial developer feedback during OT, and serves a useful
>> purpose.
>>
>> I would ask y'all to pay attention to the TAG in case they provide
>> substantive feedback in the near future. But given that the review was
>> initially filed a year ago, and the conversation stalled in January, I
>> don't think we need to block on their input.
>>
>> -mike
>>
>>
>> On Thu, Sep 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/yoavweiss/status/1382050433632456711> me as a user
>>>>
>>>> Oof! Yes, we'd like to help figure out a way to make *that* not
>>>> happen...
>>>>
>>>> > What would be the timelines for [the commitment to see through the
>>>> WPT test suite]?
>>>>
>>>> My team will be working on test automation for SPC in Q4 2021. As the
>>>> ex-lead of WPT in Chromium, I am quite insistent that we get it done :D.
>>>>
>>>>  > Any feedback from the Origin Trial?
>>>>
>>>> During the Origin Trial we did iterate on the API shape significantly,
>>>> but that more came from discussions in the working group than Origin Trial
>>>> participant feedback (who are themselves also in the working group, so some
>>>> overlap).
>>>>
>>>> From our Origin Trial partners, we mostly heard that the overall
>>>> experience is working for them and that they're really excited to be able
>>>> to build lower-friction authentication solutions in the payments 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 Stephen Mcgruer 
>>>>> wrote:
>>>>>
>>>>>> 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 authentication
>>>>>> experience on the web with the help of WebAuthn. The feature adds a new
>>>>>> 'payment' extension to WebAuthn, which allows a relying party such as a
>>>>>> bank to create a PublicKeyCredential that can be queried by any merchant
>>>>>> origin as part of an online checkout via the Payment Request API using 
>>>>>> the
>>>>>> 'secure-payment-confirmation payment' method.
>>>>>>
>>>>>> Blink componentBlink>Payments
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments>
>>>>>>
>>>>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/544
>>>>>>
>>>>>> TAG review statusPending
>>>>>>
>>>>>> *Supported on all platforms?*
>>>>>> No.
>>>>>>
>>>>>> SPC is launching on MacOS and Windows only initially, as they are
>>>>>> platforms that have built-in authenticators and which payment partners

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Stephen Mcgruer]

> Can you clarify what breakage may look like for sites that may rely on it?

If a site was *entirely* relying on basic-card to collect credit card
details from their user, it would be impossible for the user to complete
their checkout. So arguably 'site completely broken' from that perspective
(assuming buying a thing is the main user journey).

However, such a site would also be broken on Firefox and Safari today
(unless serving user-agent specific code), and sites also tend to not rely
on just one approach to get paid. Sites will almost definitely have a
fallback mechanism, and it will likely be invisible to the user. For
example:

1. Site checks `if (window.PaymentRequest)` - passes in Chrome and Safari,
fails in Firefox.
2. Site calls `new PaymentRequest([basic-card-data]).canMakePayment()` (or
`show()` directly) - passes in Chrome today, fails/throws in Safari.
3. If either of #1 or #2 failed, render a fallback payment information
collection flow such as a HTML form.

TL;DR - we expect very few to no sites to break due to this removal, unless
they're doing user-agent specific branching with no fallback mechanisms for
'what if basic-card fails'.

On Thu, 9 Sept 2021 at 08: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 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
>> <https://chromestatus.com/metrics/feature/timeline/popularity/2895>.
>> They're still very important, so we have to measure usage other ways :)
>>
>> 2) In particular for basic-card, it's actually just a method-type of
>> PaymentRequest, so our top-level usecounters don't show it.
>>
>> We have internal stats that I can't share publicly due to sensitivity
>> (Googlers, feel free to ping me for a link), but I can share that of
>> transactions using PaymentRequest, basic-card is ~2% of all transactions
>> and <1% of completed transactions. So it's a very niche feature that also
>> performs poorly.
>>
>> Max has also done an analysis of the top 10 sites from UKM data that use
>> basic-card. For 4, he couldn't get to the payments page or couldn't get it
>> to trigger basic-card at all (possibly geographically gated), but for the
>> remaining 6 he confirmed that all 6 function properly in a version of
>> Chrome that has basic-card disabled (falling back to the same behavior they
>> use for Firefox + Safari).
>>
>> On Mon, 6 Sept 2021 at 03:26, Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Fri, Sep 3, 2021 at 4:25 PM Liquan (Max) Gu 
>>> wrote:
>>>
>>>> Contact emailsma...@chromium.org, payments-...@chromium.org
>>>>
>>>> Specificationhttps://www.w3.org/TR/payment-method-basic-card/
>>>>
>>>> Summary
>>>>
>>>> Deprecate the "basic-card" payment method from PaymentRequest API.
>>>>
>>>> Blink componentBlink>Payments
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments>
>>>>
>>>> Motivation
>>>>
>>>> * Its usage is low and declining, underperforms other payment methods
>>>> in time-to-checkout and completion rate and does not have improvement
>>>> potential.
>>>>
>>>
>>> Any usecounter stats you can share?
>>>
>>>> * W3C's interest in it has waned. 6 participants supported the
>>>> deprecation and no objection[1], and W3C has deprecated the spec[2]. [1]
>>>> https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0038.html
>>>> [2] https://github.com/w3c/payment-method-basic-card/pull/90/files
>>>>
>>>>
>>>> Interoperability and Compatibility
>>>> * Chrome is the only implementer of basic-card, so the basic-card
>>>> removal from Chrome will increase interoperability.
>>>> * Since no other browser implements basic-card, web developers already
>>>> need workarounds to support other browsers.
>>>> * Whether basic-card is supported can be detected via canMakePayment
>>>> <https://w3c.github.io/payment-request/#canmakepayment-method>. Web
>>>> developers normally use this to decide whether

[blink-dev] Intent to Deprecate and Remove: Calling PaymentRequest.show without user activation

[Stephen Mcgruer]

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 are now following through in the
Chrome implementation.


Plan is to deprecate in M98 and remove in M99. We may push the M99 date to
M100 based on compat risk; see below.

Blink componentBlink>Payments


TAG reviewN/A - enforcement of feature from an already-reviewed
specification

TAG review statusPending

Risks
Interoperability and Compatibility

Interoperability: no risk. Firefox has not shipped PaymentRequest at all,
whilst Safari's implementation already requires user activation for calling
show(). Compatibility: the main risk. If a website is calling
PaymentRequest.show() without a user activation today, it will stop
working. If that website doesn't have fallback code to use another payments
flow, it may lead to a broken purchase experience for the user. Due to this
risk, we added a UseCounter, kPaymentRequestShowWithoutGesture, which
tracks use of the feature. Although hits on the UseCounter have reduced
significantly since 2019*, there is still non-zero usage which is growing
slowly over time. We believe the growth to be related to the general
increase of web payments, rather than an expanded number of sites. To
tackle the remaining usage, we have performed a UKM analysis, and
identified the primary remaining site. We are in contact with them, and
expect them to roll out a fix in the coming weeks - after which we will
revisit the numbers and this thread. *
https://chromestatus.com/metrics/feature/timeline/popularity/2398

Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1445138)

WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=179056)

Web developers: No signals

Other signals:

Debuggability

As we are treating this as a deprecation, we intend to use the issues tab
(as per the checklist) to warn developers of the upcoming removal. Once the
support is removed, calling show() will throw a SecurityError with a clear
error message.

Is this feature fully tested by web-platform-tests

?Yes -
https://wpt.fyi/results/payment-request/show-consume-activation.https.html?label=experimental&label=master&aligned

Requires code in //chrome?False

Tracking bughttps://crbug.com/825270

Estimated milestones
Deprecate in M98, remove in M99 or M100 (compat risk depending).

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5948593429020672

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/2PhPgk_k9a0/m/alO4yt_HBQAJ
Intent to Experiment:
https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/i6pAWsjU7zg/m/CzqgcGAXAwAJ

   - This is a bit of a strange case, where we initially believed that we
   needed Capability Delegation to support deprecating this feature. However,
   the partner who needed that ability has instead solved their problem in a
   different way. As such, we believe it safe to require user activation for
   show() calls *without* Capability Delegation being available.


This intent message was generated by Chrome Platform Status
 and hand edited by smcgruer@.

-- 
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/CADY3Mae4RVpVxnjMS8oJ7WE7yOtAiqqa79%3D8v%2ByNf2XhCtHWgg%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: Calling PaymentRequest.show without user activation

[Stephen Mcgruer]

> Does the primary remaining site have fallback code, or will it be broken?

Yes and no :). It doesn't have automatic fallback for the specific payment
method the user has selected (Google Pay), but the user could then select
one of the other payment methods that the site supports (either a credit
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-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 are now following through in the
>> Chrome implementation.
>>
>>
>> Plan is to deprecate in M98 and remove in M99. We may push the M99 date
>> to M100 based on compat risk; see below.
>>
>> Blink componentBlink>Payments
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments>
>>
>> TAG reviewN/A - enforcement of feature from an already-reviewed
>> specification
>>
>> TAG review statusPending
>>
>> Risks
>> Interoperability and Compatibility
>>
>> Interoperability: no risk. Firefox has not shipped PaymentRequest at all,
>> whilst Safari's implementation already requires user activation for calling
>> show(). Compatibility: the main risk. If a website is calling
>> PaymentRequest.show() without a user activation today, it will stop
>> working. If that website doesn't have fallback code to use another payments
>> flow, it may lead to a broken purchase experience for the user. Due to this
>> risk, we added a UseCounter, kPaymentRequestShowWithoutGesture, which
>> tracks use of the feature. Although hits on the UseCounter have reduced
>> significantly since 2019*, there is still non-zero usage which is growing
>> slowly over time. We believe the growth to be related to the general
>> increase of web payments, rather than an expanded number of sites. To
>> tackle the remaining usage, we have performed a UKM analysis, and
>> identified the primary remaining site. We are in contact with them, and
>> expect them to roll out a fix in the coming weeks - after which we will
>> revisit the numbers and this thread.
>>
>
> Does the primary remaining site have fallback code, or will it be broken?
>
>
>> * https://chromestatus.com/metrics/feature/timeline/popularity/2398
>>
>> Gecko: In development (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1445138)
>>
>> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=179056)
>>
>> Web developers: No signals
>>
>> Other signals:
>>
>> Debuggability
>>
>> As we are treating this as a deprecation, we intend to use the issues tab
>> (as per the checklist) to warn developers of the upcoming removal. Once the
>> support is removed, calling show() will throw a SecurityError with a clear
>> error message.
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>> ?Yes -
>> https://wpt.fyi/results/payment-request/show-consume-activation.https.html?label=experimental&label=master&aligned
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/825270
>>
>> Estimated milestones
>> Deprecate in M98, remove in M99 or M100 (compat risk depending).
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5948593429020672
>>
>> Links to previous Intent discussionsIntent to prototype:
>> https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/2PhPgk_k9a0/m/alO4yt_HBQAJ
>> Intent to Experiment:
>> https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/i6pAWsjU7zg/m/CzqgcGAXAwAJ
>>
>>- This is a bit of a strange case, where we initially believed that
>>we needed Capability Delegation to support deprecating this feature.
>>However, the partner who needed that ability has instead solved their
>>problem in a different way. As such, we believe it safe to require user
>>activation for show() calls *without* Capability Delegation being
>>available.
>>
>>
>> This intent message was generated by Chrome Platform Status
>> <https://www.chromestatus.com/> and hand edited by smcgruer@.
>>
>> --
>> You received this mes

Re: [blink-dev] Intent to Deprecate and Remove: Calling PaymentRequest.show without user activation

[Stephen Mcgruer]

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 the removal till they have, and
2. Don't need to provide an alternative in the form of capability
delegation.

But the code change to at least start this deprecation would have to land
by December 9th (or we punt for 1.5 months), hence why we're filing this
ahead of them fixing their site :).

On Wed, 1 Dec 2021 at 12:22, Stephen Mcgruer  wrote:

> > Does the primary remaining site have fallback code, or will it be broken?
>
> Yes and no :). It doesn't have automatic fallback for the specific payment
> method the user has selected (Google Pay), but the user could then select
> one of the other payment methods that the site supports (either a credit
> 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-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 are now following through in the
>>> Chrome implementation.
>>>
>>>
>>> Plan is to deprecate in M98 and remove in M99. We may push the M99 date
>>> to M100 based on compat risk; see below.
>>>
>>> Blink componentBlink>Payments
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments>
>>>
>>> TAG reviewN/A - enforcement of feature from an already-reviewed
>>> specification
>>>
>>> TAG review statusPending
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> Interoperability: no risk. Firefox has not shipped PaymentRequest at
>>> all, whilst Safari's implementation already requires user activation for
>>> calling show(). Compatibility: the main risk. If a website is calling
>>> PaymentRequest.show() without a user activation today, it will stop
>>> working. If that website doesn't have fallback code to use another payments
>>> flow, it may lead to a broken purchase experience for the user. Due to this
>>> risk, we added a UseCounter, kPaymentRequestShowWithoutGesture, which
>>> tracks use of the feature. Although hits on the UseCounter have reduced
>>> significantly since 2019*, there is still non-zero usage which is growing
>>> slowly over time. We believe the growth to be related to the general
>>> increase of web payments, rather than an expanded number of sites. To
>>> tackle the remaining usage, we have performed a UKM analysis, and
>>> identified the primary remaining site. We are in contact with them, and
>>> expect them to roll out a fix in the coming weeks - after which we will
>>> revisit the numbers and this thread.
>>>
>>
>> Does the primary remaining site have fallback code, or will it be broken?
>>
>>
>>> * https://chromestatus.com/metrics/feature/timeline/popularity/2398
>>>
>>> Gecko: In development (
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1445138)
>>>
>>> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=179056
>>> )
>>>
>>> Web developers: No signals
>>>
>>> Other signals:
>>>
>>> Debuggability
>>>
>>> As we are treating this as a deprecation, we intend to use the issues
>>> tab (as per the checklist) to warn developers of the upcoming removal. Once
>>> the support is removed, calling show() will throw a SecurityError with a
>>> clear error message.
>>>
>>> Is this feature fully tested by web-platform-tests
>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>> ?Yes -
>>> https://wpt.fyi/results/payment-request/show-consume-activation.https.html?label=experimental&label=master&aligned
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://crbug.com/825270
>>>
>>> Estimated milestones
>>> Deprecate in M98, remove in M99 or M100 (compat risk depending).
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5948593429020672
>>>
>>> Links to previo

Re: [blink-dev] Intent to Deprecate and Remove: Calling PaymentRequest.show without user activation

[Stephen McGruer]

Hey folks,

Following up here - we have determined that the remaining uses *do* necessitate 
making Capability Delegation available for web developers (see our Intent 
to Experiment 
<https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/i6pAWsjU7zg/m/CzqgcGAXAwAJ>
 - 
unfortunately our partner didn't engage at that time or we would have 
caught this earlier :(. )

We expect an Intent to Ship to be sent for Capability Delegation 'soon', 
targeting M100, and so are planning to push this deprecation out to M100 as 
well to align with that.

Thanks,
Stephen
On Wednesday, December 1, 2021 at 3:25:01 PM UTC-5 Mike Taylor wrote:

> LGTM3
>
> On 12/1/21 12:34 PM, Chris Harrelson wrote:
>
> LGTM2
>
> On Wed, Dec 1, 2021 at 9:33 AM Yoav Weiss  wrote:
>
>> LGTM1 to deprecate in M98 and remove in M99, assuming no surprises come 
>> up on the usage front.
>>
>> 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 the removal till they have, and
>>> 2. Don't need to provide an alternative in the form of capability 
>>> delegation.
>>>
>>> But the code change to at least start this deprecation would have to 
>>> land by December 9th (or we punt for 1.5 months), hence why we're filing 
>>> this ahead of them fixing their site :).
>>>
>>> On Wed, 1 Dec 2021 at 12:22, Stephen Mcgruer  
>>> wrote:
>>>
>>>> > Does the primary remaining site have fallback code, or will it be 
>>>> broken?
>>>>
>>>> Yes and no :). It doesn't have automatic fallback for the specific 
>>>> payment method the user has selected (Google Pay), but the user could then 
>>>> select one of the other payment methods that the site supports (either a 
>>>> credit 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 emails smcgr...@chromium.org
>>>>>>
>>>>>> Specification https://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 are now following 
>>>>>> through in the Chrome implementation.
>>>>>>
>>>>>> Plan is to deprecate in M98 and remove in M99. We may push the M99 
>>>>>> date to M100 based on compat risk; see below.
>>>>>>
>>>>>> Blink component Blink>Payments 
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments>
>>>>>>
>>>>>> TAG review N/A - enforcement of feature from an already-reviewed 
>>>>>> specification
>>>>>>
>>>>>> TAG review status Pending
>>>>>>
>>>>>> Risks 
>>>>>> Interoperability and Compatibility 
>>>>>>
>>>>>> Interoperability: no risk. Firefox has not shipped PaymentRequest at 
>>>>>> all, whilst Safari's implementation already requires user activation for 
>>>>>> calling show(). Compatibility: the main risk. If a website is calling 
>>>>>> PaymentRequest.show() without a user activation today, it will stop 
>>>>>> working. If that website doesn't have fallback code to use another 
>>>>>> payments 
>>>>>> flow, it may lead to a broken purchase experience for the user. Due to 
>>>>>> this 
>>>>>> risk, we added a UseCounter, kPaymentRequestShowWithoutGesture, which 
>>>>>> tracks use of the feature. Although hits on the UseCounter have reduced 
>>>>>> significantly since 2019*, there is still non-zero usage which is 
>>>>>> growing 
>>>>>> slowly over time. We believe the growth to be related to the general 
>>>>>> increase of web payments, rather than an expanded number of sites. To 
>>>>>> tackle t

Re: [blink-dev] Intent to Ship: Capability Delegation with Payment Request

[Stephen Mcgruer]

> 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 Remove: Calling
PaymentRequest.show without user activation
.
We had hoped to land them simultaneously (as we have a good relationship
with the primary user that does not currently have user-activation when
calling show()), however our partner is having trouble with their
migration and we may request to push the enforcement (aka the deprecation)
back to M102. (TBD still; I expect to make the request on the deprecation
thread in the next few days.)

On Fri, 28 Jan 2022 at 11:55, Chris Harrelson  wrote:

> I'm a bit confused about the bit regarding transitioning existing sites.
> 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?
>
> Chris
>
> On Thu, Jan 27, 2022 at 11:13 PM Yoav Weiss 
> wrote:
>
>> LGTM2 % fixing the spec issue.
>>
>> On Thu, Jan 27, 2022 at 9:53 PM Mike Taylor 
>> wrote:
>>
>>> Appreciate the replies, Mustaq.
>>>
>>> This seems like a useful addition to the platform, thanks for working on
>>> it. LGTM1.
>>>
>>> On 1/27/22 12:35 PM, Mustaq Ahmed wrote:
>>>
>>> Hi Mike:
>>>
>>> Appreciate your feedback.  My answers are inline.
>>>
>>> Mustaq
>>>
>>>
>>> On Wed, Jan 26, 2022 at 6:03 PM Mike Taylor 
>>> wrote:
>>>
 Hi Mustaq,

 On 1/25/22 4:45 PM, Mustaq Ahmed wrote:

 Contact emails

 mus...@chromium.org, smcgr...@chromium.org
 Explainer

 https://github.com/WICG/capability-delegation
 Specification

 https://wicg.github.io/capability-delegation/spec.html
 Design doc


 https://docs.google.com/document/d/1IYN0mVy7yi4Afnm2Y0uda0JH8L2KwLgaBqsMVLMYXtk/edit?usp=sharing
 Summary

 Capability delegation means allowing a frame to relinquish its ability
 to call a restricted API and transfer the ability to another (sub)frame it
 trusts.

 Can you expand more on the relinquishing aspect and how regaining the
 capability happens? I can't find any normative text in
 https://wicg.github.io/capability-delegation/spec.html that explains
 how it happens. Do we look for expired timestamps in
 DELEGATED_CAPABILITY_TIMESTAMPS["feature"] of all frames? Something else?

 (maybe I'm looking in the wrong place!)

>>> You got it right: our proposal missed the normative text around the
>>> relinquishing, yikes!  I opened this spec issue
>>> , we will send
>>> out a PR to fix this when we get a chance.  In the meantime here is what we
>>> wanted to mean: access to activation-gated APIs
>>> 
>>>  is
>>> lost from the sender frame through consumption, and the receiver frame
>>> checks its own DELEGATED_CAPABILITY_TIMESTAMPS["feature"] only.
>>>
>>> If an app wants to delegate its ability to call a restricted JS
 capability (e.g. popups, fullscreen, etc) to a known+trusted third-party
 frame, the app would utilize a Capability Delegation API to "transfer" the
 ability to the target frame in a time-constrained manner (unlike static
 mechanisms like  attributes).

 What happens if the delegation is refused (or fails) by the browser for
 some reason? As a developer, how do I know that I shouldn't fire off a
 PaymentRequest that's going to fail? Do we signal anything in the message
 event, if not, should we?

 (From the PaymentRequest side, I guess I can handle the failure if
 PaymentRequest.show() is rejected.)

>>> Yes, just trying PaymentRequest.show() works on the receiver side
>>> today.  As we get more use-cases around delegation, we can explore
>>> signaling on the received message event.  I would suggest starting a new
>>> issue to discuss this.
>>>
>>> That's fair - I'll file an issue, but I don't consider this to be a
>>> blocking concern.
>>>
>>>
>>> As for error handling on the sender side, we have a few synchronous
>>> failure conditions in our postMessage
>>> 
>>>  algorithm
>>> 
>>>  already,
>>> can easily new ones as needed.  However, if you are thinking about an
>>> asynchronous failure (e.g. detected later when the browser decided to run
>>> the posted task), it seems like an existing problem with postMessage unless
>>>

Re: [blink-dev] Intent to Deprecate and Remove: Calling PaymentRequest.show without user activation

[Stephen McGruer]

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 
engaged in helping them we haven't made much progress yet.

As such, I'm currently requesting that we delay this deprecation *until 
M102*, 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 determined that the remaining uses *do* 
> necessitate 
> making Capability Delegation available for web developers (see our Intent 
> to Experiment 
> <https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/i6pAWsjU7zg/m/CzqgcGAXAwAJ>
>  - 
> unfortunately our partner didn't engage at that time or we would have 
> caught this earlier :(. )
>
> We expect an Intent to Ship to be sent for Capability Delegation 'soon', 
> targeting M100, and so are planning to push this deprecation out to M100 as 
> well to align with that.
>
> Thanks,
> Stephen
> On Wednesday, December 1, 2021 at 3:25:01 PM UTC-5 Mike Taylor wrote:
>
>> LGTM3
>>
>> On 12/1/21 12:34 PM, Chris Harrelson wrote:
>>
>> LGTM2
>>
>> On Wed, Dec 1, 2021 at 9:33 AM Yoav Weiss  wrote:
>>
>>> LGTM1 to deprecate in M98 and remove in M99, assuming no surprises come 
>>> up on the usage front.
>>>
>>> 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 the removal till they have, and
>>>> 2. Don't need to provide an alternative in the form of capability 
>>>> delegation.
>>>>
>>>> But the code change to at least start this deprecation would have to 
>>>> land by December 9th (or we punt for 1.5 months), hence why we're filing 
>>>> this ahead of them fixing their site :).
>>>>
>>>> On Wed, 1 Dec 2021 at 12:22, Stephen Mcgruer  
>>>> wrote:
>>>>
>>>>> > Does the primary remaining site have fallback code, or will it be 
>>>>> broken?
>>>>>
>>>>> Yes and no :). It doesn't have automatic fallback for the specific 
>>>>> payment method the user has selected (Google Pay), but the user could 
>>>>> then 
>>>>> select one of the other payment methods that the site supports (either a 
>>>>> credit 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 emails smcgr...@chromium.org
>>>>>>>
>>>>>>> Specification https://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 are now following 
>>>>>>> through in the Chrome implementation.
>>>>>>>
>>>>>>> Plan is to deprecate in M98 and remove in M99. We may push the M99 
>>>>>>> date to M100 based on compat risk; see below.
>>>>>>>
>>>>>>> Blink component Blink>Payments 
>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments>
>>>>>>>
>>>>>>> TAG review N/A - enforcement of feature from an already-reviewed 
>>>>>>> specification
>>>>>>>
>>>>>>> TAG review status Pending
>>>>>>>
>>>>>>> Risks 
>>>>>>> Interoperability and Compatibility 
>>>>>>>
>>>>>>> Interoperability: no risk. Firefox has not shipped PaymentRequest at 
>>>>>>> all, whilst Safari's implementation already requires user activation 
>>>>&

Re: [blink-dev] Intent to Deprecate and Remove: Calling PaymentRequest.show without user activation

[Stephen Mcgruer]

> Is there anything we can learn about their challenges that might apply to
the broader ecosystem?

A little, though largely it appears to be a bug in either their application
or in Chrome (we're still trying to figure out which!). Simplifying, the
problem is that they seem to be losing the Capability Delegation between
click and (in a different iframe) the call to PR.show(), and it's quite
tricky to debug this in a large async application. I can think of a few
things that might help:

1. Adding capability delegation support to navigator.userActivation
<https://github.com/dtapuska/useractivation> would likely be useful, e.g.
exposing an array of capabilities currently active. This would make it much
easier to quickly debug 'do I have a CD right here'. I hope the Capability
Delegation folks might consider adding this! :)
2. Pausing user activation timeout when code execution in devtools is
paused would be useful.
3. More generally (and more hand-wavingly), being able to more easily trace
flows through async iframes 'somehow'. Devtools has some support for this,
and it might just be user error that we and the partner are struggling, but
when we're trying to answer questions like "Is it possible that this event
flowed through an intermediary iframe that was created and destroyed again
before this line of code executed", it can be tricky.

On Mon, 14 Feb 2022 at 09:27, Mike Taylor  wrote:

> Hi Stephen,
>
> Is there anything we can learn about their 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
> engaged in helping them we haven't made much progress yet.
>
> As such, I'm currently requesting that we delay this deprecation *until
> M102*, 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 determined that the remaining uses *do* 
>> necessitate
>> making Capability Delegation available for web developers (see our Intent
>> to Experiment
>> <https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/i6pAWsjU7zg/m/CzqgcGAXAwAJ>
>>  -
>> unfortunately our partner didn't engage at that time or we would have
>> caught this earlier :(. )
>>
>> We expect an Intent to Ship to be sent for Capability Delegation 'soon',
>> targeting M100, and so are planning to push this deprecation out to M100 as
>> well to align with that.
>>
>> Thanks,
>> Stephen
>> On Wednesday, December 1, 2021 at 3:25:01 PM UTC-5 Mike Taylor wrote:
>>
>>> LGTM3
>>>
>>> On 12/1/21 12:34 PM, Chris Harrelson wrote:
>>>
>>> LGTM2
>>>
>>> On Wed, Dec 1, 2021 at 9:33 AM Yoav Weiss 
>>> wrote:
>>>
>>>> LGTM1 to deprecate in M98 and remove in M99, assuming no surprises come
>>>> up on the usage front.
>>>>
>>>> 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 the removal till they have, and
>>>>> 2. Don't need to provide an alternative in the form of capability
>>>>> delegation.
>>>>>
>>>>> But the code change to at least start this deprecation would have to
>>>>> land by December 9th (or we punt for 1.5 months), hence why we're filing
>>>>> this ahead of them fixing their site :).
>>>>>
>>>>> On Wed, 1 Dec 2021 at 12:22, Stephen Mcgruer 
>>>>> wrote:
>>>>>
>>>>>> > Does the primary remaining site have fallback code, or will it be
>>>>>> broken?
>>>>>>
>>>>>> Yes and no :). It doesn't have automatic fallback for the specific
>>>>>> payment method the user has selected (Google Pay), but the user could 
>>>>>> then
>>>>>> select one of the other payment methods that the site supports (either a
>>>>>> credit card flow or I think PayPal IIRC).
>>>>>>
>>>>>> On Wed, 1 Dec 2021

Re: [blink-dev] Intent to Deprecate and Remove: Calling PaymentRequest.show without user activation

[Stephen Mcgruer]

Thanks folks for all the discussion here. We're close to branch point so I
wanted to check - do I need, and may have I have, the third LGTM for a
delay to M102?

On Tue, 15 Feb 2022 at 13:21, Domenic Denicola  wrote:

>
>
> On Tue, Feb 15, 2022 at 11:38 AM 'Mustaq Ahmed' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>>
>>
>> On Tue, Feb 15, 2022 at 11:16 AM Chris Harrelson 
>> wrote:
>>
>>> LGTM2 for the extension to 102, but comments below. It would be very
>>> good to make progress on landing additional spec pieces.
>>>
>>> On Tue, Feb 15, 2022 at 8:09 AM 'Mustaq Ahmed' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
>>>> I think [1] would be useful for developers but I see two blockers here:
>>>> first we need to land the Capability Delegation patch
>>>> <https://wicg.github.io/capability-delegation/spec.html#monkey-patch-to-html-tracking-delegation>
>>>> in HTML  spec as a "reference point" for this idea, then the PR for
>>>> navigator.userActivation <https://github.com/whatwg/html/pull/4009>
>>>> needs to land too.
>>>>
>>>
>>> Hi Mustaq,
>>>
>>> Is there anything blocking integrating the delegation patch into the
>>> HTML spec, and landing the PR for userActivation? There seems to be
>>> implementer interest from at least Gecko.
>>>
>>
>> - For the Capability Delegation patch
>> <https://wicg.github.io/capability-delegation/spec.html#monkey-patch-to-html-tracking-delegation>,
>> yes we are already working with Gecko and will start working on an HTML PR
>> soon (see its intent
>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/PHT_2X7oRBE/m/gR9UiZxBAQAJ>
>>  thread).
>> - The PR for navigator.userActivation
>> <https://github.com/whatwg/html/pull/4009> still "needs implementer
>> interest" I think, cc-ing dtapuska@ if I missed something.  (Note that
>> this is separate from the "user activation v2" model which is already
>> spec-ed
>> <https://html.spec.whatwg.org/multipage/interaction.html#tracking-user-activation>
>> .)
>>
>
> At the last HTML triage meeting
> <https://github.com/whatwg/html/issues/7488#issuecomment-1029510684> we
> got multi-implementer interest and agreement on navigator.userActivation.
> We still weren't clear on the use cases for the postMessage() parts of that
> PR. So, 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:
>>>>
>>>>> Thanks for the thoughtful answers!
>>>>>
>>>>> LGTM1. I'll trust you to file bugs / feature requests for those 3
>>>>> items (and yeah, 3 sounds like a useful, but hard problem to solve).
>>>>>
>>>>> On 2/14/22 9:44 AM, Stephen Mcgruer wrote:
>>>>>
>>>>> > Is there anything we can learn about their challenges that might
>>>>> apply to the broader ecosystem?
>>>>>
>>>>> A little, though largely it appears to be a bug in either
>>>>> their application or in Chrome (we're still trying to figure out which!).
>>>>> Simplifying, the problem is that they seem to be losing the Capability
>>>>> Delegation between click and (in a different iframe) the call to 
>>>>> PR.show(),
>>>>> and it's quite tricky to debug this in a large async application. I can
>>>>> think of a few things that might help:
>>>>>
>>>>> 1. Adding capability delegation support to navigator.userActivation
>>>>> <https://github.com/dtapuska/useractivation> would likely be useful,
>>>>> e.g. exposing an array of capabilities currently active. This would make 
>>>>> it
>>>>> much easier to quickly debug 'do I have a CD right here'. I hope the
>>>>> Capability Delegation folks might consider adding this! :)
>>>>> 2. Pausing user activation timeout when code execution in devtools is
>>>>> paused would be useful.
>>>>> 3. More generally (and more hand-wavingly), being able to more easily
>>>>> trace flows through async iframes 'somehow'. Devtools has some support for
>>>>> this, and it might just 

[blink-dev] Intent to Prototype: Secure Payment Confirmation - Opt-Out Support

[Stephen Mcgruer]

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 SPC UXes will render an 'opt-out' link of some sort
that the user can interact with to indicate to the RP that they wish to be
opted out.


Note: This work is *very experimental*, and this I2P should not be taken as
a sign of anything other than we are experimenting with this proposal.
Blink componentBlink>Payments


Motivation

In certain regions and situations, developers interacting with Secure
Payment Confirmation may need to offer an opt-out experience - in which the
user can indicate that they want their information removed from the
developers server. Traditionally access to the opt-out experience is
embedded directly into the Relying Party's website. However in the case of
SPC the Relying Party may not be part of the web content flow, as the
authentication may be initiated from a third-party website (e.g., a
merchant site). In order to support these needs for an opt-out flow, we are
experimenting with direct support for opt-out in the SPC browser UX. (Note
that Chrome-stored information is NOT in scope here).

Initial public proposal
https://github.com/w3c/secure-payment-confirmation/issues/172

TAG review
TAG review statusNot applicable

Risks

Interoperability and CompatibilityGecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

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?

No


Debuggability

Normal devtools javascript debugging capabilities should suffice.

Is this feature fully tested by web-platform-tests

?Not at this time.

Flag name
SecurePaymentConfirmationOptOut (expected, not yet landed)

Requires code in //chrome?True

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1325854

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5133415903920128

This intent message was generated by Chrome Platform Status
.

-- 
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/CADY3MaeKbgWe%3DJV%2Bo7_MkYFdjduVxNUshLPd_iuqtSKtZ3xLzg%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: Secure Payment Confirmation - Opt-Out Support

[Stephen McGruer]

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 

 
is that "An initial origin trial for a feature may only run for 6 
milestones of Chromium", we would like to use the full 6 milestones allowed 
to give partners the most flexibility.

I am assuming I need one (re)LGTM for this change, please :)

Thanks,
Stephen

On Monday, June 6, 2022 at 11:09:18 AM UTC-4 Mike Taylor wrote:

> LGTM to experiment from M104 to M106.
>
> On 6/6/22 11:07 AM, Rouslan Solomakhin wrote:
>
> *Contact emails*
> smcgr...@chromium.org, rous...@chromium.org
>
> *Explainer*
> https://github.com/w3c/secure-payment-confirmation/issues/172
>
> *Specification*
> https://w3c.github.io/secure-payment-confirmation
>
> *Summary*
> Adds an 'opt-out' flow to Secure Payment Confirmation. When the (optional) 
> input flag is set, the SPC UXes will render an 'opt-out' link of some sort 
> that the user can interact with to indicate to the relying party that they 
> wish to be opted out.
>
> *Blink component*
> Blink>Payments
>
> *TAG review status*
> Not applicable
>
>
> *Risks *
>
>
> *Interoperability and Compatibility **Gecko*: No signal
> *WebKit*: No signal
> *Web developers*: Positive. The feature is proposed by web developers 
> .
>
>
>
> * Ergonomics *SPC feature is a combination of WebAuthn and PaymentRequest 
> APIs.
>
>
> * Activation *To take advantage of this feature, developers have to 
> specify a new optional API parameter `showOptOut: true`.
>
>
> * Debuggability*
> Normal devtools javascript debugging capabilities should suffice.
>
> *Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)?*
> No. SPC is currently launched only on Mac and Windows. This opt-out 
> feature also exists only on Mac and Windows.
>
> *Is this feature fully tested by web-platform-tests?*
> No
>
> *Flag name*
> --enable-blink-features=SecurePaymentConfirmationOptOut
>
> *Requires code in //chrome?*
> True
>
> *Tracking bug*
> https://crbug.com/1325854
>
> *Launch bug*
> https://crbug.com/1329512
>
> *Estimated milestones*
> OriginTrial desktop last106
> OriginTrial desktop first104
> DevTrial on desktop104
>
> *Link to entry on the Chrome Platform Status*
> https://chromestatus.com/feature/5133415903920128
>
> *Links to previous Intent discussions*
> Intent to prototype 
> 
> .
>
> This intent message was generated by Chrome Platform Status 
> .
>
> -- 
> 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/CAMMzaWHTs2nBYT7bFKEd%2BtLvFvyzrunzq7bD6%3DXJtwWpb8J2%2BA%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ba22a117-01ba-468e-915a-c51eaa2219ecn%40chromium.org.

Re: [blink-dev] Intent to Deprecate and Remove: PaymentInstruments

[Stephen Mcgruer]

(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 reporting, but I am happy to
> adjust our plans if necessary. What would you recommend?
>
> On Wed, Sep 21, 2022 at 1:42 AM Yoav Weiss  wrote:
>
>> What did you have in mind in terms of a deprecation timeline? Are you
>> planning to pipe that through CountDeprecation
>> 
>>  to
>> ensure deprecation reporting?
>>
>> On Tue, Sep 20, 2022 at 4:26 PM Rouslan Solomakhin 
>> wrote:
>>
>>> > Would we expect those uses to break? Are they feature detecting the
>>> API before using it?
>>>
>>> Partially (for both questions!). In examining the site logic we have
>>> found that:
>>>
>>> Good news:
>>>
>>>1. These websites will correctly fall back to JIT install of payment
>>>handlers in the absence of PaymentInstruments. That does not use the
>>>PaymentInstruments API and will continue to work as before.
>>>2. The websites are feature-detecting the parent PaymentManager
>>>interface, registration.paymentManager, which is currently
>>>implemented only in Blink.
>>>
>>> Bad news:
>>>
>>>1. Once the websites detect the presence of
>>>registration.paymentManager, they assume that it has all of the
>>>fields present, including registration.paymentManager.instruments.
>>>If we remove this instruments field, then there will be some
>>>JavaScript errors on these websites. As far as we can tell, these errors
>>>are limited in impact and do not affect overall site functionality.
>>>
>>>
>>> On Tue, Sep 20, 2022 at 5:20 AM Yoav Weiss 
>>> wrote:
>>>


 On Thu, Sep 15, 2022 at 9:03 PM Rouslan Solomakhin <
 rous...@chromium.org> wrote:

> Hi Mike,
>
> >  do we have any reason to believe there are consumers of this API
> who have disabled telemetry, i.e. maybe in enterprise contexts?
>
> We don't have any indications that this could be happening.
>
> > do we know how these few sites who are using the API... are using
> the API? Does any real-world usage show up in HTTP Archive?
>
> Found 2 websites in HTTP Archive:
>
>1. A payment app website that also uses a JIT install for payment
>handlers.
>2. A payment app website that installs a payment handler when you
>visit their home page, but the code looks more like a demo because of
>hard-coded strings.
>
> Would we expect those uses to break? Are they feature detecting the
 API before using it?


> Happy to discuss further.
>
> Cheers,
> Rouslan
>
> On Wed, Sep 14, 2022 at 12:23 PM Mike Taylor 
> wrote:
>
>> Hi Rouslan,
>>
>> Usage is indeed low - do we have any reason to believe there are
>> consumers of this API who have disabled telemetry, i.e. maybe in 
>> enterprise
>> contexts? And do we know how these few sites who are using the API... are
>> using the API? Does any real-world usage show up in HTTP Archive?
>>
>> thanks,
>> Mike
>>
>> On 9/14/22 8:55 AM, Chris Harrelson wrote:
>>
>> LGTM1
>>
>> On Wed, Sep 14, 2022 at 8:05 AM Rouslan Solomakhin <
>> rous...@chromium.org> wrote:
>>
>>> Contact emails rous...@chromium.org, smcgr...@chromium.org
>>>
>>> Summary
>>>
>>> PaymentInstruments
>>> 
>>> is the Web API that backs non-JIT install of payment apps (see
>>> https://w3c.github.io/payment-handler/). It was designed with the
>>> assumption that the browser would store the actual payment instrument
>>> details, which has not turned out to be true, and has some privacy 
>>> leaks.
>>> It also has not shipped on any other browser, not have we seen any 
>>> interest
>>> from other browser vendors. As such, we are interested in deprecating 
>>> and
>>> removing the API.
>>>
>>> Blink component Blink>Payments
>>> 
>>>
>>> Motivation
>>>
>>> The PaymentInstruments.set() method allows an attacker website to
>>> store arbitrary data, which can later be retrieved via
>>> PaymentInstruments.get() potentially in a third-party context. For 
>>> example,
>>> the user visits https://tracker.example, which generates and stores
>>> a UUID for that user via PaymentInstruments.set(key, UUID). Later, the 
>>> user
>>> visits https://site.example, which opens an iframe for
>>> https://tracker.example. That iframe calls

Re: [blink-dev] Intent to Experiment: Web Payment API - connect-src CSP policy

[Stephen Mcgruer]

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 if
necessary for anyone to opt out for a few milestones.

Thoughts Yoav?

On Wed, Sept 21, 2022, 9:06 a.m. Rouslan Solomakhin 
wrote:

> > So is the plan to get properties currently using PaymentHandler to
> experiment with this and see if there's breakage?
>
> Yes, that's the plan.
>
> > Should we initially ship a "report only" mode that would help all
> properties know that CSP errors may be happening soon?
>
> Yes, we certainly could do that, if that's your recommendation.
> Assuming that does not require a Blink intent, we can start doing that in
> M108. Should we run the opt-in OT for enforcing CSP in M 110--112 in that
> case?
>
> On Wed, Sep 21, 2022 at 1:30 AM Yoav Weiss  wrote:
>
>> So is the plan to get properties currently using PaymentHandler to
>> experiment with this and see if there's breakage? Should we initially ship
>> a "report only" mode that would help all properties know that CSP errors
>> may be happening soon?
>>
>> On Tue, Sep 20, 2022 at 6:20 PM Rouslan Solomakhin 
>> wrote:
>>
>>> Contact emailssmcgr...@chromium.org, rous...@chromium.org
>>>
>>> Specification
>>> https://www.w3.org/TR/payment-method-manifest/#processing-model
>>>
>>> Summary
>>>
>>> Deprecate the ability for Web Payment API to bypass the connect-src CSP
>>> policy when fetching the manifest. After this deprecation, a site's
>>> connect-src CSP policy will need to allow for the payment method URL
>>> specified in a PaymentRequest call, as well as any other URLs that the
>>> method chains to fetch its manifest.
>>>
>>> Blink componentBlink>Payments
>>> 
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>> Interoperability and Compatibility*Gecko*: N/A. Does not currently
>>> implement or ship PaymentHandler.
>>> *WebKit*: N/A. Does not currently implement or ship PaymentHandler.
>>> *Web developers*: No signals
>>>
>>> WebView application risks
>>>
>>> None: PaymentHanlders are not supported in WebView.
>>>
>>> Debuggability
>>>
>>> CSP violations print console error messages.
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?No. PaymentHandlers are
>>> not supported on WebView.
>>>
>>> Is this feature fully tested by web-platform-tests?No
>>>
>>> Flag name#web-payment-api-csp
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://crbug.com/1349091
>>>
>>> Launch bughttps://crbug.com/1349093
>>>
>>> Estimated milestones
>>> Origin Trial first: 108
>>> Origin Trial last: 110
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/6286595631087616
>>>
>>> Links to previous Intent discussionsIntent to prototype
>>> 
>>> .
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>>
>>> --
>>> 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/CAMMzaWFUbSFNuCbyefZKuSDmFtOd%3DD5xsOpVE0p6pwoxVPgRog%40mail.gmail.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.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWFXYXBqDjBzC8RnjUmNXQ8apiBAHdAGMV16Pq0F%2BbV-Mg%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MacR62b90CCV2xBru_ZEP0P7Wjf4EqAdfcX_AZKXj%3D8UDg%40mail.gmail.com.

Re: [blink-dev] Intent to experiment: Deprecate and remove merchant identity in "canmakepayment"

[Stephen McGruer]

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 milestones*
> Origin trial: 108
> Reverse origin trial: 111
> Removal: 114

This was a misunderstanding over what Removal meant. We thought "Reverse 
origin trial" implied that the feature would be disabled by default in 
M111, with a reverse-OT to re-enable it if needed, and then Removal was 
when the feature was completely off with no way to re-enable. However based 
on Yoav's comments above, we think API Owners may have thought that we were 
not intending to disable this feature until M114.

So we are explicitly seeking approval to *Remove this API in M111*, 
alongside starting a reverse Origin Trial to guard against developers being 
caught by surprise. To the best of our knowledge this reverse Origin Trial 
will probably be unnecessary, as all known payment partners using 
PaymentHandler do not utilize these fields, however we are including it as 
a safe-guard.

No developer signed up to the current Origin Trial, unfortunately (possibly 
because there is no impact), so we have no data from that.

Please let us know if we should send a separate Intent to Remove thread 
instead, happy to do so.

Thanks,
Stephen

On Tuesday, October 11, 2022 at 11:00:31 AM UTC-4 Rouslan Solomakhin wrote:

> Hello,
>
> FYI, we are renaming the flag and reversing its meaning to make the Origin 
> Trial framework work.
>
>- Dev Trial: *chrome://flags/#identity-in-can-make-payment *- enabled 
>by default. Disabling this flag would remove the fields from the 
>"canmakepayment" event.
>- Origin Trial: *chrome://flags/#clear-identity-in-can-make-payment* - 
>disabled by default. Enabling this flag will remove fields from the 
>"canmakepayment" event.
>
> This change is necessary because Origin Trials can only enable runtime 
> flags, not disable them. So, a flag must be default-disabled to be 
> togglable by an Origin Trial. More information is available in Proposal 
> to Fix the CanMakePayment Identity OT 
> .
>  
> This has also been discussed on blink-reviews-bindings@ 
> 
> .
>
> If you are feature-detecting the presence of the fields in the event, the 
> most reliable way is:
>   if (event.topOrigin) {}
>   if (event.paymentRequestOrigin) {}
>   if (evt.methodData && evt.methodData.length > 0) {}
>   if (evt.modifiers && evt.modifiers.length > 0) {}
>
> Cheers,
> Rouslan
>
> On Tuesday, September 20, 2022 at 11:06:03 AM UTC-4 Rouslan Solomakhin 
> wrote:
>
>> > Chrome is reaching out to the known partners that may be depending on 
>> these fields.
>>
>> We have reached out to the known partners with dev-trial instructions and 
>> received back feedback that this change does not affect their API usage.
>>
>> > Estimated milestones
>> > Origin trial: 108
>> > LGTM to run Origin Trial removal 108-110
>>
>> M108 is upon us. We intend to start the origin trial shortly.
>>
>> On Wednesday, April 20, 2022 at 12:03:22 PM UTC-4 Yoav Weiss wrote:
>>
>>> LGTM to run Origin Trial removal 108-110
>>>
>>> On Wednesday, April 20, 2022 at 4:27:10 PM UTC+2 Rouslan Solomakhin 
>>> wrote:
>>>
 > So this intent is requesting to run the first OT M108-M110?

 Correct.

 > Any deprecation period you have in mind?

 Good point. We should start by printing a warning message when these 
 fields are accessed for a few milestones. M105--M107 would be good. Do I 
 need to resend this as an intent to deprecate first?

>>>
>>> LGTM to deprecate as well. From my perspective, you could start 
>>> deprecating earlier than 105, assuming we know the timelines we're aiming 
>>> for.
>>>  
>>>

 On Wed, Apr 20, 2022 at 9:24 AM Yoav Weiss  
 wrote:

> So this intent is requesting to run the first OT M108-M110?
> Any deprecation period you have in mind?
>
> It might be better to send separate intents for the rest when their 
> milestones get closer. 
>
> On Mon, Apr 18, 2022 at 5:49 PM 'Rouslan Solomakhin' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailsrous...@chromium.org
>>
>> Specificationhttps://w3c.github.io/payment-handler/
>>
>> Summary
>>
>> This is an early heads up that we intend to remove the merchant 
>> origin and arbitrary data from the "canmakepayment" service worker 
>> event of the Payment Handler API. These are the event fields to be 
>> removed:
>>
>>
>>- topOrigin
>>- paymentReuqestOrigin
>>- methodData
>>- modifiers
>>
>> The removal will be happening th

Re: [blink-dev] Intent to experiment: Deprecate and remove merchant identity in "canmakepayment"

[Stephen Mcgruer]

> please update the chromestatus entry to indicate the "shipping" stage.

Done, thanks. This also made us realize we hadn't actually published the
spec change (!); that is now up for review
<https://github.com/w3c/payment-handler/pull/404> and we are working on
associated WPT test 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 AM Stephen McGruer 
> wrote:
>
>> 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 milestones*
>> > Origin trial: 108
>> > Reverse origin trial: 111
>> > Removal: 114
>>
>> This was a misunderstanding over what Removal meant. We thought "Reverse
>> origin trial" implied that the feature would be disabled by default in
>> M111, with a reverse-OT to re-enable it if needed, and then Removal was
>> when the feature was completely off with no way to re-enable. However based
>> on Yoav's comments above, we think API Owners may have thought that we were
>> not intending to disable this feature until M114.
>>
>> So we are explicitly seeking approval to *Remove this API in M111*,
>> alongside starting a reverse Origin Trial to guard against developers being
>> caught by surprise. To the best of our knowledge this reverse Origin Trial
>> will probably be unnecessary, as all known payment partners using
>> PaymentHandler do not utilize these fields, however we are including it as
>> a safe-guard.
>>
>> No developer signed up to the current Origin Trial, unfortunately
>> (possibly because there is no impact), so we have no data from that.
>>
>> Please let us know if we should send a separate Intent to Remove thread
>> instead, happy to do so.
>>
>> Thanks,
>> Stephen
>>
>> On Tuesday, October 11, 2022 at 11:00:31 AM UTC-4 Rouslan Solomakhin
>> wrote:
>>
>>> Hello,
>>>
>>> FYI, we are renaming the flag and reversing its meaning to make the
>>> Origin Trial framework work.
>>>
>>>- Dev Trial: *chrome://flags/#identity-in-can-make-payment *-
>>>enabled by default. Disabling this flag would remove the fields from the
>>>"canmakepayment" event.
>>>- Origin Trial: *chrome://flags/#clear-identity-in-can-make-payment* -
>>>disabled by default. Enabling this flag will remove fields from the
>>>"canmakepayment" event.
>>>
>>> This change is necessary because Origin Trials can only enable runtime
>>> flags, not disable them. So, a flag must be default-disabled to be
>>> togglable by an Origin Trial. More information is available in Proposal
>>> to Fix the CanMakePayment Identity OT
>>> <https://docs.google.com/document/d/1ItfkdtzDfZZfnuWHqwS9XSqexNQLsuN_4M_9PQZjQXE/edit?usp=sharing>.
>>> This has also been discussed on blink-reviews-bindings@
>>> <https://groups.google.com/u/1/a/chromium.org/g/blink-reviews-bindings/c/MQkhAEiivNs>
>>> .
>>>
>>> If you are feature-detecting the presence of the fields in the event,
>>> the most reliable way is:
>>>   if (event.topOrigin) {}
>>>   if (event.paymentRequestOrigin) {}
>>>   if (evt.methodData && evt.methodData.length > 0) {}
>>>   if (evt.modifiers && evt.modifiers.length > 0) {}
>>>
>>> Cheers,
>>> Rouslan
>>>
>>> On Tuesday, September 20, 2022 at 11:06:03 AM UTC-4 Rouslan Solomakhin
>>> wrote:
>>>
>>>> > Chrome is reaching out to the known partners that may be depending on
>>>> these fields.
>>>>
>>>> We have reached out to the known partners with dev-trial instructions
>>>> and received back feedback that this change does not affect their API 
>>>> usage.
>>>>
>>>> > Estimated milestones
>>>> > Origin trial: 108
>>>> > LGTM to run Origin Trial removal 108-110
>>>>
>>>> M108 is upon us. We intend to start the origin trial shortly.
>>>>
>>>> On Wednesday, April 20, 2022 at 12:03:22 PM UTC-4 Yoav Weiss wrote:
&g

[blink-dev] Intent to Deprecate and Remove: Secure Payment Confirmation: Rename rp --> rpId in CollectedClientAdditionalPaymentData

[Stephen Mcgruer]

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 builds on top of WebAuthn
to bring strong authentication to payment flows. In the initial spec and
implementation of SPC, the output CollectedClientAdditionalPaymentData
dictionary[0] of the cryptogram contained a parameter named 'rp'. This was
renamed in the specification[1] to 'rpId' to align with WebAuthn, and
Chrome is changing its implementation to match (that is, adding 'rpId' and
removing 'rp'). [0]:
https://w3c.github.io/secure-payment-confirmation/#sctn-collectedclientadditionalpaymentdata-dictionary
[1]: https://github.com/w3c/secure-payment-confirmation/pull/198


Blink componentBlink>Payments


Motivation

Secure Payment Confirmation (SPC) is a Web API to support streamlined
authentication during a payment transaction. It builds on top of WebAuthn
to bring strong authentication to payment flows. In the initial spec and
implementation of SPC, the output CollectedClientAdditionalPaymentData
dictionary[0] of the cryptogram contained a parameter named 'rp'. This was
renamed in the specification[1] to 'rpId' to align with WebAuthn, and
Chrome is changing its implementation to match (that is, adding 'rpId' and
removing 'rp'). In M107, we added[2] 'rpId' to
CollectedClientAdditionalPaymentData as an additional, identical field to
'rp'. We will now be removing the old 'rp' parameter. [0]:
https://w3c.github.io/secure-payment-confirmation/#sctn-collectedclientadditionalpaymentdata-dictionary
[1]: https://github.com/w3c/secure-payment-confirmation/pull/198 [2]:
https://chromium.googlesource.com/chromium/src/+/3472ddafd924cbffab61b88746c5fe81e71e26a7


Initial public proposal
https://github.com/w3c/secure-payment-confirmation/issues/191

TAG reviewN/A

TAG review statusN/A

Risks

Interoperability and Compatibility

Compatibility: The main risk is that a developer is still using the 'rp'
parameter (and has not migrated to 'rpId'), and that their
cryptogram-parsing code fails. Notably, we cannot detect this via browser
metrics, as cryptogram-parsing is normally done server-side (i.e. the
client just sends the received cryptogram up to a server). This also means
that we cannot do e.g., a devtool deprecation warning. However, there are
still relatively few users of SPC, and all are active participants in its
development. We have announced this planned rename previously, and will now
announce its deprecation + removal timeline ('deprecate' today, remove in
M113).

*Gecko*: N/A Firefox does not ship SPC

*WebKit*: N/A Safari does not ship SPC

*Web developers*: No signals

*Other signals*:

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?

No - SPC does not ship on WebView.

Debuggability

Developers may inspect the output CollectedClientAdditionalPaymentData
dictionary in devtools if desired.

Is this feature fully tested by web-platform-tests

?Yes, in
https://wpt.fyi/results/secure-payment-confirmation/authentication-accepted.https.html?label=experimental&label=master&aligned
- will need to be updated in M113 to assert that the field is no longer
present.

Flag nameN/A

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1356224

Estimated milestones

Deprecation: 'now' (M110, but impossible to add e.g. deprecation warnings)

Removal: M113

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5203057325899776

This intent message was generated by Chrome Platform Status
, and edited by smcgruer@ by hand.

-- 
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/CADY3MafrN3_3_aV4RZ7YWL8qS2waK1zXbA88b6nncmX3uLHgJQ%40mail.gmail.com.

[blink-dev] Re: Intent to Deprecate and Remove: Secure Payment Confirmation: Rename rp --> rpId in CollectedClientAdditionalPaymentData

[Stephen Mcgruer]

I was asked to clarify the level of compat risk for this change (very
reasonably, I did a poor job in the original email!).

Conceptually, this change is risky as we cannot detect exact usage of
'someone is reading the old "rp" field',
because CollectedClientAdditionalPaymentData is essentially a data blob
returned from Chrome which is usually sent to the website's server backend
and processed there.

However, for SPC we believe there is low enough usage in general and we
have good enough partner relations that we can make sure partners are aware
of and adapt to this change* ahead of the removal. The usecounter
<https://chromestatus.com/metrics/feature/timeline/popularity/3376> for SPC
is at ~0.0005% of page loads, and we have internal metrics with more
details. We know of a short list of partners who are actively experimenting
with SPC 'in the wild'. There is a slightly longer and not fully known list
of partners who may be experimenting with SPC in a dev environment, but we
still expect to be able to inform these partners via the Web Payments WG
and Web Payments SIG where most payment partners interact.

* by using the already existing "rpId" field instead

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 Payment Confirmation (SPC) is a Web API to support streamlined
> authentication during a payment transaction. It builds on top of WebAuthn
> to bring strong authentication to payment flows. In the initial spec and
> implementation of SPC, the output CollectedClientAdditionalPaymentData
> dictionary[0] of the cryptogram contained a parameter named 'rp'. This was
> renamed in the specification[1] to 'rpId' to align with WebAuthn, and
> Chrome is changing its implementation to match (that is, adding 'rpId' and
> removing 'rp'). [0]:
> https://w3c.github.io/secure-payment-confirmation/#sctn-collectedclientadditionalpaymentdata-dictionary
> [1]: https://github.com/w3c/secure-payment-confirmation/pull/198
>
>
> Blink componentBlink>Payments
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments>
>
> Motivation
>
> Secure Payment Confirmation (SPC) is a Web API to support streamlined
> authentication during a payment transaction. It builds on top of WebAuthn
> to bring strong authentication to payment flows. In the initial spec and
> implementation of SPC, the output CollectedClientAdditionalPaymentData
> dictionary[0] of the cryptogram contained a parameter named 'rp'. This was
> renamed in the specification[1] to 'rpId' to align with WebAuthn, and
> Chrome is changing its implementation to match (that is, adding 'rpId' and
> removing 'rp'). In M107, we added[2] 'rpId' to
> CollectedClientAdditionalPaymentData as an additional, identical field to
> 'rp'. We will now be removing the old 'rp' parameter. [0]:
> https://w3c.github.io/secure-payment-confirmation/#sctn-collectedclientadditionalpaymentdata-dictionary
> [1]: https://github.com/w3c/secure-payment-confirmation/pull/198 [2]:
> https://chromium.googlesource.com/chromium/src/+/3472ddafd924cbffab61b88746c5fe81e71e26a7
>
>
> Initial public proposal
> https://github.com/w3c/secure-payment-confirmation/issues/191
>
> TAG reviewN/A
>
> TAG review statusN/A
>
> Risks
>
> Interoperability and Compatibility
>
> Compatibility: The main risk is that a developer is still using the 'rp'
> parameter (and has not migrated to 'rpId'), and that their
> cryptogram-parsing code fails. Notably, we cannot detect this via browser
> metrics, as cryptogram-parsing is normally done server-side (i.e. the
> client just sends the received cryptogram up to a server). This also means
> that we cannot do e.g., a devtool deprecation warning. However, there are
> still relatively few users of SPC, and all are active participants in its
> development. We have announced this planned rename previously, and will now
> announce its deprecation + removal timeline ('deprecate' today, remove in
> M113).
>
> *Gecko*: N/A Firefox does not ship SPC
>
> *WebKit*: N/A Safari does not ship SPC
>
> *Web developers*: No signals
>
> *Other signals*:
>
> 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?
>
> No - SPC does not ship on WebView.
>
> Debuggability
>
> Developers may inspect the output CollectedClientAddit

Re: [blink-dev] Re: Intent to Ship: EyeDropper API

[Stephen McGruer]

> 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 https://github.com/GoogleChrome/chromium-dashboard/issues/1498

On Friday, August 27, 2021 at 9:23:51 AM UTC-4 Yoav Weiss wrote:

> One question that came up (and that should've been included in the 
> template): Will this be supported on all platforms?
>
> On Thursday, August 26, 2021 at 9:08:28 PM UTC+2 Mike West wrote:
>
>> LGTM3. I'm particularly happy with the way this evolved after excellent 
>> feedback from our colleagues in the TAG. Thank you!
>>
>> -mike
>>
>>
>> On Thu, Aug 26, 2021 at 7:04 PM Chris Harrelson  
>> wrote:
>>
>>> LGTM2
>>>
>>> On Thu, Aug 26, 2021 at 1:14 AM Yoav Weiss  
>>> wrote:
>>>
 LGTM1

 This seems like a useful API, that can help users perform creative 
 tasks that are impossible on the web today. (or require the user to jump 
 through hoops)
 Looking forward to this being able to represent the actual colors 
 picked, once a `Color` object becomes a real boy.

 On Friday, August 13, 2021 at 7:04:09 PM UTC+2 Ionel Popescu wrote:

> Contact emails 
>
> iopop...@microsoft.com, pc...@microsoft.com
>
>  
> Explainer 
>
> https://github.com/WICG/eyedropper-api/blob/main/README.md
>
>  
> Specification 
>
> https://wicg.github.io/eyedropper-api/
>
>  
>
> *API spec* 
>
> Yes
>
>  
> Summary 
>
> The EyeDropper API enables developers to use a browser-supplied 
> eyedropper in the construction of custom color pickers.
>
>  
> Blink component 
>
> Blink>Forms 
> 
> >Color
>
>  
> TAG review 
>
> https://github.com/w3ctag/design-reviews/issues/587
>

 Great feedback from the TAG!! Thanks for addressing it. 

>  
> TAG review status 
>
> Issues addressed
>
>  
> Risks   Interoperability and Compatibility 
>
>  
>
> The new API can be feature-detected by checking for the existence of 
> the EyeDropper interface on the window object. On browsers without 
> support, 
> web apps can invoke the full color picker programmatically.
>
>  
>
> Chrome: Public support 
> 
>
>  
>
> Gecko: No signal 
> 
>
>  
>
> WebKit: No signal 
> 
>
>  
>
> Web developers: Positive
>
> · https://github.com/WICG/proposals/issues/35
>
> · https://twitter.com/argyleink/status/1291056673348415489
>
>  
> Debuggability 
>
> No special support is needed.
>
>  
> Is this feature fully tested by web-platform-tests 
> 
> ? 
>
> Yes, to the extent that it can be.
>
>  
> Flag name 
>
> EyeDropperAPI
>
>  
> Tracking bug 
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=897309
>
>  
> Link to entry on the Chrome Platform Status 
>
> https://chromestatus.com/feature/6304275594477568
>
>  
> Links to previous Intent discussions 
>
> Intent to prototype: 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/cPTMI1i6d7I
>
>
>
> This intent message was generated by Chrome Platform Status 
> .
>
 -- 
 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/807e61b9-bedd-4ca0-85be-d6c7daa4fafcn%40chromium.org
  
 
 .

>>> -- 
>>> 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/CAOMQ%2Bw-95m07c-jQx3_iNQrwdbFwPm0RwXVdc80zwRnGvYWg0g%40mail.gmail.com
>>>  
>>> 

[blink-dev] Intent to Ship: Secure Payment Confirmation

[Stephen Mcgruer]

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 authentication experience
on the web with the help of WebAuthn. The feature adds a new 'payment'
extension to WebAuthn, which allows a relying party such as a bank to
create a PublicKeyCredential that can be queried by any merchant origin as
part of an online checkout via the Payment Request API using the
'secure-payment-confirmation payment' method.

Blink componentBlink>Payments


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/544

TAG review statusPending

*Supported on all platforms?*
No.

SPC is launching on MacOS and Windows only initially, as they are platforms
that have built-in authenticators and which payment partners have noted as
important targets.

Android has browser-level support for SPC, but is excluded from the launch
due to the lack of Discoverable Credentials currently. We will add Android
once the platform supports that.

Risks
Interoperability and Compatibility

This feature adds a WebAuthn extension and PaymentRequest payment method
type, so the interop risk is that other browsers do not implement these
types. The feature is detectable (though it could be easier[0]), so it
should be possible for Web Developers to determine if SPC is enabled for a
given user agent visiting their site. There is a risk that the feature will
evolve away from the PaymentRequest API[1], which would then require a
deprecation of the current API entry-point. It is worth noting that
deprecations for payment are often easier than for the general web, as
there are far, far fewer payment developers and websites that accept
payments are almost always kept up to date (or their payment integrations
might break!). [0]:
https://github.com/w3c/secure-payment-confirmation/issues/81#issuecomment-885046226
[1]: https://github.com/w3c/secure-payment-confirmation/issues/65

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/570
)
Historically (>1 year old) positive signal from informal conversation in
W3C Payment Handler meetings. However Firefox have since not been involved
in the API development.

WebKit: No signal (
https://lists.webkit.org/pipermail/webkit-dev/2021-August/031956.html)

Web developers: Positive (
https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0005.html)
Support and involvement in API development from multiple web developers and
payment industry partners. Both Stripe and AirBnB have publicly stated that
they have either completed or are in the process of
prototyping/experimenting with SPC

Debuggability

Existing devtools debugging features should cover SPC (e.g. breakpoints,
console, etc)

Is this feature fully tested by web-platform-tests

?Partially

https://wpt.fyi/results/secure-payment-confirmation?label=master&label=experimental&aligned

The WPT test suite is only partially complete and needs to be extended, but
this first requires building out test automation machinery and
content_shell support. The team is committed to this post initial launch.

Requires code in //chrome?True

Tracking bughttps://crbug.com/1124927

Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1236570#

Estimated milestones
Ship: M95. Note that this is directly after the end of the Origin Trial, so
we are still trying to determine whether we should do the 'week off'
approach or apply for a no-skip transition. For the latter option, I think
we may meet the bar. We've significantly changed the API in both M93 and
M94 during the origin trial, and so M95 for example is not compatible with
someone using code from M93.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5702310124584960

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/topic/blink-dev/myUR5gyd5Js/discussion
Intent to Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/6Dd00NJ-td8


This intent message was generated by Chrome Platform Status
, and then hand-edited.

-- 
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/CADY3Maf_i31Fw0VLVbaLfmvNDS1kqWb-RqbOei_in7O0jXC89Q%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Secure Payment Confirmation

[Stephen Mcgruer]

> This is desktop only, right?

Yep! MacOS + Windows only initially; see the 'Supported on all platforms?'
section for justification.

On Mon, 30 Aug 2021 at 14:22, 'Joe Medley' via blink-dev <
blink-dev@chromium.org> wrote:

> This is desktop only, right?
> Joe Medley | Technical 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...@chromium.org
>>
>> Explainerhttps://github.com/w3c/secure-payment-confirmation
>>
>> Specificationhttps://w3c.github.io/secure-payment-confirmation/
>>
>> Summary
>>
>> Secure payment confirmation augments the payment authentication
>> experience on the web with the help of WebAuthn. The feature adds a new
>> 'payment' extension to WebAuthn, which allows a relying party such as a
>> bank to create a PublicKeyCredential that can be queried by any merchant
>> origin as part of an online checkout via the Payment Request API using the
>> 'secure-payment-confirmation payment' method.
>>
>> Blink componentBlink>Payments
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments>
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/544
>>
>> TAG review statusPending
>>
>> *Supported on all platforms?*
>> No.
>>
>> SPC is launching on MacOS and Windows only initially, as they are
>> platforms that have built-in authenticators and which payment partners have
>> noted as important targets.
>>
>> Android has browser-level support for SPC, but is excluded from the
>> launch due to the lack of Discoverable Credentials currently. We will add
>> Android once the platform supports that.
>>
>> Risks
>> Interoperability and Compatibility
>>
>> This feature adds a WebAuthn extension and PaymentRequest payment method
>> type, so the interop risk is that other browsers do not implement these
>> types. The feature is detectable (though it could be easier[0]), so it
>> should be possible for Web Developers to determine if SPC is enabled for a
>> given user agent visiting their site. There is a risk that the feature will
>> evolve away from the PaymentRequest API[1], which would then require a
>> deprecation of the current API entry-point. It is worth noting that
>> deprecations for payment are often easier than for the general web, as
>> there are far, far fewer payment developers and websites that accept
>> payments are almost always kept up to date (or their payment integrations
>> might break!). [0]:
>> https://github.com/w3c/secure-payment-confirmation/issues/81#issuecomment-885046226
>> [1]: https://github.com/w3c/secure-payment-confirmation/issues/65
>>
>> Gecko: No signal (
>> https://github.com/mozilla/standards-positions/issues/570
>> <https://chromestatus.com/admin/features/launch/5702310124584960/5?intent=1>)
>> Historically (>1 year old) positive signal from informal conversation in
>> W3C Payment Handler meetings. However Firefox have since not been involved
>> in the API development.
>>
>> WebKit: No signal (
>> https://lists.webkit.org/pipermail/webkit-dev/2021-August/031956.html)
>>
>> Web developers: Positive (
>> https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0005.html)
>> Support and involvement in API development from multiple web developers and
>> payment industry partners. Both Stripe and AirBnB have publicly stated that
>> they have either completed or are in the process of
>> prototyping/experimenting with SPC
>>
>> Debuggability
>>
>> Existing devtools debugging features should cover SPC (e.g. breakpoints,
>> console, etc)
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>> ?Partially
>>
>>
>> https://wpt.fyi/results/secure-payment-confirmation?label=master&label=experimental&aligned
>>
>> The WPT test suite is only partially complete and needs to be extended,
>> but this first requires building out test automation machinery and
>> content_shell support. The team is committed to this post initial launch.
>>
>> Requires code in //chrome?True
>>
>> Tracking bughttps://crbug.com/1124927
>>
>> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1236570#
>>

Re: [blink-dev] Intent to Ship: Secure Payment Confirmation

[Stephen Mcgruer]

> and one which impacted
<https://twitter.com/yoavweiss/status/1382050433632456711> me as a user

Oof! Yes, we'd like to help figure out a way to make *that* not happen...

> What would be the timelines for [the commitment to see through the WPT
test suite]?

My team will be working on test automation for SPC in Q4 2021. As the
ex-lead of WPT in Chromium, I am quite insistent that we get it done :D.

 > Any feedback from the Origin Trial?

During the Origin Trial we did iterate on the API shape significantly, but
that more came from discussions in the working group than Origin Trial
participant feedback (who are themselves also in the working group, so some
overlap).

>From our Origin Trial partners, we mostly heard that the overall experience
is working for them and that they're really excited to be able to build
lower-friction authentication solutions in the payments 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 Stephen Mcgruer 
> wrote:
>
>> 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 authentication
>> experience on the web with the help of WebAuthn. The feature adds a new
>> 'payment' extension to WebAuthn, which allows a relying party such as a
>> bank to create a PublicKeyCredential that can be queried by any merchant
>> origin as part of an online checkout via the Payment Request API using the
>> 'secure-payment-confirmation payment' method.
>>
>> Blink componentBlink>Payments
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments>
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/544
>>
>> TAG review statusPending
>>
>> *Supported on all platforms?*
>> No.
>>
>> SPC is launching on MacOS and Windows only initially, as they are
>> platforms that have built-in authenticators and which payment partners have
>> noted as important targets.
>>
>> Android has browser-level support for SPC, but is excluded from the
>> launch due to the lack of Discoverable Credentials currently. We will add
>> Android once the platform supports that.
>>
>> Risks
>> Interoperability and Compatibility
>>
>> This feature adds a WebAuthn extension and PaymentRequest payment method
>> type, so the interop risk is that other browsers do not implement these
>> types. The feature is detectable (though it could be easier[0]), so it
>> should be possible for Web Developers to determine if SPC is enabled for a
>> given user agent visiting their site. There is a risk that the feature will
>> evolve away from the PaymentRequest API[1], which would then require a
>> deprecation of the current API entry-point. It is worth noting that
>> deprecations for payment are often easier than for the general web, as
>> there are far, far fewer payment developers and websites that accept
>> payments are almost always kept up to date (or their payment integrations
>> might break!). [0]:
>> https://github.com/w3c/secure-payment-confirmation/issues/81#issuecomment-885046226
>> [1]: https://github.com/w3c/secure-payment-confirmation/issues/65
>>
>> Gecko: No signal (
>> https://github.com/mozilla/standards-positions/issues/570
>> <https://chromestatus.com/admin/features/launch/5702310124584960/5?intent=1>)
>> Historically (>1 year old) positive signal from informal conversation in
>> W3C Payment Handler meetings. However Firefox have since not been involved
>> in the API development.
>>
>> WebKit: No signal (
>> https://lists.webkit.org/pipermail/webkit-dev/2021-August/031956.html)
>>
>> Web developers: Positive (
>> https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0005.html)
>> Support and involvement in API development from multiple web developers and
>> payment industry partners. Both Stripe and AirBnB have publicly stated that
>> they have either completed or are in the process of
>> prototyping/experimenting with SPC
>>
>> Debuggability
>>
>> Existing devtools debugging features should cover SPC (e.g. breakpoints,
>> console, etc)
>>
>> Is this feature fully tested by web-platform-t