OpenID Authentication 2.0 / OpenID Аутентификация 2.0: 10.1. Positive Assertions

Положительное утверждение - это непрямой ответ со следующими полями:

Reyko32 09.07.12 в 08:23

openid.ns

Reyko32 09.07.12 в 08:28

Как указано в секции 4.1.2.

Reyko32 09.07.12 в 08:29

openid.mode

Reyko32 09.07.12 в 08:29

Значение "id_res"

Reyko32 09.07.12 в 08:30

openid.op_endpoint

Reyko32 09.07.12 в 08:31

Конечный адрес Провайдера(The OP Endpoint URL)

Reyko32 13.07.12 в 03:00

openid.claimed_id

Reyko32 09.07.12 в 08:35

Значение(опционально): Заявленный Идентификатор(Claimed Identifier). "openid.claimed_id" и "openid.identity" СЛЕДУЕТ или обим присутствовать , или обим отсутствовать.

Reyko32 13.07.12 в 02:59

Примечание: Конечный Пользователь(end user) МОЖЕТ сделать выбор использовать OP-Local Identifier как Заявленый Идентификатор(Claimed Identifier)

Reyko32 13.07.12 в 03:03

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

Reyko32 13.07.12 в 03:07

openid.identity

Reyko32 09.07.12 в 08:35

Значение: The OP-Local Identifier

Reyko32 13.07.12 в 03:11

Примечание: Провайдер(OpenID Providers ) МОГУТ помогать Конечным Пользователям(end user) в выборе Заявленного(Claimed) и OP-Local Идентификаторов о которых делается утверждение. Поле openid.identity МОЖЕТ быть опущено если используются расширения, которые делают ответ значимым без него(смотри выще про openid.claimed_id)

Reyko32 13.07.12 в 03:18

openid.return_to

Reyko32 09.07.12 в 08:35

Значение: точная копия параметра return_to URL в запросе

Reyko32 13.07.12 в 03:45

openid.response_nonce

Reyko32 09.07.12 в 08:35

Значение: Строка днлинной 255 символов, или менее, которая ДОЛЖНА быть уникальна для определенного отвта успешной аутентификации. Данное значение ДОЛЖНО начинаться с текущего времени на сервере и МОЖЕТ содержать дополнительные ASCII-символы в диапозоне [33-126 ] (печатные непробельные символы), по мере необходимости делает каждый запрос уникальным. Дата и время ДОЛЖНЫ быть отформатированы как определено в секции 5.6 документа RFC3339, со следующими ограничениями:
Время, которое должно быть во временной зоне UTC, обозначается "Z"
Не допускаются дробные секунды
Для примера: 2005-05-15T17:11:51ZUNIQUE

Reyko32 13.07.12 в 04:59

openid.invalidate_handle

Reyko32 09.07.12 в 08:35

Значение:(опционально). Если Зависимая Сорона(Relying Party) шлет в запросе некоректный обработчик ассоциаций, это должно быть указано здесь

Reyko32 13.07.12 в 05:02

openid.assoc_handle

Reyko32 09.07.12 в 08:35

Значение: Обработчик для ассоциации, которая используется для подписи утверждения

Reyko32 17.07.12 в 04:51

openid.signed

Reyko32 09.07.12 в 08:36

Значение: разделенный запятыми список подписанных полей

Reyko32 17.07.12 в 04:50

Примечание: Эта запись состоит из полей без префикса "openid." который охватывает подпись. Этот список ДОЛЖЕН содержать хотя бы "op_endpoint", "return_to", "response_nonce" и "assoc_handle", также поля "claimed_id" и "identity", если они присутствуют в если в ответе присутствуют.

Reyko32 17.07.12 в 04:58

Пример: "op_endpoint,identity,claimed_id,return_to,assoc_handle,response_nonce".

Reyko32 17.07.12 в 04:58

openid.sig

Reyko32 09.07.12 в 08:36

Подпись закодированная по основанию 64, полученная как указано в секции 6.

Reyko32 17.07.12 в 05:01