Skip to content

STATUS.md

Latest commit

 

History

History
71 lines (47 loc) · 13.9 KB

STATUS.md

File metadata and controls

71 lines (47 loc) · 13.9 KB
Raw

Implementation status

What is implemented, deployed, and published, measured against atrib-spec.md and the decision log. The README carries a short summary; this file is the full enumeration. When a feature ships, a service deploys, or a package publishes or is deprecated, update this file in the same change (see DOC-SYNC-TRIGGERS.md).

Deployed services

Service URL Role
services/log-node/ https://log.atrib.dev/v1 Merkle log (§2): commitments, inclusion proofs, signed checkpoints
services/graph-node/ https://graph.atrib.dev/v1 Graph queries (§3): nine-edge derivation, trace, chain
services/directory-node/ https://directory.atrib.dev/v6 AKD public-key directory (§6)
services/archive-node/ https://archive.atrib.dev/v1 Record body archive (§2.12)

Archive-node is the deployed §2.12 reference service for public body and evidence retrieval. The public block explorer at https://explore.atrib.dev/ composes the log, graph, directory, and archive evidence APIs into seven views (overview, identity, session, action, demo, trace, anchoring), with Sigma.js-rendered DAGs for session, identity, trace, and demo views.

A reproducible end-to-end verifier with 13 gate assertions across 8 named categories (tree integrity, format conformance, checkpoint signature, pubkey-publication agreement, signer scope, attribution, record signature replay, chain integrity) ships at services/log-node/scripts/verify-loop.mjs and runs daily in CI against the deployed log.

Published packages

The package inventory, grouped current / deprecated / private, lives in the README packages tables. Fourteen current packages and six deprecated legacy packages are published on npm; the deprecated six stay installable as re-export shims (or, for @atrib/summarize, a standalone server) whose tool names remain permanent aliases per D164. The python/ directory ships the atrib Python SDK (published on PyPI), the first non-TypeScript implementation of the §1 record layer, held byte-identical to the TypeScript implementation by the shared conformance corpora and a cross-implementation determinism harness.

Protocol surface: implemented

Record layer

  • Record signing (§1) including INFORMED_BY (D041), PROVENANCE_OF (D044), ANNOTATES (D058), REVISES (D059), and directory_anchor (D056) event types.
  • Parent-child producer threading now has a single same-session subagent env bundle: ATRIB_CONTEXT_ID, ATRIB_CHAIN_TAIL_<context_id>, and ATRIB_PARENT_RECORD_HASH, built by @atrib/mcp buildSubagentProducerEnv() when the parent dispatch hash is known before the child signs (D104, D115).
  • Source-aware producer validation lets @atrib/mcp-wrap keep configured informedByPaths only when refs resolve through the wrapper mirror, local mirrors, or log lookup, while parent env seeds stay producer-owned (D116).
  • Sandboxed producer key isolation (§1.4.6, D102) keeps signing keys outside sandboxed execution via a tested host signer-proxy example.
  • Opt-in autoChain plus a cross-producer chain-tail handoff via ATRIB_CHAIN_TAIL_<context_id> env var for hosts that don't propagate atrib's outbound token.
  • Privacy postures (§8, D045) with disclosure dials per record.

Transparency log

  • Transparency log (§2) with persistent storage, C2SP-canonical signed-note checkpoints (D031), and optional SSE / JSON Feed subscription surfaces (§2.5.6, D103).

Graph

  • Graph query interface (§3) with full nine-edge §3.2.4, /v1/trace/<record_hash>, /v1/chain/<record_hash>, /v1/creators/<key>/graph, and an explorer primary trace path that composes trace plus chain without changing the protocol APIs (D068, D118).

Key directory and identity

  • AKD-backed public-key directory (§6, D034) deployed at https://directory.atrib.dev/v6 (unblinded mode for atrib's own use; VRF-blinded mode available for downstream consumers requiring privacy-preserving lookup).
  • Per-operation directory anchoring back into the log (§6.2.4).
  • Key rotation and revocation (§1.9, D033): verifier honors revocations, @atrib/cli exposes publish-claim / revoke commands, conformance corpus generated.
  • Capability declarations (§6.7, D051) surfaced by the verifier as soft signals per §6.7.3.

Verification and evidence

  • Pattern 3 handoff claim acceptance lets a receiving agent verify another agent's record_hash, body commitment, inclusion proof, checkpoint signature, signer trust, context policy, and freshness before signing an informed_by follow-up; @atrib/verify provides the library helper and @atrib/verify-mcp exposes the atrib-verify primitive (§5.5.5, D105, D106).
  • Cross-attestation requirement on transaction records (§1.7.6, D052) flagged by the verifier when fewer than two distinct signer keys verify, composing with a caller-supplied trust set so two untrusted co-signers surface as sybil_suspected rather than counting as authority (D149); the same trusted-corroboration check generalizes off transactions to any signed target through the attestation extension (§8.7.6, D150), and @atrib/action-gate turns both into fail-closed policies.
  • AP2 / Verifiable Intent evidence checks (payments profile §11, D089, D090, D091, D092, D093, D094, D096, D097, D098, D107) validate AP2 receipt references, signed receipt JWTs, VI SD-JWT / VC mandate chains, typed AP2 mandate constraints, offline JOSE / JWKS / SD-JWT crypto edge cases, opt-in AP2 reference artifacts, and AP2 transaction-record artifacts off the detector path.
  • AP2 Path 2 transaction emission uses a stable receipt identity ladder when receipt or mandate identity is visible (D095) and carries an agent signers[] entry over the D052 canonical bytes; AP2 counterparties can add their own signer entry with signTransactionAttestation().
  • verifyRecord() and AtribVerifier.verify() attach supplied evidence as tiered ap2_vi_evidence without counting AP2 receipt JWTs as transaction signers.
  • The read primitives consume local mirror, archive body material, or caller-supplied evidence per spec §5.9, §2.12, and §5.5.5.
  • @atrib/verify also exposes generic tiered authorization evidence blocks (§5.5.6, D109, D110, D111, D119, D132, D134). verifyRecord() can attach MCP/OAuth, AAuth, or x401 evidence under evidence[] and consume caller-supplied resolvedFacts for capability checks without changing base record validity. x401 evidence proves that a route-specific proof requirement was checked by a verifier; it does not prove payment completion. @atrib/mcp can capture validated MCP authInfo, AAuth callback evidence, and opt-in x401 proof headers into local-only sidecars, including DPoP proof material, HTTP signature facts, token hashes, proof hashes, proof-gate constraints, and caller-owned x401 origin, issuer-trust, and proof-payment binding outcomes without storing raw bearer tokens, raw AAuth JWTs, or private credential payloads by default. Hosts that need live OAuth introspection can use introspectOAuthToken() to produce caller-owned evidence, and AAuth or x401 callers supply trusted JWKS, verified claims, decoded claims, credential-verifier outcomes, or hashed external verifier references under an explicit verification policy.
  • For the delegation and capability-system boundary, see Delegation and capabilities: atrib verifies external authorization evidence, but the issuing and enforcement layers remain outside the protocol.

Payments profile

Conformance corpora

  • Substrate-wide conformance corpora (D101) pin §1.4 adversarial signing vectors, §3.2.4 full edge derivation, D067 multi-producer race vectors, and D052 creator-signer separation.

Spec-defined, not yet implemented

  • Witnessing (§2.9, D032; first implementation deferred until an independent verifier exists).
  • Cross-log replication (§2.11, D050; spec-defined; second log-node deployment + verifier multi-log proof bundles forthcoming).
  • §6.3 verifier consultation steps 1, 3, 4, 5, 7 (anchor + lookup-proof + append-only + emergency-key paths; AKD WASM bridge upstream gating).