Standards and protocols

STACK uses standard token formats and protocols to connect clients, verify identities and exchange signed records. The sections below distinguish those working interfaces from evidence formats that STACK can record but does not independently verify.

Passports and signed records

Passports are JSON Web Tokens signed with EdDSA using Ed25519 keys. Public verification keys are published as JSON Web Keys. The relevant specifications are JWT (RFC 7519), JWK (RFC 7517) and Edwards curves in JOSE (RFC 8037). Signature verification establishes who signed a token; an offline verifier must also check expiry and use an online revocation check if it needs current access status.

Individual Passport claims use signed envelopes based on COSE_Sign1 (RFC 9052). The envelope contains the claim and its signature, while the signing mode determines who holds the signing key. A standard envelope is not, by itself, evidence that an external transparency service has registered it. See agent signing keys and evidence exports.

Client connections

The MCP server uses Streamable HTTP, with OAuth and PKCE for interactive client authorization. STACK requires the S256 challenge method and publishes authorization-server metadata for client discovery. These are the client-to-STACK controls; connecting an upstream service uses that service’s own supported authentication flow. See the MCP authorization specification and MCP setup.

The A2A interface publishes an Agent Card at /.well-known/agent.json on the API host and accepts JSON-RPC requests at /v1/a2a/jsonrpc. Its supported operations are defined by that interface; an Agent Card does not grant access to an agent or service.

Identity federation

OpenID Connect connects a configured identity provider to STACK. Issuer discovery, signature verification and configured claim mapping determine which identity STACK accepts; accepting an ID token does not automatically establish a person’s legal identity or authority to act for an organisation. See authentication and authority.

Workloads can present a SPIFFE JWT-SVID or a WIMSE JWT Workload Identity Token. STACK checks the configured issuer, audience and subject-to-agent mapping before issuing a Passport. It consumes these workload identities rather than issuing SVIDs, and the WIMSE endpoint accepts JWT tokens, not X.509 credentials. Configuration and request examples are in Workload Identity.

Evidence formats

The claim schemas can retain verification results and references from other systems. The submitter is responsible for the underlying verification unless a specific STACK verifier is documented for that format.

• RATS / EAT: rats_evidence records workload-attestation results and an optional evidence reference. Schema acceptance does not perform vendor-specific hardware or TEE attestation verification.
• SLSA: slsa_provenance records build-provenance metadata. It does not prove that a build met a SLSA assurance level.
• CycloneDX: ai_bom_ref carries a reference and digest for an AI bill of materials, rather than auditing the referenced components.
• C2PA: c2pa_assertion records content-provenance information. Accepting the claim does not independently validate the media or its complete provenance chain.

The published claim schema bundle describes the accepted fields. Using these formats is separate from certification or an assessment of the wider system.