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

út 8. 7. 2025 v 13:24 odesílatel April Daly <adaly@labobjects.com> napsal:

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

Thanks Joshua & April,

acl:paymentRequired is meant as a tiny shortcut for the very common
“pre-pay X credits” case, nothing more.

Think of a metered chat agent or a rate-limited API that charges per
request.

Anything richer (royalties, attribution, medical-credentials, post-facto
duties) should live in a full policy layer (ODRL or similar) that ACL can
simply reference.

So: simple paywall ⇒ one decimal in ACL; complex conditional access ⇒ point
to a policy object.

Best,
Melvin


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