Resumen

  • El borrador individual Capability Language Core distingue allow_unresolved de una autorización plena cuando el núcleo reconoce una condición que no puede comprobar.
  • La decisión final corresponde al componente que aplica la política; los ensayos de tres programas del mismo autor no acreditan aún interoperabilidad independiente.

Supongamos que un agente recibe una facultad para consultar datos, pero la concesión también exige una franja horaria o una red determinada. El lenguaje de autorización puede analizar la instrucción y reconocer el límite sin tener acceso al reloj o a la red del lugar donde se ejecutará. Si en ese punto se devuelve un «sí» binario, una condición sustantiva se convierte en decoración. El nuevo texto de Jijie Wei intenta impedir precisamente ese salto.

draft-wei-capability-language-core-00, publicado el 27 de septiembre de 2026, es un Internet-Draft individual con intención Experimental. La ficha del IETF lo mantiene en I-D Exists y advierte que el envío no representa respaldo formal del proceso de estandarización. No hay un RFC ni una implantación demostrada. Lo que se propone es una semántica común para nombrar capacidades, comprobar la relación entre concesiones y operaciones, intersectar varias fuentes y obtener decisiones deterministas.

La novedad más operativa está en la respuesta de tres valores. Según la sección 8.4, una restricción de tiempo o red válida en su forma pero sin evaluador en el núcleo v1 debe permanecer en la lista unresolved. El resultado es allow_unresolved, no allow. El texto obliga al consumidor de la respuesta —el punto de aplicación o el perfil que declara la regla— a comprobar todas esas condiciones antes de permitir la acción; si no puede, debe negar. Dos obligaciones pendientes se acumulan: verificar una no borra la otra.

El mecanismo Resolve de la sección siguiente permite comunicar, por obligación, si se cumplió, se infringió o sigue sin conocerse. A partir de ahí se calcula una nueva decisión. Ese paso no suministra por sí mismo un sensor de red fiable ni decide qué autoridad fijó la regla horaria. Son piezas del sistema consumidor. Un conector que convierta «cualquier cosa menos negar» en permiso operativo rompería la frontera semántica del borrador. Es una advertencia de diseño inferida del texto, no la descripción de un fallo observado.

También hay que distinguir el lenguaje de la confianza en la fuente. CLC no define quién debe emitir una concesión, cómo se verifica criptográficamente el soporte, cómo se registra la ejecución o qué formato tiene un recibo. RFC 9396 ya permite expresar detalles finos de autorización en OAuth; el documento nuevo solo lo menciona como posible vehículo. Que un formato existente pueda llevar una expresión de capacidad no lo convierte en una aprobación de CLC ni garantiza que el destinatario compruebe las condiciones pendientes.

El borrador comunica 123 vectores y 1.184 casos de propiedades para su clase de autorización, superados por programas en Go, Python y TypeScript. Los tres comparten autor. El propio documento reconoce que se trata de una prueba de regresión, no de validación independiente, y que el umbral de dos implementaciones autónomas continúa sin cumplirse. Se declara la clase de base CLC-A, pero no se reivindica la clase probatoria CLC-E. La noticia no es que la interoperabilidad esté resuelta, sino que la propuesta hace explícito dónde aún falta una decisión.

Fuentes