Internet Engineering Task Force (IETF) E. Lear
Request for Comments: 6616 Cisco Systems GmbH
Category: Standards Track H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
H. Mauldin
Cisco Systems, Inc.
S. Josefsson
SJD AB
May 2012
Internet Engineering Task Force (IETF) E. Lear
Request for Comments: 6616 Cisco Systems GmbH
Category: Standards Track H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
H. Mauldin
Cisco Systems, Inc.
S. Josefsson
SJD AB
May 2012
A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID
OpenID的简单身份验证和安全层（SASL）和通用安全服务应用程序接口（GSS-API）机制
Abstract
摘要
OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API.
OpenID已经在Internet上找到了用于Web单点登录的方法。简单身份验证和安全层（SASL）和通用安全服务应用程序接口（GSS-API）是通用身份验证的应用程序框架。此备忘录为OpenID指定了SASL和GSS-API机制，允许将现有OpenID身份提供程序与使用SASL和GSS-API的应用程序集成。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6616.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6616.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. Applicability for Application Protocols other than HTTP . . . 4
2.1. Binding SASL to OpenID in the Relying Party . . . . . . . 7
2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8
3. OpenID SASL Mechanism Specification . . . . . . . . . . . . . 8
3.1. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Authentication Request . . . . . . . . . . . . . . . . . . 9
3.3. Server Response . . . . . . . . . . . . . . . . . . . . . 10
3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 11
4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 11
4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 12
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6.1. Binding OpenIDs to Authorization Identities . . . . . . . 14
6.2. RP Redirected by Malicious URL to Take an Improper
Action . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. Applicability for Application Protocols other than HTTP . . . 4
2.1. Binding SASL to OpenID in the Relying Party . . . . . . . 7
2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8
3. OpenID SASL Mechanism Specification . . . . . . . . . . . . . 8
3.1. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Authentication Request . . . . . . . . . . . . . . . . . . 9
3.3. Server Response . . . . . . . . . . . . . . . . . . . . . 10
3.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 11
4. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . 11
4.1. GSS-API Principal Name Types for OpenID . . . . . . . . . 12
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6.1. Binding OpenIDs to Authorization Identities . . . . . . . 14
6.2. RP Redirected by Malicious URL to Take an Improper
Action . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
OpenID 2.0 [OpenID] is a web-based three-party protocol that provides a means for a user to offer identity assertions and other attributes to a web server (Relying Party) via the help of an identity provider. The purpose of this system is to provide a way to verify that an end user controls an identifier.
OpenID2.0[OpenID]是一种基于web的三方协议，它为用户提供了一种手段，通过身份提供者的帮助向web服务器（依赖方）提供身份声明和其他属性。该系统的目的是提供一种验证最终用户是否控制标识符的方法。
Simple Authentication and Security Layer (SASL) [RFC4422] is used by application protocols such as IMAP [RFC3501], Post Office Protocol (POP) [RFC1939], and Extensible Messaging and Presence Protocol (XMPP) [RFC6120], with the goal of modularizing authentication and security layers, so that newer mechanisms can be added as needed. This memo specifies just such a mechanism.
简单身份验证和安全层（SASL）[RFC4422]由应用程序协议使用，如IMAP[RFC3501]、邮局协议（POP）[RFC1939]和可扩展消息和状态协议（XMPP）[RFC6120]，其目标是模块化身份验证和安全层，以便可以根据需要添加更新的机制。这份备忘录明确规定了这样一种机制。
The Generic Security Service Application Program Interface (GSS-API) [RFC2743] provides a framework for applications to support multiple authentication mechanisms through a unified interface. This document defines a pure SASL mechanism for OpenID, but it conforms to the new bridge between SASL and the GSS-API called GS2 [RFC5801]. This means that this document defines both a SASL mechanism and a GSS-API mechanism. Implementors of the SASL component MAY implement the GSS-API interface as well.
通用安全服务应用程序接口（GSS-API）[RFC2743]为通过统一接口支持多种身份验证机制的应用程序提供了一个框架。本文档为OpenID定义了一个纯粹的SASL机制，但它符合SASL和GSS-API（称为GS2[RFC5801]）之间的新桥梁。这意味着本文档定义了SASL机制和GSS-API机制。SASL组件的实现者也可以实现GSS-API接口。
This mechanism specifies interworking between SASL and OpenID in order to assert identity and other attributes to Relying Parties. As such, while SASL servers (as Relying Parties) will advertise SASL mechanisms, clients will select the OpenID mechanism.
该机制指定SASL和OpenID之间的交互，以便向依赖方声明身份和其他属性。因此，虽然SASL服务器（作为依赖方）将公布SASL机制，但客户端将选择OpenID机制。
The OpenID mechanism described in this memo aims to reuse the OpenID mechanism to the maximum extent and therefore does not establish a separate authentication, integrity, and confidentiality mechanism. It is anticipated that existing security layers, such as Transport Layer Security (TLS) [RFC5246], continue to be used. Minimal changes are required to non-web applications, as most of the transaction occurs through a normal web browser. Hence, this specification is only appropriate for use when such a browser is available.
本备忘录中描述的OpenID机制旨在最大限度地重用OpenID机制，因此不会建立单独的身份验证、完整性和机密性机制。预计将继续使用现有的安全层，如传输层安全（TLS）[RFC5246]。对于非web应用程序，需要进行最小的更改，因为大多数事务都是通过普通的web浏览器进行的。因此，本规范仅适用于此类浏览器可用的情况。
Figure 1 describes the interworking between OpenID and SASL. This document requires enhancements to the Relying Party and to the Client (as the two SASL communication end points), but no changes to the OpenID Provider (OP) are necessary. To accomplish this goal, indirect messaging required by the OpenID specification is tunneled through the SASL/GSS-API mechanism.
图1描述了OpenID和SASL之间的互通。本文档要求增强依赖方和客户端（作为两个SASL通信端点），但不需要更改OpenID提供程序（OP）。为了实现这一目标，OpenID规范所需的间接消息传递通过SASL/GSS-API机制进行隧道传输。
+-----------+
| Relying |
>| Party / |
/ | SASL |
// | Server |
// +-----------+
// ^
OpenID // +--|--+
// | O| | G
/ S | p| | S
// A | e| | S
// S | n| | A
// L | I| | P
// | D| | I
</ +--|--+
+------------+ v
| | +----------+
| OpenID | OpenID | |
| Provider |<--------------->| Client |
| | | |
+------------+ +----------+
+-----------+
| Relying |
>| Party / |
/ | SASL |
// | Server |
// +-----------+
// ^
OpenID // +--|--+
// | O| | G
/ S | p| | S
// A | e| | S
// S | n| | A
// L | I| | P
// | D| | I
</ +--|--+
+------------+ v
| | +----------+
| OpenID | OpenID | |
| Provider |<--------------->| Client |
| | | |
+------------+ +----------+
Figure 1: Interworking Architecture
图1：互通架构
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The reader is assumed to be familiar with the terms used in the OpenID 2.0 specification.
假定读者熟悉OpenID2.0规范中使用的术语。
Because this mechanism transports information that should not be controlled by an attacker, the OpenID mechanism MUST only be used over channels protected by TLS, and the client MUST successfully validate the server certificate [RFC5280][RFC6125].
由于此机制传输不应由攻击者控制的信息，因此OpenID机制只能在TLS保护的通道上使用，并且客户端必须成功验证服务器证书[RFC5280][RFC6125]。
OpenID was originally envisioned for HTTP- [RFC2616] and HTML-based [W3C.REC-html401-19991224] communications, and with the associated semantic; the idea being that the user would be redirected by the Relying Party (RP) to an identity provider (IdP) who authenticates the user and then sends identity information and other attributes (either directly or indirectly) to the Relying Party. The identity
OpenID最初设想用于HTTP-[RFC2616]和基于HTML的[W3C.REC-html401-19991224]通信，并具有相关的语义；其思想是，依赖方（RP）将用户重定向到身份提供者（IdP），后者认证用户，然后（直接或间接）向依赖方发送身份信息和其他属性。身份
provider in the OpenID specifications is referred to as an OpenID Provider (OP). The actual protocol flow can be found in Section 3 of the OpenID 2.0 specification [OpenID]. The reader is strongly encouraged to be familiar with that specification before continuing.
OpenID规范中的提供者称为OpenID提供者（OP）。实际的协议流可以在OpenID2.0规范[OpenID]的第3节中找到。强烈建议读者在继续之前熟悉该规范。
When considering that flow in the context of SASL, we note that while the RP and the client both need to change their code to implement this SASL mechanism, it is a design constraint that the OP behavior remain untouched, in order for implementations to interoperate with existing IdPs. Hence, an analog flow that interfaces the three parties needs to be created. In the analog, we note that unlike a web server, the SASL server already has some sort of session (probably a TCP connection) established with the client. However, it may be necessary for a SASL client to invoke to another application. This will be discussed below. By doing so, we externalize much of the authentication from SASL.
在SASL上下文中考虑该流时，我们注意到，虽然RP和客户机都需要更改其代码以实现该SASL机制，但设计约束是操作行为保持不变，以便实现与现有IDP的互操作。因此，需要创建连接三方的模拟流。在模拟中，我们注意到与web服务器不同，SASL服务器已经与客户端建立了某种会话（可能是TCP连接）。但是，SASL客户端可能需要调用另一个应用程序。这将在下文讨论。通过这样做，我们将SASL的大部分身份验证外部化。
The steps are listed below:
步骤如下所示：
1. The SASL server advertises support for the SASL OpenID mechanism to the client.
1. SASL服务器向客户端公布对SASL OpenID机制的支持。
2. The client initiates a SASL authentication and transmits the User-Supplied Identifier as its first response. The SASL mechanism is client-first, and, as explained in [RFC4422], the server will send an empty challenge if needed.
2. 客户端启动SASL身份验证，并将用户提供的标识符作为其第一个响应进行传输。SASL机制是客户机优先，如[RFC4422]中所述，如果需要，服务器将发送一个空质询。
3. After normalizing the User-Supplied Identifier as discussed in [OpenID], the Relying Party performs discovery on it and establishes the OP Endpoint URL that the end user uses for authentication.
3. 按照[OpenID]中的讨论规范化用户提供的标识符后，依赖方对其执行发现，并建立最终用户用于身份验证的OP端点URL。
4. The Relying Party and the OP optionally establish an association -- a shared secret established using Diffie-Hellman Key Exchange. The OP uses an association to validate those messages through the use of a Hashed Message Authentication Code (HMAC); this removes the need for subsequent direct requests to verify the signature after each authentication request/response.
4. 依赖方和OP可以选择建立一个关联——一个使用Diffie-Hellman密钥交换建立的共享秘密。OP使用关联通过使用散列消息认证码（HMAC）来验证这些消息；这样就不需要在每次身份验证请求/响应之后，后续直接请求来验证签名。
5. The Relying Party transmits an authentication request to the OP to obtain an assertion in the form of an indirect request. These messages are passed through the client rather than directly between the RP and the OP. OpenID defines two methods for indirect communication -- namely, HTTP redirects and HTML form submission. Neither mechanism is directly applicable for usage with SASL. To ensure that an OP that is OpenID 2.0 capable can be used, a new method is defined in this document that requires the OpenID message content to be encoded using a
5. 依赖方向OP发送认证请求，以获得间接请求形式的断言。这些消息通过客户端传递，而不是直接在RP和OP之间传递。OpenID定义了两种间接通信方法——即HTTP重定向和HTML表单提交。这两种机制都不直接适用于SASL。为了确保能够使用支持OpenID2.0的OP，本文定义了一种新方法，该方法要求使用
Universal Resource Identifier (URI) [RFC3986]. Note that any Internationalized Resource Identifiers (IRIs) must be normalized to URIs by the SASL client, as specified in [RFC3987], prior to transmitting them to the SASL server.
通用资源标识符（URI）[RFC3986]。请注意，在将国际化资源标识符（IRI）传输到SASL服务器之前，SASL客户端必须按照[RFC3987]中的规定将其规范化为URI。
6. The SASL client now sends a response consisting of "=" to the server, to indicate that authentication continues via the normal OpenID flow.
6. SASL客户端现在向服务器发送一个由“=”组成的响应，以指示身份验证通过正常的OpenID流继续进行。
7. At this point, the client application MUST construct a URL containing the content received in the previous message from the RP. This URL is transmitted to the OP by either the SASL client application or an appropriate handler, such as a browser.
7. 此时，客户端应用程序必须构造一个URL，其中包含从RP收到的上一条消息中的内容。此URL由SASL客户端应用程序或适当的处理程序（如浏览器）传输到OP。
8. Next, the end user optionally authenticates to the OP and then, depending on the OP, may approve or disapprove authentication to the Relying Party. For reasons of its own, the OP has the option of not authenticating a request. The manner in which the end user is authenticated to their respective OP and any policies surrounding such authentication are out of scope of OpenID and, hence, also out of scope for this specification. This step happens out of band from SASL.
8. 接下来，最终用户可选地对OP进行认证，然后根据OP，可以批准或不批准对依赖方的认证。出于自身原因，OP可以选择不验证请求。最终用户向其各自的OP进行身份验证的方式以及围绕此类身份验证的任何策略不在OpenID的范围内，因此也不在本规范的范围内。此步骤发生在SASL的带外。
9. The OP will convey information about the success or failure of the authentication phase back to the RP, again using an indirect response via the client browser or handler. The client transmits to the RP (over HTTP/TLS) the redirect of the OP result. This step happens out of band from SASL.
9. OP将再次通过客户端浏览器或处理程序使用间接响应，将认证阶段成功或失败的信息传递回RP。客户端向RP（通过HTTP/TLS）传输OP结果的重定向。此步骤发生在SASL的带外。
10. The RP MAY send an OpenID check_authentication request directly to the OP, if no association has been established, and the OP should respond. Again, this step happens out of band from SASL.
10. 如果未建立任何关联，RP可直接向OP发送OpenID check_认证请求，OP应作出响应。同样，这一步发生在SASL的带外。
11. The SASL server sends an appropriate SASL response to the client, with optional Open Simple Registry (SREG) attributes.
11. SASL服务器向客户端发送一个适当的SASL响应，该响应具有可选的开放简单注册表（SREG）属性。
SASL Serv. RP/Client OP
|>-----(1)----->| | Advertisement
| | |
|<-----(2)-----<| | Initiation
| | |
|> - - (3) - - - - - - - - - ->| Discovery
| |
|>- - -(4)- - - - - - - - - - >| Association
|<- - -(4)- - - - - - - - - - <|
| | |
|>-----(5)----->| | Indirect Auth Request
| | |
|<-----(6)-----<| | Client "=" Response
| | |
| |>- - (7)- - ->| Client GET to the OP (ext.)
| | |
| |<- - (8)- - ->| Client / OP Auth. (ext.)
| | |
|<- - -(9)- - - + - - - - - - <| HTTPS Indirect id_res
| | |
|<- - -(10)- - - - - - - - - ->| Optional
| | | check_authentication
| | |
|>-----(11)---->| | SASL completion with status
SASL Serv. RP/Client OP
|>-----(1)----->| | Advertisement
| | |
|<-----(2)-----<| | Initiation
| | |
|> - - (3) - - - - - - - - - ->| Discovery
| |
|>- - -(4)- - - - - - - - - - >| Association
|<- - -(4)- - - - - - - - - - <|
| | |
|>-----(5)----->| | Indirect Auth Request
| | |
|<-----(6)-----<| | Client "=" Response
| | |
| |>- - (7)- - ->| Client GET to the OP (ext.)
| | |
| |<- - (8)- - ->| Client / OP Auth. (ext.)
| | |
|<- - -(9)- - - + - - - - - - <| HTTPS Indirect id_res
| | |
|<- - -(10)- - - - - - - - - ->| Optional
| | | check_authentication
| | |
|>-----(11)---->| | SASL completion with status
----- = SASL
- - - = HTTPS
----- = SASL
- - - = HTTPS
Note the directionality in SASL is such that the client MUST send the "=" response. Specifically, the SASL client processes the redirect and then awaits a final SASL decision, while the rest of the OpenID authentication process continues.
注意SASL中的方向性使得客户端必须发送“=”响应。具体地说，SASL客户端处理重定向，然后等待SASL的最终决定，而OpenID身份验证过程的其余部分继续进行。
OpenID is meant to be used in serial within the web, where browser cookies are easily accessible. As such, there are no transaction IDs within the protocol. To ensure that a specific request is bound, and in particular to ease inter-process communication, the Relying Party MUST encode a nonce or transaction ID in the URIs it transmits through the client for success or failure, as either a base URI or fragment component to the "return_to" URI. This value is to be used to uniquely identify each authentication transaction. The nonce value MUST be at least 2^32 bits and large enough to handle well in excess of the number of concurrent transactions a SASL server shall see.
OpenID是为了在web中串行使用，在web中浏览器cookie很容易访问。因此，协议中没有事务ID。为了确保绑定特定请求，特别是为了简化进程间通信，依赖方必须在其通过客户端传输的URI中编码一个nonce或事务ID，作为“return_To”URI的基本URI或片段组件。此值用于唯一标识每个身份验证事务。nonce值必须至少为2^32位，并且足够大，以处理远远超过SASL服务器应看到的并发事务数。
As mentioned above, OpenID is primarily designed to interact with web-based applications. Portions of the authentication stream are only defined in the crudest sense. That is, when one is prompted to approve or disapprove an authentication, anything that one might find on a browser is allowed, including JavaScript, complex style-sheets, etc. Because of this lack of structure, implementations will need to invoke a rich browser in order to ensure that the authentication can be completed.
如上所述，OpenID主要设计用于与基于web的应用程序交互。认证流的部分仅在最粗糙的意义上定义。也就是说，当提示用户批准或不批准身份验证时，允许用户在浏览器上找到任何内容，包括JavaScript、复杂样式表等。由于缺乏结构，实现需要调用富浏览器以确保身份验证能够完成。
Once there is an outcome, the SASL server needs to know about it. The astute reader will hopefully by now have noticed an "=" client SASL response. This is not to say that nothing is happening, but rather that authentication flow has shifted from SASL and the client application to OpenID within the browser, and it will return to the client application when the server has an outcome to hand to the client. The alternative to this flow would be some sort of signal from the HTML browser to the SASL client of the results that would in turn be passed to the SASL server. The inter-process communication issue this raises is substantial. Better, we conclude, to externalize the authentication to the browser and have an "=" client response.
一旦有了结果，SASL服务器就需要了解它。机敏的读者希望现在已经注意到“=”客户端SASL响应。这并不是说什么都没有发生，而是说验证流已经从SASL和客户端应用程序转移到浏览器中的OpenID，当服务器将结果交给客户端时，它将返回到客户端应用程序。这个流程的另一种选择是从HTML浏览器向SASL客户端发送某种信号，将结果传递给SASL服务器。这引起的进程间通信问题是实质性的。我们得出结论，更好的做法是将身份验证外部化到浏览器，并有一个“=”客户端响应。
This section specifies the details of the OpenID SASL mechanism. Recall Section 5 of [RFC4422] for what needs to be described here.
本节指定OpenID SASL机制的详细信息。回顾[RFC4422]第5节，了解此处需要描述的内容。
The name of this mechanism is "OPENID20". The mechanism is capable of transferring an authorization identity (via "gs2-header"). The mechanism does not offer a security layer.
该机制的名称为“OPENID20”。该机制能够传输授权标识（通过“gs2头”）。该机制不提供安全层。
The mechanism is client-first. The first mechanism message is from the client to the server, and it is the "initial-response" described below. As described in [RFC4422], if the application protocol does not support sending a client-response together with the authentication request, the server will send an empty server-challenge to let the client begin.
机制是客户机优先。第一条机制消息是从客户端到服务器的，它是下面描述的“初始响应”。如[RFC4422]中所述，如果应用程序协议不支持将客户端响应与身份验证请求一起发送，则服务器将发送一个空的服务器质询以让客户端开始。
The second mechanism message is from the server to the client, and it is the "authentication_request" described below.
第二个机制消息是从服务器到客户端，它是下面描述的“身份验证请求”。
The third mechanism message is from client to the server, and it is the fixed message consisting of "=".
第三个机制消息是从客户端到服务器的，它是由“=”组成的固定消息。
The fourth mechanism message is from the server to the client, described below as "outcome_data" (with SREG attributes), sent as additional data when indicating a successful outcome.
第四条机制消息是从服务器发送到客户机的，如下所述为“output_data”（带有SREG属性），在指示成功结果时作为附加数据发送。
A client initiates an OpenID authentication with SASL by sending the GS2 header followed by the URI, as specified in the OpenID specification.
按照OpenID规范中的规定，客户机通过发送GS2头，后跟URI来启动SASL的OpenID身份验证。
The ABNF [RFC5234] syntax is as follows:
ABNF[RFC5234]语法如下：
initial-response = gs2-header Auth-Identifier Auth-Identifier = Identifier ; authentication identifier Identifier = URI ; Identifier is specified in ; Sec. 7.2 of the OpenID 2.0 spec.
初始响应=gs2标头身份验证标识符身份验证标识符=标识符；身份验证标识符=URI；标识符在中指定；秒。OpenID2.0规范的7.2。
The syntax and semantics of the "gs2-header" are specified in [RFC5801], and we use it here with the following limitations: The "gs2-nonstd-flag" MUST NOT be present. The "gs2-cb-flag" MUST be "n" because channel binding is not supported by this mechanism.
[RFC5801]中指定了“gs2头”的语法和语义，我们在这里使用它时有以下限制：“gs2 NONSD标志”不能存在。“gs2 cb标志”必须为“n”，因为此机制不支持通道绑定。
URI is specified in [RFC3986]. Extensible Resource Identifiers (XRIs) [XRI2.0] MUST NOT be used.
URI在[RFC3986]中指定。不能使用可扩展资源标识符（XRI）[XRI2.0]。
The SASL server sends the URL resulting from the OpenID authentication request, containing an "openid.mode" of either "checkid_immediate" or "checkid_setup", as specified in Section 9.1 of the OpenID 2.0 specification [OpenID].
SASL服务器发送OpenID身份验证请求产生的URL，其中包含“checkid_immediate”或“checkid_setup”的“OpenID.mode”，如OpenID 2.0规范[OpenID]第9.1节所述。
authentication-request = URI
authentication-request = URI
As part of this request, the SASL server MUST append a unique transaction ID to the "return_to" portion of the request. The form of this transaction is left to the RP to decide, but it SHOULD be large enough to be resistant to being guessed or attacked.
作为该请求的一部分，SASL服务器必须在请求的“return_to”部分追加一个唯一的事务ID。此事务的形式由RP决定，但它应该足够大，以防被猜测或攻击。
The client now sends that request via an HTTP GET to the OP, as if redirected to do so from an HTTP server.
客户端现在通过HTTP GET将该请求发送到OP，就像从HTTP服务器重定向到OP一样。
The client MUST handle both user authentication to the OP and confirmation or rejection of the authentication by the RP via this SASL mechanism.
客户端必须通过此SASL机制处理OP的用户身份验证和RP对身份验证的确认或拒绝。
After all authentication has been completed by the OP, and after the response has been sent to the client, the client will relay the response to the Relying Party via HTTP/TLS, as specified previously in the transaction ("return_to").
OP完成所有身份验证后，并将响应发送给客户端后，客户端将通过HTTP/TLS将响应转发给依赖方，如事务中前面所述（“返回”）。
The Relying Party now validates the response it received from the client via HTTP/TLS, as specified in the OpenID specification, using the "return_to" URI given previously in the transaction.
依赖方现在使用前面在事务中给出的“return_to”URI验证它通过HTTP/TLS从客户端收到的响应，如OpenID规范中所指定的。
The response by the Relying Party constitutes a SASL mechanism outcome, and it SHALL be used to set state in the server accordingly. Also, it SHALL be used by the server to report that state to the SASL client as described in Section 3.6 of [RFC4422]. In the additional data, the server MAY include OpenID Simple Registry (SREG) attributes that are listed in Section 4 of [SREG1.0]. SREG attributes are encoded as follows:
依赖方的响应构成SASL机制的结果，应使用该响应在服务器中相应地设置状态。此外，服务器应使用它向SASL客户端报告该状态，如[RFC4422]第3.6节所述。在附加数据中，服务器可能包括[SREG1.0]第4节中列出的OpenID简单注册表（SREG）属性。SREG属性编码如下：
1. Strip "openid.sreg." from each attribute name.
1. 从每个属性名称中去掉“openid.sreg.”。
2. Treat the concatenation of results as URI parameters that are separated by an ampersand (&) and encode as one would a URI, absent the scheme, authority, and the question mark.
2. 将结果的串联视为URI参数，这些参数由一个符号（&）分隔，并按照URI编码，没有方案、权限和问号。
For example: email=lear@example.com&fullname=Eliot%20Lear
For example: email=lear@example.com&fullname=Eliot%20Lear
More formally:
更正式地说：
outcome-data = [ sreg-avp *( "," sreg-avp ) ]
sreg-avp = sreg-attr "=" sreg-val
sreg-attr = sreg-word
sreg-val = sreg-word
sreg-word = 1*( unreserved / pct-encoded )
; pct-encoded from Section 2.1 of RFC 3986
; unreserved from Section 2.3 of RFC 3986
outcome-data = [ sreg-avp *( "," sreg-avp ) ]
sreg-avp = sreg-attr "=" sreg-val
sreg-attr = sreg-word
sreg-val = sreg-word
sreg-word = 1*( unreserved / pct-encoded )
; pct-encoded from Section 2.1 of RFC 3986
; unreserved from Section 2.3 of RFC 3986
A client who does not support SREG MUST ignore SREG attributes sent by the server. Similarly, a client MUST ignore unknown attributes.
不支持SREG的客户端必须忽略服务器发送的SREG属性。类似地，客户端必须忽略未知属性。
In the case of failures, the response MUST follow this syntax:
如果出现故障，响应必须遵循以下语法：
outcome-data = "openid.error" "=" sreg-val *( "," sregp-avp )
outcome-data = "openid.error" "=" sreg-val *( "," sregp-avp )
Section 3.6 of [RFC4422] explicitly prohibits additional information in an unsuccessful authentication outcome. Therefore, the openid.error and openid.error_code are to be sent as an additional challenge in the event of an unsuccessful outcome. In this case, as the protocol is in lockstep, the client will follow with an additional exchange containing "=", after which the server will respond with an application-level outcome.
[RFC4422]第3.6节明确禁止在认证结果不成功的情况下提供额外信息。因此，如果结果不成功，openid.error和openid.error_代码将作为附加质询发送。在这种情况下，由于协议处于lockstep状态，客户端随后将执行一个包含“=”的附加交换，之后服务器将以应用程序级结果进行响应。
This section MUST be observed to properly implement the GSS-API mechanism that is described below.
必须遵守本节，以正确实施下文所述的GSS-API机制。
The OpenID SASL mechanism is actually also a GSS-API mechanism. The OpenID user takes the role of the GSS-API Initiator and the OpenID Relying Party takes the role of the GSS-API Acceptor. The OpenID Provider does not have a role in GSS-API and is considered an internal matter for the OpenID mechanism. The messages are the same, but a) the GS2 header on the client's first message and channel binding data are excluded when OpenID is used as a GSS-API mechanism, and b) the initial context token header (described in Section 3.1 of RFC 2743) is prefixed to the client's first authentication message (context token).
OpenIDSASL机制实际上也是一种GSS-API机制。OpenID用户扮演GSS-API发起人的角色，OpenID依赖方扮演GSS-API接受者的角色。OpenID提供程序在GSS-API中没有角色，被认为是OpenID机制的内部事务。消息是相同的，但a）当OpenID用作GSS-API机制时，客户端第一条消息和通道绑定数据上的GS2头被排除，b）初始上下文令牌头（如RFC 2743第3.1节所述）在客户端的第一条身份验证消息（上下文令牌）前加前缀。
The GSS-API OID for the OpenID 2.0 mechanism is 1.3.6.1.5.5.16 (see Section 7 for more information). The DER encoding of the OID is 0x2b 0x06 0x01 0x05 0x05 0x10.
OpenID2.0机制的GSS-API OID为1.3.6.1.5.5.16（有关更多信息，请参阅第7节）。OID的DER编码为0x2b 0x06 0x01 0x05 0x05 0x10。
OpenID security contexts MUST have the mutual_state flag (GSS_C_MUTUAL_FLAG) set to TRUE. OpenID does not support credential delegation; therefore, OpenID security contexts MUST have the deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE.
OpenID安全上下文必须将相互_状态标志（GSS_C_相互_标志）设置为TRUE。OpenID不支持凭证委派；因此，OpenID安全上下文必须将deleg_状态标志（GSS_C_deleg_标志）设置为FALSE。
The mutual authentication property of this mechanism relies on successfully comparing the TLS server identity with the negotiated target name. Since the TLS channel is managed by the application outside of the GSS-API mechanism, the mechanism itself is unable to confirm the name while the application is able to perform this comparison for the mechanism. For this reason, applications MUST match the TLS server identity with the target name, as discussed in [RFC6125].
此机制的相互身份验证属性依赖于成功地将TLS服务器标识与协商的目标名称进行比较。由于TLS通道由GSS-API机制之外的应用程序管理，因此当应用程序能够对该机制执行此比较时，该机制本身无法确认名称。因此，应用程序必须将TLS服务器标识与目标名称相匹配，如[RFC6125]中所述。
The OpenID mechanism does not support per-message tokens or GSS_Pseudo_random.
OpenID机制不支持每消息令牌或GSS_伪_随机。
The [RFC5587] mechanism attributes for this mechanism are GSS_C_MA_MECH_CONCRETE, GSS_C_MA_ITOK_FRAMED, and GSS_C_MA_AUTH_INIT.
此机制的[RFC5587]机制属性是GSS_C_MA_MECH_CONCRETE、GSS_C_MA_ITOK_FRAMED和GSS_C_MA_AUTH_INIT。
OpenID supports standard generic name syntaxes for acceptors such as GSS_C_NT_HOSTBASED_SERVICE (see Section 4.1 of [RFC2743]).
OpenID支持接受程序的标准通用名称语法，如GSS_C_NT_HOSTBASED_服务（参见[RFC2743]第4.1节）。
OpenID supports only a single name type for initiators: GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for OpenID.
OpenID仅支持启动器的单一名称类型：GSS\u C\u NT\u USER\u name。GSS_C_NT_USER_NAME是OpenID的默认名称类型。
OpenID name normalization is covered by the OpenID specification; see Section 7.2 of [OpenID].
OpenID名称规范化包含在OpenID规范中；参见[OpenID]第7.2节。
The query, display, and exported name syntaxes for OpenID principal names are all the same. There are no OpenID-specific name syntaxes -- applications should use generic GSS-API name types such as GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see Section 4 of [RFC2743]). The exported name token does, of course, conform to Section 3.2 of [RFC2743], but the "NAME" part of the token should be treated as a potential input string to the OpenID name normalization rules. For example, the OpenID Identifier "https://openid.example/" will have a GSS_C_NT_USER_NAME value of "https://openid.example/".
OpenID主体名称的查询、显示和导出的名称语法都是相同的。没有OpenID特定的名称语法——应用程序应使用通用GSS-API名称类型，如GSS_C_NT_USER_name和GSS_C_NT_HOSTBASED_SERVICE（请参阅[RFC2743]第4节）。当然，导出的名称令牌符合[RFC2743]的第3.2节，但令牌的“名称”部分应视为OpenID名称规范化规则的潜在输入字符串。例如，OpenID标识符“https://openid.example/“将具有GSS\u C\u NT\u用户名值”https://openid.example/".
GSS-API name attributes may be defined in the future to hold the normalized OpenID Identifier.
将来可能会定义GSS-API名称属性来保存规范化的OpenID标识符。
Suppose a user has an OpenID of https://openid.example and wishes to authenticate his IMAP connection to mail.example (where .example is the top-level domain specified in [RFC2606]). The user would input his OpenID into his mail user agent when he configures the account. In this case, no association is attempted between the OpenID RP and the OP. The client will make use of the "return_to" attribute to capture results of the authentication to be redirected to the server. Note the use of [RFC4959] for the initial response. The authentication on the wire would then look something like the following:
假设用户的OpenID为https://openid.example 并希望验证其与mail.example的IMAP连接（其中.example是[RFC2606]中指定的顶级域）。当用户配置帐户时，他会将他的OpenID输入到他的邮件用户代理中。在这种情况下，不会尝试在OpenID RP和OP之间建立关联。客户端将使用“return_to”属性捕获要重定向到服务器的身份验证结果。注意初始响应使用[RFC4959]。然后，线路上的身份验证将如下所示：
(S = IMAP server; C = IMAP client)
(S = IMAP server; C = IMAP client)
C: < connects to IMAP port>
S: * OK
C: C1 CAPABILITY
S: * CAPABILITY IMAP4rev1 SASL-IR SORT [...] AUTH=OPENID20
S: C1 OK Capability Completed
C: C2 AUTHENTICATE OPENID biwsaHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS8=
[ This is the base64 encoding of "n,,https://openid.example/".
Server performs discovery on http://openid.example/ ]
S: + aHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS9vcGVuaWQvP29wZW5pZC5ucz1
odHRwOi8vc3BlY3Mub3BlbmlkLm5ldC9hdXRoLzIuMCZvcGVuaWQucm
V0dXJuX3RvPWh0dHBzOi8vbWFpbC5leGFtcGxlL2NvbnN1bWVyLzFlZ
jg4OGMmb3BlbmlkLmNsYWltZWRfaWQ9aHR0cHM6Ly9vcGVuaWQuZXhh
bXBsZS8mb3BlbmlkLmlkZW50aXR5PWh0dHBzOi8vb3BlbmlkLmV4YW1
wbGUvJm9wZW5pZC5yZWFsbT1pbWFwOi8vbWFpbC5leGFtcGxlJm9wZW
5pZC5tb2RlPWNoZWNraWRfc2V0dXA=
C: < connects to IMAP port>
S: * OK
C: C1 CAPABILITY
S: * CAPABILITY IMAP4rev1 SASL-IR SORT [...] AUTH=OPENID20
S: C1 OK Capability Completed
C: C2 AUTHENTICATE OPENID biwsaHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS8=
[ This is the base64 encoding of "n,,https://openid.example/".
Server performs discovery on http://openid.example/ ]
S: + aHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS9vcGVuaWQvP29wZW5pZC5ucz1
odHRwOi8vc3BlY3Mub3BlbmlkLm5ldC9hdXRoLzIuMCZvcGVuaWQucm
V0dXJuX3RvPWh0dHBzOi8vbWFpbC5leGFtcGxlL2NvbnN1bWVyLzFlZ
jg4OGMmb3BlbmlkLmNsYWltZWRfaWQ9aHR0cHM6Ly9vcGVuaWQuZXhh
bXBsZS8mb3BlbmlkLmlkZW50aXR5PWh0dHBzOi8vb3BlbmlkLmV4YW1
wbGUvJm9wZW5pZC5yZWFsbT1pbWFwOi8vbWFpbC5leGFtcGxlJm9wZW
5pZC5tb2RlPWNoZWNraWRfc2V0dXA=
[ This is the base64 encoding of "https://openid.example/openid/
?openid.ns=http://specs.openid.net/auth/2.0
&openid.return_to=https://mail.example/consumer/1ef888c
&openid.claimed_id=https://openid.example/
&openid.identity=https://openid.example/
&openid.realm=imap://mail.example
&openid.mode=checkid_setup"
with line breaks and spaces added here for readability.
]
C: PQ==
[ The client now sends the URL it received to a browser for
processing. The user logs into https://openid.example and
agrees to authenticate imap://mail.example. A redirect is
passed back to the client browser that then connects to
https://imap.example/consumer via SSL with the results.
From an IMAP perspective, however, the client sends the "="
response, and awaits mail.example.
Server mail.example would now contact openid.example with an
openid.check_authentication message. After that...
]
S: + ZW1haWw9bGVhckBtYWlsLmV4YW1wbGUsZnVsbG5hbWU9RWxp
b3QlMjBMZWFy
[ Here, the IMAP server has returned an SREG attribute of
email=lear@mail.example,fullname=Eliot%20Lear.
Line break in response added in this example for readability. ]
C:
[ In IMAP, client must send a blank response after receiving
the SREG data. ]
S: C2 OK
[ This is the base64 encoding of "https://openid.example/openid/
?openid.ns=http://specs.openid.net/auth/2.0
&openid.return_to=https://mail.example/consumer/1ef888c
&openid.claimed_id=https://openid.example/
&openid.identity=https://openid.example/
&openid.realm=imap://mail.example
&openid.mode=checkid_setup"
with line breaks and spaces added here for readability.
]
C: PQ==
[ The client now sends the URL it received to a browser for
processing. The user logs into https://openid.example and
agrees to authenticate imap://mail.example. A redirect is
passed back to the client browser that then connects to
https://imap.example/consumer via SSL with the results.
From an IMAP perspective, however, the client sends the "="
response, and awaits mail.example.
Server mail.example would now contact openid.example with an
openid.check_authentication message. After that...
]
S: + ZW1haWw9bGVhckBtYWlsLmV4YW1wbGUsZnVsbG5hbWU9RWxp
b3QlMjBMZWFy
[ Here, the IMAP server has returned an SREG attribute of
email=lear@mail.example,fullname=Eliot%20Lear.
Line break in response added in this example for readability. ]
C:
[ In IMAP, client must send a blank response after receiving
the SREG data. ]
S: C2 OK
In this example, the SASL server / RP has made use of a transaction ID 1ef888c.
在本例中，SASL服务器/RP使用了事务ID 1ef888c。
This section will address only security considerations associated with the use of OpenID with SASL and GSS-API. For considerations relating to OpenID in general, the reader is referred to the OpenID specification [OpenID] and to other literature [OpReview]. Similarly, for general SASL [RFC4422] and GSS-API [RFC5801] security considerations, the reader is referred to those specifications.
本节仅讨论与SASL和GSS-API使用OpenID相关的安全注意事项。关于OpenID的一般注意事项，读者可以参考OpenID规范[OpenID]和其他文献[OpReview]。类似地，对于一般SASL[RFC4422]和GSS-API[RFC5801]安全考虑，读者可以参考这些规范。
As specified in [RFC4422], the server is responsible for binding credentials to a specific authorization identity. It is therefore necessary that a registration process takes place in advance that binds specific OpenIDs to specific authorization identities, or that only specific trusted OpenID Providers be allowed, where a mapping is predefined. For example, it could be prearranged between an IdP and RP that "https://example.com/user" maps to "user" for purposes of authorization.
如[RFC4422]中所述，服务器负责将凭据绑定到特定的授权标识。因此，有必要提前进行注册过程，将特定的OpenID绑定到特定的授权标识，或者只允许特定的受信任OpenID提供者，其中映射是预定义的。例如，它可以在IdP和RP之间预先安排，即“https://example.com/user映射到“用户”以进行授权。
In the initial SASL client response, a user or host can transmit a malicious response to the RP for purposes of taking advantage of weaknesses in the RP's OpenID implementation. It is possible to add port numbers to the URL so that the outcome is that the RP does a port scan of the site. The URL could contain an unauthorized host or even the local host. The URL could contain a protocol other than http or https, such as file or ftp.
在初始SASL客户端响应中，用户或主机可以向RP发送恶意响应，以利用RP的OpenID实现中的弱点。可以将端口号添加到URL，这样RP就可以对站点进行端口扫描。URL可能包含未经授权的主机，甚至可能包含本地主机。URL可以包含http或https以外的协议，如文件或ftp。
One mitigation would be for RPs to have a list of authorized URI bases. OPs SHOULD only redirect to RPs with the same domain component of the base URI. RPs MUST NOT automatically retry on failed attempts. A log of those sites that fail SHOULD be kept, and limitations on queries from clients SHOULD be imposed, just as with any other authentication attempt. Applications SHOULD NOT invoke browsers to communicate with OPs that they are not themselves configured with.
一种缓解措施是让RPs拥有一个授权URI基的列表。OPs应该只重定向到具有相同基本URI域组件的RPs。RPs不得在尝试失败时自动重试。应该保留失败站点的日志，并对来自客户端的查询施加限制，就像任何其他身份验证尝试一样。应用程序不应调用浏览器来与自身未配置的OPs通信。
The OP is aware of each RP that a user logs into. There is nothing in the protocol to hide this information from the OP. It is not a requirement to track the visits, but there is nothing that prohibits the collection of information. SASL servers should be aware that
OP知道用户登录的每个RP。协议中没有对OP隐藏此信息。不要求跟踪访问，但也没有禁止收集信息的规定。SASL服务器应该知道
OpenID Providers will be able to track -- to some extent -- user access to their services and any additional information that OP provides.
OpenID提供商将能够在某种程度上跟踪用户对其服务的访问以及OP提供的任何附加信息。
IANA has updated the "SASL Mechanisms" registry using the following template, as described in [RFC4422].
IANA已使用以下模板更新了“SASL机制”注册表，如[RFC4422]所述。
SASL mechanism name: OPENID20
SASL机制名称：OPENID20
Security Considerations: See this document
安全注意事项：请参阅本文档
Published specification: See this document
发布的规范：参见本文档
Person & email address to contact for further information: Authors of this document
联系人和电子邮件地址以获取更多信息：本文档作者
Intended usage: COMMON
预期用途：普通
Owner/Change controller: IESG
所有者/变更控制员：IESG
Note: None
注：无
IANA has also assigned an OID for this GSS mechanism in the "SMI Security for Mechanism Codes" registry, with the prefix of iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and referencing this specification in the registry.
IANA还在“SMI安全机制代码”注册表中为该GSS机制分配了一个OID，前缀为iso.org.dod.internet.Security.mechanism（1.3.6.1.5.5），并在注册表中引用了该规范。
The authors would like to thank Alexey Melnikov, Joe Hildebrand, Mark Crispin, Chris Newman, Leif Johansson, Sam Hartman, Nico Williams, Klaas Wierenga, Stephen Farrell, and Stephen Kent for their review and contributions.
作者要感谢Alexey Melnikov、Joe Hildebrand、Mark Crispin、Chris Newman、Leif Johansson、Sam Hartman、Nico Williams、Klaas Wierenga、Stephen Farrell和Stephen Kent的评论和贡献。
[OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", December 2007, <http://specs.openid.net/auth/2.0>.
[ OpenID ] OpenID基金会，“OpenID认证2 -最终”，2007年12月，<http://specs.openid.net/auth/2.0>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]Eastlake，D.和A.Panitz，“保留顶级DNS名称”，BCP 32，RFC 26061999年6月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]Melnikov，A.和K.Zeilenga，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5587] Williams, N., "Extended Generic Security Service Mechanism Inquiry APIs", RFC 5587, July 2009.
[RFC5587]Williams，N.，“扩展通用安全服务机制查询API”，RFC5587，2009年7月。
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family", RFC 5801, July 2010.
[RFC5801]Josefsson，S.和N.Williams，“在简单身份验证和安全层（SASL）中使用通用安全服务应用程序接口（GSS-API）机制：GS2机制系列”，RFC 58012010年7月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
[SREG1.0] OpenID Foundation, "OpenID Simple Registration Extension version 1.0", June 2006, <http://openid.net/sreg/1.0>.
[SReG1.0] OpenID基金会，“OpenID简单注册扩展版1”，2006年6月，<http://openid.net/sreg/1.0>.
[OpReview] "Google Sites OpenID Reference Page", <http://sites.google.com/site/openidreview/resources>.
[OpReview]“谷歌网站OpenID参考页”<http://sites.google.com/site/openidreview/resources>.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response", RFC 4959, September 2007.
[RFC4959]Siemborski，R.和A.Gulbrandsen，“简单身份验证和安全层（SASL）初始客户端响应的IMAP扩展”，RFC 49592007年9月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC61202011年3月。
[W3C.REC-html401-19991224] Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 Specification", World Wide Web Consortium Recommendation REC-html401-19991224, December 1999, <http://www.w3.org/TR/1999/REC-html401-19991224>.
[W3C.REC-html401-19991224]Hors，A.，Raggett，D.，和I.Jacobs，“HTML 4.01规范”，万维网联盟建议REC-html401-19991224，1999年12月<http://www.w3.org/TR/1999/REC-html401-19991224>.
[XRI2.0] Reed, D., Ed. and D. McAlpin, Ed., "Extensible Resource Identifier (XRI) Syntax V2.0", OASIS Standard xri-syntax-V2.0-cs, September 2005, <http://www.oasis-open.org/ committees/download.php/15376/xri-syntax-V2.0-cs.html>.
[XRI2.0]Reed，D.，Ed.和D.McAlpin，Ed.，“可扩展资源标识符（XRI）语法V2.0”，绿洲标准XRI-Syntax-V2.0-cs，2005年9月<http://www.oasis-open.org/ committees/download.php/15376/xri-syntax-V2.0-cs.html>。
Authors' Addresses
作者地址
Eliot Lear Cisco Systems GmbH Richtistrasse 7 CH-8304 Wallisellen Switzerland
艾略特·李尔思科系统有限公司瑞士瓦利塞伦Richtistrasse 7 CH-8304
Phone: +41 44 878 9200
EMail: lear@cisco.com
Phone: +41 44 878 9200
EMail: lear@cisco.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Henry Mauldin Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Henry Mauldin Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
Phone: +1 (800) 553-6387
EMail: hmauldin@cisco.com
Phone: +1 (800) 553-6387
EMail: hmauldin@cisco.com
Simon Josefsson SJD AB Johan Olof Wallins vag 13 171 64 Solna Sweden
西蒙·约瑟夫森SJD AB约翰·奥洛夫·沃林斯弗吉尼亚州13171 64索尔纳瑞典
EMail: simon@josefsson.org
URI: http://josefsson.org/
EMail: simon@josefsson.org
URI: http://josefsson.org/