Associate payments with provider

[wilsonianb]

Pooling the amount paid to a website / payment pointer by a web monetization provider on behalf of all of its users adds several benefits (as described in interledger/open-payments#17):

One is that a site can start serving WM content faster, without waiting for SPSP to initialize. The site can just see the user's provider and let them in right away once they validate the provider has paid. Another advantage is that this smooths out users with varying rates on a single provider.

This could be supported with as few changes as:

1. Use the provider’s id instead of a random UUID as the Monetization ID. Privacy conscious users who are acting as their own provider can use unique IDs with the understanding that an amount paid to a website during one page load cannot benefit them in a future page load.
2. Websites should verify a token from the provider authenticating the user as belonging to said provider before performing payment verification (as described in step 9 of the current explainer flow). The provider's id for (1) can be a public key from a public/private key pair used to sign a JWT authenticating the user. This token would need to be included in a new monetization event (prior to monetizationstart which isn’t emitted until after the first in-session payment is made).

See #46 for a more drastic approach.

[AlexLakatos]

I think this would break the privacy locks we have around the standard right now. But on a different note, we've changed the flow for the state of "monetized" in the current iteration of the spec. The "interactive" state triggers as soon as we validate the payment pointer, hence providing a middle solution here. We're showing content as soon as the first payment can be made (which is similar to "you have a web monetization provider"), instead of showing it only after the first payment has been made.

[huijing]

No longer relevant.