Summary

  • Acts-For gives a person a pairwise subject at each site, but the same agent's key identifier, handle and key thumbprint travel across sites.
  • The draft says two sites comparing those agent fields can link their separate person subjects. Its test account reports one human sign-in at one site, not a multi-site agent test.

The human gets a different number at every shop. The agent keeps the same membership card in its wallet.

That is the privacy seam in Acts-For, an individual Internet-Draft updated on 21 October 2026. The proposal lets a person use a ~handle and passkey to sign in without giving every site the same personal identifier. A website publishes a DNS record; the issuer registers it as a client. The person approves a fresh passkey ceremony, and the site receives a subject generated for that site alone.

The draft computes that subject from an issuer-held HMAC secret, the person's internal identifier and the normalized site domain. At two sites, the same person gets two different subjects. A comparison of those subjects alone cannot join the accounts. OpenID Connect calls this a pairwise subject: an identifier scoped to a relying party rather than reused everywhere.

The agent path carries another set of fields. An authorized agent asks the issuer for a short-lived acts-for pass. The pass names the person by the site's pairwise subject, while identifying the agent with acting.kid, its Bot-tier handle and cnf_jkt, a thumbprint of its signing key. The site checks the issuer's signature, its own audience, expiry, and a request signed by the agent's key. The pass expires within five minutes and no later than the grant's stated validity.

The pass checks make the credential harder to replay as a loose bearer token. The agent identifier remains global across sites: the draft's privacy section states that acting.kid, acting.handle and cnf_jkt stay the same wherever that agent signs in. Two sites that compare them can learn that their pairwise person subjects belong to one person. The draft's open issue 10 asks whether agents should present a key and handle per site.

That question sits beside a second concentration point. The issuer holds the HMAC secret and can compute a person's subject at any site; it also sees each sign-in for which it issues a token. Sites cannot join users by the pairwise subject alone. The issuer can calculate the mapping, and cooperating sites can use the travelling agent identity as a join key.

The status record is small. Datatracker lists an individual Internet-Draft with no intended RFC status. Its implementation section reports that one small-business site published a record and one person completed passkey sign-in. It reports no agent sign-in test, no two-site comparison and no observed correlation. The draft establishes the design and names the risk; deployment evidence has not yet arrived.

The distinction matters to operators considering delegated sign-in. “Pairwise subject” describes one field, not the privacy of the entire credential. Review the complete pass: the person's subject, the agent's key and handle, the sites that receive them, the issuer that can derive subjects, and the grant that controls what the agent may do. The draft leaves the grant itself out of scope, so its account of a pass is more complete than its account of the authority that produced it.

Sources