Intent to Ship: Digital Goods API v2.0

[Rouslan Solomakhin]

Contact emails

mgi...@chromium.org, rou...@chromium.org, gle...@chromium.org

Explainer

https://github.com/WICG/digital-goods/blob/main/explainer.md

Spec

https://wicg.github.io/digital-goods/ - Currently being reviewed by a spec mentor, so some details may change (hopefully, only formatting).

Summary

An API for querying and managing digital products to facilitate in-app purchases from web applications, in conjunction with the Payment Request API (which is used to make the actual purchases). The API would be linked to a digital distribution service connected to via the user agent. In Chrome, this is specifically a web API wrapper around the Android Play Billing API.

Origin trial analysis

DGAPI v2.0 is currently in an origin trial with M99 being the last milestone. So far, 40 people have responded to the origin trial survey. Notable data points:

How easy was it to use the feature: 4.1 out of 6.

(0 - extremely difficult … 6 - extremely easy.)

How likely are you to keep using this feature: 5.5 out of 6.

(0 - extremely unlikely … 6 - extremely likely.)

The most common comments were about improving feature documentation and debuggability. That is being tracked in https://github.com/WICG/digital-goods/issues/33.

Blink component

Blink>Payments

Search tags

payments, billing

TAG review

https://github.com/w3ctag/design-reviews/issues/571 TAG recommends making a Chrome-specific API. Other issues addressed.

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Similar to Payment Request: this API is used to talk to specific store backends, and so its usage is tailored to the specific store. The reason it's a proposed web standard is so that the same code (which is specific to one store) is portable across browsers.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/349) Requested 2020-05-27.

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-October/032001.html) Requested 2021-10-08.

Web developers: Positive (https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350).

Other signals: rouslan@ presented DGAPI at 2021 TPAC (meeting notes) and at a recent PWA Dev Sync (meeting notes). Other browser implementers and app stores do not appear to have immediate plans to engage with DGAPI. There were some questions, no objections.

Ergonomics

Digital Goods API is used in tandem with the Payment Request API.

In order for another browser to implement Digital Goods API for Play Billing in the same way as Chrome, they would need to implement something like the Trusted Web Activity (TWA) feature and then invoke the TWA shell methods for communicating with Play Billing. The android-browser-helper is a TWA template code that we have been recommending app developers to use for the Play Billing integration.

Debuggability

We have had several requests from developers to make the API easier to debug, but it is difficult due to the interaction with a backing service based in an app/store context. We are looking for suggestions (https://github.com/WICG/digital-goods/issues/33) on how we might improve the debuggability of the API.

Is this feature fully tested by web-platform-tests?

The tests are in //third_party/blink/web_tests/wpt_internal/digital-goods.

Flag name

DigitalGoods

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1248319

Launch bug

https://crbug.com/1250123 - There are no code changes from the current origin trial to what we intend to ship to stable. Therefore, there is no new tracking bug or launch bug being filed.

Estimated milestones

Origin trial end: 99

Ship to stable begin: 100

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5339955595313152

Links to previous Intent discussions

Intent to prototype 1.0:

https://groups.google.com/a/chromium.org/g/blink-dev/c/vkS3k30lWNs.

Intent to experiment 1.0:

https://groups.google.com/a/chromium.org/g/blink-dev/c/syI9_M9dANY/m/3lt-QGMHAgAJ.

Intent to continue experimenting 1.0:

https://groups.google.com/a/chromium.org/g/blink-dev/c/uoTx_cRuL5o.

Intent to experiment 2.0:

https://groups.google.com/a/chromium.org/g/blink-dev/c/wIYqo3F_Vmo/m/uKw6hDa8BgAJ.

[Chris Harrelson]

LGTM1

I think these could move to WPT proper with .tentative file names?

 

Flag name

DigitalGoods

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1248319

Launch bug

https://crbug.com/1250123 - There are no code changes from the current origin trial to what we intend to ship to stable. Therefore, there is no new tracking bug or launch bug being filed.

Estimated milestones

Origin trial end: 99

Ship to stable begin: 100

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5339955595313152

Links to previous Intent discussions

Intent to prototype 1.0:

https://groups.google.com/a/chromium.org/g/blink-dev/c/vkS3k30lWNs.

Intent to experiment 1.0:

https://groups.google.com/a/chromium.org/g/blink-dev/c/syI9_M9dANY/m/3lt-QGMHAgAJ.

Intent to continue experimenting 1.0:

https://groups.google.com/a/chromium.org/g/blink-dev/c/uoTx_cRuL5o.

Intent to experiment 2.0:

https://groups.google.com/a/chromium.org/g/blink-dev/c/wIYqo3F_Vmo/m/uKw6hDa8BgAJ.

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWEND_DnBLvCqrtiRoXzxgUrRzC0i%2Bs55Jxa439yui0xFw%40mail.gmail.com.

[Yoav Weiss]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw835Xd4N%2BhdqG6e-U0U8O39rHPrmDKncRQNn9bGeET8nQ%40mail.gmail.com.

[Manuel Rego Casasnovas]

TAG suggested back in July that this API something specific to Chrome or
Google Play Store. It looks like this hasn't been done, any good reason
to not doing that?

Also there's been an update on the TAG about the plan of shipping this
API without changing the name. But that was just 1 week ago, should we
give them some time to reply before shipping?

Cheers,
Rego

On 01/02/2022 20:41, Yoav Weiss wrote:
> LGTM2
>
> On Tue, Feb 1, 2022 at 8:00 PM Chris Harrelson <chri...@chromium.org
> <mailto:chri...@chromium.org>> wrote:
>
>
> LGTM1
>
> On Tue, Feb 1, 2022 at 6:16 AM Rouslan Solomakhin

> <rou...@chromium.org <mailto:rou...@chromium.org>> wrote:
>
> Contact emails
>
> mgi...@chromium.org <mailto:mgi...@chromium.org>,
> rou...@chromium.org <mailto:rou...@chromium.org>,
> gle...@chromium.org <mailto:gle...@chromium.org>
>
>
> Explainer
>
> https://github.com/WICG/digital-goods/blob/main/explainer.md

> <https://github.com/WICG/digital-goods/blob/main/explainer.md>
>
>
> Spec
>
> https://wicg.github.io/digital-goods/
> <https://wicg.github.io/digital-goods/>- Currently being
> reviewed by a spec mentor, so some details may change
> (hopefully, only formatting).
>
>
> Summary
>
> An API for querying and managing digital products to facilitate
> in-app purchases from web applications, in conjunction with the
> Payment Request API (which is used to make the actual
> purchases). The API would be linked to a digital distribution
> service connected to via the user agent. In Chrome, this is
> specifically a web API wrapper around the Android Play Billing API.
>
>
> Origin trial analysis
>
> DGAPI v2.0 is currently in an origin trial with M99 being the
> last milestone. So far, 40 people have responded to the origin
> trial survey. Notable data points:
>
>
> How easy was it to use the feature:4.1 out of 6.
>
> (0 - extremely difficult … 6 - extremely easy.)
>
>
> How likely are you to keep using this feature:5.5 out of 6.
>
> (0 - extremely unlikely … 6 - extremely likely.)
>
>
> The most common comments were about improving feature
> documentation and debuggability. That is being tracked in
> https://github.com/WICG/digital-goods/issues/33

> <https://github.com/WICG/digital-goods/issues/33>.
>
>
> Blink component
>
> Blink>Payments
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments>
>
>
> Search tags
>
> payments <https://chromestatus.com/features#tags:payments>,
> billing <https://chromestatus.com/features#tags:billing>

>
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/571
> <https://github.com/w3ctag/design-reviews/issues/571>TAG
> recommends making a Chrome-specific API. Other issues addressed.
>
>
> TAG review status
>
> Issues addressed
>
>
> Risks
>
> Interoperability and Compatibility
>
> Similar to Payment Request: this API is used to talk to specific
> store backends, and so its usage is tailored to the specific
> store. The reason it's a proposed web standard is so that the
> same code (which is specific to one store) is portable across
> browsers.
>
>
> Gecko: No signal
> (https://github.com/mozilla/standards-positions/issues/349

> <https://github.com/mozilla/standards-positions/issues/349>)

> Requested 2020-05-27.
>
>
> WebKit: No signal
> (https://lists.webkit.org/pipermail/webkit-dev/2021-October/032001.html

> <https://lists.webkit.org/pipermail/webkit-dev/2021-October/032001.html>)

> Requested 2021-10-08.
>
>
> Web developers: Positive
> (https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350

> <https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350>).

>
>
> Other signals: rouslan@ presented DGAPI at 2021 TPAC

> <https://www.w3.org/2021/Talks/rouslan-dgapi-20211028.pdf>(meeting
> notes <https://www.w3.org/2021/10/28-wpwg-minutes.html#t04>) and

> at a recent PWA Dev Sync

> <https://drive.google.com/file/d/1a_6_QVEQrEeUduc8nPE-uc7PKCr-Yhx7/view>(meeting
> notes
> <https://docs.google.com/document/d/1X2j1wKC2T4RONcUGYxGus8Dytv6s2_tVTUSkWDWPza4/edit#heading=h.chc35okxwb9>).

> Other browser implementers and app stores do not appear to have
> immediate plans to engage with DGAPI. There were some questions,
> no objections.
>
>
> Ergonomics
>
> Digital Goods API is used in tandem with the Payment Request API.
>
>
> In order for another browser to implement Digital Goods API for
> Play Billing in the same way as Chrome, they would need to
> implement something like the Trusted Web Activity

> <https://developer.chrome.com/docs/android/trusted-web-activity/>(TWA)

> feature and then invoke the TWA shell methods for communicating
> with Play Billing. The android-browser-helper

> <https://github.com/GoogleChrome/android-browser-helper>is a TWA

> template code that we have been recommending app developers to
> use for the Play Billing integration.
>
>
>
> Debuggability
>
> We have had several requests from developers to make the API
> easier to debug, but it is difficult due to the interaction with
> a backing service based in an app/store context. We are looking
> for suggestions (https://github.com/WICG/digital-goods/issues/33

> <https://github.com/WICG/digital-goods/issues/33>) on how we

> might improve the debuggability of the API.
>
>
> Is this feature fully tested by web-platform-tests

> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?

>
> The tests are in
> //third_party/blink/web_tests/wpt_internal/digital-goods.
>
>
> I think these could move to WPT proper with .tentative file names?
>  
>
>
> Flag name
>
> DigitalGoods
>
>
> Requires code in //chrome?
>
> False
>
>
> Tracking bug
>

> https://crbug.com/1248319 <https://crbug.com/1248319>
>
>
> Launch bug
>
> https://crbug.com/1250123 <https://crbug.com/1250123> - There

> are no code changes from the current origin trial to what we
> intend to ship to stable. Therefore, there is no new tracking
> bug or launch bug being filed.
>
>
> Estimated milestones
>
> Origin trial end: 99
>
> Ship to stable begin: 100
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5339955595313152
> <https://chromestatus.com/feature/5339955595313152>
>
>
> Links to previous Intent discussions
>
> Intent to prototype 1.0:
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/vkS3k30lWNs

> <https://groups.google.com/a/chromium.org/g/blink-dev/c/vkS3k30lWNs>.

>
> Intent to experiment 1.0:
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/syI9_M9dANY/m/3lt-QGMHAgAJ

> <https://groups.google.com/a/chromium.org/g/blink-dev/c/syI9_M9dANY/m/3lt-QGMHAgAJ>.

>
> Intent to continue experimenting 1.0:
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/uoTx_cRuL5o

> <https://groups.google.com/a/chromium.org/g/blink-dev/c/uoTx_cRuL5o>.

>
> Intent to experiment 2.0:
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/wIYqo3F_Vmo/m/uKw6hDa8BgAJ

> <https://groups.google.com/a/chromium.org/g/blink-dev/c/wIYqo3F_Vmo/m/uKw6hDa8BgAJ>.

>
>
> --
> 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+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWEND_DnBLvCqrtiRoXzxgUrRzC0i%2Bs55Jxa439yui0xFw%40mail.gmail.com

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWEND_DnBLvCqrtiRoXzxgUrRzC0i%2Bs55Jxa439yui0xFw%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+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw835Xd4N%2BhdqG6e-U0U8O39rHPrmDKncRQNn9bGeET8nQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw835Xd4N%2BhdqG6e-U0U8O39rHPrmDKncRQNn9bGeET8nQ%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+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVwSgxMeq%3DvPmstfiOEcciNSCw9wDkyTiadrvc7z9qnVw%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVwSgxMeq%3DvPmstfiOEcciNSCw9wDkyTiadrvc7z9qnVw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Yoav Weiss]

On Wednesday, February 2, 2022 at 9:25:54 AM UTC+1 Manuel Rego wrote:

TAG suggested back in July that this API something specific to Chrome or
Google Play Store. It looks like this hasn't been done, any good reason
to not doing that?

From my perspective, I believe that piece of feedback runs contrary to Blink's interoperability principles, and is contrary to what we (well, I) told the API's developers when they came to this list with a proprietary proposal.

The proposal got a lot of interest on WICG, and even if the only store that implements it is the Google Play Store, I think there's value in having an interoperable API that would enable other Chromiums to ship, as well as enable implementations in non-Chromium Android browsers. I'd also be hesitant to exclude the possibility of other stores implementing this API as well in the future.

> it, send an email to blink-dev+unsubscribe@chromium.org
> <mailto:blink-dev+unsubscribe@chromium.org>.

> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWEND_DnBLvCqrtiRoXzxgUrRzC0i%2Bs55Jxa439yui0xFw%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWEND_DnBLvCqrtiRoXzxgUrRzC0i%2Bs55Jxa439yui0xFw%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+unsubscribe@chromium.org
> <mailto:blink-dev+unsubscribe@chromium.org>.

> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw835Xd4N%2BhdqG6e-U0U8O39rHPrmDKncRQNn9bGeET8nQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw835Xd4N%2BhdqG6e-U0U8O39rHPrmDKncRQNn9bGeET8nQ%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+unsubscribe@chromium.org
> <mailto:blink-dev+unsubscribe@chromium.org>.

[Rick Byers]

+1 to Yoav's perspective here. Our job is not to force interoperability but to create the conditions to make future interoperability as easy as possible. We have multiple examples of APIs where originally Chrome was the only interested browser, but once sites started to adopt them and demonstrate the value, other browsers decided they wanted to provide their users with that value too. I would hate to create a condition where, for example, Brave, Edge or Samsung browser felt compelled to support an API with 'Chrome' in it's name once there was clear user value to supporting the use case. Further, if we put Chrome in the name that could be perceived as indicating that we were actively trying to create such browser lock-in or otherwise create conditions for Chrome to have an unfair advantage over other browsers when nothing could be further from the truth.

Rouslan, it looks to me like the API is designed to support multiple stores, right? For example if Samsung decided that they wanted to support connecting it up to both the Android Play Billing API (so SBrowser could provide equivalent user experience to Chrome) AND to the Samsung store (so merchants could have a choice in stores, perhaps competing on terms like commission rate) they could do that with the current API shape, right?

We've fought hard to get away from the webkit-prefixed and "chrome apps" world and we know it's not possible to know up front that an API will never have interoperable implementations. I think the downside of potentially using up a small piece of the global API namespace for an API that fails to achieve interoperability is much smaller than the downside of disincentivizing other implementations or burning a Chrome/Play API name into the web for what may become more general.

At the same time, the TAG has been clear that their time is best spent on the APIs that are most likely to become interoperable standards. Dan told me at one point that it might be best if we didn't even both asking for TAG review that didn't have engagement from a 2nd browser., so I don't think we should expect them to have any real interest in reviewing this API. They've already marked this review as closed, so I don't think we should expect a response.

Rego, what do you think? I'll give my LGTM3 but also happy to keep discussing the tradeoffs here. I really appreciate having the non-google API owners perspective here, it's always possible that us Googlers have some unconscious bias influencing our thinking.

Rick

> it, send an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWEND_DnBLvCqrtiRoXzxgUrRzC0i%2Bs55Jxa439yui0xFw%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWEND_DnBLvCqrtiRoXzxgUrRzC0i%2Bs55Jxa439yui0xFw%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+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw835Xd4N%2BhdqG6e-U0U8O39rHPrmDKncRQNn9bGeET8nQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw835Xd4N%2BhdqG6e-U0U8O39rHPrmDKncRQNn9bGeET8nQ%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+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVwSgxMeq%3DvPmstfiOEcciNSCw9wDkyTiadrvc7z9qnVw%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVwSgxMeq%3DvPmstfiOEcciNSCw9wDkyTiadrvc7z9qnVw%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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/58d2ff10-efe9-470c-9ed6-9ec555a44194n%40chromium.org.

[Rouslan Solomakhin]

> Rouslan, it looks to me like the API is designed to support multiple stores, right?

> For example if Samsung decided that they wanted to support connecting it up to

> both the Android Play Billing API (so SBrowser could provide equivalent user

> experience to Chrome) AND to the Samsung store (so merchants could have

> a choice in stores, perhaps competing on terms like commission rate) they

> could do that with the current API shape, right?

That is correct. The API shape has been generalized enough to be store-agnostic and browser-agnostic. We have been pitching the API to other stores and browsers as well.

[Manuel Rego Casasnovas]

On 02/02/2022 16:51, Rouslan Solomakhin wrote:
>> Rouslan, it looks to me like the API is designed to support multiple
> stores, right?
>> For example if Samsung decided that they wanted to support connecting
> it up to
>> both the Android Play Billing API (so SBrowser could provide
> equivalent user
>> experience to Chrome) AND to the Samsung store (so merchants could have
>> a choice in stores, perhaps competing on terms like commission rate) they
>> could do that with the current API shape, right?
>
> That is correct. The API shape has been generalized enough to be
> store-agnostic and browser-agnostic. We have

> <https://docs.google.com/document/d/1X2j1wKC2T4RONcUGYxGus8Dytv6s2_tVTUSkWDWPza4/edit#heading=h.chc35okxwb9>
> been <https://www.w3.org/2021/10/28-wpwg-minutes.html#t04> pitching the

> API to other stores and browsers as well.

It'd be really nice to get some engagement from other browsers or
stores. There are lots of stores, and also several browsers based on
Chromium. Have we talked to them? Is anyone interested in adding support
for this?

There are also mentions to v2.0 and v2.1. Which one would be shipping?
Are you expecting more changes on the API in the short term? It might be
hard to implement those changes once it's shipped.

On the TPAC presentation there was this plan:
* Collect feedback from the origin trial.
* Publish draft spec in WICG.
* Iterate with more developer feedback.
* Collaborate with other user agents and app stores.
* Ship it.

It looks like the spec PR hasn't been merged yet
(https://github.com/WICG/digital-goods/pull/40), and I'd love to
understand better the efforts to convince other browsers and stores
about the benefits of this API.

I agree this is something we want to avoid. And I understand what Yoav
and your are explaining. It makes sense to create standard APIs not
attached to a single browser, so in the future they can be adopted by
others.

I just want to have a better picture of what we're doing to convince
others to adopt this.

> At the same time, the TAG has been clear that their time is best
> spent on the APIs that are most likely to become interoperable
> standards. Dan told me at one point that it might be best if we
> didn't even both asking for TAG review that didn't have engagement
> from a 2nd browser., so I don't think we should expect them to have
> any real interest in reviewing this API. They've already marked this
> review as closed, so I don't think we should expect a response.

TAG was closed with that feedback in July:
https://github.com/w3ctag/design-reviews/issues/571

A week ago there was a comment that this was going to ship without
following that feedback, and the TAG reopened the issue. That's what I
was suggesting to give them some time to reply.

> Rego, what do you think? I'll give my LGTM3 but also happy to keep
> discussing the tradeoffs here. I really appreciate having the
> non-google API owners perspective here, it's always possible that us
> Googlers have some unconscious bias influencing our thinking.

I believe I agree with your POV here. After looking deeper into this, my
concerns now are mostly related to find other browsers or stores
interested. Once we get more people involved, there'll be probably
changes on the API and so on.

Cheers,
Rego

> On Wed, Feb 2, 2022 at 6:52 AM Yoav Weiss <yoav...@chromium.org
> <mailto:yoav...@chromium.org>> wrote:
>
>
>
> On Wednesday, February 2, 2022 at 9:25:54 AM UTC+1 Manuel Rego
> wrote:
>
> TAG suggested back in July that this API something specific
> to Chrome or
> Google Play Store. It looks like this hasn't been done, any
> good reason
> to not doing that?
>
>
> From my perspective, I believe that piece of feedback runs
> contrary to Blink's interoperability principles

> <https://docs.google.com/document/d/1romO1kHzpcwTwPsCzrkNWlh0bBXBwHfUsCt98-CNzkY/edit#heading=h.t71a2ioil8j0>,

> and is contrary to what we (well, I) told the API's developers
> when they came to this list with a proprietary proposal

> <https://groups.google.com/a/chromium.org/g/blink-dev/c/vkS3k30lWNs/m/Gt4sKECQEgAJ>.

> The proposal got a lot of interest

> <https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350> on

> WICG, and even if the only store that implements it is the
> Google Play Store, I think there's value in having an
> interoperable API that would enable other Chromiums to ship, as
> well as enable implementations in non-Chromium Android browsers.
> I'd also be hesitant to exclude the possibility of other stores

> <https://github.com/w3ctag/design-reviews/issues/571#issuecomment-861188412>

> implementing this API as well in the future.
>
>
>
>
> Also there's been an update on the TAG about the plan of
> shipping this
> API without changing the name. But that was just 1 week ago,
> should we
> give them some time to reply before shipping?
>
> Cheers,
> Rego
>
> On 01/02/2022 20:41, Yoav Weiss wrote:
> > LGTM2
> >
> > On Tue, Feb 1, 2022 at 8:00 PM Chris Harrelson
> <chri...@chromium.org <mailto:chri...@chromium.org>

> > <mailto:chri...@chromium.org

> <mailto:chri...@chromium.org>>> wrote:
> >
> >
> > LGTM1
> >
> > On Tue, Feb 1, 2022 at 6:16 AM Rouslan Solomakhin
> > <rou...@chromium.org <mailto:rou...@chromium.org>

> <mailto:rou...@chromium.org <mailto:rou...@chromium.org>>>

> wrote:
> >
> > Contact emails
> >
> > mgi...@chromium.org <mailto:mgi...@chromium.org>

> <mailto:mgi...@chromium.org <mailto:mgi...@chromium.org>>,
> > rou...@chromium.org <mailto:rou...@chromium.org>
> <mailto:rou...@chromium.org <mailto:rou...@chromium.org>>,
> > gle...@chromium.org <mailto:gle...@chromium.org>
> <mailto:gle...@chromium.org <mailto:gle...@chromium.org>>

> <mailto:blink-dev%2Bunsu...@chromium.org>
> > <mailto:blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWEND_DnBLvCqrtiRoXzxgUrRzC0i%2Bs55Jxa439yui0xFw%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWEND_DnBLvCqrtiRoXzxgUrRzC0i%2Bs55Jxa439yui0xFw%40mail.gmail.com>
>
> >

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWEND_DnBLvCqrtiRoXzxgUrRzC0i%2Bs55Jxa439yui0xFw%40mail.gmail.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWEND_DnBLvCqrtiRoXzxgUrRzC0i%2Bs55Jxa439yui0xFw%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+...@chromium.org

> <mailto:blink-dev%2Bunsu...@chromium.org>
> > <mailto:blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw835Xd4N%2BhdqG6e-U0U8O39rHPrmDKncRQNn9bGeET8nQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw835Xd4N%2BhdqG6e-U0U8O39rHPrmDKncRQNn9bGeET8nQ%40mail.gmail.com>
>
> >

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw835Xd4N%2BhdqG6e-U0U8O39rHPrmDKncRQNn9bGeET8nQ%40mail.gmail.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw835Xd4N%2BhdqG6e-U0U8O39rHPrmDKncRQNn9bGeET8nQ%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+...@chromium.org

> <mailto:blink-dev%2Bunsu...@chromium.org>
> > <mailto:blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVwSgxMeq%3DvPmstfiOEcciNSCw9wDkyTiadrvc7z9qnVw%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVwSgxMeq%3DvPmstfiOEcciNSCw9wDkyTiadrvc7z9qnVw%40mail.gmail.com>
>
> >

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVwSgxMeq%3DvPmstfiOEcciNSCw9wDkyTiadrvc7z9qnVw%40mail.gmail.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVwSgxMeq%3DvPmstfiOEcciNSCw9wDkyTiadrvc7z9qnVw%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+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/58d2ff10-efe9-470c-9ed6-9ec555a44194n%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/58d2ff10-efe9-470c-9ed6-9ec555a44194n%40chromium.org?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWGvt-NRov%3D3M8sCw9SzzKPcq3fC8CLRuQtv2xnhxmPZOg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWGvt-NRov%3D3M8sCw9SzzKPcq3fC8CLRuQtv2xnhxmPZOg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Rouslan Solomakhin]

> There are lots of stores, and also several browsers based on

> Chromium. Have we talked to them? Is anyone interested in

> adding support for this?

Yes, we have talked to the other browsers and stores. We have received some questions and no objections. So far, there are no public signals that any other browser has concrete plans to implement DGAPI.

> There are also mentions to v2.0 and v2.1.

> Which one would be shipping?

We would like to ship 2.0 to stable. The 2.1 changes are non-breaking (only additive) and feature-detectable. These would be coming several milestones after 2.0 ships.

> Are you expecting more changes on the API in the short term?

As with anything, it's hard to say for sure, but it is possible that 2.2 may eventually come out.

> It might be hard to implement those changes once it's shipped.

What kind of difficulties do you foresee? In my (admittedly small) past experience, the web platform has the ability to carefully iterate on shipped features, if the need arises.

> It looks like the spec PR hasn't been merged yet

> (https://github.com/WICG/digital-goods/pull/40).

https://wicg.github.io/digital-goods/ is the snapshot of what we would like to ship, while the pull request at https://github.com/WICG/digital-goods/pull/40 has been left open for a spec mentor to review it and leave any comments that they may have. (Pull requests on GitHub have convenient features for reviews like that.)

> I'd love to understand better the efforts to convince other browsers

> and stores about the benefits of this API.

We reached out widely during the 2021 TPAC, in the PWA Dev Sync meeting in January of 2022, through bug trackers, and in personal communications. The reception has been mostly neutral so far. I suspect that other members of the ecosystem would like to see DGAPI succeed with web developers before they invest their own resources into it, which makes sense on some level.

[Rick Byers]

On Thu, Feb 3, 2022 at 11:45 AM Rouslan Solomakhin <rou...@chromium.org> wrote:

> There are lots of stores, and also several browsers based on

> Chromium. Have we talked to them? Is anyone interested in

> adding support for this?

Yes, we have talked to the other browsers and stores. We have received some questions and no objections. So far, there are no public signals that any other browser has concrete plans to implement DGAPI.

Are you able to share which groups specifically you've talked with about this proposal? I've seen that there's been a serious attempt to engage others but I understand Rego's perspective that it's not clear from the public information how serious we are about that. Perhaps just naming them would help?

We discussed this in the API owners meeting yesterday. +Alex Russell mentioned that he would look into what he could say from a Microsoft perspective. There were no objections to shipping in the meeting (API owners present IIRC were Alex, Yoav, Chris, Daniel, Rick, Mike Taylor and Mike West). So with my LGTM3, you're approved to ship Rouslan. But continuing the discussion on whether there's more we can be doing to accelerate and increase the chance of this having multiple implementations is great.

[Rouslan Solomakhin]

> Are you able to share which groups specifically you've talked with about this proposal? 

> Perhaps just naming them would help?

The browsers (and stores) that we had engaged were Oculus Browser (Oculus Store), Samsung Internet browser (Samsung Galaxy Store), Safari (Apple App Store), and Edge (Microsoft Store). Our vision is that -- eventually -- a PWA installed from any of these stores and running in any of those browsers, could have the ability to use the same DGAPI calls for in-app purchases and subscriptions.

[Rick Byers]

On Thu, Feb 3, 2022 at 1:38 PM Rouslan Solomakhin <rou...@chromium.org> wrote:

> Are you able to share which groups specifically you've talked with about this proposal? 

> Perhaps just naming them would help?

The browsers (and stores) that we had engaged were Oculus Browser (Oculus Store), Samsung Internet browser (Samsung Galaxy Store), Safari (Apple App Store), and Edge (Microsoft Store). Our vision is that -- eventually -- a PWA installed from any of these stores and running in any of those browsers, could have the ability to use the same DGAPI calls for in-app purchases and subscriptions.

Perfect, thank you for sharing! Knowing that you haven't heard fundamental objections from any of those potential partners is huge in my mind. I'm sure there will be some need for iterating if we're going to get to the point that any of them would be interested and actually want to implement, but shipping now with integration with one store is probably the fastest way to get broader support. Thank you for doing this outreach!

Since my wording last message was perhaps _still_ somewhat ambiguous: LGTM3

[Mike Taylor]

On 2/4/22 10:13 AM, Rick Byers wrote:

On Thu, Feb 3, 2022 at 1:38 PM Rouslan Solomakhin <rou...@chromium.org> wrote:

> Are you able to share which groups specifically you've talked with about this proposal? 

> Perhaps just naming them would help?

The browsers (and stores) that we had engaged were Oculus Browser (Oculus Store), Samsung Internet browser (Samsung Galaxy Store), Safari (Apple App Store), and Edge (Microsoft Store). Our vision is that -- eventually -- a PWA installed from any of these stores and running in any of those browsers, could have the ability to use the same DGAPI calls for in-app purchases and subscriptions.

Perfect, thank you for sharing! Knowing that you haven't heard fundamental objections from any of those potential partners is huge in my mind. I'm sure there will be some need for iterating if we're going to get to the point that any of them would be interested and actually want to implement, but shipping now with integration with one store is probably the fastest way to get broader support. Thank you for doing this outreach!

Since my wording last message was perhaps _still_ somewhat ambiguous: LGTM3

To pile on, thanks for engaging with other browser vendors and stores here. Non-needed LGTM4.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_%2B-vsXBovxjco1gWxMxnYsRLhSBtUE66ipguf_WRKbpQ%40mail.gmail.com.

[polyset]

late to the party, but here are a few inputs as an outsider web-app developer:

1. "In general, we are opposed to adding proprietary APIs via the browser. However, we consider the Play Billing APIs to be part of a separate ecosystem, similar to that of Android Apps in the Play Store, or iPhone Apps in the App Store. Developers explicitly opt into this ecosystem when they publish their Web App to the Play Store, and, as such, the API is not exposed to the open Web" [1]. 
   
   I'd like to challenge this assumption, and point to the excellent work done @ chromium on private-state-tokens [2]. That spec could have taken the webkit/apple approach and implemented a proprietary API requiring a spiritual equivalent to an iCloud attester [3], but they did not, and instead built an open, secure, and simple API.
   
   
2. The state problem DG API addresses is, "PWAs wish to be listed in the Play store, to increase their discoverability. However, Play policy dictates that all in-app purchases (IAPs) from apps listed in the store **MUST** go through Play Billing. This is not a problem for native apps, as Play provides an SDK allowing them to do this but there is no equivalent on the web, which means that PWAs with IAPs cannot be listed in the store." [1]. 
   
   As chromium has done elsewhere, why not use a list of trusted providers, instead of hardwiring in the PlayBillingAPI? This would make it easier for folks like Brave, Arc, and I dare say Firefox to actually adopt this API. So what we have here is a proprietary API that few if any browsers will implement, and for web app developers (the ones the API was made for)... they have to bubblewrap their PWA's (using a janky jdk11 build process detailed over multiple pages in [4]), submit them to the Google Play Store, set up Play-Store & GCP proprietary services, and then can use the API?
   
   
3. On KPIs: I've noticed Chromium features use the following language:
   
   ```
   Firefox:No signal
   Safari:No signal
   Web Developers:Positive
   ```
   Which web developers have you spoken with, and why did they find this API positive? How are you making decisions here? Obviously Play Store wants .*, but as a developer myself I find the above frustrating and limited. Using the power of Google, would it be possible to ask a statistically significant number of non-Google employed developers for feedback? What's the NPS? It seems disingenuous to cite something like, "we spoke with a few devs at the conference and they liked it". We can do better!
   
   And what are the KPIs for your team on something like this, given the proprietary nature of this API. When it goes GA, and hypothetically let's say after a few quarters, zero dollars is generated via Play Store TWA IAPs, does this mean it's a failure? If no other browsers implement this API, does that mean it's a failure? Will heads roll? Does anyone care?
   

I'm not saying this is easy or simple, I just loathe to see the web getting fragmented in this way && to see such talented developers work on things that won't actually get used. I do however deeply respect the art of creative exploration and love to see it happening here. Buen dia!

[1] https://docs.google.com/document/d/1Jbt2Mzt-xg1cWVlFScBQsoX_pE8Kg1gYpulxUSV8FM0/edit
[2] https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit#heading=h.6a92f2gfl9le
[3] https://developer.apple.com/news/?id=huqjyh7k
[4] https://github.com/chromeos/pwa-play-billing