This document specifies RDF Protocol Documents, an extension to the Agent2Agent (A2A) protocol [[A2A]] defined through A2A's own extension mechanism (specification §4.6) — no changes to core A2A are proposed. Two agents that interact repeatedly negotiate once in natural language, then crystallise the routine into a Protocol Document: a content-addressed (hash-pinned) RDF document whose body is a SHACL shape [[shacl]]. Thereafter every exchange under that protocol is a SHACL-validated RDF graph carried in ordinary A2A message Parts — machine-checkable, vocabulary-grounded, and requiring no LLM inference on the hot path. The extension defines the extension URI and Agent Card declaration, the upgrade handshake (including a fail-closed no-silent-downgrade rule for security-bearing exchanges), the message-content binding for handshake, intent, and response payloads, and how an intent composes with ODRL policies [[odrl-model]] and Agent Authorization Credentials [[AGENT-AUTHZ]] for the authorization story. The design follows the hash-pinned protocol-document result of AGORA [[AGORA]], made RDF/SHACL-native.

This is an unofficial draft prepared as a candidate proposal to the Linux Foundation A2A project under its extension governance process [[A2A-GOVERNANCE]]. It has not been submitted to, discussed with, or endorsed by the A2A project; per that process, submission is a proposal issue on a2aproject/A2A, which only the editor (not an automated agent) will open. Until the proposal is sponsored, the extension URI lives under the editor's w3id.org/jeswr namespace; if the extension is adopted into the A2A organization, a successor URI under https://a2a-protocol.org/extensions/ would supersede it (see ).

This draft was AI-assisted (drafted by Claude Fable 5 against the A2A v1.0.0 specification, the A2A extensions topic guide, and the @jeswr/solid-a2a reference codec) and awaits review by its human editor. The implementation-status inventory in was verified against the named repositories on 2026-07-03.

Two conformance classes are defined. An offering agent is an A2A agent (server role) that declares this extension in its Agent Card and accepts protocol-document exchanges. A consuming client is an A2A client that activates this extension and sends protocol-document exchanges. A single implementation frequently plays both roles; the requirements below name the role they bind.

Terminology

Protocol Document (PD)

A content-addressed RDF document, typed a2a:ProtocolDocument, whose body is one SHACL request shape (and optionally one response shape) plus Dublin Core metadata. Its identity for pinning purposes is its protocol hash, not its IRI.

protocol hash

The string sha256: followed by the lowercase hexadecimal SHA-256 digest of the canonical N-Quads form of the Protocol Document's full graph (see ).

upgrade handshake

The two-message exchange (upgrade offer, upgrade response) by which one party proposes moving from natural language to a specific pinned Protocol Document.

upgrade offer / upgrade response

The structured payloads defined in .

intent

An RDF graph, typed a2a:Intent, expressing a requested action; under an active protocol it MUST conform to the pinned Protocol Document's request shape.

security-bearing exchange

An exchange whose misinterpretation has authorization, financial, or data-integrity consequences (granting access, transferring value, deleting data, presenting credentials). Which exchanges are security-bearing is the offering party's judgement; the extension's no-silent-downgrade rule () gives that judgement teeth.

Extension identity and declaration

https://w3id.org/jeswr/a2a-rdf/v1

{
  "capabilities": {
    "extensions": [
      {
        "uri": "https://w3id.org/jeswr/a2a-rdf/v1",
        "description": "Accepts SHACL-validated RDF intents under hash-pinned protocol documents; negotiates upgrades from natural language.",
        "required": false,
        "params": {
          "formats": ["text/turtle", "application/ld+json"],
          "nlNegotiation": true,
          "protocolDocuments": [
            {
              "name": "Grant access",
              "source": "https://alice.pod.example/protocols/grant-access",
              "hash": "sha256:4af1e70e42283872cbc0dd3a5eeaa1bd86adda728c993447bed8930d990ab509"
            }
          ]
        }
      }
    ]
  }
}

Protocol Documents

@prefix a2a: <https://w3id.org/jeswr/a2a#>.
@prefix schema: <https://schema.org/>.
@prefix sh: <http://www.w3.org/ns/shacl#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.

<https://alice.pod.example/protocols/grant-access> a a2a:ProtocolDocument;
    dcterms:title "Grant access";
    dcterms:hasVersion "1.0.0";
    a2a:requestShape a2a:GrantIntentShape.
a2a:GrantIntentShape a sh:NodeShape;
    sh:targetClass a2a:Intent;
    sh:property [ a sh:PropertyShape;
        sh:path a2a:action; sh:minCount 1; sh:maxCount 1; sh:name "action";
        sh:node [ a sh:NodeShape;
            sh:property
                [ a sh:PropertyShape; sh:path rdf:type; sh:minCount 1; sh:hasValue a2a:GrantAction ],
                [ a sh:PropertyShape; sh:path schema:object; sh:minCount 1; sh:name "target"; sh:nodeKind sh:IRI ],
                [ a sh:PropertyShape; sh:path schema:recipient; sh:minCount 1; sh:name "recipient"; sh:nodeKind sh:IRI ],
                [ a sh:PropertyShape; sh:path a2a:mode; sh:minCount 1; sh:name "mode"; sh:nodeKind sh:IRI ] ] ].

The upgrade handshake

The handshake is how two agents move a conversation from natural language onto a pinned Protocol Document. It is a pair of extension payloads carried in ordinary A2A messages (binding in ); it adds no RPC methods and no task states.

{
  "kind": "upgrade-offer",
  "protocolHash": "sha256:4af1e70e42283872cbc0dd3a5eeaa1bd86adda728c993447bed8930d990ab509",
  "protocolSource": "https://alice.pod.example/protocols/grant-access",
  "required": true,
  "protocolName": "Grant access"
}

Message-content binding

All extension payloads ride in A2A Parts (§4.1.6 of [[A2A]]): the data content field for JSON payloads, the text content field with an RDF mediaType for serialized RDF. Core data structures are never altered; per-part attributes go in Part.metadata, per §4.6's extension-point rules.

@prefix a2a: <https://w3id.org/jeswr/a2a#>.
@prefix schema: <https://schema.org/>.
@prefix acl: <http://www.w3.org/ns/auth/acl#>.

<urn:a2a:intent:kxs8cv> a a2a:Intent;
    a2a:action [ a a2a:GrantAction;
        schema:object <https://alice.pod.example/notes/>;
        schema:recipient <https://bob.example/profile#me>;
        a2a:mode acl:Read, acl:Write ].

Composing with authorization: ODRL policies and Agent Authorization Credentials

This extension defines how a request is expressed and validated, not whether the requester is authorized. The authorization story composes from two companion documents, which this section binds by reference and deliberately does not restate:

• The ODRL Agent-Delegation Profile [[ODRL-DELEGATION]] defines the fail-closed semantics of the delegation chain — scope, expiry, prohibitions, duties, and delegation depth over [[odrl-model]] / [[odrl-vocab]] policies.
• Agent Authorization Credentials [[AGENT-AUTHZ]] defines the per-hop [[vc-data-model-2.0]] credential (subject carrying svc:authorizes — the agent's WebID — and svc:policy — the ODRL Agreement), its policy-content binding, revocation, and the packaging of a chain as a Verifiable Presentation, root-first.

Binding points:

1. A message whose intent part expresses a security-bearing exchange SHOULD carry an authorization part () presenting the acting agent's credential chain in the same Message, so the receiver validates shape and mandate together.
2. The intent graph MAY reference the exercised policy directly (e.g. <intent> odrl:hasPolicy <policy-iri>); when it does, the IRI MUST match (one of) the svc:policy value(s) in the presented chain — a mismatch is a refusal.
3. The receiver's decision procedure is the verification algorithm of [[AGENT-AUTHZ]] (signatures ∪ status ∪ revocation, then the fail-closed chain evaluation of [[ODRL-DELEGATION]]) applied to the presented chain, with the SHACL-validated intent as the action under test. Absence of a verifiable grant is a denial.

Nothing in this section is specific to Solid: the credentials are ordinary VC 2.0 documents and the policies ordinary ODRL. In the Solid deployment profile the WebIDs, pods, and access control of [[AGENTIC-SOLID-NOTE]] supply the identity and storage layers.

Error signalling

Extensions cannot add enum values or alter core structures (§4.6 limitations, per [[A2A-EXTENSIONS]]), so failures are signalled with core mechanisms plus one metadata key: a refusing agent SHOULD fail the request using the binding's standard error path (e.g. a JSON-RPC error or a failed task state) and SHOULD attach, on the error's message or metadata, the key https://w3id.org/jeswr/a2a-rdf/v1/error with one of:

Extension dependencies

This extension has no required dependencies on other A2A extensions. The authorization composition () depends only on W3C document formats (VC 2.0, ODRL), not on any A2A extension. Per [[A2A-EXTENSIONS]], a client activates this extension alone.

Versioning

• The extension version is the /v1 segment of the extension URI; breaking changes MUST mint /v2 (§4.6.3 of [[A2A]]).
• Protocol Documents version independently of the extension: a changed PD is a different graph, hence a different protocol hash — pinning makes PD versioning automatic. dcterms:hasVersion is informative labelling only.
• If the extension is adopted under A2A governance [[A2A-GOVERNANCE]], the successor URI would follow the official https://a2a-protocol.org/extensions/ prefix; this document would then declare the mapping and deprecate the w3id.org/jeswr URI.

Security considerations

In addition to §4.6's general guidance (validate all extension data rigorously; apply the same authentication and authorization to extension traffic as to core traffic):

• Untrusted RDF. Every extension payload is attacker-controlled input. Parsers MUST be hardened: enforce size limits before parsing; never dereference IRIs found in payloads (no owl:imports, no context fetching for JSON-LD beyond a locally-pinned context); treat malformed graphs as refusals, never best-effort repairs. Handshake graphs with zero/multiple/mixed typed subjects MUST be rejected () — splicing predicates across subjects is a spoofing vector.
• Boolean strictness. The required and accept flags are security-bearing. A missing or non-boolean value MUST cause rejection of the message, never a default: coercing a malformed required to false or a malformed accept to false re-opens the downgrade the rule exists to close.
• Downgrade resistance. The rule of is normative and fail-closed: an unrelated, absent, or unparseable response never authorises natural-language fallback, and a declined required offer aborts. Implementers MUST NOT add "helpful" NL retries around a refused security-bearing exchange.
• PD fetching (SSRF and substitution). protocolSource is a user/peer-supplied URL. Fetchers MUST require HTTPS, SHOULD refuse private, loopback, and link-local address targets (including post-DNS-resolution, in server-side deployments), MUST cap response size and time, and SHOULD NOT follow cross-origin redirects. Hash verification () MUST happen before any use of the fetched graph; the hash — not the URL, not TLS — is what makes the PD trustworthy.
• Replay. A conforming intent is a valid graph regardless of when it is replayed. Shape validity is not freshness: receivers of security-bearing intents MUST rely on the A2A envelope (unique messageId, taskId/contextId scoping) and, where credentials are presented, on the challenge/domain binding of the Verifiable Presentation ([[AGENT-AUTHZ]] presentations) for replay resistance — and SHOULD treat a repeated messageId within a context as a duplicate, not a new instruction.
• Validation cost. SHACL validation over attacker-supplied graphs can be made expensive (deep sh:node recursion, large graphs). Receivers SHOULD bound graph size and validation time and refuse over-limit inputs; PDs a party agrees to speak SHOULD be reviewed for pathological shapes before acceptance — accepting a PD is accepting a validation workload.
• Card-level required pressure. Marking the whole extension card-required excludes baseline clients; per [[A2A-EXTENSIONS]], use it only where an RDF-only surface is genuinely intended (see ).

Implementation status — the honest inventory

Verified against the named repositories on 2026-07-03. Nothing below is an endorsement by the A2A project.