Amphtml: amp-access-iframe for amp-subscriptions

[merwan7]

Describe the new feature or change to an existing feature you'd like to see

We're looking into implementing metered access for our clients using AMP. Our main client (The Washington Post) implemented their paywall using amp-subscriptions, but this requires us to have a service to determine if someone has access to the content or not. Our initial effort (without AMP) consists of a client-side implementation of the meter/paywall. We would like to see something similar to amp-access's amp-access-iframe, but which works with the amp-subscriptions extension.

Describe alternatives you've considered

We currently are working on a server-side implementation of our meter, but not all our clients want to go with this route, since it is more expensive. Running the meter client-side has a couple of main benefits:

• It's cheaper to run, since we reduce requests to the server to 0 from one per article view.
• We have access to browser storage which may contain additional data that we can use to evaluate the rules set for a specific paywall (e.g. some readers may be exempt due to them being in some control group when A/B testing).

I believe our client-side meter implementation would work with amp-access & amp-access-iframe after some modification to the meter script to return the right payloads that amp-access expects.

Additional context

We are implementing this as part of Arc so flexibility is very important, since we have many different clients with different needs and budgets. I started this conversation on AMP's slack and was directed to open an issue by @jpettitt so we can discuss this further.

[aghassemi]

/to @dvoytenko

[dvoytenko]

/to @jpettitt . This makes sense. We should just open up the amp-access-iframe to amp-subscriptions.

[jpettitt]

Should we make this a new service amp-subscriptions-iframe effectively a sibling to amp-subscriptions-google. Doing so would require that we make the local service optional.

Or, should we extend the local service? My inclination is to bit the bullet and make it a stand alone service as that's more in line with the underlying amp-subscriptions pluggable design.

Thoughts?

[dvoytenko]

I'd recommend to just add an option for "local" service to function via an iframe. I don't believe this will add a lot of new size demands on the binary.

[jpettitt]

SGTM. I've prioritized this as P2, we'll need take a look at the schedule. @merwan7 what timeline are you looking at for integrating amp-subscriptions in other words when does this become a critical path issue for you?

[merwan7]

@jpettitt We were hoping to deliver the new meter solution in June of this year. I believe that is when it will become critical for us. How doable do you think this is? If not very, is there anything we can do to help speed things up?

[jpettitt]

I've added this to my backlog for April. Barring unforeseen events I should have something by the end of April or 1st week in May. I'll post some design notes here next week for comment.

[jpettitt]

@merwan7 here is what I'm thinking from an API standpoint

This will be a different type of local service. If the "type": "iframe" and "iframeSrc": "..." are present it will be treated as if it were the local service (that is it will be preferred in platform selection and will be called in any circumstances where the local service would normally be called) .

Messages will be sent to the iframe in the same format as amp-access. In addition to the iframeVars specified there will be an "Version" : "amp-subscriptions-1.0" in the data object passed with commands. This will allow the iframe to handle amp-access, amp-subscriptions and allow for future protocol versions, returning the appropriate data structures, should you choose to build a frame that support both.

Sample config:
````JSON
{
"services": [{
"type": "iframe",
"iframeSrc": "https://example.org/access-controller-iframe",
"iframeVars": [
"READER_ID",
"CANONICAL_URL",
"AMPDOC_URL",
"SOURCE_URL",
"DOCUMENT_REFERRER"
],
"actions": {
"login": "https://...",
"subscribe": "https://..."
}
},
{

}

]
}
````

The authorize command will expect the same response object as the local service.
Actions will behave as the local service.

How does that sound?

cc @dvoytenko

[merwan7]

@jpettitt This is great. Thank you for the details! I really like that this would allow us to write something to support both amp-access and amp-subscriptions. This flexibility will be useful.

Am I correct in assuming that if someone is already using the amp-subscriptions-google extension they could also use a service of type iframe if they want to? That is, would this work with any amp-subscriptions-<vendor> extension that may be developed in the future?

[jpettitt]

Correct, I'm building this as part of the core amp-subscriptions as an alternate local platform. It will be compatible with other vendor supplied platforms that cooperate with amp-subscriptions including amp-subscriptions-google

[jpettitt]

I got most of it written today, unit tests pass, I still need to do full end to end testing, and sample page and some doc. I dropped the Version: idea and just changed the protocol header from amp-access to amp-subscriptions which seem more logical.

[jpettitt]

@merwan7 I just merged the code, it should in the the canary release next tuesday and prod a week later. I'll update the doc later this week but for now you can use the spec above. The changes are that I also pass in the publicationId, productId and set the protocol header to amp-subscriptions. The file in the examples directory includes a working stub iframe.

[merwan7]

@jpettitt thanks so much for the quick work on this! Thank you for the examples in the PR as well. Very helpful!

I will most likely be working on an internal PoC in our next sprint using the canary release and our metering script and will report back. If all goes well, I'll implement this in production sites thereafter.

Thanks again for all the work and for making this process super smooth!

[jpettitt]

FYI this is now live in the canary release (enable dev channel at https://cdn.ampproject.org/experiments.html)

[jpettitt]

@merwan7 please ping me in email (same user @google.com) I have a couple of questions about your implementation.