KYA-OS COMMUNITY

STANDARDS RAILS

What KYA-OS provides, carries, and projects onto — every row grounded and dated. A status is never listed above what its evidence shows.

shipping code at the current release specified normative spec text planned on the roadmap none exactly that — listed so nobody has to guess

Click a row for the full relationship and evidence. Disputes and updates are one pull request: every row is one file in registry/interop/; the machine-readable matrix is interop.json.

Discovery projections

A2A AgentExtension Emits an AgentCard.capabilities.extensions[] entry (uri https://kya-os.org/a2a/ext/entity-card/v1); scoped to entityType "agent" only, throws otherwise. shipping 2026-08-19

toA2AExtension in src/card/emit.ts; SPEC-ENTITY-CARD section 6.2. Activated via the A2A-Extensions header; unaware peers ignore it.

evidence -> edit this row ->

MCP catalog.json index entry Emits an always-by-ref catalog index row, so the index stays cheap and the card lazy-fetches. shipping 2026-08-19

toCatalogEntry in src/card/emit.ts; SPEC-ENTITY-CARD section 6.4. All four discovery projections gate proof-posture advertising identically; golden fixture at src/card/__tests__/__fixtures__/emit-golden.json.

evidence -> edit this row ->

MCP server.json / catalog.json _meta["org.kya-os/card"] Projects the Entity Card, inline or by-ref, into the MCP Registry _meta extension point. shipping 2026-08-19

toServerCardMeta in src/card/emit.ts; SPEC-ENTITY-CARD section 6.1. SEP-2127 server-card is cited as an informative reference.

evidence -> edit this row ->

NANDA AgentFacts Emits an AgentFacts JSON-LD projection of the Entity Card, populating NANDA's shipped owner slot from responsibleParty; namespaced kya:* keys ride graceful degradation. shipping 2026-08-19

toAgentFacts in src/card/emit.ts since v1.9.0; SPEC-ENTITY-CARD section 6.3 is NORMATIVE. Populates the owner slot, does not re-claim it. Spec anchor: SPEC-ENTITY-CARD.md#63-nanda-agentfacts.

evidence -> edit this row ->

Identity

W3C DIDs: did:web, did:key, did:cheqd did:web REQUIRED for accountable entities, did:key for ephemeral or human principals (SPEC-ENTITY-CARD section 5.1); resolvers for all three in-tree. shipping 2026-08-19

did:cheqd resolves via a configured resolver endpoint and is an integration (src/integrations/cheqd/resolver.ts), NOT one of the card spec's section 5.1 anchor methods.

evidence -> edit this row ->

OAuth Client ID Metadata Document (draft-ietf-oauth-client-id-metadata-document / SEP-991) L1 on-ramp: client_id and did:web form a bijection, jwks_uri maps to DID keys; fail-closed verifyCimdBind; cardFromClientMetadata mints L1 client cards. shipping 2026-08-19

src/card/cimd.ts; SPEC-ENTITY-CARD section 7 is NORMATIVE [TAAWG-NORMATIVE]. verifyCimdBind enforces origin equality plus alsoKnownAs anti-substitution. Spec anchor: SPEC-ENTITY-CARD.md#7-cimd-on-ramp-normative-taawg-normative.

evidence -> edit this row ->

RFC 9449 DPoP + RFC 7638 JWK Thumbprint cnf.jkt sender-constraint fusion (SPEC-ENTITY-CARD section 8.6, 'the spine'): the access token's cnf.jkt (RFC 9449 semantics, RFC 7638 thumbprint) must equal the proof key's thumbprint. shipping 2026-08-19

cnf handled across src/card/proof/*; normative references. Section 8.8 defines the relationship to DPoP explicitly.

evidence -> edit this row ->

Credential formats

W3C Data Integrity, eddsa-jcs-2022 cryptosuite Delegation proofs are DataIntegrityProof / eddsa-jcs-2022 (SPEC.md section 6.10); the schema literal is enforced, the suite gate rejects unknown proof.type, JCS canonicalization is in-tree. shipping 2026-08-19

proof-bearing rail

Shipping with a seam: raw Ed25519 sign/verify is an injected provider (SignatureVerificationFunction), not a bundled DI suite library. Legacy Ed25519Signature2020 proofs are also accepted.

evidence -> edit this row ->

W3C VC Data Model 2.0 DelegationCredential is a VC 2.0 whose credentialSubject is an attenuated ZCAP-LD capability; the card delegation schema requires the credentials/v2 context first. shipping 2026-08-19

proof-bearing rail

Schema plus verifier plus conformance vectors; https://www.w3.org/ns/credentials/v2 is required as the first @context. CAVEAT: the legacy 1.x session profile (src/types/protocol.ts wrapDelegationAsVC) still pins the VC 1.1 context 2018/credentials/v1; VC 2.0 is the card-profile shape.

evidence -> edit this row ->

W3C CCG ZCAP-LD The authority object: the credentialSubject of every delegation hop is an attenuated ZCAP-LD capability (context https://w3id.org/security/zcap/v1); chain attenuation invariants are enforced. shipping 2026-08-19

proof-bearing rail

Normative reference; chain enforcement in src/delegation/chain-enforcement.ts plus the delegation credential schema.

evidence -> edit this row ->

Revocation

W3C Bitstring Status List v1.0 Card revocation field is a BitstringStatusListEntry; fail-closed reader treats unreachable or malformed lists as revoked; MSB-first bits, GZIP+multibase decode, statusPurpose asserted. shipping 2026-08-19

proof-bearing rail

src/card/revocation.ts and src/delegation/bitstring.ts; SPEC-ENTITY-CARD section 10.3. Shared bit mechanics in src/utils/statuslist-bits.ts (16 MiB inflation cap).

evidence -> edit this row ->

cheqd DID-Linked Resources (on-chain anchoring + StatusListCredential resolver) prepareCheqdDlrResource anchors JCS-hashed artifacts including whole signed StatusList2021 credentials; CheqdStatusListResolver does fail-closed on-chain revocation checks. shipping 2026-08-19

proof-bearing rail

NEW in 1.14.0 (CHANGELOG 2026-08-13). Issuer pinned and list proof verified against the on-chain DID document. Upstreamed from the DEF CON 34 'REVOKED' demo; also src/integrations/cheqd/dlr.ts.

evidence -> edit this row ->

W3C StatusList2021 (predecessor) More than read-compat: StatusList2021Manager creates and updates lists for the legacy delegation profile, and the cheqd resolver verifies on-chain StatusList2021 credentials. shipping 2026-08-19

proof-bearing rail

The legacy publish format, not just read-compat.

evidence -> edit this row ->

Transparency

RFC 9162 (Certificate Transparency v2 Merkle trees) Audit ledger checkpoints are RFC 9162 section 2 tree heads with inclusion and consistency proofs; profile ID KYA-AUDIT-RFC9162-SHA256-JWS-2026. shipping 2026-08-19

proof-bearing rail

Rfc9162MerkleTree in src/audit/merkle.ts; SPEC-AUDIT-READ.md, AUDITABILITY.md, conformance vectors/audit-integrity.json.

evidence -> edit this row ->

Payments

Visa Trusted Agent Protocol / TAP None. KYA-OS neither implements nor references TAP today. none 2026-08-19

Confirmed zero at origin/main: the only matches are base64 lockfile false positives. The README DEF CON demo pays testnet invoices under a delegation VC but names no payment standard.

edit this row ->

x402 payments None. KYA-OS neither implements nor references x402 today. none 2026-08-19

Confirmed zero at origin/main: a repo-wide search for x402 returns nothing. Not shipping, not specified, not planned. Listed so nobody has to guess.

edit this row ->

Canonicalization

RFC 8785 JCS Strict fail-closed canonicalization for every integrity-critical digest: requestHash, audit event bytes, DLR content addressing, VC canonicalization. shipping 2026-08-19

proof-bearing rail

Normative reference [RFC8785] in the SPEC-ENTITY-CARD References.

evidence -> edit this row ->

Transport

OAuth 2.1/OIDC hardening: RFC 9207 iss validation, PKCE S256, RFC 8707 resource SPEC.md section 9.4 aligns with MCP 2026-07-28 authz hardening: the client MUST validate iss per RFC 9207 on callback; PKCE and protected-resource metadata live in @kya-os/mcp/authz. specified 2026-08-19

Mixed maturity, listed at the conservative tier: the PKCE/OIDC adapter is shipping (src/authz/oidc/), but RFC 9207 iss validation is spec text ([RFC9207] in SPEC.md section 9.4 and SPEC-MCP-EXTENSION) with no iss-validation code in src/authz - it is a client-side MUST.

evidence -> edit this row ->

RFC 9421 HTTP Message Signatures OPTIONAL dual-carrier sibling: a second raw EdDSA/ES256 signature by the same DID key over the 9421 signature base (label kyaos), verifiable by stock 9421 verifiers. shipping 2026-08-19

proof-bearing rail

SPEC-ENTITY-CARD section 8.5; conformance/verify.py verifies both carriers. Covers content-digest, kya-audience, kya-nonce, kya-cnf. Degrades away if the signer lacks signRaw; detached JWS stays canonical; Layer-2 headers are NOT required to be 9421-covered (CONFORMANCE.md). Interop targets: SEP-1960, Cloudflare Web Bot Auth.

evidence -> edit this row ->