Resumen

  • La carta propuesta del grupo Web Authentication incluye la firma de datos arbitrarios bajo mediación WebAuthn, con una clave asociada a la credencial pero separada de la clave de autenticación.
  • La redacción cita la IA agentiva y las credenciales verificables, pero mantiene fuera del alcance el acceso de bajo nivel a claves privadas y las API criptográficas generales independientes de las funciones enumeradas.
  • La admisión temática no equivale a madurez: la revisión de la carta sigue abierta, WebAuthn 4 no tiene FPWD, la pull request sign es un borrador y su explicación no registra estudios de usuario ni señales de Chrome, Firefox, Safari o Edge.
  • Un recibo público por función debe unir la autoridad de la carta con la versión exacta, las garantías de presencia y consentimiento, la separación de claves y mensajes, las revisiones, las pruebas, las implementaciones independientes y la adopción efectiva.

Cambiar el perímetro no publica una norma

La carta vigente del grupo Web Authentication delimita una tarea reconocible. Habla de autenticación fuerte, pares de claves ligados a un origen, prueba de posesión, recuperación y copias de respaldo. Declara fuera de alcance el acceso de bajo nivel a operaciones criptográficas o material de claves.

El proyecto sometido a examen añade una excepción cuidadosamente redactada. Su punto 11 permite firmar datos adicionales a los de la autenticación estándar. La operación estaría mediada por WebAuthn y usaría una clave de firma distinta de la clave de la credencial. Como contextos posibles cita la IA agentiva y los ecosistemas de credenciales digitales verificables. Otros dos puntos incorporan señales de confianza sobre gestores de credenciales y mejoras de confidencialidad.

No es una pequeña corrección editorial. El propio Proceso del W3C considera importante cualquier ampliación de alcance. Por eso hay revisión del Advisory Committee y debe haber una Decisión del W3C. La consulta pública empezó el 10 de agosto, termina el 7 de septiembre a las 23:59 UTC y la carta actual fue prorrogada hasta el 30 de octubre. La nueva todavía es una propuesta.

Si se aprueba, la conclusión será que el grupo puede ocuparse del asunto. No será que la API de la pull request queda elegida, que dos implementaciones interoperan o que los navegadores deben ofrecerla. Web Authentication nivel 4 figura como futuro entregable normativo, pero la carta reconoce que aún no se publicó su First Public Working Draft y sitúa la posible conclusión en el cuarto trimestre de 2028.

Firmar bytes no demuestra haber entendido una decisión

WebAuthn ya produce firmas, pero una aserción normal no firma el reto del sitio sin más. Firma una estructura definida que combina datos del autenticador con el hash de los datos del cliente. La extensión nueva persigue una salida diferente: una firma directamente sobre la entrada que entrega la aplicación.

La ventaja es la compatibilidad. Un verificador existente puede saber validar una firma convencional y no entender la envoltura de una aserción WebAuthn. Con la nueva capacidad, una aplicación web podría usar claves protegidas por hardware para una cartera digital, un token de autorización o una firma de software sin recibir la clave privada en JavaScript.

La arquitectura propuesta intenta mantener límites valiosos. La clave de firma debe ser distinta y no estar relacionada criptográficamente con la credencial padre. Así se evita que un sitio use el mecanismo general para obtener algo que parezca una aserción de autenticación válida. La vinculación al origen busca impedir que la clave se convierta en un identificador entre sitios. La política mínima de presencia y verificación se fija al crearla. Las páginas web no obtendrían el modo de firma desatendida que sí puede existir en la capa inferior para clientes nativos.

Pero ninguna de esas propiedades significa que una persona vio y comprendió el contenido firmado.

La propia explicación dice que la confirmación de transacciones no es un objetivo. Supone datos binarios opacos y no obliga a una interfaz confiable a mostrarlos de forma comprensible. La ceremonia puede probar que una clave operó bajo una política determinada. No prueba por sí sola que la persona leyó un documento, autorizó el paso concreto elegido por un agente o aceptó el efecto jurídico que una organización atribuirá después a la firma.

La frontera está publicada y debe conservarse. «Usuario verificado», «mensaje entendido» y «agente facultado para escoger el mensaje» no son sinónimos.

La evidencia disponible sigue siendo de incubación

La página explicativa declara que no se ha realizado investigación con usuarios. En la tabla de partes interesadas no aparece una señal de Chrome, Firefox, Safari ni Edge. Sí hay un apoyo de un fabricante de autenticadores y otro de una relying party. «Sin señal» no quiere decir «en contra»; quiere decir que la posición no está fijada.

La pull request 2078 continúa marcada como Draft y vinculada al hito del primer borrador público de nivel 4. En septiembre de 2024 su autor habló de prototipos internos apenas iniciados y de ninguna promesa de otros participantes en ese momento. Las conversaciones y pruebas posteriores muestran avance e interés. No equivalen, en el registro consultado, a un informe abierto con dos implementaciones independientes e interoperables.

El Proceso del W3C ofrece una escalera que evita confusiones. Primero se decide la carta. Después existe una propuesta concreta, un FPWD, revisiones horizontales, pruebas abiertas y experiencia de implementación. Candidate Recommendation solicita revisión final y experiencia. Recommendation añade otra decisión institucional. Al final, fabricantes y usuarios deciden si ejecutan la función.

Cada peldaño responde una pregunta: competencia del grupo, existencia del diseño, publicidad del texto, examen de riesgos, verificabilidad, interoperabilidad, respaldo formal y adopción. Saltarlos retóricamente no acelera la ingeniería; sólo borra qué se ha probado.

La idea de Heng Lu de no confundir publicación con realidad operativa sirve aquí de forma acotada. Este análisis no equipara el W3C con un registro de recursos numéricos. Toma una disciplina más elemental: una modificación posterior se vuelve real cuando sistemas independientes la implementan, validan y adoptan, no cuando una institución la menciona por primera vez.

El recibo debe seguir a la función, no sólo al documento

La ficha empezaría con el punto exacto de la carta y su estado. Luego identificaría la revisión del explainer y del texto técnico. Para cada versión registraría qué se firma—datos completos, un hash o una envoltura—, el identificador del algoritmo y la regla de separación de dominios. También indicaría cómo se separan la credencial y la clave de firma, a qué origen queda ligada, qué política de presencia y verificación es inmutable y qué ve realmente la persona.

Otro bloque conservaría lo que la atestación demuestra y lo que no; el análisis de correlación y huella digital; las señales de navegadores, autenticadores y sitios; las cuestiones de accesibilidad, privacidad, internacionalización y seguridad; su resolución; la cobertura de pruebas; las implementaciones independientes; las objeciones; y el estado de madurez.

No hace falta revelar claves, identificadores de dispositivo, datos personales ni detalles aprovechables para atacar una implementación. Tampoco hace falta inventar una junta nueva. El recibo es un índice versionado de las pruebas y decisiones del proceso existente.

Su utilidad aparece cuando cambia el expediente. Una señal posterior no reescribe el antiguo «sin señal». Una nueva interfaz de confirmación no borra que el diseño inicial no la prometía. Una función descartada termina como descartada. Y una frase de la carta deja de circular como si fuera una autorización de producto sin fecha.

Fuentes

  1. W3C — convocatoria para revisar la carta propuesta de Web Authentication
  2. Carta propuesta del grupo Web Authentication
  3. Carta actual del grupo Web Authentication
  4. Recomendación Web Authentication nivel 3
  5. Explicación de la extensión de firma en bruto
  6. Pull request preliminar sign 2078
  7. Proceso del W3C, 18 de agosto de 2025
  8. Heng Lu — Running-Code Primacy
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision and Voluntary Adoption