402 Payment Required

[michielbdejong]

Similar to anyone logged in
we introduce "anyone who paid"; we'll need to pick a predicate similar to acl:AuthenticatedAgent, for instance acl:PayingAgent.

One test: 401 if you haven't authenticated at all and authenticating may help

• If the current agent is not authenticated
• Even if the ACL doc for a resource contains an authorization with acl:agentClass acl:PayingAgent
• If there is at least one other authorization that would accept the request for some authenticated user
• But based on just the other authorizations the request would be rejected for unauthenticated users

Then the server should give a 401 response like it normally would

One test: 402 if you haven't authenticated and paying is the only way in

• If the current agent is not authenticated
• And the ACL doc for a resource contains an authorization with acl:agentClass acl:PayingAgent
• And there are no other authorization that would accept the request for any authenticated user
• And the request would be rejected for unauthenticated users

Then the server should give a 402 response, along with a WWW-Pay header, for instance:

WWW-Pay: ilp-stream-webid realm=<realm>

Another test: 402 if you haven't paid

• If the current agent is authenticated but didn't pay
• And the ACL doc for a resource contains an authorization with acl:agentClass acl:PayingAgent
• And based on that authorization the request would be accepted for authenticated users who paid
• And based on just the other authorizations the request would be rejected for the current user

Then the server should give a 402 response, along with a WWW-Pay header, for instance:

WWW-Pay: ilp-stream-webid realm=<realm>

Another test: OK if paid

• If the current agent is authenticated as a WebID who has already paid
• And the ACL doc for a resource contains an authorization with acl:agentClass acl:PayingAgent
• And based on that authorization the request would be accepted for authenticated users who paid

Then the server should give a 200 response

[michielbdejong]

This by itself should probably not link to https://interledger.org/rfcs/0039-stream-receipts/ and https://webmonetization.org/docs/receipt-verifier. It's just the link between the resource server and the payment processor.

[michielbdejong]

The tricky part here is the format of that WWW-Pay header. We can pick an arbitrary syntax in this first experiment, then get it working, then write the full spec for it using what we learned from test-driven exploration.

Found some prior art: https://github.com/interledgerjs/ilp-fetch/blob/master/index.js#L49. So omitting the WWW- from the header name, and with no realm indicator:

Pay: <method> <params...>

[michielbdejong]

Supported method (from here:

• interledger-psk
• interledger-psk2
• interledger-stream

[michielbdejong]

And reverse-engineering from here, a valid Pay header would be:

Pay: interledger-stream <destinationAccount> <sharedSecretBase64>

[michielbdejong]

Ha, found it: https://interledger.org/rfcs/0014-http-ilp/#2-client-interaction

[michielbdejong]

Implementing this in NSS at nodeSolidServer/node-solid-server#1577

[michielbdejong]

Done