Spec canónica de protocols/capability-token/README.md, copiada sin reescribir.
protocols/capability-token/README.mdPágina generada desde
protocols/capability-token/README.md. No se edita a mano:bun run docs:genla regenera ybun run docs:checkfalla si difiere.
Contrato binario entre playback-svc (Bun, emite) y styx-media-daemon (Zig, verifica)
para autorizar cada acceso al data plane: leer una sesión por WebTransport/HTTP/3, suscribirse
o hacer FETCH en MoQT, y publicar en MoQT. Decisión: dec-0117 §4.1 (LOCKED).
| Fichero | Qué |
|---|---|
SCT_SPEC.md | Spec humana: formato, campos, digests, transporte, verificación, límites, errores |
vectors.json | Vectores de conformidad (fixtures). Los genera el codec TS; el daemon los verifica |
Implementaciones:
dec-0119 §9, dec-0120), una sola implementación por lenguaje:
@spire/bus/sct (TS: emisión y verificación) y spire.cap (Zig: sct + authority).apps/playback-svc/src/service/capability/capability-issuer.ts (clave, audiencia y
TTL; firma con @spire/bus/sct).spire.cap a través de su módulo security
(native/zig/media-daemon/security/security.zig), que añade request_cap (cómo lleva el
token cada transporte).Regenerar los vectores: bun apps/playback-svc/scripts/gen-sct-vectors.ts. Los comprueban
apps/playback-svc/test/service/capability/sct.test.ts (el fichero es la salida del generador),
spire sobre su copia vectors/sct-v1.json (autoridad Zig y verificador TS), y el daemon exige
que esa copia sea este fichero byte a byte (security.zig); si uno discrepa, un test falla.