Fecha de publicación: 13 de noviembre de 2024
A partir de Chrome 132, la versión para computadoras de Chrome (macOS, Windows, Linux y ChromeOS) es compatible con la API de Signal, que puede mantener las llaves de acceso en los proveedores de llaves de acceso coherentes con las credenciales de clave pública en el servidor del usuario de confianza.
Cuando se crea una llave de acceso (una credencial detectable), los metadatos, como un nombre de usuario y un nombre visible, se guardan en el proveedor de llaves de acceso (como un administrador de contraseñas) junto con la clave privada, y la credencial de clave pública se guarda en el servidor de la parte de confianza (RP). Guardar el nombre de usuario y el nombre visible ayuda al usuario a identificar con qué llave de acceso acceder, ya que se le solicita que seleccione una llave de acceso cuando accede. Esto es útil cuando tienen más de dos llaves de acceso de diferentes proveedores.
Sin embargo, hay algunos casos en los que las diferencias entre la lista de llaves de acceso del proveedor de llaves de acceso y la lista de credenciales del servidor pueden causar confusión.
El primer caso es cuando un usuario borra una credencial del servidor y deja intacta la llave de acceso en el proveedor de llaves de acceso. La próxima vez que el usuario intente acceder con la llave de acceso, el proveedor de llaves de acceso se la seguirá presentando. Sin embargo, el intento de acceso fallará porque el servidor no podrá verificar con la clave pública borrada.
El segundo caso es cuando un usuario actualiza su nombre de usuario o el nombre visible en el servidor. La próxima vez que el usuario intente acceder, la llave de acceso en el proveedor de llaves de acceso seguirá mostrando el nombre de usuario y el nombre visible anteriores, aunque se hayan actualizado en el servidor. Idealmente, deberían estar sincronizados.
API de Signal
La API de WebAuthn Signal permite que los RP indiquen credenciales existentes a los proveedores de llaves de acceso conectados. Esto permite que un proveedor de llaves de acceso compatible actualice o quite llaves de acceso incorrectas o revocadas de su almacenamiento para que sea coherente con el servidor.
Por ejemplo, cuando un usuario no puede acceder a un RP porque la credencial asociada en el servidor del RP ya no existe, el RP puede usar la API de Signal para indicar que la credencial borrada ya no es válida para el proveedor de llaves de acceso, de modo que este pueda borrar la llave de acceso asociada.
Otro ejemplo es cuando un usuario va a la página de configuración del RP y borra la credencial existente. El RP puede usar la API de Signal para indicar una lista de credenciales disponibles al proveedor de llaves de acceso, de modo que este pueda mantener sincronizadas las llaves de acceso asociadas.
También puede indicar el nombre de usuario y el nombre visible actualizados para que se puedan actualizar los metadatos de la llave de acceso almacenados para el mismo usuario.
Por ejemplo, cuando un usuario actualiza su nombre de usuario o nombre visible en la RP, esta puede usar la API de Signal para indicar la información del usuario actualizada al proveedor de llaves de acceso, de modo que este pueda mantener sincronizada la información del usuario de las llaves de acceso asociadas.
El Administrador de contraseñas de Google en Chrome para computadoras implementa el AP de Signal. En el caso de los proveedores de llaves de acceso basados en extensiones de Chrome, depende de ellos si reflejan el indicador o no.
Planeamos admitir la API de Signal en Chrome para Android en el futuro.
Para obtener información sobre cómo integrar la API de WebAuthn Signal, lee Mantén la lista de llaves de acceso sincronizada con el servidor con la API de Signal.