Готовый перевод OpenID Authentication 2.0 / OpenID Аутентификация 2.0: 14.2.1. Relying Parties

Когда происходит извлечение данных из HTML, конечный URL провайдера отмечен в атрибуте rel тега link значением "openid.server" чаще чем "openid2.provider". Локальный(OP-Local) идентификатор конечного пользователя отмечен в атрибуте rel тега link со значением "openid.delegate" чаще значением "openid2.local_id". Версия протокола в этом случае http://openid.net/signon/1.1. HTML позволяет несколько объявлений тегов link для одной связи, так если Провайдер поддерживает обе спецификации OpenID Authentication 1.1 и OpenID Authentication 2.0, "openid2.provider" и "openid.server" могут содержать одинаковое атрибуты rel.

Когда происходит получение информации, основанное на XRDS, локальной идентификатор(OP-Local Identifier) конечного пользователя отражается в теге элемента OpenID чаще чем в теге. В порядке поддержки уже выпущенного кода получения информации(discovery code), оба тега МОГУТ содержаться в элементе.

Зависимым сторонам СЛЕДУЕТ извлекать и использовать OpenID Authentication 1.x элементы сервиса из XRDS документов, если Yadis успешно на URL идентификаторе. Такие элементы сервиса определяются тегами текст которых содержит http://openid.net/server/1.0 или http://openid.net/server/1.1. К тому же это не определено предыдущей версией протокола, это общепринятая практика рекламы сервисо OpenID Authentication 1.x по средствам Yadis.

"openid.claimed_id" не определен спецификацией by OpenID Authentication 1.1. Зависимая сторона МОЖЕТ выслать значение во время запроса, но НЕ ЖОЛЖНА зависеть от значения высланного в ответе. Когда локальный идентификатор ("openid.identity") отличается от заявленного идентификатора (Claimed Identifier), зависимая сторона ДОЛЖНА хратить записи того какой заявленный идентификатор был использован для получения информации о локальном идентификаторе (OP-Local Identifier), например хранить это в состоянии сессии. Даже если заявленный идентификатор не будет присутствовать в ответе, он ДОЛЖЕН быть использован как идентификатор пользователя.

"openid.identity" ДОЛЖНА быть выслана в запросе идентификации

Зависимые Стороны ДОЛЖНЫ отсылать пустой параметр session_type в запросе с ассоциацией "no-encryption"

В OpenID Authentication 1.1, тип ассоциации "no-encryption" представленный пустым или отсутствием параметра "openid.session_type". Зависимая сторона НЕ ДОЛЖНА посылать запрос со значением "no-encryption" в "openid.session_type"

В запросах идентификации, параметру "openid.identity" НЕ СЛЕДУЕТ присваивать специальное значение "http://specs.openid.net/auth/2.0/identifier_select", потому что OpenID Authentication 1.1 не поддерживает использования OP Identifiers

Параметр "openid.realm" в запросе идентификации должен пониматься как "openid.trust_root". Синтаксис и смысл идентичны.

Когда отвечают отрицательным утверждением на запрос идентификации в режиме "checkid_immediate", ДОЛЖЕН БЫТЬ возвращен параметр "user_setup_url". Это url, который может посетить конечный пользователь для завершения запроса. Провайдер МОЖЕТ перенаправить конечного пользователя на этот URL, или обеспечить конечного пользователя ссылкой на этот URL.

Зависимая Сторона ДОЛЖНА принимать ответ идентификации, в котором не указан параметр "openid.response_nonce". Зависимой Сторона СЛЕДУЕТ использовать метод для предотвращения повторный атак.

Зависима Сторона ДОЛЖНА принимать ответы идентификации, в которых отсутствует параметр "openid.op_endpoint" .

Переведено на Нотабеноиде
http://notabenoid.org/book/23365/104323

Переводчики: Reyko32