Content passes: proposal to improve the web’s support for paywalls and paid content

Hi all,

I’d like to propose a new metadata standard to solve the following problems:

• In not knowing whether payment is required to view a piece of content, search engines lack an important piece of metadata that prevents them from making fully informed decisions about which content to recommend to searchers.
• In being required to comply with the rules of “First click free” laid down by search engines, publishers are forced to introduce a huge security vulnerability in their authorisation software, and find their options to design an appropriate business model severely constrained
• In not knowing that a piece of content was only visible to them as a result of a First click free rule, users unwittingly share that content with other users who then are unable to see it.

The proposal is called “Content passes”. I have written up a more detailed description of it on my blog:

https://trib.tv/2015/11/08/content-passes/

And created a rough first draft of a specification for the relevant META and LINK tag extensions here:

http://bit.ly/1HYBaJY *

It is likely that this proposal would need to be extended through further work to cover constraints on product availability, eg that some offers are only available to students, or only those in a particular region, or only for a limited time. It’s also likely that the same product when available in multiple currencies may accept different forms of payment in each currency or region. I’d like to invite this or any other critique, and find out whether this proposal has support from search engines, publishers and news aggregators.

On behalf of the FT, I can say the Financial Times supports this proposal.

Cheers!

Andrew

* Sorry for shortlink, can’t post gist link directly as it contains more than 5 links and I’m limited as a new discourse user.

This proposal fits very well with the proposed payment flows we are looking at in the Web Payments WG. There are currently two under consideration [1][2] but they are fairly similar in many respects and I see an opportunity for the paymentRequest object in these proposals to provide some of the meta-data you describe in yours with regard to things like payment terms.

If we get the payment piece right I can imagine an experience where clicking the content link triggers the payment flow immediately and the user is able to complete the payment in very few clicks (or none if they have configured one of their “payment apps” to automatically make certain payments under specific conditions).

This raises an interesting use case where knowing that a user is already aware that they will have to pay for access to a resource and have confirmed their willingness to do so is useful data to pass to the “payment app” as this could be considered in deciding whether or not to prompt the user for confirmation.

This proposal also has some connections with a discussion currently underway in the Web Payments Community Group [3] (who authored one of the proposals) about defining a standard for the 402 Payment Required HTTP response code.

Enhancements to the Web Payments API are under discussion as a next piece of work for the Web Payments IG to tackle including the ability to handle loyalty programs (subscriptions may fit into this) and coupons (which could handle the FT’s “send an article to a friend” use case) and more.

I’d encourage you to join both the Web Payments IG and WG to represent the interests of digital publishers.

[1] https://github.com/WICG/paymentrequest/
[2] https://github.com/WICG/web-payments-browser-api [3] https://lists.w3.org/Archives/Public/public-webpayments/2015Nov/0059.html

Where this proposal is different from other Web Payment efforts is that it is aimed mostly towards content embedders (and search engines in particular) and AFAICT doesn’t require implementation in browsers. Does that fit the scope of the Web Payments WG/CG?

Thanks for pointing me at the WPWG. I wasn’t familiar with the two threads you mentioned so I took a look:

• Payment Request API: This is certainly a promising step towards allowing content providers to make paying for content more seamless (and we all want to achieve the UX only an app store can currently provide), but there’s no crossover that I can see with my proposal. I’m not proposing any kind of payment mechanism, only a way of declaring the payment scheme.
• HTTP 402: This again could help make payments more seamless, but since we’re not charging search spiders for the content, a 402 response would be inappropriate in those cases

What I’m proposing is akin to handing a customer a price list - or perhaps a hotel reviewer gets to stay in a hotel for free but needs to know how much the hotel costs in order to make an appropriate judgement about the quality of the hotel in their review. A basic but clean hotel might get a 5 star review if it’s $50 a night, but might get a scathing review if it were $400/night. Search engines need the ability to make similar value judgements about premium content.

Users also need easier ways of understanding what the deal is. To extend the analogy, if I want to know the price of a hotel, I don’t go to the hotel’s website because each hotel displays their pricing in a different format, despite the fact that all hotels price their services on the same basis. It’s therefore a lot easier for me to go to booking.com where I’m familiar with the way the prices are displayed regardless of which hotel it is. Obviously premium content is subject to far more complex pricing than hotels, which explains why we need a metadata format to describe it.

The connection to WPWG seems complementary rather than an alternative. About implementation in browsers, I think understanding contentpass metadata could be useful in a user agent - for example, kicking off a web payments flow for premium content as soon as the user arrives on the page is premature. First the user may already have a subscription and is not signed in, and second if they don’t have a sub, they may have multiple choices about what kind of sub to buy (in FT’s case there are two tiers).

So landing on a piece of paid content is like being on a product page on amazon where you haven’t decided to put the product in your cart yet, and where there are options to customise it that you haven’t yet considered. A user agent could read the content pass metadata, and present native UI to tell the user what subscription or content purchase options are available. Choosing one of these would then kick off the web payment request workflow.

This was what I had in mind, yes. I’m not suggesting the Web payments work is handling your use case but rather that it’s complimentary (as you say).

It would be very valuable if we could get two things from you:

1. A better understanding of the use case and user experience flow so that we can consider the requirements that are implicit in this for the development of the Web Payments work. As I mentioned, the online publishing industry is a prominent online merchant and is underrepresented (in my opinion) in the payments activity at the W3C. Do you have capacity to join the WG?
2. Collaboration on the design of the language for defining payment terms. Our recommendations will include a vocabulary and message schema for a “payment request” from the payee that will describe things like the price, recurrence etc. It seems sensible that content passes should use the same terms to describe the “offer”.

I represent the FT and Nikkei, neither of which is a W3C member I’m afraid, but I’m happy to be an invited expert if you like. Is WPWG the best place to push content passes themselves or are you only interested in the extent to which there is crossover on metadata? If so where should we progress content passes?

Agreed, and happy to help define that.

Let me chat with our staff contacts.

Probably not, I think this is the right forum. I will keep tracking this proposal and feed back any progress we make in the WPWG that is relevant.