Comment on page
Frequently Asked Questions
For our test implementation, we extended the
podcast:valueRecipienttag with a
lsat-keysendattribute. This attribute can be used to identify the payment verifier by clients that don’t want / can’t parse data from the 402 response:
That way, you can pay for the episode in advance and request the episode with the preimage without ever receiving a 402 response from the server. See Why don’t you introduce new XML tags for the RSS feed? to understand why we don't include that in the protocol for now.
The server responds with the address (+ customKey & customValue if necessary) to identify the payment verifier. If there are multiple splits for the payment verifier, the client can simply choose the preimage of the payment with the largest split.
This design decision is driven by the popularity of Value4Value payments in Podcasting 2.0, which rely on value tags as well as keysend payments and are already integrated by a number of popular podcast players such as Breez, Fountain, Podverse and Castamatic. The usage of keysend payments eases the LSAT integration and ensures compatibility with Value4Value.
However, OCPS is designed to be extensible so invoices could be used in the future.
The token contains arbitrary data that the server uses to associate a request to a client.
If a server has no reason to associate a request to a client, e.g., to restrict access by time or geographic region, it can simply return a constant for all requests.
When a server implements the OCPS to protect resources, it securely verifies that only clients with a valid payment preimage gain access.
The payment preimage proves that a valid payment to the payment verifier (as chosen by the server) was made by the client. Payments to other recipients defined in the podcast's RSS feed are not verified by default. However, the server could validate these additionally if it has read access to the recipients' nodes.
The server can also use the
tokenthat he sends to the client in the 402 response to introduce additional security measures, e.g., restricting resource access by time and geographic region.
However, as in every other protocol that distributes digital resources, it is not possible to completely prevent malicious client behavior, e.g., sharing a valid preimage & token with other clients or duplicating the resource after rightfully gaining access to it.
Still, the OCPS provides a much more secure approach to protecting resources in comparison to most existing solutions because it protects each audio file in a podcast feed individually.