Resumen

  • La persona recibe un sujeto pairwise distinto en cada sitio; el agente conserva el mismo identificador de clave, handle y huella de clave.
  • El borrador dice que dos sitios pueden comparar esos campos y volver a unir las identidades de una persona. Su prueba registrada cubrió un inicio de sesión humano en un solo sitio.

En cada tienda, la persona usa un número distinto. El agente lleva la misma tarjeta de socio.

El recorrido del agente lleva otros campos. Un agente autorizado pide al emisor un acts-for pass de corta duración. El pass nombra a la persona mediante el sujeto específico del sitio e identifica al agente con acting.kid, su handle de nivel Bot y cnf_jkt, la huella de su clave de firma. El sitio comprueba la firma del emisor, la audiencia, el vencimiento y una solicitud firmada por la clave del agente. El pass vence como máximo cinco minutos después de emitirse y antes del fin de vigencia indicado en la autorización.

Esos controles limitan la reutilización del pass; la identidad del agente sigue siendo común entre sitios. La sección de privacidad dice que acting.kid, acting.handle y cnf_jkt permanecen iguales allí donde inicie sesión el mismo agente. Si dos sitios comparan esos campos, pueden asociar sus sujetos pairwise con una sola persona. La cuestión abierta 10 del borrador pregunta si cada sitio debería recibir una clave y un handle propios del agente.

Esa es la costura de privacidad de Acts-For, un Internet-Draft individual actualizado el 21 de octubre de 2026. La propuesta permite iniciar sesión con un ~handle y una passkey sin entregar a cada sitio el mismo identificador personal. El sitio publica un registro DNS; el emisor lo registra como cliente. La persona confirma una nueva autenticación con passkey y el sitio recibe un sujeto calculado para ese dominio.

El borrador deriva el sujeto de un HMAC que conserva el emisor, el identificador interno de la persona y el dominio normalizado del sitio. La misma persona obtiene sujetos distintos en dos sitios. Comparar solo esos sujetos no permite reunir las cuentas. OpenID Connect llama pairwise a este tipo de identificador: queda asociado a una parte confiante en vez de repetirse en todas partes.

El emisor forma otro punto de concentración. Conserva el secreto HMAC y puede calcular el sujeto de cualquier persona para cualquier sitio; también ve cada inicio de sesión para el que emite un token. El sujeto pairwise evita la unión directa por ese campo. El emisor puede calcular la correspondencia, y los sitios que cooperen pueden usar la identidad compartida del agente como llave común.

El registro de estado es acotado. Datatracker identifica el texto como un Internet-Draft individual, sin estado RFC previsto. El apartado de implementación relata que un sitio de una pequeña empresa publicó su registro y que una persona completó el inicio con passkey. No registra un inicio de sesión de agente, una comparación entre sitios ni una correlación observada. El borrador define el mecanismo y señala el riesgo; no publica su frecuencia de adopción.

Para un operador que valore el inicio delegado, «sujeto pairwise» describe un campo, no toda la identidad del justificante. Conviene revisar todos los campos del pass, los sitios que los reciben, el emisor capaz de calcular los sujetos y la autorización que limita al agente. El propio borrador deja esa autorización fuera de alcance; describe el pass con más detalle que la autoridad que lo originó.

Fuentes