Re: Proposal: Adding acl:paymentRequired predicate for HTTP 402 handling

I do have one recommendation (I saw the Cloudflare proposal), and 402 solves a concrete and narrow proposal from the 90s.

 

As an obligation, “payment” is one of many – you can think of a use case where the data you are trying to access as a fragment of document/play/musical composition, one obligation can be “pay me a percentage” and another could be “attribution as co-author”.

 

Also, Cloudflare’s solution is tightly coupled – the consumer pays on their platform – I assume you can’t implement that in a pod.

 

Finally, think about tracking mechanisms for obligation fulfilment vs compliance/tracking on that fulfilment (e.g. payment happens pre-facto / attribution happens post-facto).

 

Regards,

 

___________________________________

Joshua Cornejo

marketdata

smart authorisation management for the AI-era

 

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Tuesday, 8 July 2025 at 09:36
To: Joshua Cornejo <josh@marketdata.md>
Cc: public-solid <public-solid@w3.org>
Subject: Re: Proposal: Adding acl:paymentRequired predicate for HTTP 402 handling
Resent-From: <public-solid@w3.org>
Resent-Date: Tue, 08 Jul 2025 08:36:01 +0000

 

Thanks, Joshua!


Exactly, this is a lightweight step in that direction without the full ODRL overhead. If it proves useful we can always map it onto richer ODRL policies later. 

 

út 8. 7. 2025 v 10:33 odesílatel Joshua Cornejo <josh@marketdata.md> napsal:

Slowly evolving to ODRL … nice 😊

 

___________________________________

Joshua Cornejo

marketdata

smart authorisation management for the AI-era

 

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Tuesday, 8 July 2025 at 09:18
To: public-solid <public-solid@w3.org>
Subject: Proposal: Adding acl:paymentRequired predicate for HTTP 402 handling
Resent-From: <public-solid@w3.org>
Resent-Date: Tue, 08 Jul 2025 08:17:17 +0000

 

Hi All,

Short version
=============

I propose we mint a single new predicate in the ACL namespace:

    acl:paymentRequired  

If an `Authorization` statement includes this triple,
a compliant server **MUST** deny access when the requester’s account
balance—in the server’s ledger for that realm—falls below the
literal.  The denial is expressed as an *HTTP 402 Payment Required*
response that also tells the client where and how to top-up.

Why?
====

Many Solid agents run on usage-based quotas
(API tokens, Streaming Chat Interfaces, storage bytes, etc.).
Today servers have no *standard* way to:

* signal “the request was good, but please pay a bit first”, **and**
* tell the client where to send that payment.

Applications therefore cook up ad-hoc headers and status codes,
breaking interoperability.

One predicate plus the already standard HTTP 402 closes that gap.

Proposed vocabulary diff
========================


@prefix acl: [http://www.w3.org/ns/auth/acl#](http://www.w3.org/ns/auth/acl#) .
@prefix xsd: [http://www.w3.org/2001/XMLSchema#](http://www.w3.org/2001/XMLSchema#) .

acl:paymentRequired
a                rdf:Property ;
rdfs:label       "payment required" ;
rdfs:comment     "Minimum positive balance the agent must hold
before this Authorization is granted.
Decimal, same currency unit the server’s
ledger uses." ;
rdfs:domain      acl:Authorization ;
rdfs:range       xsd:decimal .


Example ACL
-----------


@prefix acl: [http://www.w3.org/ns/auth/acl#](http://www.w3.org/ns/auth/acl#) .
@prefix foaf: [http://xmlns.com/foaf/0.1/](http://xmlns.com/foaf/0.1/) .

<#paid-read>
a               acl:Authorization ;
acl:accessTo    </data/> ;
acl:mode        acl:Read ;
acl:agentClass  foaf:Agent ;
acl:paymentRequired "0.0005"^^xsd:decimal .



Server behaviour (normative)
============================

* Evaluate the requester’s **current balance** (ledger details are
  implementation-specific).
* If balance < required, respond:



HTTP/1.1 402 Payment Required
Link: https://pay.example/topup ; rel="payment"
Pay-Balance: "-0.0001"
Pay-Required: "0.0005"



* After the client tops up and retries, normal `2xx` processing
  resumes.

Open questions
==============

1. **Currency unit** —  keep it server-wide (simplest) or add another
   predicate for per-rule currency?
2. **Headers** —  are `Pay-Balance` / `Pay-Required` worth standardising
   or should there be a problem JSON body alone carry the numbers?
3. **Ledger location** —  should the spec normatively reference a
   `webledger.json` (or similar) so clients can fetch balances?

Implementor feedback is very welcome.

Best,
Melvin