Identity
A dereferenceable WebID URI naming exactly one principal or agent.
Any web-accessible digital artifact can become a commercial product — packaged as a machine-computable offer, and released only after identity, delegation, and payment are all verified live.
Two Tracks, One Gate
A human buys this the way you'd buy anything online: click, checkout, done. An AI agent buys the same offer without a browser at all — same price, same license, same ABAC policy — negotiated entirely over raw HTTP headers instead of a shopping cart. Both hit the identical gate on the identical resource; this report shows you both tracks, side by side, so neither reads as the "real" one and the other as a simulation.
Click, checkout, a Stripe payment form, "Add to Cart." See it in the offers screenshot and the purchase-flow screencast below.
A WebID certificate, an mTLS handshake, a raw WWW-Authenticate: Payment header — no browser involved. See it in the HTTP transcripts and the empirical access matrix.
Linked Open Agentic Commerce (LOAC) names the problem as "agentic execution without agentic representation" and proposes a hyperlink-based entity-relationship graph as the fix: principals, agents, offers, licenses, and resources as first-class, dereferenceable entities. This report puts three of its concrete mechanics to a live test: WebID identity with On-Behalf-Of delegation as a first-class graph relationship, ABAC policy derived from a resource's license, and dereferenceable Offer IRIs surfaced on payment challenges.
So what counts as a modern digital good or service, packaged as constrained file (document) access, in the age of AI? Almost anything that can be represented as a file is a candidate LOAC product — the mechanism this report tests doesn't care whether the underlying content is a spreadsheet or a symphony, only that it's addressable, licensable, and access-controllable as a discrete resource:
The demonstration exercised LOAC's full request lifecycle end to end, live:
COUNT(*) query — each exposed as a web resource with its own LOAC offer.WWW-Authenticate and Link: rel="offer" response headers — no proprietary APIs or application-specific protocols required.HTTP/1.1 402 Payment Required
Server: Virtuoso/08.03.3335 (Linux) x86_64-generic-linux-glibc2.12 VDB
Connection: Keep-Alive
Date: Thu, 02 Jul 2026 16:46:57 GMT
Accept-Ranges: bytes
Content-Type: application/problem+json
WWW-Authenticate: Payment
id="oi1sNcIsrVzJapveBrnn5LDZogltGHyEyEN-k25m6No",
realm="linkeddata.uriburner.com",
method="stripe",
intent="charge",
request="eyJhbW91bnQiOjI5OSwiY3VycmVuY3kiOiJ1c2QiLCJleHRlcm5hbElkIjoiaHR0cDovL2RhdGEub3Blbmxpbmtzdy5jb20vb3Bsd2ViL29mZmVyL1dvcmxkQ3VwMjAyNkd1aWRlTmFtZWRHcmFwaE9mZmVyVVJJQnVybmVyI3RoaXMiLCJtZXRob2REZXRhaWxzIjp7Im5ldHdvcmtJZCI6ImludGVybmFsIiwicGF5bWVudE1ldGhvZFR5cGVzIjpbImNhcmQiLCJsaW5rIl19LCJyZWNpcGllbnQiOiJodHRwczovL29kcy1xYS5vcGVubGlua3N3LmNvbS9zaG9wLyJ9",
description="2026 FIFA World Cup Country & Player Guide Knowledge Graph (Named Graph) — Graph Access on URIBurner",
expires="2026-07-02T16:56:57.141647Z"
Link:
<http://data.openlinksw.com/oplweb/offer/WorldCup2026GuideNamedGraphOfferURIBurner#this>;
rel="https://schema.org/offers";
type="text/turtle";
title="2026 FIFA World Cup Country & Player Guide Knowledge Graph (Named Graph) — Graph Access on URIBurner";
seller="https://ods-qa.openlinksw.com/shop#this"
Captured live against the SPARQL COUNT(*) route — the raw evidence behind the 402 and offer-discovery bullets above.
Silent screencast: completing the ACP-mediated Stripe purchase for the exact offer (WorldCup2026GuideNamedGraphOfferURIBurner) the 402 challenge above named — the not-entitled → entitled provisioning transition this report's own curl-based tests deliberately did not execute.
Each layer is independently swappable — changing one does not require changing the others.
A dereferenceable WebID URI naming exactly one principal or agent.
The RDF profile document the WebID dereferences to, carrying keys and delegation grants.
WebID-TLS: certificate modulus checked against the published profile key.
ABAC policy derived from the resource's license, evaluated server-side per request against a real, priced Offer.
One named graph, exposed as DAV file routes and a SPARQL endpoint, each with its own license-derived ABAC policy.
Three credential bundles, one of them reused with and without a delegation header, for four total test conditions. Before any request was sent, both certificates were cryptographically checked — not assumed — against their published WebID profile documents.
Primary NetID for the human principal. ✓ verified
...81E1B1E6...c719382f
Second WebID for the same human principal, backed by an OpenLink Data Spaces (ODS) profile with a live, correctly-registered delegation grant toward the Agent.
Delegate agent WebID. Used bare, and again with an On-Behalf-Of header naming User Principal B. ✓ verified
...5ed8f459...da2b8932
Principal — Kingsley Uyi Idehen
Founder & CEO, OpenLink Software
CN=Kingsley Uyi Idehen
SHA-256: A1:47:71:84:4A:8E:F1:C0:DE:95:F9:DC:AA:2A:7A:12:31:87:EC:28:3B:CB:2F:D8:93:4D:9A:77:1B:42:25:96
Valid Jun 16 2026 → Jun 16 2027 · modulus ✓ match with profile.ttl
Also known as: LinkedIn, X, Substack, Mastodon, Bluesky, Threads, GitHub, and others.
Delegate agent — Claude Sonnet 5
Running in Claude Code · this report's generation environment
CN=Kingsley Idehen's Agent
SHA-256: 40:B9:7C:B0:D7:27:55:CA:E0:60:50:52:17:EF:FB:A6:61:2E:9E:ED:D7:24:F3:10:5A:E0:8F:0E:0A:0C:34:5E
Valid Jun 18 2026 → Jun 18 2027 · modulus ✓ match with profile.ttl
On-Behalf-Of Kingsley Uyi Idehen · delegation ✓ corroborated in both profiles
The same credential bundles used throughout this report — verified fresh immediately before testing, not asserted from memory.
Three real, dereferenceable schema:Offer entities — read directly from live WWW-Authenticate: Payment and Link: rel="offer" response headers, not invented for this report. Each is a Stripe-backed Machine Payment Protocol (MPP) charge intent gating one resource.
File Access — RDF Turtle. Gates .ttl.
File Access — Meshup Infographic (HTML). Gates .html.
Graph Access — Named Graph. Gates the SPARQL COUNT(*) route.
Four identities × three offer-gated resources, run as a single clean batch (one script, one pass) so cross-identity comparison is apples-to-apples at one point in time.
| Identity | .ttl (offerTtl) | .html (offerHtml) | SPARQL COUNT(*) (offerSparql) |
|---|---|---|---|
| User Principal A (link-in-bio-credentials-5) | 402 | 402 | 402 |
| Agent (bare, no delegation) | 402 | 402 | 402 |
| User Principal B (my.demo.openlinksw.com) | 200 | 200 | 200 |
Agent + On-Behalf-Of Principal B | 200 | 200 | 200 |
Reading the matrix: entitlement is per-WebID, not per-person — Principal A and Principal B are the same human but get opposite outcomes, uniformly, across all three resources. Neither Principal A nor the bare Agent holds any standing entitlement, so both are paywalled across the board. Principal B holds standing entitlement on all three resources, and delegation via On-Behalf-Of extends that entitlement to the Agent consistently — same 200 OK, same resources, no payment gate triggered anywhere.
Silent screencast: the matrix above, in motion — the same 402 payment gate triggered for an unentitled WebID, then negated (200 OK, no gate) for an entitled one, against the identical resource.
Ten questions and answers derived directly from the companion RDF FAQPage.
LOAC names three mechanics this session exercises directly and live: (1) WebID identity with On-Behalf-Of delegation as a first-class, checkable graph relationship, not a narrative claim — verified here via reciprocal oplcert:hasIdentityDelegate / oplcert:onBehalfOf triples with the delegate's key inlined; (2) ABAC policy governing access to digital artifacts, derived from a resource's license, evaluated per principal — verified via the matrix of 200/402 outcomes below; (3) dereferenceable Offer IRIs surfaced on 402 challenges, exactly as LOAC's worked example shows. No purchase was made, so the settlement-to-provisioning transition itself was not observed — only the per-principal entitlement snapshot LOAC's ABAC model predicts.
The same three stored resources — a Turtle file, an HTML infographic, and a SPARQL COUNT(*) query, each gated by its own real, dereferenceable LOAC Offer — fetched over mutual TLS under four identity conditions: a User Principal WebID, a bare Agent WebID, a second User Principal WebID, and the Agent WebID presenting an On-Behalf-Of header naming the second User Principal as delegator.
Because Authorization is evaluated as Attribute-Based Access Control (ABAC) against the authenticated WebID, independently of whether Authentication (the mTLS handshake) succeeded. A valid certificate proves who is asking; the offer and entitlement decision is a separate, server-side policy evaluation.
Both WebIDs authenticate as the same real-world person, but they are distinct principals from the server's ABAC perspective. my.demo.openlinksw.com held a standing entitlement; link-in-bio-credentials-5 did not, and was offered the same paid LOAC Offer instead.
Yes, uniformly. Across all three resources — the .ttl file, the .html file, and the SPARQL COUNT(*) route — the Agent presenting On-Behalf-Of: idUserB received the same 200 OK that idUserB gets directly, with no payment gate triggered anywhere. Delegation extended the full standing entitlement, consistently, regardless of which storage access path was used.
Yes. The live delegator profile (my.demo.openlinksw.com) contains oplcert:hasIdentityDelegate pointing at the agent's WebID, with the agent's cert:key inlined and byte-matching its actual certificate modulus.
Three real, dereferenceable schema:Offer entities, each read directly from a live WWW-Authenticate: Payment header and its companion Link: rel="offer" header. All three are $2.99 USD, Stripe-backed Machine Payment Protocol (MPP) charge intents: DemoFileAccessOffer2URIBurner (.ttl), DemoFileAccessOffer1URIBurner (.html), and WorldCup2026GuideNamedGraphOfferURIBurner (SPARQL graph access).
No. Every 402 Payment Required challenge was reported and its offer identified, never acted on. No Stripe Shared Payment Token was created and no charge was authorized at any point in this session — this was verification, not purchase.
That "the Agent, acting on behalf of the Principal" is an operational, checkable RDF assertion: a live delegation pair with an inlined public key, evaluated by a real ABAC gate, against a real dereferenceable Offer, over a real mTLS connection.
That Identity, Identification, Authentication, Authorization, and Storage are five independently swappable layers. Swapping only the Identity layer changed the Authorization outcome without touching Authentication, Identification, or Storage at all.
Sixteen terms wrapped in a schema:DefinedTermSet in the companion RDF.
LOAC's core problem statement: AI-era commerce has "agentic execution without agentic representation." LOAC's fix is a hyperlink-based entity-relationship graph where principals, agents, offers, and licenses are first-class, dereferenceable entities.
LOAC's insistence that a transaction is never merely "the Agent did X" but "Agent, acting on behalf of Principal, did X" — with the delegation relationship itself a first-class, checkable entity in the graph.
LOAC's model of entitlement over time: not entitled → a 402/403 payment challenge → entitled → 200 OK, with an ABAC policy expressed in RDF once a purchase settles.
A dereferenceable WebID URI that names exactly one principal or agent, independent of how that naming is later authenticated or authorized.
The RDF profile document a WebID dereferences to, asserting the principal's public key(s) and any delegation relationships.
Proof that the requester holds the private key matching a public key published in a given WebID's profile, established via mutual-TLS.
A server-side policy decision made per request against the authenticated WebID's attributes, independent of whether authentication succeeded.
The underlying persistence layer — here, a Virtuoso quad store — exposed through multiple independently-gated access paths.
A URI that identifies an agent and dereferences to an RDF profile document describing that agent, per the W3C WebID specification.
A TLS handshake in which both client and server present certificates; the client key is cross-checked against the WebID profile's published key.
Attribute-Based Access Control — an authorization model evaluating access based on requester, resource, and context attributes.
An HTTP header plus reciprocal RDF triples asserting one WebID is acting under another's authority.
A payment-challenge protocol triggered by HTTP 402, decoupling monetary settlement from the resource-access decision itself.
A schema:Offer with its own dereferenceable IRI, surfaced via WWW-Authenticate and Link: rel="offer" headers on a 402 response.
Linked Open Agentic Commerce — commerce represented as a hyperlink-constructed entity-relationship graph of principals, agents, offers, licenses, and resources.
An architecture where trust layers are independently swappable components connected only by dereferenceable IRIs.
The verification protocol followed for every identity before it was used to request an offer-gated resource.
openssl pkcs12 -in cert.p12 -noout -passin pass:$PW — confirm the bundle unlocks before use.
openssl x509 -noout -ext subjectAltName -in cert.pem — confirm it matches the WebID under test.
Compare the cert modulus against cert:modulus in the WebID's own profile.ttl.
Fetch the delegator's live profile and confirm oplcert:hasIdentityDelegate names the agent with its key inlined.
Always show the sanitized command (password masked) before execution.
Record the offer IRI and price named in the challenge — do not act on it without explicit authorization.
Build the full entitlement matrix rather than inferring from a single spot check.
Identities, offers, resources, and the layers that connect them. Click a node or an edge label to open its resolver-backed description.
Identities, LOAC offers, storage resources, and the layers connecting them.
Graph embedded at generation time from the identities, offers, resources, and layer entities in the companion RDF.
Two publications of the same LOAC framework that this session verifies.
Technical writeup with worked examples: ABAC policy derived from a resource's license, principal/agent delegation as a first-class graph entity, ACP/MPP separation, a Stripe SPT trace, and a dereferenceable offer IRI.
https://community.openlinksw.com/t/linked-open-agentic-commerce-loac/6287
Companion publication of the same framework: commerce as a hyperlink-constructed entity-relationship graph, WebID identity/ABAC authorization, and MPP/Stripe settlement via dereferenceable Offer IRIs.
https://www.linkedin.com/pulse/linked-open-agentic-commerce-loac-kingsley-uyi-idehen-5k8pe/