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

Hi,

From a modeling perspective, wouldn’t this be considered a “Business Rule”? (i.e., in this context, rule(s) that govern conditional access)

I can’t think of many use cases, but I imagine over time there could be many conditions applied, depending on usage/context, each requiring different rules and supporting actions.

If I’m granting access to medical information, I may want to grant access to a medical group (organization), but only individuals with certain credentials (memberships) and properties.

For example, all doctors that are active members in medical group XYZ that specialize in cardiology and are in good standing with the ABC medical association can read my cardiogram.

This is a contrived example but hopefully illustrates the potential complexity for conditional access.

The payment required feature complexity is increasing and demonstrates the need for different rules depending on context (and a need to address boundaries between public normative rules and implementation):

Melvin wrote:

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?

Joshua Cornejo wrote:

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).



I think the proposal identifies an important need/gap that needs to be addressed, but I’m not sure that the ACL model is the best fit for conditional access rules given the potential for complexity and the need to support (context specific) variations.

Would a Business Rule ‘layer’ better serve this need (overall)?

Thank you.

Kind regards,
April


From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Tuesday, July 8, 2025 4:17 AM
To: public-solid <public-solid@w3.org>
Subject: Proposal: Adding acl:paymentRequired predicate for HTTP 402 handling

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/)<http://xmlns.com/foaf/0.1/%5d(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