Кратко

  • Человек получает отдельный pairwise subject на каждом сайте; идентификатор ключа агента, его handle и отпечаток ключа остаются одинаковыми между сайтами.
  • В проекте сказано, что два сайта могут сравнить эти поля агента и связать отдельные идентификаторы одного человека. Описанный тест охватывает вход человека на одном сайте.

В путь агента встроены другие поля. Уполномоченный агент запрашивает у издателя короткоживущий acts-for pass. В нем человек обозначен subject для этого сайта, а агент — значениями acting.kid, handle уровня Bot и cnf_jkt, отпечатком ключа подписи. Сайт проверяет подпись издателя, аудиторию, срок действия и запрос, подписанный ключом агента. Pass истекает не позднее чем через пять минут после выпуска и не позже срока valid_until, указанного в полномочии.

Эти проверки ограничивают использование pass. Идентификатор агента остается общим для всех сайтов. В разделе о приватности сказано, что acting.kid, acting.handle и cnf_jkt не меняются, когда один и тот же агент входит на разные сайты. Сравнив их, два сайта могут установить, что разные pairwise subject относятся к одному человеку. Открытый вопрос 10 прямо спрашивает, должен ли агент предъявлять отдельные ключ и handle для каждого сайта.

У издателя тоже сосредоточены данные. Он хранит HMAC-секрет и может вычислить subject любого человека для любого сайта; он видит и каждый вход, для которого выпускает токен. Pairwise subject мешает сайтам напрямую связывать пользователей по одному этому полю. Издатель может вычислить соответствие, а сотрудничающие сайты могут использовать общую идентичность агента как ключ сопоставления.

Так выглядит шов приватности в Acts-For — индивидуальном Internet-Draft, обновленном 21 октября 2026 года. Предложение позволяет входить с ~handle и passkey, не передавая каждому сайту один и тот же личный идентификатор. Сайт публикует запись DNS, а издатель регистрирует его как клиента. При каждом входе человек проходит новую проверку passkey и получает subject, рассчитанный для этого сайта.

Проект вычисляет subject по HMAC-секрету издателя, внутреннему идентификатору человека и нормализованному домену сайта. На двух сайтах один человек получает разные значения. Сравнения этих значений недостаточно, чтобы соединить учетные записи. В OpenID Connect такой идентификатор называют pairwise subject: он закреплен за конкретной доверяющей стороной и не повторяется повсюду.

Запись об испытании невелика. Datatracker указывает индивидуальный Internet-Draft без запланированного статуса RFC. В разделе реализации говорится, что один сайт малого бизнеса опубликовал запись, а один человек завершил вход с passkey. В документе не описаны вход агента, сравнение двух сайтов или наблюдавшаяся корреляция. Проект фиксирует механизм и его риск; данных о распространении нет.

В каждом магазине у человека новый номер. У агента — одна и та же карта лояльности.

Операторам, оценивающим делегированный вход, следует рассматривать «pairwise subject» как одно поле, а не как гарантию приватности всего удостоверения. Нужно отдельно проверить поля pass, сайты-получатели, издателя, способного пересчитать subject, и полномочие, ограничивающее агента. Само полномочие оставлено за рамками проекта; описание pass подробнее описания власти, на которой он основан.

Источники