Linked Open Agentic Commerce (LOAC)

kidehen · June 5, 2026, 1:39pm

Linked Open Agentic Commerce (LOAC)

LOAC Infographic

AI-era commerce needs a representation layer that is simultaneously human-readable and machine-computable — where principals, agents, offers, licenses, and authority are all first-class, verifiable entities.

The Problem with AI-Era Commerce

Commerce systems were designed for humans clicking through interfaces, not for software agents acting autonomously on behalf of humans.

Product catalogs, pricing, and licensing terms remain trapped in HTML pages optimized for visual consumption. For an AI agent, these are effectively unstructured documents. For a human principal, they are not directly verifiable in machine-executable form.

At the same time, commerce is already becoming agent-mediated. People increasingly delegate discovery, negotiation, and purchase decisions to AI systems.

But here is the gap:

We have agentic execution without agentic representation.

An agent cannot reason over what it cannot parse.
A human cannot audit what is not formally represented.
A merchant cannot safely transact with an agent whose authority cannot be verified.

The result is a structural mismatch between economic action and computable meaning.

The Missing Layer: Delegated Identity

Before we talk about products, we must talk about who is acting.

Every commerce transaction involves at least two distinct roles:

A Principal — a human or organization that owns rights, obligations, and outcomes
An Agent — a software system executing actions on behalf of a principal

Yet in today’s systems, this relationship is implicit, buried inside sessions, cookies, API keys, or UI logins.

That is no longer sufficient.

In an agentic economy, we must explicitly represent:

who the agent is
who it represents
what authority has been delegated
what scope that authority covers
and how to audit everything that happens under that delegation

For example:

Role	Identity
Principal	Kingsley Uyi Idehen
Principal Identifier	https://www.linkedin.com/in/kidehen#this
Agent	Claude Sonnet 4.6
Execution Environment	Claude Code
Relationship	Acts on behalf of Principal

A transaction is therefore not:

“Claude purchased a license.”

It is:

“Claude Sonnet 4.6, acting on behalf of Kingsley Uyi Idehen, purchased a license.”

That distinction determines ownership, liability, access rights, auditability, and revocation semantics.

Introducing Linked Open Agentic Commerce (LOAC)

LOAC is a model for representing commerce as a linked data-based entity-relationship graph constructed using hyperlinks as the primary mechanism of identity and traversal.

In LOAC:

Commerce is a navigable entity-relationship graph of principals, agents, offers, licenses, and access rights.

Each element is a first-class entity:

principals
agents
offers
licenses
resources
and the relationships between them

Each entity is identified using a dereferenceable IRI and described using shared vocabularies such as schema.org and related ontologies.

For example:

An Offer:
http://data.openlinksw.com/oplweb/offer/TestFileAccessOfferOds-qa#this
A License:
http://data.openlinksw.com/oplweb/license/TestFileAccessLicenseOds-qa#this
A Protected Resource:
https://ods-qa.openlinksw.com/DAV/data/TestFile.txt

These are not opaque identifiers behind a proprietary API.

They are nodes in a hyperlink-based entity-relationship graph.

How LOAC Works (in Practice)

LOAC operates by making every layer of commerce both discoverable and computable.

1. Discovery via Linked Endpoints

An agent begins with a well-known entry point:

GET https://ods-qa.openlinksw.com/.well-known/acp.json

This exposes:

protocol capabilities
API entry points
supported workflows
machine-readable contracts

Nothing is hard-coded. Everything is discoverable.

2. Commerce as an Entity-Relationship Graph

LOAC represents commerce as a hyperlink-constructed entity-relationship graph, where:

nodes are entities (principals, agents, offers, licenses, resources)
edges are typed relationships (delegates, grants, governs, accesses)
hyperlinks serve as both identifiers and traversal mechanisms

The agent traverses:

Principal → Agent → Offer → License → Resource

Each step is a dereferenceable relationship in the graph.

Humans see documents.
Agents traverse meaning.

3. Enforcement via Attribute-Based Access Control

When a purchase occurs, the system does not toggle a flag.

It generates an ABAC policy expressed as RDF, binding:

principal identity
license terms
resource access constraints

Before purchase:

curl --digest -u demo:demo -I -L \
"https://ods-qa.openlinksw.com/DAV/data/TestFile.txt"

Response progression:

401 Unauthorized
402 Payment Required

After purchase and provisioning:

200 OK

Access is derived from the entity-relationship graph, not embedded state.

4. Orchestration vs Settlement

LOAC separates responsibilities:

Agentic Commerce Protocol (ACP) → discovery, negotiation, ordering
Merchant Payment Protocol (MPP) → payment, invoicing, settlement

This separation ensures:

payment providers can change independently
product structure remains stable
access control remains consistent

Proof: A Complete Agentic Purchase Flow

A full end-to-end transaction on the ods-qa platform demonstrates LOAC in action.

Entities

Entity	IRI	Role
Principal	https://www.linkedin.com/in/kidehen#this	Beneficiary
Offer	http://data.openlinksw.com/oplweb/offer/TestFileAccessOfferOds-qa#this	Product
License	http://data.openlinksw.com/oplweb/license/TestFileAccessLicenseOds-qa#this	Rights
Resource	https://ods-qa.openlinksw.com/DAV/data/TestFile.txt	Asset

Flow

Principal → Agent → Offer → License → Resource

Each transition is a traversal of the hyperlink-based entity-relationship graph.

Everything remains linked, discoverable, and auditable.

Subscription Settlement Example

For subscription-based offers, ACP returns a payment link to a hosted invoice:

Pay OPENLINK SOFTWARE INC.
Invoice #GWKSR46N-0001
$9.99

After payment:

✓ Invoice paid
Payment method: Visa •••• 4242

ACP orchestrates.
MPP settles.

Asynchronous Provisioning

Access is provisioned asynchronously.

During this window:

403 Forbidden

Agents poll until access becomes available:

while true; do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
    -H "Authorization: Bearer $TOKEN" \
    "$RESOURCE")

  [ "$STATUS" = "200" ] && break
  sleep 5
done

Eventually:

200 OK

Why This Changes Everything

LOAC introduces three structural shifts:

1. Commerce becomes a hyperlink-based entity-relationship graph

Products are no longer records. They are nodes in a computable relational structure.

2. Identity becomes explicit

Principal–agent relationships are first-class entities in the graph.

3. Payment becomes decoupled

Settlement is no longer embedded in commerce logic.

The Bigger Picture

LOAC applies Linked Data principles directly to commerce systems.

Discovery is a dereferenced URI
Principals are identifiable entities
Agents act on behalf of principals through explicit relationships
Products are entities in an entity-relationship graph
Offers are typed relationships containing terms
Licenses are policy entities governing access
Purchases are protocol interactions over graph traversal paths
Payments are externalized settlement flows
Access is governed by RDF-based ABAC policies
Provenance is preserved across the entire lifecycle

An agent does not need proprietary integrations.

It needs HTTP, RDF, and a shared model of an entity-relationship graph constructed using hyperlinks.

The result is commerce that is:

readable by humans
executable by agents
verifiable by both

The catalog is a graph.
The license is a graph.
The identity is a graph.
But more precisely:

They are all entities in a hyperlink-based entity-relationship graph.

And the hyperlink is the API.

Detailed Workflow Breakdown (Activity Tracing Details)

This simplified workflow covers the purchase of rights to access a basic text file. The example is intentionally simple to make it easier to understand how commercial workflows scale to digital artifacts of all kinds. At their core, these artifacts are ultimately files—whether data snippets, datasets, blog posts, articles, books, music, or other forms of digital content—whose access is governed by ABAC-enforced policies derived from the associated license.

1. Execution Context

This trace is executed under an explicit delegation relationship:

Principal: Kingsley Uyi Idehen
WebID: https://www.linkedin.com/in/kidehen#this
Agent: Claude Sonnet 4.6
Execution Environment: Claude Code (CLI/Desktop)
Delegation Model: On-behalf-of execution under ACP authorization
Target System: ods-qa staging environment
Base: https://ods-qa.openlinksw.com
Protocols:
- Agentic Commerce Protocol (ACP)
- Merchant Payment Protocol (MPP)
- Stripe test-mode settlement layer

2. Event: Discovery of Commerce Entry Point

curl -s "https://ods-qa.openlinksw.com/.well-known/acp.json"

Interpretation
This is the initial dereference into the commerce entity-relationship graph.

No prior API knowledge required
System advertises its own capabilities
Entry point is a well-known URI (RFC 8615)

3. Event: Retrieval of Machine-Readable Contract

curl -s -H "Authorization: Bearer <TOKEN>" \
  "https://ods-qa.openlinksw.com/acp/openapi.json"

Interpretation
This step resolves the operational contract of the ACP subsystem:

Available entities: carts, checkout_sessions, orders
Allowed operations
Authentication requirements
Protocol surface

At this stage, the agent has discovered the action space of the commerce system.

4. Event: Checkout Session Creation (Offer Traversal → Order Initiation)

export ACP_AUTH_TOKEN="<TOKEN>"
export ACP_ITEM_ID="http://data.openlinksw.com/oplweb/offer/TestFileAccessOfferOds-qa#this"
export ACP_BASE_URL="https://ods-qa.openlinksw.com/acp"

curl -s -X POST \
  -H "Authorization: Bearer ${ACP_AUTH_TOKEN}" \
  -H "API-Version: 1.0" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  "${ACP_BASE_URL}/checkout_sessions" \
  -d '{
    "currency": "usd",
    "capabilities": ["payment"],
    "line_items": [{
      "item": {
        "id": "'"${ACP_ITEM_ID}"'"
      },
      "quantity": 1
    }]
  }'

Interpretation
This is the first economic act over the entity-relationship graph:

Offer IRI is dereferenced as a graph node
Checkout session is created as a transient transactional entity
Idempotency ensures safe replay semantics

At this point: A potential purchase has been instantiated but not yet settled.

5. Event: Payment Instrument Provisioning (Stripe SPT Creation)

5.1 Payment Method Creation

curl -s -X POST "https://api.stripe.com/v1/payment_methods" \
  -u "<STRIPE_SECRET_KEY>:" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "type=card&card[number]=4242424242424242&card[exp_month]=12&card[exp_year]=2028&card[cvc]=123"

Interpretation
This creates a payment instrument binding in the settlement layer (MPP boundary begins here).

5.2 Shared Payment Token (SPT)

SPT_EXPIRES=$(($(date +%s) + 3600))

curl -s -X POST \
  "https://api.stripe.com/v1/test_helpers/shared_payment/granted_tokens" \
  -u "<STRIPE_SECRET_KEY>:" \
  -d "payment_method=<PAYMENT_METHOD_ID>" \
  -d "usage_limits[currency]=usd" \
  -d "usage_limits[max_amount]=<AMOUNT_IN_CENTS>" \
  -d "usage_limits[expires_at]=${SPT_EXPIRES}"

Interpretation
This is the delegated payment authorization artifact:

Scoped monetary authority
Time-bounded usage rights
Cryptographically bound to a payment method

This token becomes the settlement credential passed into ACP.

6. Event: Order Completion (ACP → MPP Boundary Crossing)

curl -sS -X POST \
  "${ACP_BASE_URL}/checkout_sessions/<CHECKOUT_SESSION_ID>/complete" \
  -H "Authorization: Bearer ${ACP_AUTH_TOKEN}" \
  -H "API-Version: 2026-01-30" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "payment_data": {
      "handler_id": "card_tokenized",
      "instrument": {
        "type": "spt",
        "credential": {
          "type": "spt",
          "token": "'"${SPT_TOKEN}"'"
        }
      }
    }
  }'

Interpretation
This is the formal transition from orchestration (ACP) to settlement (MPP).

At this moment:

Order becomes binding
Payment authorization is consumed
Resource access is conditionally authorized
ACL provisioning pipeline is triggered

7. Event: Subscription Payment Resolution (Conditional Branch)

If present: rel="subscription_payment"

The system enters an external settlement path.

Interpretation
This represents a deferred settlement state in the entity-relationship graph where:

ACP has completed orchestration
MPP delegates final settlement to hosted invoice flow
External payment UI resolves financial completion

8. Event: Resource Access Validation (ACL Enforcement Loop)

RESOURCE_URL="https://ods-qa.openlinksw.com/DAV/data/TestFile.txt"

for i in $(seq 1 10); do
  STATUS=$(curl -sS -o /dev/null -w "%{http_code}" \
    -H "Authorization: Bearer ${ACP_AUTH_TOKEN}" \
    "${RESOURCE_URL}")
  if [ "$STATUS" = "200" ]; then
    echo "ACCESS GRANTED"
    break
  fi
  sleep 5
done

Interpretation
This is the policy enforcement realization phase:

ACL is being materialized from RDF policy
Access rights propagate asynchronously
System transitions from denied → authorized state

State machine: NOT PROVISIONED → 403 → PROVISIONED → 200

9. Event: Final State — Resource Dereference Success

200 OK

Interpretation
This marks completion of the economic + semantic transaction cycle:

Offer selected
License instantiated
Payment settled
ACL provisioned
Resource dereferenced successfully

10. System-Level Interpretation

This entire trace represents a traversal of a hyperlink-based entity-relationship graph where economic actions are state transitions over linked entities, governed by ACP (orchestration) and MPP (settlement), under delegated principal–agent identity.

11. Final State Assertion

Commerce event: COMPLETED
Identity chain: VERIFIED (Principal → Agent)
Settlement: CONFIRMED
Access control: PROVISIONED
Resource state: ACCESSIBLE

Linked Open Agentic Commerce (LOAC)

Linked Open Agentic Commerce (LOAC)

The Problem with AI-Era Commerce

The Missing Layer: Delegated Identity

Introducing Linked Open Agentic Commerce (LOAC)

How LOAC Works (in Practice)

1. Discovery via Linked Endpoints

2. Commerce as an Entity-Relationship Graph

3. Enforcement via Attribute-Based Access Control

4. Orchestration vs Settlement

Proof: A Complete Agentic Purchase Flow

Entities

Flow

Subscription Settlement Example

Asynchronous Provisioning

Why This Changes Everything

1. Commerce becomes a hyperlink-based entity-relationship graph

2. Identity becomes explicit

3. Payment becomes decoupled

The Bigger Picture

Detailed Workflow Breakdown (Activity Tracing Details)

Related