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

This statement is subjective: in general, business rules are flexible and tend to “bind” with accounting, whilst policy rules are inflexible and tend to “bind” with governance.

 

My first research project was 3 3-year of development of a HIS, and from my experience, probably everything is “policy” – because everything should/has to be auditable.

 

In your example, you are referring to patient data, which would be audited, and lands in policy. But policies can live inside business processes as cross concerns (arrive -> treatment -> departure is the high-level business processes, everything inside treatment is covered by policies)

 

Extending your 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, whilst they are in location DEF, and only for 24hrs, no more than 1 concurrent and 5 accesses in total can read my cardiogram

 

As a corollary, one of the proposals I’ve made to ODRL around condition specification would open the ability to implement encryption with FAME (https://eprint.iacr.org/2017/807.pdf)

 

"Allow [decryption] at the office when in France or the UK, anywhere in Germany"

 

Regards,

 

___________________________________

Joshua Cornejo

marketdata

smart authorisation management for the AI-era

 

From: April Daly <adaly@labobjects.com>
Date: Tuesday, 8 July 2025 at 12:23
To: 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 11:22:31 +0000

 

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

<#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