Digital Goods API

[phoglenix]

Kia ora TAG!

I'm requesting a TAG review of the Digital Goods API.

The Digital Goods API is 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.

• Explainer: https://github.com/WICG/digital-goods/blob/master/explainer.md
• Security and Privacy self-review: https://github.com/WICG/digital-goods/blob/master/security-privacy-self-review.md
• GitHub repo: https://github.com/WICG/digital-goods
• Primary contacts (and their relationship to the specification):
  • Glen Robertson (phoglenix), Google Inc.
  • Matt Giuca (mgiuca), Google Inc.
• Organization/project driving the design: Google Inc.
• External status/issue trackers for this feature: https://chromestatus.com/feature/5339955595313152

Further details:

• ✅ I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done: unknown
• Existing major pieces of multi-stakeholder review or discussion of this design: github issues.
• Major unresolved issues with or opposition to this design: Don't use PaymentRequest WICG/digital-goods#5 also discussion at making the "total" field optional in PaymentRequest API #512
• This work is being funded by: Google Inc.

We'd prefer the TAG provide feedback as:

🐛 open issues in our GitHub repo for each point of feedback

Thanks!

[torgo]

Hi @phoglenix - we are just triaging the issue in today's TAG call and the question came up : why not use the existing web payment payment request API? Feels like this should be added to the explainer. Also can you please add some more use cases - use cases for the web (as opposed to only in app stores).

[phoglenix]

Thanks for the feedback!

The Digital Goods API does not cover making payments/purchases itself, it's specifically about querying and managing digital goods, which is not covered by the Payment Request API. We expect the DG API to be used with the PR API to make the actual purchases (it does not have a purchase method itself). This is called out in the explainer's introduction and first section ("The Problem") and in the "Making a Purchase" section. Is there some way you think we could make the distinction more clear?

The API is all about web sites integrating with digital stores, so all examples are for the web. But I'll add some use cases/examples that hopefully illustrate it better [in progress].

[kenchris]

Write that "This is a complementary API to Web Payments, ..." - then maybe show examples of how to use them in combination.

You could even call it "Web Payments: Digital Goods API"

[phoglenix]

I just updated the explainer with a few more clarifications / examples. Is that better?

[rhiaro]

Thanks, the use cases are much clearer now.

It looks like this could potentially be very good for enabling smaller/independent creatives (artists, writers, musicians, designers, etc) to have stores that aren't the existing mainstream ones. A diversity of digital goods stores would likely necessitate aggregation/search/discovery/similar services, which would tie into the stores using this API.

To what extent have you considered this use case, and is there anything in the design that would make this explicitly difficult?

The explainer notes "sites using the proposed API would still need to be configured to work with each individual store they are listed in" - what would this mean for an ecosystem of many diverse digital goods stores? What sort of configuration are we talking about?

I see reference to the Play and Samsung stores; do you have other expected major store implementers like Apple, Kindle, Spotify, etc?

Finally, some concerns about the name, because it's so general. Maybe "Digital Goods Lookup/Listing"?

[phoglenix]

Regarding a diversity of stores:
Per the start of the explainer, this is an API to facilitate web apps selling their own in-app digital goods, not a general marketplace for multiple stores to sell some common set of digital goods. The site needs to have a pre-existing relationship with a store for it to function, because the store is the source of truth for item details (eg. prices, descriptions) which the site author has configured with the store.

So there's not really a need for dynamic search and discovery of stores - the site author would choose one to use (or possibly use a different store depending on the context).

I do hope that this API leads to a diversity of small digital goods stores in the future, but that's not really likely in its current form, because the UA needs to have custom code to interface with each store. Each store has a slightly different API, and many of them aren't available through web technologies. I think that ideally in the future we define a standard HTTP (REST?) store API that the UA can interact with, without the need for custom per-store code. In the distant future, all stores would support the HTTP API and sites could interact without reliance on the UA to facilitate. But right now web apps aren't a big enough motivator to shift stores to implement such an API. See discussion of this point here.

Regarding naming:
One of the core API functions is to consume/acknowledge digital items, which finalizes a transaction. It also facilitates purchases through interaction with the PaymentRequest API. So I'm not sure "Lookup/Listing" is broad enough. Happy to take other suggestions on naming though.

[phoglenix]

Hi, are there any updates on this? Is it waiting for some input from me?

[phoglenix]

FYI, we are moving towards shipping this API.
The API shape has changed a bit since the original TAG review, with a v2.0 and upcoming v2.1 update, but the general approach remains the same. We're still hoping to get other browsers and stores to implement the API, so haven't made it Chrome/Play specific as you recommended. A draft spec is in review. Let us know if you have any more feedback.

[chrishtr]

Intent to ship thread for context.

[torgo]

Given the API shape has changed we will have another look at our f2f coming up in 2 weeks.

[rsolomakhin]

FYI, we've updated the API to version 2.1 in the WICG/digital-goods#45 pull request.

[torgo]

Hi @rsolomakhin thanks for that pointer. Is there any further info you can share on multiple implementations or other stores besides the Play store that are looking at implementing this? This still looks to us like a "product-specific API within one company" as @hadleybeeman mentioned in the closing comment. Is there any further info on this point?

[rsolomakhin]

Hi @torgo. This was also discussed in a blink-dev@chromium.org email thread in February. The situation remains the same. We have talked to several browsers and stores, have received some questions and no objections. We have reached out through public W3C channels to Oculus Browser (Oculus Store), Samsung Internet browser (Samsung Galaxy Store), Safari (Apple App Store), and Edge (Microsoft Store). There are no public signals that any other browser has concrete plans to implement DGAPI at this point.

[torgo]

Ok @rsolomakhin - I think we're gonna close this again based on our discussion in TAG meetings this week. This isn't a comment the technical merits of the API design - it's purely about it being a "product-specific API within one company" - since we have limited bandwidth and we prioritise proposals with significant multi-stakeholder interest.