Resumen

  • La revisión 03 de draft-wilder-scitt-physical-site-engage-receipt, registrada el 9 de septiembre de 2026 y fechada el día 10, incorpora el modo de atestación al propio recibo y obliga a informar undetermined cuando no se resuelve un hecho externo publicado por el emisor. Es un Internet-Draft individual activo, no una propuesta adoptada por SCITT ni una norma del IETF.
  • La misma revisión reconoce que no existe un dato para la relación entre el dueño del sitio y el servicio de transparencia. Por eso, demostrar que el servicio es externo al emisor no demuestra que sea independiente de la parte que controla el sitio.

Pensemos en una inspección autónoma dentro de una planta. El recibo identifica el lugar, al actor y la ventana de trabajo; incluye evidencia sellada por un entorno de ejecución confiable; y obtiene una prueba de que la declaración firmada entró en un servicio de transparencia. Si todas esas comprobaciones son válidas, el expediente acredita algo importante y limitado.

No acredita quién gobierna el servicio. Un dueño del sitio podría operar el registro mientras un emisor sin relación con él firma los recibos. El documento que sí entra sería auténtico y su inclusión estaría probada. Pero el dueño conservaría una capacidad sobre el conjunto visible: podría retener una entrada relativa a su propio emplazamiento. La firma impide fabricar la voz del emisor; no obliga al operador del registro a mostrar todo lo que nunca admitió.

La revisión 03 del perfil Physical-Site Engagement Receipt, PSER, no oculta esa tensión. Añade una sección dedicada a ella. El avance consiste en nombrar el hueco con precisión, no en presentarlo como cerrado.

Estado institucional y cambio técnico

El registro de Datatracker muestra un Internet-Draft individual activo sin flujo RFC ni estado RFC previsto en sus metadatos. La portada solicita Standards Track, pero esa aspiración del autor no convierte el texto en documento de un grupo de trabajo, consenso del IETF ni despliegue. El historial sitúa la revisión a las 22:26 PDT del 9 de septiembre; el propio archivo lleva fecha del 10.

La revisión 02 exigía consultar cuatro veces un «manifiesto del emisor» cuyo formato nunca definía. El comparador oficial deja claro que el arreglo no es cosmético. El perfil sube de wilder.pser/0.4 a wilder.pser/0.5 e introduce attestation.bindingMode como miembro obligatorio.

Ese valor distingue un testigo directo, donde la clave de la TEE firma el recibo, de un testigo delegado, donde firma el emisor autorizado por una credencial de la TEE. Si un recibo declara modo directo y attestation.witnessKey no coincide con iss, el verificador debe rechazarlo. Una propiedad que antes dependía de un documento exterior ahora viaja con los bytes a los que se aplica.

Quedan fuera dos hechos que sí requieren resolución. Uno es la credencial de delegación; el otro, la relación entre emisor y servicio de transparencia. Deben localizarse en un identificador estable bajo control del emisor y descubrible a partir de iss. Al cambiar la clave, no se puede conservar el resultado almacenado en caché.

Cuando el hecho no es accesible, legible o localizable, el resultado es undetermined. No equivale a independencia ni a afiliación, tampoco a una ausencia que se haya comprobado. El verificador no puede convertirlo en la salida más cómoda para el emisor. Tampoco rechaza el recibo por esa sola causa: entrega el estado a la política de la parte usuaria, que decide si puede asumir la incertidumbre.

Las tres aristas no tienen la misma custodia

Entre emisor, propietario y servicio aparecen tres relaciones.

Emisor–propietario del sitio está dentro del recibo. issuerAffiliation declara si son afiliados, independientes o si la relación no se revela. Es una afirmación firmada por el emisor, con una identidad y un momento; no es una auditoría corporativa automática.

Emisor–servicio de transparencia se publica por separado. Si el servicio está operado por el propio emisor o por una entidad afiliada, la parte usuaria no debe tratar la inscripción como evidencia externa al emisor. Si es independiente y la revelación se resuelve, sí puede aportar esa propiedad acotada.

Propietario del sitio–servicio de transparencia no tiene representación en PSER-03. La nueva sección 7.9 explica que las otras dos relaciones no la permiten inferir. Un emisor puede ser independiente del propietario y del servicio mientras el propietario opera ese servicio. Todas las declaraciones existentes encajan, pero falta justamente la independencia frente a quien controla el entorno físico observado.

No es una acusación contra un despliegue. El borrador no acredita que exista una implementación con esa estructura ni que alguien haya ocultado datos. Identifica una opción de control: el propietario que maneja el servicio puede suprimir o retener entradas sobre su propio sitio aunque no pueda falsificar la firma del emisor.

El recibo responde a una pregunta más estrecha

El RFC 9942 define los recibos COSE como pruebas firmadas sobre propiedades de una estructura de datos verificable. Verificar una prueba de inclusión confirma que una entrada pertenece a esa estructura. El RFC 9943 coloca por separado al emisor, al servicio que aplica una política de registro y a la parte que consume la declaración transparente.

Esa separación protege integridad y observabilidad, pero no aporta por sí sola independencia institucional. PSER dice además que registrar cada recibo es obligatorio sin que la inscripción de uno demuestre que el emisor registró todos los que produjo. Una cadena de hashes tampoco detecta una cola omitida si nadie conservó antes un ancla externa.

Por tanto, «recibo válido» puede sostener decisiones distintas. Una política contractual puede pedir autenticidad. Un auditor puede exigir un servicio externo al emisor. Un regulador puede requerir que la evidencia sea externa también al propietario del sitio. La interfaz criptográfica no debería borrar esas diferencias de mandato.

La nueva categoría undetermined ofrece una salida honesta. Si la tercera relación no se comprobó, debe seguir indeterminada en el expediente. Una fuente posterior puede actualizar el conocimiento, pero no cambiar lo que se sabía cuando se aprobó un pago, se rechazó una reclamación o se cerró una inspección.

Un registro de custodia con tres aristas

El control mínimo es un registro de custodia de tres aristas. Para cada recibo, conserva la versión de perfil y las identidades del emisor, dueño y servicio; el estado de cada relación bilateral; la fuente y hora de resolución; y el criterio de independencia que la parte usuaria decidió aplicar.

También debe enlazar la identidad del servicio, el punto de control de inclusión, la observación temporal, un segundo servicio o monitor si existe, cualquier salida undetermined, el resultado profesional y su motivo, y la corrección que lo sustituya. No hace falta publicar una ficha sensible del lugar. Basta con poder demostrar qué relación fue verificada, cuál siguió abierta y cuál no era exigida.

Un segundo registro no equivale siempre a un segundo custodio: dos servicios bajo el mismo propietario comparten el poder que se pretende dividir. De igual modo, una afiliación conocida no obliga al rechazo si la política la permite. El objetivo es evitar que una comprobación correcta responda a una pregunta diferente de la que activó el efecto.

Esta lectura aplica el mapa de control de The Policy Mirror y la insistencia de Running-Code Primacy en conservar evidencia de lo que realmente ejecutó el sistema. Reality, Not Advocacy marca el límite editorial: informar del hueco reconocido sin inventar abuso, fracaso o adopción. El registro de tres aristas es una propuesta de Daniel Kade, no texto del IETF.

PSER-03 ha separado por fin «externo al emisor» de «independiente del sitio». Mientras esa tercera relación no viaje con la decisión, la mejor prueba de inclusión seguirá siendo exactamente eso: prueba de inclusión, no de independencia.

Fuentes