# Dependencias pendientes de P1-01

La adopción de D01–D03 y las comprobaciones de fixtures no cierran estas
dependencias. **Ningún resultado del paquete local es `XCIM_PASS`.**

[AS-01](https://xcim.org/standardization/source/AUTHORITY-STATE-PROPOSAL.md) propone contratos C1–C8 y alternativas
para G04–G06, con decisiones A1–A6 y criterios M/O. A1–A6 están adoptadas y AS01-F01 aporta schemas/fixtures offline;
su cobertura actual está en [AS dependencies](https://xcim.org/standardization/as01/DEPENDENCIES.md). Los
casos AS no se suman a resultados P1 ni establecen autoridad viva.
Los pins/flags sintéticos actuales siguen sin ser autoridad autenticada.

| Brecha / decisión | Lo que falta concretamente | Sustituto de fixture y límite | Criterio para cerrar |
|---|---|---|---|
| G04 / D04 | Bootstrap aceptado, roles nuevos RBA/control/MP, formatos y transporte de autoridad de app/claves/dominios y lifecycle. | Pins sintéticos en `vectors/context.json`; no prueban autoridad real. | Contratos autenticados portables, rotación/compromiso/revocación y pruebas de otra implementación sin APIs privadas. |
| G04–G05 / D04–D05 | Schema y prueba autenticada del estado revocable de MSA, clave MP y authority_epoch. | Flags/ventanas de test, con casos revocados/stale; no emitir objetos de estado fingidos. | Estado vinculado a autorización/app/epoch/key, ausencia y revocación verificables; definidas frescura y recuperación. |
| G05–G06 / D05–D06 | Evidencia pública fresca del permiso y autoridad: inclusión, sparse state, batches, chain/finality o nuevo perfil explícito. | El checker no valida una Proof; rechaza usarla como evidencia. | Verificador completo del perfil seleccionado y operación de snapshots sucesivos/revocaciones con clocks y caché comprobados. |
| G07 / D07 | Transición de algoritmos/versiones/roles y aceptación de claves históricas. | `Ed25519` para nuevos objetos y `EdDSA` explícito sólo en receipt fixture legacy. | Matriz de combinaciones, nueva autoridad/metadata y negativos de downgrade; sin reescribir bytes históricos. |
| G08–G09 / D08–D09 | Revisión completa de tablas y parsers, conformance por rol y precedencia de fallos. | Puerta E1, schema/canonicalización Python y contraste Node parcial. | Implementación externa de todos los contratos, Unicode/IDNA/versiones fijadas, determinismo de resultados multifallo y reportes por rol. |
| G10–G12 / D10–D12 | Tipos, namespace, headers, extensiones y posibles métodos/resultados registrados. | IDs de schemas `.invalid`, nombres `typ` candidatos y códigos locales de test. | Estrategia/plantillas revisadas, política de asignación y transición; registrar sólo resultados reales de IANA. |
| G13 / D13 | Contrato OIDC completo y políticas de autoridad por proveedor; EVP fuera del perfil inicial. | Receipt sintético de forma OIDC-01; no se valida un login externo. | Adaptador/política versionados y pruebas del flujo real, manteniendo consentimiento separado. |
| G14 / D14 | Revisión independiente de criptografía, canonicalización, enumeración/correlación y consentimiento. | Ataques de fixture y fuentes primarias; sin auditoría externa. | Informe versionado con hallazgos, correcciones o riesgos aceptados explícitamente. |
| G15 / D15 | Sender/receiver de operadores/equipos independientes y segundo issuer si se afirma multi-issuer. | Python/Node ejecutados por el mismo trabajo no cuentan. | Ensayo opt-in documentado con versiones, dependencias compartidas, positivos/negativos y límites reales. |
| G16 / D16 | MX compartidos, transacciones SMTP/replay, fallos de store, reintentos 4xx/250 perdido, forwarding, límites y coste. | Lista de nonce ya aceptado, DKIM offline y tamaños locales; no hay aceptación SMTP transaccional. | Store/aceptación atómicos y ensayo de carreras/recuperación en varios workers/MX; medidas de CPU/red/tamaño/latencia/renuevo. |
| G17–G20 | Autores/derechos/categoría, nits, release autenticada y discusión de encaje. | Trabajo local, integridad por manifest sin firma y metadata editorial provisional. | Resolver el checklist S y obtener evidencia real de revisión/contacto autorizado. |

Si falta evidencia de autoridad, revocación, frescura o replay exigida, un
receiver completo debe retirar la señal positiva bajo su política. No convertir
un HTTP 200, signature válida, schema válido, flag de test o manifest de hashes
en prueba de esas condiciones. La entrega editorial y los permisos de envío
siguen siendo decisiones distintas.