Authority and fresh revocable state

AS-01 — propuesta de autoridad, revocación y frescura para P1

Diseño de referencia: AS-01-proposal-01, 2026-10-19. Estado actual: A1–A6 / D04–D06 adoptadas como dirección por instrucción explícita del usuario. AS01-F01 concreta schemas y fixtures; las dependencias y el cierre M/O siguen pendientes. Este texto conserva el razonamiento y alternativas del diseño. No cambia WD-02-E1, los objetos P1-01 ni sus 135 casos. Los sitios distribuyen material de desarrollo; no hay verificador de anchor AS ni autoridad operativa acreditada.

1. Recomendación concreta y decisión solicitada

Recomiendo desarrollar AS-01 como perfil nuevo explícito: raíz de confianza provisionada por el receiver, manifiesto de autoridad firmado por esa raíz, checkpoint que vincule permiso y autoridad del mismo corte y una cabeza de control firmada con otra clave. El checkpoint requiere publicación anclada independientemente verificada. La presentación puede adjuntar la evidencia o permitir recuperarla de mirrors; no exige consultar al issuer por mensaje.

Dirección adoptada: A1–A6 de §12, registrada en ACCEPTED-A1-A6.md. La recomendación es A1/A2/A3/A4 como aquí, A5 con parámetros iniciales medibles y A6 con pins locales primero. La adopción habilitó schemas y vectores AS; no cierra G04–G06 M/O.

2. Garantías y límites

El receiver debe poder responder cinco preguntas separadas:

1. ¿Acepto a este issuer y este log bajo mi política, para este perfil?
2. ¿Qué clave podía firmar cada objeto al emitirlo y conserva autoridad actual?
3. ¿Siguen activos la app/epoch, los dominios, la MSA y su clave MP?
4. ¿Sigue activo exactamente este permiso del destinatario/app/propósito?
5. ¿Hasta cuándo es utilizable esta evidencia, y he observado algo posterior?

No se prueba la veracidad del consentimiento frente a un issuer deshonesto. Un anchor autentica compromisos y orden bajo su política; no valida la autorización del cambio de estado ni la verdad de sus hojas. El receiver sigue confiando en las atestaciones de autoridad/consentimiento y, salvo que replique y compruebe todo el log, en la proyección firmada del estado. Se requieren monitores para detectar transiciones inválidas. Separar claves dentro del mismo operador no equivale a operadores independientes.

Una revocación desconocida puede quedar oculta durante la ventana de evidencia todavía válida. La propuesta ofrece una cota de antigüedad, no conocimiento instantáneo del último estado mundial. Si se observa una revocación o cabeza más nueva, no se puede seguir usando una anterior aunque aún no haya vencido.

3. Contratos candidatos y bytes

Se proponen siete contratos principales C1–C7 y un registro de lifecycle C8. Los schemas y fixtures ejecutables actuales se publican en AS01-F01, con concreciones de C1/C7 documentadas en su CONTRACT.md. Falta el Proof verifier con anchor vivo; los checks de AS y P1 son offline y no emiten XCIM_PASS.

Para nuevos objetos AS: JSON estricto/E1, JCS y enteros seguros; tiempos iat, exp, this_update, next_update, effective_at en segundos Unix UTC. Intervalos [inicio, fin). Identificadores existentes se comparan exactamente; hashes/thumbprints nuevos son base64url canónico de 32 octetos. No emitir direcciones ni PII en los objetos públicos. Los objetos son cerrados salvo uniones enumeradas aquí; un campo crítico desconocido no se ignora.

Payloads firmados usan proposal_version: "as-01", object_type exacto, issuer_id y log_id donde corresponda. JWS flattened de P1 para una firma; para quórum, objeto cerrado {payload, signatures} y firmas cerradas {protected, signature}, ambas cadenas base64url. Cada protected es {alg, kid, typ}, JCS, alg: "Ed25519"; kid selecciona una clave previamente autorizada, nunca una URL. Distintos firmantes se cuentan por thumbprint, no por cantidad de firmas. typ candidato application/xcim-as-{object_type}+jcs, sin registro IANA ni sufijo aprobado. G07/G10 deben revisar estos bytes.

H = SHA-256; J = JCS; U = UTF-8; b64u = base64url sin padding
commit(type, payload) = b64u(H(U("XCIM-AS-01-" + type + "\0") || J(payload)))

Tags exactos de tipo: GENESIS, MANIFEST, CHECKPOINT, CONTROL-HEAD, EVENT, STATE-VALUE, LOCATOR, MATERIAL. El compromiso es del payload validado, no del JWS completo. Los compromisos RBA/MSA/MP de P1 no cambian. MATERIAL compromete el objeto canónico {format, value}: format es p1-jws-envelope para la MSA completa firmada, o as-record para registros app/clave/dominio. Cualquier comparación debe identificar ambos tipo y bytes.

C1 — ReceiverTrustPolicy (configuración local)

No se recibe como autoridad desde un email. Campos locales obligatorios: policy_id, policy_epoch, issuer_id, log_id, profile_id, root_keys, root_threshold, recovery_keys, recovery_threshold, trusted_genesis_commitment, accepted_manifest_epoch_floor, anchor_policy, fetch_origins, valid_until, max_clock_uncertainty y los límites de §7. profile_id: "as-01-anchored" es nombre candidato. Cada pin identifica alg/key/thumbprint y rol. Sin pin público por defecto.

El genesis AS es el payload cerrado {issuer_id, log_id, profile_id, origin_nonce, anchor_policy_id}. Su compromiso usa tag GENESIS, nonce de 32 octetos y política de anchor ya aceptada; no incluye hashes de manifiestos o checkpoints que lo referencien. C2/C3/C4 incluyen genesis_commitment además de sus campos enumerados abajo y deben coincidir con C1. Así el origen se liga al perfil sin compromisos circulares. Un nuevo log_id/genesis exige nueva aceptación local; no lo elige libremente un mensaje.

Recomendación inicial: raíz de mantenimiento con quórum 2 de 3 y recuperación 2 de 3 disjunta; las claves online no pertenecen a esos conjuntos. Un equipo puede configurar otro quórum explícitamente, documentando menor tolerancia. Se requiere al menos un ancla inicial de historia aceptada y el control de la distribución local de políticas; reinstalar no permite resetear floors.

Una rotación ordinaria de raíz requiere quórum de raíz vieja y nueva sobre el mismo documento de transición {issuer_id, old_policy_epoch, new_policy_epoch, old_set_commitment, new_set_commitment, effective_at}. La recuperación utiliza el conjunto de recuperación ya provisionado y eleva policy_epoch; suspende positivos hasta instalar nueva raíz/genesis o un sucesor verificado. No se acepta una recovery key anunciada por la raíz comprometida. Si se compromete también el quórum de recuperación, hace falta reprovisionamiento externo; la especificación no puede reconstruir confianza.

Registry opcional futuro: raíz de registry aceptada localmente → acreditación vigente y acotada a issuer/perfil → raíz del issuer. Profundidad máxima dos delegaciones después de la raíz local, sin ciclos ni fallback automático a otro registry. El contrato de estado del registry y sus propias revocaciones debe diseñarse antes de habilitar esa ruta. No se presupone que exista hoy.

C2 — AuthorityManifest (raíz → roles online)

Payload cerrado: campos comunes, manifest_epoch, previous_manifest_commitment (null sólo en origen aceptado), root_policy_epoch, keys, publication_profile, fetch_origins, iat, exp. keys es lista finita única por kid/thumbprint con {kid, alg, public_jwk, thumbprint, role, valid_from, valid_until, status}; status es active, retired o revoked. Una clave tiene un solo rol AS.

Roles: receipt, recipient_binding, authority_attestation, state_checkpoint y control_head. Claves state_checkpoint y control_head deben tener thumbprints distintos. app_control/message_presentation no se obtienen de discovery: sus autoridades específicas están en C5. La raíz autoriza el manifiesto por quórum; verificar hash de JWK y límites de cada descriptor. El manifiesto nunca autoriza a sus claves a reemplazar la raíz.

El receiver conserva el mayor epoch/commitment aceptado. Mismo epoch con otro compromiso implica conflicto; epoch menor no restaura autoridad. Nuevos epochs requieren la cadena completa de manifiestos o un floor reprovisionado por raíz aceptada; no se salta un revocado. Discovery sólo localiza bytes. El manifiesto define orígenes de transporte, limitados además por la allowlist local.

Límite de seguridad: las claves C3/C4 se revocan en C2 o mediante política de recuperación C1, nunca por una hoja que ellas mismas autentican. C2 tiene edad máxima candidata de 24 horas. Un atacante que oculte un C2 más nuevo puede conservar un C2 anterior aún válido hasta ese límite. No se promete retirar esas claves en cinco minutos; raíz/recuperación y sus canales deben ensayarse.

C3 — ControlHead (cabeza reciente, firma separada)

Payload cerrado: campos comunes, head_sequence, previous_head_commitment, manifest_epoch, manifest_commitment, checkpoint_sequence, checkpoint_commitment, checkpoint_key_thumbprint, this_update, next_update. La primera cabeza referencia null sólo en el origen aceptado; las demás avanzan exactamente en uno con historial recuperable.

Se firma con control_head bajo C2 vigente. Cada cabeza referencia un solo checkpoint C4 exacto del mismo issuer/log/manifiesto. No puede declarar vigente otro C2. checkpoint_key_thumbprint debe coincidir con el firmante C4 autorizado. No es una prueba de terceros ni una nueva raíz: limita la capacidad de una clave de checkpoint comprometida de inventar por sí sola una publicación actual. Comprometer ambos roles anula esa separación; C1/C2 siguen siendo necesarios.

this_update de C3 debe ser igual al this_update C4, y next_update no lo excede. Una cabeza creada después no renueva el corte. Para renovar se genera un nuevo C4, aun sin eventos, y se verifica nuevamente su anclaje.

C4 — StateCheckpoint (corte consistente y publicación)

Payload cerrado: campos comunes, checkpoint_sequence, previous_checkpoint_commitment, manifest_epoch, manifest_commitment, snapshot_id (32 octetos aleatorios), permission_batch, authority_history, authority_state_root, this_update, next_update, publication_profile. Firma state_checkpoint; secuencia inicia en uno y avanza en uno, con null predecesor sólo en genesis aceptado. No hay URL ni evidencia de anchor dentro del payload que será comprometido por ese mismo anchor.

permission_batch es objeto cerrado {batch_sequence, batch_manifest_commitment, tree_size, event_root, state_root, created_at}. Identifica el payload exacto de un batch WD 0.1 verificado con su clave batch autorizada por la política de compatibilidad; se agrega rol legacy_batch explícito en C1 para ese caso, sin confundirlo con state_checkpoint. Se conserva el compromiso establecido XCIM-BATCH-MANIFEST-0.1\0; no se renombra como hash AS. Validar schema, firma, todos los campos, continuidad y pruebas de receipt/permiso WD existentes.

authority_history es {tree_size, event_root} de la historia AS (§5). Permisos conservan su árbol/estado WD; app, dominios, MSA y claves usan un árbol AS separado. No se introducen tipos nuevos en los schemas/raíces WD cerrados. permission_batch.created_at == this_update C4; ambos se sellan sobre el mismo corte lógico de escritura. El productor debe impedir cambios concurrentes a cualquiera de las dos proyecciones hasta sellarlas o abortar y reintentar. La firma atestigua esa atomicidad: por sí sola no la demuestra a un tercero.

Un checkpoint sin eventos nuevos requiere nuevo batch WD de cero eventos y nuevo C4/anclaje. Debe comprobarse que raíces/tamaños no cambiaron; no se permite referenciar un viejo batch y cambiarle sólo el reloj. next_update candidato como máximo this_update + 300. Un timestamp de wrapper/descarga no lo extiende.

Anchor AS nuevo: el adaptador elegido debe autenticar al menos (profile_id, issuer_id, log_id, checkpoint_sequence, checkpoint_commitment, previous_checkpoint_commitment) y comprobar red, contrato/código, firmante, transacción/evento exactos, bloque canónico, finalidad y variantes conflictivas. El hash C4 ya compromete ambas proyecciones y sus raíces; no hay ciclo. La identidad/genesis del adaptador está fijada en C1 y referida por C2/C4.

No se define aquí un ABI final ni se despliega un contrato. El anchor Amoy 0.1 no se reinterpreta como anchor AS. Su validación histórica continúa intacta. Seleccionar red/contrato/finalidad y fijar los bytes exactos del adaptador es una dependencia bloqueante de G06-M, no un detalle de configuración oculto.

C5 — AuthorityStateValue y materiales

La hoja de estado AS es cerrada: proposal_version, object_type: "authority_state_value", issuer_id, log_id, locator, state_epoch, status, effective_at, valid_until, material_commitment, latest_event_commitment. El locator se deriva del objeto esperado, nunca se copia sin verificar de la prueba. No hay next_update autodeclarado por hoja. Frescura viene de C4/C3; valid_until agrega un deadline, no lo prolonga.

owner_id identifica issuer o app sin inferirlo del dominio. Un rol no se expande a otro. Para P1 se requieren dominio rfc5322_from y dkim_signing, además de consent_presentation_delegate cuando corresponda a la delegación. Los nombres organizacionales no sustituyen esos roles. La clave DKIM real se verifica bajo DKIM/DNS y política del receiver; una hoja XCIM de dominio no reemplaza esa comprobación. DNSSEC no se presume.

El registro de dominio se atestigua con authority_attestation después de un challenge contextual de 32 octetos, vida candidata 600 s, ligado a issuer/app, dominio/rol y clave de control. Requiere consulta DNS por el observador, nombre de registro y respuesta exactos, sin aceptar un resultado aportado por sender. Nombre TXT, payload firmado de observación, resolvers/validación y política ante transferencia deben fijarse antes de G04-M; aquí no se inventa prueba DNS. Rechequeo candidato cada 86400 s: no garantiza detectar una transferencia entre observaciones; ese riesgo debe aceptarse o reducirse explícitamente.

Al MSA la firma la clave app_control vigente de su app; no el issuer ni el ESP por afirmación propia. Su alta exige prueba de posesión de la clave MP sobre {issuer_id, app_id, app_epoch, authority_epoch, authorization_id, msa_commitment_p1, challenge, expires_at}; challenge de un uso y hasta 600 s. La evidencia de posesión no otorga consentimiento. authority_attestation valida y atestigua el registro; C5 autentica su estado vigente.

Permisos siguen usando el estado WD: comprobar receipt, permission_id, app/epoch, pairwise ID, propósito/clase y evento de emisión. Para cada permiso exigir además la app actual, su authority_epoch, las claves y MSA actuales. No hay una hoja global por dirección de email ni búsqueda pública de direcciones.

C6 — StateWitness (prueba, no firma ni trust root)

Objeto cerrado: proposal_version, object_type: "authority_state_witness", issuer_id, log_id, checkpoint_commitment, locator, present, value, siblings. present booleano; value es C5 sólo si true, null si false; siblings contiene exactamente 256 hashes de 32 octetos, orden hoja→raíz. Pruebas comprimidas/multiproof quedan para otra revisión; no mezclar formatos.

K = H(U("XCIM-AS-01-STATE-KEY\0") || J({issuer_id, log_id, locator}))
L(value) = H(U("XCIM-AS-01-STATE-LEAF\0") || K ||
             H(U("XCIM-AS-01-STATE-VALUE\0") || J(value)))
E[0] = H(U("XCIM-AS-01-STATE-EMPTY\0"))
N(l,r) = H(U("XCIM-AS-01-STATE-NODE\0") || l || r)
E[n+1] = N(E[n], E[n])

Árbol binario sparse de profundidad 256; camino raíz→hoja por bits de K MSB-first, cero a izquierda. Al reconstruir hoja→raíz usar primero el bit menos significativo (índice 255 en el camino) y consumir cada sibling una vez. Ausencia parte de E[0], no de una hoja «unknown»; raíz vacía E[256]. No duplicar el hash STATE-VALUE: es la misma fórmula que commit de §3, decodificada a 32 octetos. Verificar checkpoint/raíz, locator, status y material.

Ausencia válida significa que el estado requerido no está registrado en ese corte. No significa activo, ni necesariamente revocado. Falta de prueba no significa ausencia probada. Revocados conservan tombstones; un activo no puede reaparecer por borrado. La ausencia de la MSA actual nunca permite usar otra por coincidencia de clave. Las pruebas de permiso WD usan su propio algoritmo.

C7 — EvidenceSet y recuperación

Wrapper cerrado: proposal_version, object_type: "authority_evidence_set", profile_id, manifest, control_head, checkpoint, anchor_evidence, permission_evidence, authority_evidence, history_evidence. manifest es JWS/quórum C2; C3/C4 JWS. Cada entrada de autoridad es {witness, material, event, event_inclusion}. Todo objeto debe pertenecer al mismo corte C4 o a la historia autenticada que lo precede; objetos válidos de cortes distintos no se pueden combinar. El wrapper no está firmado y no crea frescura.

permission_evidence transporta componentes WD de receipt/evento/pruebas/batch; su autenticación externa viene del nuevo perfil AS que compromete el batch exacto. No se etiqueta ese wrapper como proof WD/Amoy 0.1. Su schema final y la matriz de compatibilidad son dependencias de G06/G07. anchor_evidence e history_evidence se seleccionan estrictamente por perfil, sin JSON arbitrario tratado como válido. history_evidence debe llevar continuidad de C2/C3/C4, consistencia de ambos logs y pruebas de transición necesarias para los floors que el receiver ya conoce. No seguir enlaces desde headers a orígenes libres.

Transporte propuesto en orígenes aceptados: GET /as-01/manifest, GET /as-01/head, GET /as-01/objects/{type}/{commitment} y POST /as-01/evidence con {checkpoint_commitment, locators}. Son rutas candidatas de un issuer/mirror, no endpoints implementados en xcim.org. El cliente selecciona previamente issuer/log y endpoints; HTTPS protege transporte, las firmas/pruebas autentican contenido. Soporte de POST y acceso deben declararse; no hay búsqueda de email. Consultas por locators opacos siguen pudiendo correlacionar permisos; preferir caché compartida y prueba adjunta.

Límites iniciales para ensayo: HTTPS sólo puerto 443, sin redirects, userinfo, fragmentos ni direcciones privadas/loopback/link-local/multicast; comprobar resoluciones y destino de conexión contra DNS rebinding. Nada de URL desde kid, JWK, receipt, Reference o Proof. Hasta 8 conexiones, 2 s por operación, 5 s totales, 1 MiB descomprimido por EvidenceSet y profundidad JSON 32. No hay fallback a un endpoint comercial ni dependencia de API privada.

Una prueba sparse sin comprimir puede requerir más de 8 KiB por hoja antes de base64/JSON. Evidencia de varias autoridades puede exceder Proof (49152 octetos raw) de P1. No subir ese límite silenciosamente: resolver por transporte acotado o diseñar multiproofs y medirlas en G16. Reference y sus compromisos P1 permanecen iguales. El checker actual sigue rechazando Proof con PROOF_VALIDATOR_PENDING; esta propuesta no cambia ese comportamiento.

C8 — LifecycleEvent (cambio autorizado e historial)

Payload cerrado: campos comunes, sequence_number, locator, state_epoch, previous_event_commitment (null sólo al alta), previous_state_commitment (null sólo al alta), new_state_core, effective_at, reason, authorization_evidence_commitment. new_state_core es C5 sin latest_event_commitment; éste se deriva del compromiso de C8 para construir la hoja. Así no se introduce un ciclo evento↔estado. Razones candidatas registration, rotation, recipient_revocation, owner_revocation, compromise, expiry, suspension, erasure.

El evento lo atestigua authority_attestation; se conserva la solicitud y evidencia firmada del actor autorizado de §6 bajo su compromiso, sin publicarla si revela PII. El receiver autentica evento/inclusión/hoja y confía en esa atestación de validación; el monitor puede exigir evidencias auditables con acceso autorizado. Una prueba de inclusión no demuestra que el actor tenía derecho al cambio. Grants/revocaciones del permiso siguen su lifecycle WD.

Locator/epochs/tiempos de C8 y su new_state_core deben coincidir; la hoja reproduce exactamente ese core más el compromiso C8.

4. Grafo de validación sin autoautorización

Política local C1 --quórum raíz--> Manifest C2
  |                                | roles separados
  |                           Head C3 + Checkpoint C4
  |                                   | commits
  +--genesis/anchor policy------------>| permiso WD + autoridad AS
                                      |
                           estados/pruebas C5/C6 + historia C8
                                      |
                 app actual -> control -> MSA + clave MP + dominios
                                      |
                    receipt + RBA + MSA + MP + DKIM de P1

La aceptación completa requiere todas las aristas. RBA/receipt se validan con sus roles C2 más su estado C5; la clave de app/control y la MP con su estado específico. C3/C4 se autorizan directamente desde C2, no mediante hojas firmadas por sí mismas. La clave batch legacy se configura explícitamente en C1; su futura migración a manifiesto nuevo requiere G07, no reutilizar el rol de checkpoint. Su descriptor local incluye vigencia/thumbprint y su estado key C5 puede retirar, pero nunca ampliar, esa autoridad provisionada. Una clave retirada puede servir a auditoría histórica sólo bajo una política histórica; no aporta autoridad actual para PASS P1.

5. Historia, cortes, rollback y equivocación

Historia AS: árbol acumulativo, sequence_number desde uno, índice cero-based sequence_number - 1. Payload C8 completo como hoja. Forma recursiva/split en la mayor potencia de dos estrictamente menor, sin duplicar hojas impares:

MTH([]) = H(U("XCIM-AS-01-EVENT-EMPTY\0"))
leaf(e) = H(U("XCIM-AS-01-EVENT-LEAF\0") || J(e))
node(l,r) = H(U("XCIM-AS-01-EVENT-NODE\0") || l || r)

Inclusion y consistency usan orden de RFC 6962 con tags AS. No son bytes CT; RFC 9162 es comparación de transparencia, no sustitución de fórmulas WD/AS. El checkpoint compromete raíz/tamaño AS y batch WD del mismo corte. Verificar consistencia de ambos árboles contra el origen/floor previamente aceptado, rechazando siblings extra, tamaño menor, secuencia duplicada con otro hash o predecesor inválido. Un log consistente no demuestra que la proyección sparse sea correcta: publicar eventos permite reconstrucción/auditoría por monitores.

Guardar durablemente por issuer/log policy_epoch, C2 epoch/hash, C3 sequence/hash, C4 sequence/hash, tamaños/raíces de ambos logs y máximo state_epoch/tombstones de cada locator observado. Ordenar primero por las cadenas autenticadas, no por timestamps de sender. Persistir floors antes de reutilizar positivamente la evidencia; un fallo del store retira la señal. Perder el store requiere resincronización contra un floor externo aceptado, no TOFU desde el mensaje.

El productor mantiene chains completas recuperables. Un receiver puede saltar varias publicaciones de red, pero debe validar los enlaces/pruebas omitidos o un checkpoint de recuperación aceptado fuera de banda. Una cabeza más nueva observada invalida la anterior para nuevas evaluaciones; el timestamp por sí solo no establece cuál es más nueva. Mismo número y distinto compromiso es evidencia de conflicto: poner en cuarentena ese issuer/log; no elegir el primer mirror. La restauración requiere resolución autenticada bajo C1, sin borrar la evidencia de conflicto.

Ante bifurcación/reorg, no bajar el floor para resucitar permiso. Detener señal positiva hasta establecer una continuación anclada y resolución aceptada. Dos RPC pueden coincidir y estar equivocados; se debe declarar si la finalidad se verifica con cliente de consenso/light client o corroboración RPC acotada.

6. Máquina de estados y revocaciones

Estados AS: active, suspended, revoked, expired, erased. La ausencia no es estado. Alta válida crea epoch 1; cada transición aumenta state_epoch en uno y enlaza el evento/estado anteriores. effective_at no puede moverse al pasado para ampliar autoridad. Una revocación por compromiso puede declarar una fecha de compromiso anterior en evidencia de incidente, pero no reescribe effective_at ni hace verificable una hora de firma no atestiguada.

active → suspended/revoked/expired/erased; suspended → active sólo para app/dominio y con evidencia nueva/epoch superior. Para una MSA suspendida, reemitir otra con ID nuevo para evitar reanimación accidental. revoked, expired y erased no vuelven a active. Tombstones sobreviven a la eliminación de material privado; erasión no borra el hecho público ni revierte una negativa.

La elección inicial conservadora ante cambio de control puede exigir renovar consentimientos aunque el propietario siga siendo el mismo: es un coste real, no una obligación textual de WD de incrementar epoch en toda rotación. La alternativa es continuidad de control con firmas de ambas claves, posesión, atestación de mismo owner y authority_epoch nuevo conservando app_epoch. Requiere fijar cómo se conserva el binding app_key_id del receipt histórico; A6 debe aceptar el coste conservador o definir esa continuidad antes de M.

Rotación MP ordinaria: crear clave/ID MSA nuevos, publicar activación y probar ambas; overlap candidato máximo 3600 s si no hubo compromiso, acotado por todas las vigencias. Retirar vieja de forma terminal. Al comprometer una clave, no hay overlap ni aceptación de firma backdated: P1 exige autoridad actual y iat no es un sello temporal independiente. Conservar auditoría histórica sin confundirla con permiso para nueva entrega. Rotación de control sigue el comportamiento conservador WD; una alternativa que preserve grants tras rotación de control necesita decisión/versionado explícitos.

La solicitud de revocación no se da por «publicada» al escribir en una cola. El operador distingue received, authenticated, committed, anchored, available. Los ACK internos nunca son proofs ni resultados de protocolo. Un timeout del anchor no permite declarar vigente un checkpoint nuevo.

7. Frescura, reloj y propagación

Parámetros candidatos para ensayo, sin mediciones ni SLA productivo:

Sean t reloj local y u cota de incertidumbre. Para estado que afirma validez desde s, exigir s <= t-u; para toda expiración exclusiva e, exigir t+u < e. Un snapshot todavía «del futuro» puede reevaluarse al avanzar reloj, sin consumir nonce. Este criterio conservador usa todo el intervalo de incertidumbre, no añade grace a la expiración. Para las firmas P1 existentes con tolerancia iat <= now+60, conservar su gate de emisión, pero exigir además que la autoridad de cada firmante cubra el iat declarado; esa tolerancia no amplía expiración ni frescura de C3/C4.

state_deadline = min(C3.next_update, C4.next_update,
                     C4.this_update + min(300, local_max_state_age))
manifest_deadline = min(C2.exp, C2.iat + min(86400, local_max_manifest_age))
effective_deadline = min(state_deadline, manifest_deadline,
    C1.valid_until, receipt.exp, RBA.exp, MSA.exp, MP.exp,
    each_required_key.valid_until, each_required_state.valid_until,
    each_required_domain.recheck_by, selected_anchor_policy_deadline)

Convertir tiempos WD RFC3339 a instante exacto sin truncar fracciones ni reescribir bytes firmados. Si la política de anchor no define deadline temporal, usa infinito sólo para ese término: igualmente debe estar verificada y la finalidad no renueva el tiempo del corte. C3/C4/C2 deben cumplir s < e y sus edades máximas al evaluarse. Intersectar también las vigencias de claves al emitir y ahora; una clave puede estar autorizada a emitir hasta antes de que expire el objeto, pero no a sostener señal positiva tras su propio retiro.

Ejemplo: corte 12:00, vence 12:05, u=30 s; a 12:04:29 puede ser utilizable si todas las demás pruebas pasan; a 12:04:30 deja de ser positivo. Descargarlo 12:04:59 no lo renueva. Recibirlo a 12:00:10 con esa incertidumbre es demasiado temprano para afirmar que el corte ya ocurrió; se puede esperar/reevaluar.

Con autoridad honesta, reloj acotado y cortes atómicos, una revocación ocurrida inmediatamente después de un corte puede ocultarse hasta el deadline de ese corte, como máximo la ventana de 300 s propuesta. Detener publicaciones hace caducar la señal; no prolonga permiso. Si se compromete C3/C4 o su autoridad, esa cota deja de aplicar: el límite de C2 puede alcanzar 24 horas y un issuer o quórum raíz deshonesto puede emitir estado falso. Recuperación/denies locales pueden actuar antes, pero no se promete entrega instantánea de esa información.

Revalidar la intersección inmediatamente antes de aceptación SMTP/commit del nonce y al reutilizar un resultado exportado. Trabajo asíncrono, 304, ETag, Age, hora de descarga o manifest de release no extienden ningún término. Si se usan cachés entre MX, compartir floors, tombstones y política de invalidez; el ledger de replay sigue siendo otra transacción pendiente en G16.

8. Ausencia, fallos y resultado compuesto

Proponer internamente {validation, permission, authority, freshness, publication, replay, effective_deadline, diagnostics}. Son dimensiones locales de diagnóstico, no nuevos códigos registrados. Conservar todos los fallos válidamente comprobados; no transformar un error de transporte en revocación.

Orden candidato determinista para retirar la señal: parseo/límites/perfil → trust/firmas/compromisos → conflicto/rollback/prueba inválida → negativa autenticada de permiso/autoridad → evidencia vencida → dependencia ausente o inaccesible → todas las condiciones satisfechas. Cada etapa sólo produce hechos después de autenticar sus prerrequisitos; un estado «revoked» en JSON no autenticado no tiene precedencia. Si hay varios fallos de una etapa, ordenar por rol/locator canónico y conservar la lista completa.

Una revocación de permiso autenticada puede retirar permiso sin anchor, como permite el core, pero el resultado debe indicar que no es verificación de publicación completa. No permitir que un anchor caído tape esa negativa; tampoco emitir revocado si la prueba está ligada a otro contexto. Ausencia autenticada de MSA/clave/app retira autoridad y no se etiqueta XCIM_REVOKED del permiso.

Para el protocolo, conservar el registro vigente: XCIM_REVOKED sólo cuando corresponda al permiso, XCIM_STATUS_STALE para evidencia vencida, XCIM_STATUS_INDETERMINATE para insuficiencia, XCIM_ANCHOR_UNAVAILABLE cuando falte el anchor requerido y XCIM_LOG_PROOF_FAIL para una prueba inválida autenticablemente atribuible al contexto. D09/D12 deben ratificar el mapeo completo de conflictos/autoridad y multifallos antes de afirmar conformidad. El código P1 de fixture sigue sin emitir PASS.

9. Alternativas y condiciones para reconsiderarlas

La separación thisUpdate/nextUpdate de OCSP inspira el vocabulario de estado, sin adoptar su ASN.1 ni su modelo de trust. La raíz como input local y las dificultades de recuperación se comparan con PKIX/DNSSEC. La propuesta AS es diseño XCIM, no un perfil ya validado por esos RFCs.

10. Criterios de cierre por brecha

Duración/carga/p99 son propuesta de ensayo, no garantías medidas. Una autoprueba puede completar evidencia interna, pero no satisface por sí sola «otro implementador», revisión externa ni operación entre equipos independientes. El primer envío S puede declarar estas brechas abiertas; no hay envío implícito.

11. Catálogo de pruebas por escribir, no resultados

Casos planificados AS-T01–AS-T24; no están sumados a los 135 casos P1 existentes:

12. Dirección adoptada y concreciones pendientes

Dirección A1–A6 adoptada; secuencia técnica: schemas AS y evidencia sintética cerrados → dos verificadores de fórmulas/temporización → adaptador/anclaje seleccionado → snapshots/rotación/revocación continuos → interop y revisión externas. En paralelo se puede revisar el diseño con expertos autorizados; no se enviaron mensajes ni se contactó a IETF por publicar este material.

13. Referencias y comparación con estándares

• Baseline WD-02-E1 core, §§4,7,10–16: confianza local, autoridad actual, árboles, anclaje y estado fresco.
• P1-01: bindings aceptados de destinatario/MSA/MP y límites de fixture.
• RFC 5280 §6.1.1: trust anchor como input a validación; AS no adopta una PKI X.509 propia.
• RFC 6960 §2.4: distingue observación de estado, próxima actualización y firma; AS define su propio deadline conservador.
• RFC 5011 §§2,8: actualización/compromiso de anclas y necesidad de recuperación externa en ciertos casos. No se reutiliza su algoritmo DNSSEC.
• RFC 9162 §§2.1,11.3: transparencia y límites ante vistas inconsistentes; no demuestra ausencia de equivocación por sí sola.
• RFC 6962 §2: orden/forma de los proofs ya usados por el baseline. RFC 9162 lo reemplaza para CT; conservar fórmulas históricas XCIM no es afirmar uso de CT moderno.

Referencias externas consultadas el 2026-10-19. Las construcciones AS adicionales son propuesta de proyecto y requieren revisión propia, no aprobación de esos RFCs.

14. Concreción propuesta del adaptador AN01-P01

AN01-P01 propone el ABI, genesis acíclico, red y finalidad del adaptador exigido por A4. Sus N1–N6 fueron adoptadas: contrato inmutable por issuer/log, Amoy opt-in y nodo de consenso del receiver. Incluye alternativas, gates y 20 casos EVM/red pendientes; AN01-F01 implementa contrato/schemas/EVM local, con cobertura parcial del plan y finalidad viva pendiente. No cambia la adopción A1–A6, C7 F01 sigue null y G04–G06 conservan sus dependencias M/O.