Resumen

  • draft-ietf-ocm-integration-protocol-00 se publicó el 11 de septiembre de 2026 después de que el grupo Open Cloud Mesh adoptara el trabajo. La adopción abre una fase colectiva; no equivale a un RFC.
  • Los modos aprovisionado, autocontenido y con introspección distribuyen de forma distinta el estado, la disponibilidad y el tiempo de revocación. La emisión también puede pasar a un servidor de tokens delegado.
  • El receptor no debe descubrir la composición interna. Daniel Kade propone que el operador conserve un mapa protegido de responsabilidades y resultados, separado de los tokens y de la vista pública.

Una decisión de trabajo, no una norma terminada

El historial del Datatracker registra el nuevo documento de grupo y su sustitución de la serie individual el 11 de septiembre. El mensaje del presidente confirma la adopción, pero llama a los textos puntos de partida que seguirán cambiando. La noticia consiste en que el grupo ha asumido el documento, no en que la IETF haya aprobado una norma o que exista una implantación general.

El borrador de grupo 00 parte de una división sencilla. El servidor OCM sigue siendo el servidor emisor ante la federación. Uno o varios servidores de protocolo atienden las operaciones concretas: WebDAV, SSH/SFTP o aplicaciones web. Pueden funcionar con otro software y en otra infraestructura.

Además, el punto de emisión de credenciales puede delegarse en un servidor de tokens. En la topología más ligera, el servidor OCM se ocupa de descubrimiento, invitaciones, notificaciones y contabilidad del intercambio, mientras el acceso y los tokens se resuelven fuera. La identidad protocolaria permanece estable aunque cambien los componentes que ejercen la función.

La primera versión del grupo añade un modelo de amenazas respecto a la versión individual 01. El modelo considera de confianza a los servidores OCM, los servidores de protocolo emparejados y el posible servidor de tokens. Supone que no están comprometidos y que aplican bien las políticas locales. Esa suposición delimita la protección: firmas y TLS resisten manipulaciones del canal, no una mala decisión administrativa o un extremo ya comprometido.

Tres maneras de repartir el coste operativo

En el modo aprovisionado, el servidor OCM envía por un canal firmado los datos del recurso compartido antes de que se use. El servidor de protocolo guarda un registro y recibe después una orden de revocación. Es el único modo que contempla SSH y el adecuado cuando una aplicación crea recursos por cada intercambio, porque existe una señal explícita para liberarlos.

En el modo autocontenido, el servidor de protocolo no mantiene ese estado ni abre una API de aprovisionamiento. La autorización viaja dentro de la declaración ocm_ip de un JWT firmado. El ahorro de estado cambia el comportamiento de la revocación: un token emitido sigue funcionando hasta caducar. El borrador prohíbe mezclar este camino con el aprovisionado en un mismo recurso para evitar que un token anterior sobreviva a la retirada del registro.

El modo con introspección consulta un endpoint conforme a RFC 7662 cada vez que necesita validar una credencial no almacenada en caché. Mantiene la compatibilidad con receptores que aún presentan el secreto compartido heredado, pero reintroduce dependencia de red y de disponibilidad. Una respuesta positiva almacenada también marca cuánto puede tardar en surtir efecto una revocación.

Por eso, la pregunta de gobernanza no es solamente quién implementa OCM-IP. También es qué modo se autorizó para cada recurso, qué duración se aceptó y qué prueba confirma que una revocación terminó donde debía.

El receptor ve el contrato, no el organigrama técnico

La exigencia de transparencia del documento está dirigida al receptor: no debe implementar OCM-IP ni saber que existe. La URI anunciada puede ser atendida por el propio servidor OCM, por un proxy o por un servidor de protocolo con otro nombre. La capa OCM no ofrece una capacidad que permita distinguirlos.

Dentro del dominio emisor sí existe una relación explícita. El emparejamiento se configura fuera de banda y especifica protocolos, tipos de recursos, modos, dominios, endpoints y ubicaciones de claves. El servidor de protocolo debe mantener una lista permitida de emisores OCM y rechazar a quien no esté emparejado.

Las peticiones del canal interno se protegen con firmas de mensajes HTTP y claves publicadas como JWK. Los accesos se apoyan en JWT firmados. Una verificación correcta enlaza un mensaje con una clave; las reglas del emparejamiento enlazan esa clave con un alcance autorizado.

Sin embargo, ese resultado no identifica al responsable que aprobó una sustitución, no conserva la razón de un cambio de modo y no demuestra que una sesión efímera fue eliminada al dejar de compartir. El propio borrador califica al servidor de protocolo como parte de la base de confianza del emisor y entrega al servidor de tokens autoridad de firma e información de identidad. Son decisiones operativas que merecen evidencia propia.

ocm_ip sigue siendo una solicitud

El apartado de IANA solicita que ocm_ip se registre como declaración JWT y como miembro de una respuesta de introspección cuando el texto llegue a ser RFC. Las consultas actuales al registro de JWT y a los registros de parámetros OAuth no muestran esa entrada exacta.

No hay contradicción. La adopción por un grupo decide quién desarrolla la propuesta; IANA actuará sobre una instrucción válida en una etapa posterior. Los experimentos deben declarar su versión y no presentar la cadena solicitada como una asignación vigente.

Un mapa local para una cadena que no se publica

Daniel Kade propone un mapa de responsabilidad de la delegación bajo control de acceso. Por cada relación debería anotar el servidor OCM, el servidor de protocolo y el servidor de tokens; las funciones y recursos asignados; el modo; identificadores de endpoint y clave; fecha de inicio y fin; quién o qué proceso autorizó el cambio; resultado de revocación y limpieza; contacto de incidentes; y ubicación de los registros probatorios.

No es un requisito de la IETF ni de OCM. Tampoco debe convertirse en un nuevo secreto incrustado en el token. Si existe una constancia pública, puede limitarse a un identificador opaco, una clase de función, un periodo de vigencia y un resultado verificado. La topología detallada y los datos personales siguen siendo internos.

El mapa documenta; no concede. Si cambia un componente, la nueva fila enlaza la anterior en vez de borrarla. Si llega una revocación aprovisionada, se registra por separado la entrega de la orden y la liberación del recurso. Si expira un token autocontenido, se evita confundir caducidad nominal con observación de que el acceso cesó.

Esta disciplina coincide con The Policy Mirror de Heng Lu: actor, regla y evidencia son objetos distintos. La Minimum Initial Specification permite que la especificación común sea pequeña sin impedir registros locales más exigentes. El par obtiene interoperabilidad; el operador conserva memoria institucional.

Fuentes

  1. Protocolo de integración OCM, WG 00
  2. Ficha actual del Datatracker
  3. Historial del documento
  4. Resultado de la adopción
  5. Predecesor individual, revisión 01
  6. Grupo de trabajo Open Cloud Mesh
  7. Acta OCM de IETF 126
  8. Protocolo base OCM, WG 06
  9. RFC 9421 — firmas de mensajes HTTP
  10. RFC 7517 — JSON Web Key
  11. RFC 7662 — introspección OAuth 2.0
  12. RFC 7519 — JSON Web Token
  13. Registro JWT de IANA
  14. Registros OAuth de IANA
  15. Heng Lu — The Policy Mirror
  16. Heng Lu — Minimum Initial Specification