Se está enviando la API de Federated Credential Management

La API de Federated Credential Management (FedCM) se lanzará en Chrome 108 (actualmente en el canal beta). Cuando se lance en la versión estable de Chrome a fines de noviembre de 2022, la API de FedCM funcionará en Chrome sin solicitar una marca ni un token de prueba de origen.

FedCM es una API de Privacy Sandbox que proporciona una abstracción específica de casos de uso para flujos de identidades federadas en la Web. FedCM expone los diálogos mediados por el navegador que permiten a los usuarios elegir cuentas de proveedores de identidad para acceder a sitios web.

Revisa los cambios más recientes de la API en la página de actualización acumulada.

Planeamos introducir varias funciones nuevas basadas en los comentarios que recibimos de los proveedores de identidad (IdP), de los usuarios de confianza (RP) y de los proveedores de navegadores. Si bien esperamos que los proveedores de identidad adopten FedCM, ten en cuenta que FedCM sigue siendo una API en desarrollo activo y que se esperan cambios incompatibles con versiones anteriores hasta el cuarto trimestre de 2023.

Para minimizar los desafíos de implementar cambios incompatibles con versiones anteriores, actualmente tenemos dos recomendaciones para los proveedores de identidad:

  • Suscríbete a nuestro boletín informativo, en el que te brindaremos actualizaciones a medida que evolucione la API.
  • Recomendamos que los IdP distribuyan la API de FedCM a través de los SDK de JavaScript mientras la API está en desarrollo y que desaconsejen los RP de los SDKs de autoaloje. Esto garantizará que los IdP puedan realizar cambios a medida que evolucione la API, sin tener que solicitar a todos los usuarios de confianza que vuelvan a realizar la implementación.

Información general

Durante la última década, la federación de identidades ha desempeñado un papel fundamental a la hora de aumentar el nivel de la autenticación en la Web en términos de confiabilidad, facilidad de uso (por ejemplo, acceso único sin contraseña) y seguridad (por ejemplo, mayor resistencia a los ataques de phishing y de uso excesivo de credenciales) en comparación con los nombres de usuario y las contraseñas por sitio.

Lamentablemente, se están utilizando de forma activa los mecanismos en los que se basa la federación de identidades (iframes, redireccionamientos y cookies) para hacer un seguimiento de los usuarios en la Web. Como el usuario-agente no puede diferenciar entre la federación de identidades y el seguimiento, las mitigaciones para los distintos tipos de abuso dificultan la implementación de la federación de identidades.

FedCM es un recorrido de varios pasos para mejorar la identidad en la Web, y en su primer paso nos enfocamos en reducir el impacto de la eliminación gradual de cookies de terceros en la identidad federada (consulta a continuación qué sigue).

Un usuario accede a un RP mediante FedCM

Chrome experimenta con FedCM desde Chrome 101.

El equipo de Servicios de identidad de Google participó en la prueba de origen y demostró que cambiar a un proceso de acceso más privado y seguro que no depende de cookies de terceros puede ocurrir con transparencia mediante actualizaciones retrocompatibles de su biblioteca existente. Habilitaron FedCM en 20 usuarios de confianza diferentes y más de 300,000 usuarios accedieron a ellos durante las pruebas de origen. Obtén más información sobre cómo planean dejar de depender de las cookies de terceros.

Nos entusiasma encontrar muchos puntos en común con Mozilla, ya que participó activamente en los debates de diseño y comenzaron a crear prototipos de FedCM en Firefox. Apple indicó su compatibilidad general con la especificación y está comenzando a participar en los debates del CG FedID.

Próximos pasos

Estamos trabajando para implementar varios cambios en FedCM.

Sabemos que aún debes realizar algunas acciones, incluidos los problemas que escucharon de los IdP, los RP y los proveedores de navegadores. Creemos que sabemos cómo resolver estos problemas:

  • Compatibilidad con iframes de origen cruzado: Los IdP pueden llamar a FedCM desde un iframe de origen cruzado.
  • Botón personalizado: Los IdP pueden mostrar la identidad de un usuario recurrente en el botón de acceso desde un iframe de origen cruzado.
  • Extremo de métricas: Proporciona métricas de rendimiento a los IdP.

Además, hay problemas sin resolver que exploramos de forma activa, incluidas las propuestas específicas que estamos evaluando o creando prototipos:

Por último, hay cosas que creemos que aún debemos hacer, según los comentarios de Mozilla, Apple y los revisores de TAG. Estamos trabajando para evaluar la mejor solución para estas preguntas abiertas:

  • Mejorar la comprensión del usuario y la intención de búsqueda de coincidencias: Como indica Mozilla, nos gustaría seguir explorando diferentes formulaciones de UX y áreas de superficie, así como criterios de activación.
  • Atributos de identidad y divulgación selectiva: como indicaron nuestros revisores de etiquetas, nos gustaría proporcionar un mecanismo para compartir de manera selectiva más o menos atributos de identidad (como correos electrónicos, edades, números de teléfono, etcétera).
  • Aumento de las propiedades de privacidad: Como sugirió Mozilla aquí, nos gustaría seguir explorando mecanismos para ofrecer mejores garantías de privacidad, como la ceguera del IdP y los identificadores dirigidos.
  • Relación con WebAuthn: Como lo sugiere Apple, nos entusiasma ver el progreso de las llaves de acceso y trabajar para proporcionar una experiencia coherente y cohesiva entre FedCM, las contraseñas, WebAuthn y WebOTP.
  • Estado de acceso: Como sugirió Apple con la API de estado de acceso de Privacy CG, compartimos la intuición de que el estado de acceso del usuario es un dato útil que puede ayudar a los navegadores a tomar decisiones fundamentadas, y nos entusiasma ver qué oportunidades surgen a partir de eso.
  • Empresas y educación: Como se indica en los CG del FedID, aún existen muchos casos de uso que FedCM no entrega bien, en los que nos gustaría trabajar, como el cierre de sesión en el canal frontal (la capacidad de que un IdP envíe una señal a los RP para salir) y la compatibilidad con SAML.
  • Relación con las Licencias de Conducir Digital, las empresas de capital de riesgo y otras entidades: Sigue trabajando para comprender cómo encajan en FedCM, por ejemplo, con la API de Mobile Document Request.

Recursos