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. Reyko32 20.09.12 в 04:18 0
	Когда происходит получение информации, основанное на XRDS, локальной идентификатор(OP-Local Identifier) конечного пользователя отражается в теге элемента OpenID чаще чем в теге. В порядке поддержки уже выпущенного кода получения информации(discovery code), оба тега МОГУТ содержаться в элементе. Reyko32 20.09.12 в 04:25 0
	Зависимым сторонам СЛЕДУЕТ извлекать и использовать OpenID Authentication 1.x элементы сервиса из XRDS документов, если Yadis успешно на URL идентификаторе. Такие элементы сервиса определяются тегами текст которых содержит http://openid.net/server/1.0 или http://openid.net/server/1.1. К тому же это не определено предыдущей версией протокола, это общепринятая практика рекламы сервисо OpenID Authentication 1.x по средствам Yadis. Reyko32 20.09.12 в 04:33 0
	"openid.claimed_id" не определен спецификацией by OpenID Authentication 1.1. Зависимая сторона МОЖЕТ выслать значение во время запроса, но НЕ ЖОЛЖНА зависеть от значения высланного в ответе. Когда локальный идентификатор ("openid.identity") отличается от заявленного идентификатора (Claimed Identifier), зависимая сторона ДОЛЖНА хратить записи того какой заявленный идентификатор был использован для получения информации о локальном идентификаторе (OP-Local Identifier), например хранить это в состоянии сессии. Даже если заявленный идентификатор не будет присутствовать в ответе, он ДОЛЖЕН быть использован как идентификатор пользователя. Reyko32 20.09.12 в 04:42 0
	"openid.identity" ДОЛЖНА быть выслана в запросе идентификации Reyko32 20.09.12 в 04:47 0
	Зависимые Стороны ДОЛЖНЫ отсылать пустой параметр session_type в запросе с ассоциацией "no-encryption" Reyko32 20.09.12 в 04:48 0
	В OpenID Authentication 1.1, тип ассоциации "no-encryption" представленный пустым или отсутствием параметра "openid.session_type". Зависимая сторона НЕ ДОЛЖНА посылать запрос со значением "no-encryption" в "openid.session_type" Reyko32 20.09.12 в 04:52 0
	В запросах идентификации, параметру "openid.identity" НЕ СЛЕДУЕТ присваивать специальное значение "http://specs.openid.net/auth/2.0/identifier_select", потому что OpenID Authentication 1.1 не поддерживает использования OP Identifiers Reyko32 20.09.12 в 04:55 0
	Параметр "openid.realm" в запросе идентификации должен пониматься как "openid.trust_root". Синтаксис и смысл идентичны. Reyko32 20.09.12 в 04:57 0
	Когда отвечают отрицательным утверждением на запрос идентификации в режиме "checkid_immediate", ДОЛЖЕН БЫТЬ возвращен параметр "user_setup_url". Это url, который может посетить конечный пользователь для завершения запроса. Провайдер МОЖЕТ перенаправить конечного пользователя на этот URL, или обеспечить конечного пользователя ссылкой на этот URL. Reyko32 20.09.12 в 05:00 0
	Зависимая Сторона ДОЛЖНА принимать ответ идентификации, в котором не указан параметр "openid.response_nonce". Зависимой Сторона СЛЕДУЕТ использовать метод для предотвращения повторный атак. Reyko32 20.09.12 в 05:03 0
	Зависима Сторона ДОЛЖНА принимать ответы идентификации, в которых отсутствует параметр "openid.op_endpoint" . Reyko32 20.09.12 в 05:04 0