# Decisiones para el primer Internet-Draft de XCIM

**Fecha:** 2026-10-19. **Estado:** D01–D06 accepted como dirección de diseño por
instrucción explícita del usuario; D07–D20 abiertas. Los IDs `IETF-Dnn` son de este paquete y no sustituyen las
decisiones D-001–D-018 de [arquitectura](https://xcim.org/standardization/source/DECISIONS.md).

Cada decisión corresponde a la brecha G del mismo número en la
[matriz](https://xcim.org/standardization/source/READINESS-MATRIX.md). El cierre requiere un registro aceptado con fecha,
responsable, motivación, alternativas descartadas, impacto de compatibilidad,
cambio normativo y evidencia indicada allí. Adopción de dirección no cierra
automáticamente las brechas M/O ni habilita claims de producción/interoperabilidad.

La [propuesta concreta P1](https://xcim.org/standardization/source/SCOPE-AND-BINDING-PROPOSAL.md) desarrolla D01–D03:
correo directo por destinatario, RBA del issuer y presentación firmada por
aplicación/delegado con DKIM adicional. Incluye alternativas, bytes candidatos,
parámetros de piloto y criterios para cerrar las brechas técnicas. La dirección
quedó adoptada en el [registro D01–D03](https://xcim.org/standardization/source/ACCEPTED-D01-D03.md). Los
[schemas, ABNF y fixtures P1-01](https://xcim.org/standardization/p1/README.md) concretan esa iteración; las
[dependencias pendientes](https://xcim.org/standardization/p1/DEPENDENCIES.md) siguen sin resolverse.

La [propuesta AS-01](https://xcim.org/standardization/source/AUTHORITY-STATE-PROPOSAL.md) concreta D04–D06: pins y
manifiesto de raíz, cabeza de control separada, checkpoint compuesto de permiso
WD/autoridad AS y nuevo perfil anclado. A1–A6 fueron adoptadas en [el registro](https://xcim.org/standardization/source/ACCEPTED-A1-A6.md). [AS01-F01](https://xcim.org/standardization/as01/README.md)
aporta 19 schemas y fixtures offline; no hay cierre M/O ni anchor/DNS/MX vivos.

| ID | Pregunta y alternativas | Dirección adoptada / recomendación | Impacto y estado técnico |
|---|---|---|---|
| IETF-D01 | ¿Un documento integral o núcleo más perfiles? ¿Qué caso de uso se intenta estandarizar primero? | Adoptada P1 §2: un draft con núcleo y perfil de correo directo; copia por destinatario, una app/epoch, un propósito `explicit_consent`, OIDC-01 y publicación explícita bajo el modelo actual. | Forwarding, listas, SMTPUTF8 y otras clases quedan fuera del primer perfil; conservar modelos multi-issuer/estado vigente. Categoría RFC sigue en D17; falta revisión de trabajo previo. |
| IETF-D02 | ¿Atestación firmada portable de destinatario, intercambio autenticado con receptor u otro mecanismo? | Adoptada P1 §3: RBA firmada por Consent Issuer, compromiso contextualizado con salt de 32 bytes, calculado por issuer sobre dirección observada y verificado contra RCPT TO local. | Sin secreto HMAC compartido ni consulta obligatoria por mensaje; RBA no establece estado vigente. Schemas y fixtures locales creados; faltan autoridad/estado G04/G05 y revisión de privacidad; salt conocido permite diccionario. |
| IETF-D03 | ¿Qué firma vincula mensaje, destinatario, permiso, aplicación y propósito? ¿Referencia o prueba adjunta? | Adoptada P1 §§4–5: MP por mensaje firmada por clave app/delegada mediante MSA; compromete RBA, MSA y contenido canonicalizado; DKIM adicional cubre XCIM. Proof opcional con verificación completa. | Evita confundir dominio DKIM compartido con autoridad de app; nonce/replay y expiración explícitos. Schemas/ABNF/fixtures creados; faltan estado autenticado MSA, Proof, replay SMTP/MX y revisión externa. |
| IETF-D04 | ¿Pins locales, registro autenticado o ambos? ¿Qué transporte y objetos permiten verificar altas, rotación y revocación? | Adoptada dirección AS-01 §§3–6: pins locales como mínimo, raíz/quórum y recuperación, manifiesto de roles, dos signers de publicación separados y estado de app/clave/dominio/MSA; registry posterior explícito. | A1/A2/A6 adoptadas; schemas y verifier de fixture disponibles. DNS/posesión/recovery/instalación reales pendientes. Ocultamiento de revocación de signers C3/C4 puede durar hasta 24h del manifiesto candidato, no 300s. |
| IETF-D05 | ¿Qué ventana de estado, clock skew, precedencia de fallos y caché aplica a cada perfil? | Adoptada dirección AS-01 §§5–8: corte compuesto, floors durables, ausencia probada, reloj con incertidumbre y deadline mínimo sin grace. Estado ≤300s, renovación objetivo 60s, autoridad raíz ≤24h como hipótesis de ensayo. | A3/A5 adoptadas; 97 casos AS (8 positivos de autoridad, 2 artefactos de transición/recovery y 87 adversariales) más 37 estructurales. Sin operación/SLA medidos. G05-M exige schemas/verificadores y G05-O ensayo continuo/concurrencia/recuperación medido. |
| IETF-D06 | ¿Anclaje externo obligatorio, perfiles de anclaje o perfil adicional sin cadena? | Adoptada dirección AS-01 §§3,5,9: nuevo perfil explícito anclado que compromete permiso WD y autoridad AS juntos; comparar log/testigos sin cadena sin habilitarlos. | A4 adoptada como dirección; [AN01-P01](https://xcim.org/standardization/anchor-adapter/CONTRACT-PROPOSAL.md) propone ABI/genesis/red/finality concretos. N1–N6 [adoptadas](https://xcim.org/standardization/source/ACCEPTED-N1-N6.md); [AN01-F01](https://xcim.org/standardization/an01/README.md) aporta contrato compilado, schemas y EVM local. [NB01-F01](https://xcim.org/standardization/nb01/README.md) implementa bootstrap/collector/floors con mocks; M/O exige nodos y pins reales, verifier integrado y pruebas vivas. El slot anchor del schema F01 es null y nunca habilita PASS. Amoy 0.1 no se reinterpreta; firmar un checkpoint compuesto no prueba por sí solo consistencia de la proyección. |
| IETF-D07 | ¿Cómo evolucionan objetos y algoritmos sin reinterpretar firmas previas? | Diseñar emisión futura con identificadores JOSE específicos, evaluando `Ed25519` de RFC 9864, y aceptación histórica explícita para `EdDSA`. | `alg` está firmado. Versiones/perfiles, schemas, keys, downgrade y fixtures deben cambiar coordinadamente; no cambiar bytes históricos. |
| IETF-D08 | ¿Qué subconjunto exacto de JSON/JCS/Unicode/IDNA puede interoperar? | Conservar E1 como baseline documentado y trasladar reglas completas con tablas/versiones externas identificadas. | Puerta léxica antes de conversión, -0, UTF-16, duplicados y EAI no soportado. Determinar cómo se actualizan tablas IDNA sin cambiar compromisos previos. |
| IETF-D09 | ¿Qué significa conformidad por rol y perfil? | Checklist por issuer, log/publicador, sender y receiver, con versiones y evidencia; separar autopruebas de pruebas entre operadores. | Perfil mínimo obligatorio, criterios PASS y dependencias de cada rol; una validación de schema no cubre el receiver. |
| IETF-D10 | ¿Registrar tipos con `+jcs`, reutilizar sufijos existentes u otra representación? | Revisar tipos de envelope/payload y `typ` por separado antes de elegir; evitar inventar equivalencias automáticas. | Tipos actuales no registrados; los valores `typ` firmados no pueden migrarse por simple sustitución. La alternativa debe describir los bytes reales. |
| IETF-D11 | ¿Registrar el NID `xcim` o adoptar identificadores bajo un espacio existente? | Comparar URN formal y URI HTTPS con reglas de asignación, persistencia y control de cambios. | Los IDs entran en firmas y hashes; preservar IDs históricos y definir una transición explícita. |
| IETF-D12 | ¿Registros IANA o registros de proyecto para perfiles, extensiones y resultados? ¿Qué políticas de asignación? | Inventariar cada espacio y justificar dónde vive; versionar semántica y documentar rechazo de extensiones críticas desconocidas. | Procedimiento de altas, controlador, colisiones, política RFC 8126 y posible método Authentication-Results con resultados propios. |
| IETF-D13 | ¿OIDC-01 como primer perfil implementable? ¿Cómo se versionan evidencia y políticas de proveedor? | Desarrollar el baseline OIDC-01; mantener EVP explícitamente experimental hasta fijar revisión externa y probarla. | Dirección de email exacta frente a autoridad del proveedor; no generalizar `email_verified`; no introducir campos nuevos en receipt 0.1. |
| IETF-D14 | ¿Qué garantías admite XCIM frente a un issuer deshonesto y qué revisión externa se necesita? | Explicitar confianza en la observación del issuer y analizar privacidad, correlación, engaño en consentimiento y abuso de consultas. | No prometer que firma/log prueba verdad del consentimiento. Asignar revisión y registrar severidades, resoluciones y limitaciones. |
| IETF-D15 | ¿Qué independencia y cobertura requiere el primer ensayo? | Sender y receiver de equipos/operadores distintos, con implementación a partir del texto y dependencias compartidas declaradas; sumar un segundo issuer para cubrir multi-issuer. | Alcance por rol y perfil, reportes opt-in y reproducibilidad. Dos lenguajes del mismo equipo o el piloto gestionado no completan este ensayo. |
| IETF-D16 | ¿Cuánto coste, latencia y dependencia de red acepta el perfil? | Medir primero referencia y prueba adjunta con tamaños/carga declarados; fijar presupuestos con participantes. | Límites de prueba/cabecera, caché, timeout, cadencia de publicación, DoS, reenvíos y degradación de la señal. |
| IETF-D17 | ¿Autores, nombre del draft, categoría pretendida, derechos y modelo de contribución? | Confirmar titulares/autores y permisos de material incorporado; revisar BCP 78/79. Comparar Experimental y Standards Track con la comunidad. | Sustituir `author`/`TBD`, `category="exp"` e `ipr="trust200902"` provisionales; licencias de texto/código/datos y autoridad para aceptar cambios. |
| IETF-D18 | ¿Qué fuente editorial y referencias sostienen draft-00? | RFCXML v3 autocontenido como fuente; TXT/HTML derivados, referencias normativas/informativas explícitas y comprobación de nits antes del envío. | Trasladar reglas y fórmulas; fijar referencias externas exactas, eliminar placeholders de metadata y conservar cuestiones técnicas abiertas etiquetadas. |
| IETF-D19 | ¿Qué distribución permite implementar sin componentes privados? | Release coherente con source, schemas, herramientas, vectores, manifest y política de integridad/firma documentada. | Alinear revisión exacta entre ZIP y repositorio; manifest de hashes no es firma de release ni raíz de confianza. Resolver licencias en D17. |
| IETF-D20 | ¿Cuál es el foro inicial y qué pregunta se le lleva? | Preparar un pitch técnico y consultar DISPATCH cuando haya autoría y borrador revisables, sujeto a autorización para el contacto. | Confirmar mandato vigente y encaje; registrar feedback real. No asumir adopción, nuevo WG ni calendario de RFC. |

## Dependencias y primeras decisiones

```text
D01 alcance + D17 derechos/autores
  -> D02 destinatario + D03 mensaje + D04 confianza + D06 publicación
  -> D07 algoritmos/versiones + D10 tipos + D11 identificadores
  -> D05 estado + D08 bytes + D09 conformidad + D12 extensiones + D13 identidad
  -> D18 texto completo + D19 distribución
  -> D14 revisión + D15 interop + D16 mediciones
```

D14 debe empezar durante el diseño, y D20 puede avanzar con un draft temprano
que exponga las brechas. Las flechas indican dependencias para cerrar una
especificación implementable, no una obligación de terminar todos los ensayos
antes de la primera presentación.

## Plantilla de resolución

```text
ID / estado / fecha / responsable y revisores:
Brechas y perfiles afectados:
Problema y alternativas evaluadas:
Decisión y justificación:
Texto normativo / schemas / herramientas afectados:
Compatibilidad, selección de versión/perfil y aceptación histórica:
Vectores positivos, negativos y evidencia externa:
Limitaciones y riesgos abiertos:
Enlaces a cambios y criterio de cierre satisfecho:
```