Screencast Storyboard · Voiceover Script + On-Screen Sequence Diagrams

Understanding "On-Behalf-Of" for Delegated Agentic Commerce Using ACP & UCP

There is no shopping cart in this story, and no "Buy Now" button — because there never was one. Commerce here is a status code and a document: 402 when you haven't paid, 200 when you have. This ~5:19 field test asks what happens when an AI agent tries to read on a human principal's behalf, across both the ACP and UCP protocols — and shows, live, exactly where that works and where it rightly doesn't.

9 scenes · ~5:19 runtime Covers: UCP + ACP Source: live curl / ucp-client / acp-client tests, 2026-09-14

Participants — Verified Identities

Every "Principal" and "Agent" in the diagrams below is a real, cryptographically-verified WebID-TLS identity — not a placeholder. Cert moduli re-checked against each identity's published profile.ttl immediately before this document was written.

Principal — "You"
Kingsley Uyi Idehen · Founder & CEO, OpenLink Software
WebID: .../link-in-bio-credentials-5/index.html#netid ✅
Cert: CN=Kingsley Uyi Idehen · SHA-1 DE:9B:0F:1E:83:DB:2F:0E:A1:70:E5:35:05:29:CB:95:D4:E6:81:07
Valid 2026-06-16 → 2027-06-16 · modulus ✅ matches profile.ttl (c71938...)
Agent — "Your AI Agent" (me, Claude Sonnet 5)
Delegate identity, presented on every agent request in this test
WebID: .../link-in-bio-agent-credentials/index.html#netid ✅
Cert: CN=Kingsley Idehen's Agent · SHA-1 B9:58:40:EF:17:45:B7:5E:FE:B9:1F:8B:CD:11:47:DE:98:6A:19:CD
Valid 2026-06-18 → 2027-06-18 · modulus ✅ matches profile.ttl (da2b89...)

Delegation ✅ corroborated on both sides: the principal's profile.ttl declares oplcert:hasIdentityDelegate → the agent's WebID, and the agent's own profile.ttl declares oplcert:onBehalfOf → the principal's WebID, consistent across Turtle, JSON-LD, RDFa, and the POSH link in index.html.

Resources Under Test

Every scene below is a live outcome against one of these two real, protected files on linkeddata.uriburner.com — not synthetic examples.

  1. Entitled resource (principal has a confirmed prior purchase) — used in Scenes 3, 4, 5, 6, 8:
    https://linkeddata.uriburner.com:5443/DAV/demos/daas_paid/food-bookmark-collection-snapshot-2026-09-08.html
  2. Never-purchased resource (control — no entitlement exists for anyone) — used in Scene 7:
    https://linkeddata.uriburner.com:5443/DAV/demos/daas_paid/trackloaded-premium-knowledge-inventory-snapshot-2026-09-08.ttl

Scene Index

  1. The Proposition 0:00–0:33
  2. UCP and ACP Meet at the Resource 0:33–1:05
  3. Establish the Baseline 1:05–1:36
  4. Verify the Entitlement 1:36–2:02
  5. Agent Identity Alone Is Insufficient 2:02–2:36
  6. Add Explicit Delegation 2:36–3:20
  7. Now Test the Boundary 3:20–3:48
  8. Try to Break It 3:48–4:27
  9. Why This Matters 4:27–5:16
1The Proposition
0:00 – 0:33
On screen
sequenceDiagram participant You as You (Principal) participant Agent as Your AI Agent participant RS as Paid Resource Server You->>Agent: "Go get that report for me" Agent-->>RS: ??? note over Agent,RS: Does the server know
the agent is acting for you?
Title card fades in over the diagram: "Does On-Behalf-Of actually work?"
Voiceover

No cart. No login form. No "Buy Now" button. Just a URL — and HTTP.

Request a protected resource without entitlement and the server responds: 402 Payment Required. Complete the purchase, retry the request, and the resource becomes readable.

That suggests a powerful model for agentic commerce: if buying ultimately establishes the right to access a resource, can an AI agent exercise that right on your behalf — without becoming you? That is what we're going to test.

2UCP and ACP Meet at the Resource
0:33 – 1:05
On screen
flowchart LR subgraph Clients["Two different client protocols"] UCP["UCP
(discover an RDF offer,
create a checkout)"] ACP["ACP
(intent-driven purchase,
cart & order flows)"] end UCP --> MPP ACP --> MPP MPP["Same gate underneath:
MPP — HTTP 402 Payment Required"] MPP --> RS[("Protected Resource")]
Voiceover

We'll use two commerce protocols. UCP discovers the offer and initiates checkout. ACP supports cart-and-order purchasing. Their transaction models differ.

But ultimately, both arrive at the same protected resource and the same MPP-controlled 402 boundary. That distinction matters.

Commerce establishes entitlement. The resource enforces it. So delegation can be tested independently of whether the purchase originated through UCP or ACP.

Part One — Without Delegation

First, the baseline: how does the gate behave when the principal shows up as themselves — no agent, no On-Behalf-Of header at all?

3Establish the Baseline
1:05 – 1:36
On screen
sequenceDiagram participant P as Principal (own cert) participant RS as Resource Server participant Pay as Stripe (SPT) P->>RS: GET protected resource RS-->>P: 302 Found → ?k=session-key P->>RS: GET (follow redirect) RS-->>P: 402 Payment Required
(offer, price, currency) P->>Pay: Request payment token Pay-->>P: Token P->>RS: Retry with payment credential RS-->>P: 200 OK + Payment-Receipt
Resource: .../daas_paid/food-bookmark-collection-snapshot-2026-09-08.html
Voiceover

First, the control case. The principal authenticates with its own certificate and requests the Food Bookmark Collection on URIBurner. It has never purchased this resource.

The result: 402 Payment Required. The response carries the information required to purchase access. Complete the payment. Retry the same URL. 200 OK. The resource is returned.

We have now established our baseline: this principal is entitled to this resource.

402 until paid200 after checkout
4Verify the Entitlement
1:36 – 2:02
On screen
sequenceDiagram participant P as Principal (own cert) participant RS as Resource Server P->>RS: GET the SAME resource, later rect rgb(220,252,231) RS-->>P: 200 OK — direct, no challenge end
Resource: same Food Bookmark Collection file as Scene 3
Voiceover

Now request exactly the same URL again using exactly the same principal identity. 200 OK. No checkout. No second payment.

This isn't merely a completed transaction. The server now recognizes a persistent relationship: this principal has standing to access this resource. That is the relationship we are about to delegate.

200 direct — no re-challenge

Part Two — With Delegation

Now the agent shows up instead — presenting its own certificate, with an On-Behalf-Of header naming the principal.

5Agent Identity Alone Is Insufficient
2:02 – 2:36
On screen
sequenceDiagram participant Ag as Agent (own cert, NO header) participant RS as Resource Server Ag->>RS: GET the principal's entitled resource rect rgb(254,242,242) RS-->>Ag: 302 → 402 Payment Required end note over Ag,RS: The agent is a stranger here —
the principal's purchase doesn't rub off
Resource: same Food Bookmark Collection file
Voiceover

Now change only the requester. The AI agent authenticates with its own certificate and requests the same resource. The principal is entitled. The agent is not.

Result: 402 Payment Required. That is important. The agent's possession of the URL conveys nothing. Its relationship with the principal conveys nothing implicitly. And its own authenticated identity does not inherit the principal's rights.

Authentication answers who the agent is. It does not answer on whose authority it is acting.

402 — agent is unentitled on its own
6Add Explicit Delegation
2:36 – 3:20
On screen
sequenceDiagram participant Ag as Agent (own cert) participant RS as Resource Server Ag->>RS: GET, header: On-Behalf-Of: Principal RS->>RS: Look up entitlement for the
NAMED identity, not the certificate rect rgb(220,252,231) RS-->>Ag: 200 OK — direct, no payment step end
Resource: .../daas_paid/food-bookmark-collection-snapshot-2026-09-08.html
Voiceover

Now we add the delegation signal: On-Behalf-Of. The agent continues authenticating with its own certificate. But the request explicitly identifies the principal on whose behalf the agent is acting. Same agent. Same resource. Same agent certificate. One additional relationship.

Result: 200 OK. We repeated this eleven times and verified it three ways: raw HTTP, the UCP client, and the ACP client. The agent made no new purchase. It did not impersonate the principal.

The principal's existing entitlement was exercised through an explicitly delegated agent.

200 direct — 11/11, order-independent
7Now Test the Boundary
3:20 – 3:48
On screen
sequenceDiagram participant Ag as Agent (own cert) participant RS as Resource Server Ag->>RS: GET a DIFFERENT resource,
same header: On-Behalf-Of: Principal RS->>RS: Principal has NEVER bought this one rect rgb(254,242,242) RS-->>Ag: 302 → 402 Payment Required — unchanged end
Resource: .../daas_paid/trackloaded-premium-knowledge-inventory-snapshot-2026-09-08.ttl (a different file — never purchased by anyone)
Voiceover

But delegation must have limits. So we point the same delegated agent at another protected resource: the Trackloaded Premium Knowledge Inventory. The principal has never purchased it.

Result: 402 Payment Required. Exactly what we want. On-Behalf-Of does not give the agent a wallet. It does not authorize arbitrary purchases. And it does not manufacture entitlements.

Delegation extends an existing right. It does not create one.

402 — unpurchased resource, header present
8Try to Break It
3:48 – 4:27
On screen
flowchart TD A["On-Behalf-Of: exact principal"] -->|"200 OK"| G1["✅ granted"] B["On-Behalf-Of: agent's own WebID"] -->|"402"| G2["🚫 blocked"] C["On-Behalf-Of: unrelated real WebID"] -->|"402"| G2 D["On-Behalf-Of: empty value"] -->|"402"| G2 E["Different header name entirely"] -->|"402"| G2
Resource: same Food Bookmark Collection file used in Scene 6
Voiceover

Now the important security test. What happens if the agent simply lies? Use the agent itself as the On-Behalf-Of identity. 402. Use an unrelated identity. 402. Omit the delegation identity. 402. Use a different header entirely. 402.

Only the correctly identified principal with an existing entitlement produces: 200 OK. So the header isn't functioning as a bypass.

The server is evaluating an authenticated agent, a delegated principal, and an existing entitlement relationship.

Only the exact named principal unlocks it
9Why This Matters
4:27 – 5:16
On screen
flowchart LR A["Delegation =
'inherit MY existing purchases'"] --- B["NOT
'spend on my behalf'"] style A fill:#ecfdf5,stroke:#a7f3d0 style B fill:#fef2f2,stroke:#fecaca
Voiceover

And that is the architectural point. The principal has one identity. The agent has another. The resource has its own identity.

Authentication establishes who is making the request. On-Behalf-Of establishes the delegation relationship. And the resource's authorization layer determines whether that relationship carries sufficient entitlement.

UCP or ACP can establish the commerce transaction. MPP can enforce the 402 boundary. But the agent never needs to become the principal. And it doesn't need unrestricted access to the principal's wallet.

Identity remains distinct. Delegation remains explicit. Authorization remains with the resource. That's a foundation on which agentic commerce can scale.

Full Voiceover Transcript

Continuous read-through for recording, without scene chrome.

Scene 1No cart. No login form. No “Buy Now” button. Just a URL — and HTTP. Request a protected resource without entitlement and the server responds: 402 Payment Required. Complete the purchase, retry the request, and the resource becomes readable. That suggests a powerful model for agentic commerce: If buying ultimately establishes the right to access a resource, can an AI agent exercise that right on your behalf — without becoming you? That is what we’re going to test.
Scene 2We’ll use two commerce protocols. UCP discovers the offer and initiates checkout. ACP supports cart-and-order purchasing. Their transaction models differ. But ultimately, both arrive at the same protected resource and the same MPP-controlled 402 boundary. That distinction matters. Commerce establishes entitlement. The resource enforces it. So delegation can be tested independently of whether the purchase originated through UCP or ACP.
Scene 3First, the control case. The principal authenticates with its own certificate and requests the Food Bookmark Collection on URIBurner. It has never purchased this resource. The result: 402 Payment Required. The response carries the information required to purchase access. Complete the payment. Retry the same URL. 200 OK. The resource is returned. We have now established our baseline: this principal is entitled to this resource.
Scene 4Now request exactly the same URL again using exactly the same principal identity. 200 OK. No checkout. No second payment. This isn't merely a completed transaction. The server now recognizes a persistent relationship: this principal has standing to access this resource. That is the relationship we are about to delegate.
Scene 5Now change only the requester. The AI agent authenticates with its own certificate and requests the same resource. The principal is entitled. The agent is not. Result: 402 Payment Required. That is important. The agent's possession of the URL conveys nothing. Its relationship with the principal conveys nothing implicitly. And its own authenticated identity does not inherit the principal's rights. Authentication answers who the agent is. It does not answer on whose authority it is acting.
Scene 6Now we add the delegation signal: On-Behalf-Of. The agent continues authenticating with its own certificate. But the request explicitly identifies the principal on whose behalf the agent is acting. Same agent. Same resource. Same agent certificate. One additional relationship. Result: 200 OK. We repeated this eleven times and verified it three ways: raw HTTP, the UCP client, and the ACP client. The agent made no new purchase. It did not impersonate the principal. The principal's existing entitlement was exercised through an explicitly delegated agent.
Scene 7But delegation must have limits. So we point the same delegated agent at another protected resource: the Trackloaded Premium Knowledge Inventory. The principal has never purchased it. Result: 402 Payment Required. Exactly what we want. On-Behalf-Of does not give the agent a wallet. It does not authorize arbitrary purchases. And it does not manufacture entitlements. Delegation extends an existing right. It does not create one.
Scene 8Now the important security test. What happens if the agent simply lies? Use the agent itself as the On-Behalf-Of identity. 402. Use an unrelated identity. 402. Omit the delegation identity. 402. Use a different header entirely. 402. Only the correctly identified principal with an existing entitlement produces: 200 OK. So the header isn't functioning as a bypass. The server is evaluating an authenticated agent, a delegated principal, and an existing entitlement relationship.
Scene 9And that is the architectural point. The principal has one identity. The agent has another. The resource has its own identity. Authentication establishes who is making the request. On-Behalf-Of establishes the delegation relationship. And the resource's authorization layer determines whether that relationship carries sufficient entitlement. UCP or ACP can establish the commerce transaction. MPP can enforce the 402 boundary. But the agent never needs to become the principal. And it doesn't need unrestricted access to the principal's wallet. Identity remains distinct. Delegation remains explicit. Authorization remains with the resource. That's a foundation on which agentic commerce can scale.