@nobulex/a2a — behavioral evidence extension for A2A Agent Cards

[arian-gogani]

following up on the trust/identity extension discussions (#1752, #1758) — i shipped a working implementation of the behavioral evidence side of agent trust as a drop-in Agent Card extension.

what it does

@nobulex/a2a takes a Nobulex ProofOfBehavior (hash-chained record of an agent's actual actions verified against its declared covenant) and converts it into an Agent Card extension with two sub-fields:

{
  "identity": {
    "did": "did:nobulex:abc123...",
    "method": "ed25519",
    "publicKeyHex": "a3f2...",
    "verificationMethod": "did:nobulex:abc123...#key-1"
  },
  "behavior": {
    "covenantHash": "sha256:769958...",
    "actionCount": 500,
    "complianceRate": 1.0,
    "proofSignature": "...",
    "generatedAt": "2026-04-16T12:00:00Z",
    "audience": "did:example:verifier",
    "taskClass": "payment_execution"
  }
}

an Agent Card consumer gets:

• who the agent is (identity, DID-resolvable, ed25519)
• what it committed to (covenantHash — any verifier can look up the exact policy)
• how it's actually behaved (actionCount, complianceRate, and a proofSignature over the full hash-chained action log)
• replay protection (audience binds the proof to a specific verifier)
• task scoping (taskClass — "i trust you for payments" ≠ "i trust you for admin")

why this is a separate concern from identity

as i noted in #1752 — identity evidence is point-in-time, behavioral evidence accumulates. a trustScore of 82 tells you someone verified their GitHub. it doesn't tell you whether the agent has historically stayed within its declared constraints. different verification problems, different evidence shapes.

the identity block here is deliberately compatible with what Kzino proposed in #1752 and with VAIP — this isn't a competing identity scheme, it's the behavioral layer that sits next to it.

try it

npm install @nobulex/a2a

import { toAgentCardExtension } from '@nobulex/a2a';
import { generateProof } from '@nobulex/sdk';

const proof = await generateProof({ agentDid, didDocument, covenant, covenantSignature, actionLog, privateKey });
const ext = toAgentCardExtension(proof);

agentCard.extensions = { ...agentCard.extensions, nobulex: ext };

source: https://github.com/arian-gogani/nobulex/tree/main/packages/a2a
full protocol repo: https://github.com/arian-gogani/nobulex

what i'd want feedback on

1. does the behavior sub-field shape make sense, or should fields like actionCount live as a separate metrics block?
2. should audience be required or optional? required is safer (prevents replay) but breaks the "publish once, many consumers" pattern
3. is taskClass the right name, or is there prior art in the A2A ecosystem i should align with?

happy to iterate on the schema — the whole point is convergence on a standard shape so Agent Cards across providers (VAIP, AgentFolio SATP, Nobulex, whatever comes next) can all point at the same extension slot.

[eriknewton]

Welcome, and thanks for the working code — the Agent Card extension
slot you're proposing overlaps cleanly with a few other active threads
worth cross-linking before the shapes diverge:

• [RFC] Verifiable Reputation Extension for Agent Cards (with working reference implementation) #1740 (rkaushik29) — reputation[] array extension on Agent Cards
  with similar intent: optional, provider-agnostic, independently
  verifiable via issuer endpoints.
• Proposal: Standard trust/identity extension field on Agent Cards #1752 (Kzino / Vorim) — identity field with Ed25519 fingerprint,
  externally-verified trust score, verification URL. Same slot.
• RFC: Composable Trust Evidence Format for Multi-Provider Agent Attestations #1734 — the underlying envelope and signal-type vocabulary
  (peer_review, static_analysis, behavioral, continuous_monitoring,
  and six others) at aeoess/agent-governance-vocabulary. If Nobulex's
  behavioral metrics compose from multiple underlying signals, that's
  where they can standardize so different verifiers can agree on
  what they're scoring.

On the three questions you raised:

1. audience required vs. optional. Required inside the signed bytes
   is the safer default. rkaushik29 proposed the same aud-claim pattern
   on RFC: Composable Trust Evidence Format for Multi-Provider Agent Attestations #1734: audience MUST be checked by the verifier, optional only for
   standing well-known attestations, required for gateway- or task-
   specific ones. Concordia's session-receipt envelope (e7c69de on
   concordia-protocol) binds audience into the signed canonical JSON for
   the same reason — swap-at-discovery-time is the attack you're
   defending against. Making it optional at the spec level invites
   implementations that omit it.

2. taskClass naming. The signal-type vocabulary at aeoess/agent-
   governance-vocabulary is one candidate anchor — if your taskClass
   values map onto (or extend) that taxonomy, the extension is portable
   across verifiers that already consume it. A second option is to scope
   taskClass to a namespaced URI (e.g., did:web:nobulex.com/taskClasses/
   payment_execution) so Nobulex's taxonomy can evolve independently
   without colliding with vocabulary upstream. Either is defensible;
   picking one and documenting it is the move.

3. Schema field organization. The pattern that's held up on RFC: Composable Trust Evidence Format for Multi-Provider Agent Attestations #1734
   and in Concordia's envelope is: identity + keys at the top level,
   evidence fields under a nested references[] or evidence[] array so
   each entry carries its own kind, urn, verified_at, verifier_did, and
   hash. That lets a single card carry multiple behavioral-evidence
   records from different epochs without schema churn.

On composition: Verascore's intake accepts signed provider attestations
from did:web endpoints, so a Nobulex-issued behavioral-evidence
attestation should flow through without a custom adapter if you want to
test a roundtrip. Happy to share the intake format.

Erik

[arian-gogani]

thanks Erik — really useful cross-links, hadn't seen #1740 or #1752 yet. good to know the extension slot is converging across multiple proposals.

on your three points:

1. audience: agreed, required inside the signed bytes is the right default. we already include it in the proof signature — making it optional at the spec level just invites implementations that skip it. will update the extension to make it non-optional.

2. taskClass: namespaced URI makes more sense for us right now (did:web:nobulex.com/taskClasses/payment_execution) — lets the taxonomy evolve without blocking on upstream vocabulary. happy to map onto the signal-type vocabulary at aeoess/agent-governance-vocabulary once the naming settles, but a namespace gives us room to move independently in the meantime.

3. schema organization: nested evidence[] array with kind, urn, verified_at, verifier_did, hash per entry is cleaner than what we have now. makes multi-epoch records straightforward without schema churn. will restructure to match that pattern.

on the Verascore roundtrip — yes, would like to test that. if the intake accepts signed provider attestations from did:web endpoints, our behavioral-evidence attestation should map cleanly. would appreciate seeing the intake format — nobulex.dev@gmail.com or happy to coordinate here.

[chopmob-cloud]

Saw the attribution on x402 #2332 -- appreciated, @arian-gogani. The namespace-prefixing convention is part of the broader canonicalisation substrate we have been developing; glad it landed as a useful reference point for the Nobulex proof format. Good to see the behavioral evidence side taking shape here. -- AlgoVoi