Кратко

  • В OpenID Authentication 2.0 адрес, заявленный человеком как свой идентификатор, отделён от внутреннего имени у провайдера. Указатель на провайдера можно было изменить, сохранив адрес.
  • Сайт, принимающий вход, обязан был обнаружить провайдера через заявленный адрес и сверить ответ с результатом обнаружения. От выбора ключа в собственной базе сайта зависело, останется ли это той же учётной записью.

В 2007 году война за кнопку входа уже имела простой экономический смысл: тот, кто держит имя клиента, усложняет ему уход. Окончательная спецификация OpenID Authentication 2.0 предложила иной порядок. Человек предъявлял сайту URL в качестве своего имени. Сайт находил по этому адресу службу, способную подтвердить личность, и отправлял туда браузер. После ответа службы сайт сам решал, какую локальную запись открыть.

Спецификация различала Claimed Identifier — адрес, который пользователь заявлял принимающему сайту, — и OP-Local Identifier, имя его учётной записи внутри службы проверки. Эти строки могли относиться к разным доменам. Внутренним именем у провайдера человек мог не распоряжаться вовсе. Если сайт запоминал именно его как постоянное имя пользователя, переносимость исчезала при первой смене провайдера.

Механизм указателя помещался на странице заявленного адреса. HTML-ссылка rel="openid2.provider" называла конечную точку провайдера; необязательная rel="openid2.local_id" указывала локальное имя клиента у него. Владелец страницы мог поменять адрес провайдера, не меняя URL, который называл другим сайтам. Это была маленькая правка страницы с большим последствием: удостоверять человека теперь могла другая компания.

Но принимать ответ от любой компании было бы опасно. По правилам OpenID сайт должен был обнаружить сведения на заявленном URL и убедиться, что ответ пришёл от найденного провайдера и относится к найденному локальному имени. Если поиск не проводился в начале входа, его требовалось выполнить при получении положительного ответа. Иначе чужой провайдер мог бы выдать себя за уполномоченного представителя чужого адреса. Указатель на странице служил границей полномочий.

Затем начиналась бухгалтерия сайта. Спецификация рекомендовала использовать заявленный адрес как ключ для локальных сведений о человеке. Провайдер мог смениться, его внутренний идентификатор тоже, а URL оставался тем же ключом. Такая конструкция сохраняла историю аккаунта без переговоров с каждым сайтом по отдельности. Если сайт ставил в основу записи внутреннее имя провайдера, он сам строил ловушку, от которой протокол обещал выход.

Совместимость с OpenID 1.1 показывала цену одной потерянной строки. Ответ старой версии не содержал openid.claimed_id. Когда заявленный адрес и локальное имя провайдера различались, сайт должен был сохранить исходный заявленный адрес после обнаружения — например, в сессии. Проверить ответ было недостаточно: сайт ещё должен был знать, к какому именно человеку относилась проверка.

Сообщение OpenID Foundation от 5 декабря 2007 года объявило финальную версию спецификации аутентификации вместе со спецификацией обмена атрибутами. Текст стандарта описывал устройство, а не число успешных переходов между провайдерами. Для истории важна точность замысла: постоянное имя принадлежало держателю URL, проверка учётных данных была услугой, а принимающий сайт оставался хранителем связки между ними.

Первичные документы