Resumen

  • El W3C publicó Web Authentication Level 3 como Recomendación el 25 de agosto de 2026 y enlazó un informe de implementación fijado al 26 de junio.
  • La página declara 53 pruebas y 415 subpruebas sobre versiones identificadas de Chrome, Firefox, Safari Preview y Edge, todas ejecutadas contra el mismo commit de WPT.
  • El registro final solo dice que una parte de Chrome difiere de Edge. Una clave por función debería explicar qué capa es independiente, con qué evidencia y para qué proposición de la transición.

La matriz conserva bien la ejecución

Web Authentication: An API for accessing Public Key Credentials — Level 3 define la interfaz con la que las aplicaciones web crean y utilizan credenciales de clave pública acotadas a una parte usuaria, mediante agentes de usuario y autenticadores. La versión del 25 de agosto es una Recomendación del W3C, recomienda su despliegue amplio y señala que no hubo cambios sustantivos después de la instantánea de Recomendación Candidata del 26 de mayo.

En su cabecera aparece un informe de implementación fijo. La página se fecha a 26 de junio, advierte que no se mantiene y remite al servicio vivo para conocer resultados posteriores. Registra 53 pruebas y 415 subpruebas dentro de /webauthn/.

También conserva datos concretos de cada ejecución. Chrome 151 y Firefox 154 alpha se probaron en Linux el 25 de junio. Safari 246 Preview se ejecutó en macOS y Edge 151 en Windows el día 26. Las cuatro entradas identifican el commit WPT d41367df1e. La tabla distingue luego PASS, FAIL, TIMEOUT, ERROR, NOTRUN y resultados ausentes.

Esa precisión responde a una pregunta verificable: ¿qué observó esta compilación, en este entorno, frente a esta revisión del conjunto de pruebas? La columna no responde automáticamente a otra pregunta del Proceso: ¿qué observaciones provienen de implementaciones independientes e interoperables de una función?

Contar cuatro nombres comerciales sería un atajo. Declarar que Chrome y Edge nunca pueden ser independientes sería el atajo opuesto. Un producto puede combinar motor, servicios del sistema operativo, autenticador de plataforma y componentes específicos del proveedor. La ruta relevante puede ser compartida en una función y distinta en otra. La independencia necesita sujeto y alcance.

La propia transición deja constancia de la ambigüedad

El expediente final enlaza bajo “Implementation” los resultados WPT vivos y la instantánea. A continuación dice que una parte de la implementación en Chrome es distinta de la de Edge.

La salvedad evita borrar una diferencia real solo porque dos productos tengan componentes comunes. Sin embargo, “una parte” no identifica función, grupo de pruebas, frontera de componente ni fuente. El lector tampoco sabe si un par de resultados Chrome-Edge se utilizó como prueba independiente para una proposición concreta de la transición.

Las actas del Grupo de Trabajo del 18 de marzo conservan más contexto. Durante el tema “Testing”, un participante mencionó diferencias técnicas de Edge respecto del “Chrome normal”. La conversación pasó a preguntar si Microsoft Authenticator operaba a través de Android o iOS y, para una extensión, trató esos caminos como dos implementaciones en la capa WebAuthn. Más tarde, las actas registran consenso sin objeciones para proponer la Recomendación una vez resueltos los asuntos pendientes.

Es una señal importante: el grupo no ignoró la independencia. Hizo preguntas por capa. La pérdida se produce al resumirlas. Cuando el razonamiento llega al recibo público final, la extensión y la capa desaparecen y queda una frase sin coordenadas. La matriz de resultados y la afirmación de linaje están juntas, pero no relacionadas fila por fila.

La decisión no está en duda. El expediente consigna aprobación del Equipo el 17 de julio, cierre de la revisión del Comité Asesor el 18 de agosto con consenso y sin objeciones formales, autorización de publicación el 19 de agosto y el enlace de la Recomendación el día 25. La falta de detalle público no demuestra ausencia de evidencia privada ni permite rebajar esos actos a borradores.

El Proceso no fija una suma de navegadores

La sección de experiencia de implementación del Proceso del W3C evita una fórmula universal. La evidencia debe mostrar que la especificación es suficientemente clara, completa y pertinente para que haya implementaciones independientes e interoperables de cada función. El Equipo puede considerar si cada función está implementada, si las implementaciones son independientes, si las construyeron personas distintas de los autores, si están desplegadas públicamente, si la experiencia cubre varias capas del ecosistema y si se han comunicado problemas.

Son proposiciones distintas. Una celda PASS demuestra un comportamiento observado en una ejecución. Sin más procedencia no demuestra quién implementó la función ni qué código intervino. Dos sistemas operativos pueden importar mucho en una función dependiente de la plataforma y casi nada en otra. Un commit común de WPT permite comparar los ensayos, pero no describe la genealogía del software sometido a prueba.

Tampoco deben convertirse los estados mixtos en una clasificación de seguridad. Un FAIL puede revelar falta de soporte, una decisión diferente o una expectativa de prueba que requiere análisis. TIMEOUT y ausencia de dato dicen menos. La transición a Recomendación no exige que todos los casilleros de todos los productos estén en verde, y este artículo no inventa ese umbral.

Un índice pequeño para una afirmación precisa

La solución puede ser una tabla auxiliar por función o grupo de pruebas. Cada fila conservaría la versión de la especificación, el commit del ensayo, el producto y la compilación, y la capa técnica relevante. Después formularía una afirmación acotada de independencia, respaldada por una fuente pública o por una declaración atribuible cuando los detalles no puedan exponerse.

La fila añadiría la observación de interoperabilidad y diría si se usó en la transición. Si Chrome y Edge ejecutan caminos distintos para una extensión, eso se registra solo allí. Si comparten el camino pertinente para otra función, dos columnas de producto no se convierten por silencio en dos implementaciones. Firefox, Safari, Android, iOS, autenticadores y software de las partes usuarias deberían recibir el mismo tratamiento funcional, no una etiqueta permanente.

No se propone una auditoría de código ni un nuevo órgano de aprobación. El Equipo del W3C conserva el juicio contextual que le asigna el Proceso. La clave separa tres hechos: dónde se ejecutó la prueba, qué conducta se observó y por qué la implementación se considera independiente para un propósito definido.

La nota Minimum Initial Specification de Lu Heng aporta la disciplina de fondo: una recomendación es un artefacto de coordinación; implementación, validación, despliegue y adopción siguen siendo hechos separados. La misma modestia vale para la evidencia previa: el nombre del navegador prueba el producto probado, no toda la arquitectura que hay debajo.

Fuentes