[要約] RFC 6616は、OpenIDのためのSASLとGSS-APIメカニズムを提供するものであり、認証とセキュリティの簡単なレイヤーを提供します。このRFCの目的は、OpenIDプロトコルのセキュリティを向上させ、安全な認証メカニズムを提供することです。
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は、インターネット上でWebシングルサインオンとして使用されています。 Simple Authentication and Security Layer（SASL）およびGeneric Security Service Application Program Interface（GSS-API）は、認証を一般化するためのアプリケーションフレームワークです。このメモは、SASLおよびGSS-APIを使用するアプリケーションと既存のOpenIDアイデンティティプロバイダーの統合を可能にするOpenIDのSASLおよびGSS-APIメカニズムを指定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
OpenID 2.0 [OpenID]は、ユーザーがIDアサーションおよびその他の属性をIDプロバイダーの助けを借りてWebサーバー（証明書利用者）に提供する手段を提供するWebベースの3者プロトコルです。このシステムの目的は、エンドユーザーが識別子を制御していることを確認する方法を提供することです。
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.
Simple Authentication and Security Layer（SASL）[RFC4422]は、IMAP [RFC3501]、Post Office Protocol（POP）[RFC1939]、Extensible Messaging and Presence Protocol（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.
Generic Security Serviceアプリケーションプログラムインターフェイス（GSS-API）[RFC2743]は、アプリケーションが統合インターフェイスを介して複数の認証メカニズムをサポートするためのフレームワークを提供します。このドキュメントはOpenIDの純粋なSASLメカニズムを定義していますが、SASLとGS2 [RFC5801]と呼ばれるGSS-API間の新しいブリッジに準拠しています。つまり、このドキュメントではSASLメカニズムとGSS-APIメカニズムの両方を定義しています。 SASLコンポーネントの実装者は、GSS-APIインターフェースも実装できます（MAY）。
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.
このメカニズムは、IDとその他の属性を依拠当事者に表明するために、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メカニズムを最大限に再利用することを目的としているため、個別の認証、整合性、および機密性メカニズムを確立しません。 Transport Layer Security（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の間の相互作用を示しています。このドキュメントでは、証明書利用者とクライアントを（2つの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 |
| | | |
+------------+ +----------+
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The reader is assumed to be familiar with the terms used in the OpenID 2.0 specification.
読者は、OpenID 2.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 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はもともと、HTTP- [RFC2616]およびHTMLベースの[W3C.REC-html401-19991224]通信用に、および関連するセマンティックで想定されていました。つまり、ユーザーは、証明書利用者（RP）によって、ユーザーを認証し、ID情報と他の属性を（直接的または間接的に）証明書利用者に送信するIDプロバイダー（IdP）にリダイレクトされます。 OpenID仕様のIDプロバイダーは、OpenIDプロバイダー（OP）と呼ばれます。実際のプロトコルフローは、OpenID 2.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メカニズムを実装するためにコードを変更する必要がある一方で、実装が相互運用できるように、OPの動作が変更されないことが設計上の制約であることに注意します。既存のIdP。したがって、3つのパーティを接続するアナログフローを作成する必要があります。アナログでは、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 Key Exchangeを使用して確立された共有秘密）を確立します。 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 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.
5.依拠当事者は、OPに認証要求を送信して、間接要求の形式でアサーションを取得します。これらのメッセージは、RPとOPの間で直接ではなく、クライアントを介して渡されます。 OpenIDは、間接通信の2つの方法、つまりHTTPリダイレクトとHTMLフォーム送信を定義します。 SASLでの使用には、どちらのメカニズムも直接適用できません。 OpenID 2.0対応のOPを使用できるようにするために、このドキュメントでは、OpenIDメッセージのコンテンツをユニバーサルリソース識別子（URI）[RFC3986]を使用してエンコードする必要がある新しいメソッドを定義しています。国際化リソース識別子（IRI）は、SASLサーバーに送信する前に、[RFC3987]で指定されているように、SASLクライアントによって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. この時点で、クライアントアプリケーションは、RPからの前のメッセージで受信したコンテンツを含むURLを構築する必要があります。この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に伝えます。これも、クライアントのブラウザーまたはハンドラーを介した間接的な応答を使用して行われます。クライアントは、OP結果のリダイレクトを（HTTP / TLSを介して）RPに送信します。この手順は、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. アソシエーションが確立されておらず、OPが応答する必要がある場合、RPはOpenID check_authenticationリクエストを直接OPに送信してもよい（MAY）。繰り返しますが、このステップはSASLの帯域外で行われます。
11. The SASL server sends an appropriate SASL response to the client, with optional Open Simple Registry (SREG) attributes.
11. SASLサーバーは、オプションのOpen Simple Registry（SREG）属性を使用して、適切なSASL応答をクライアントに送信します。
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
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は、ブラウザーのCookieに簡単にアクセスできるWeb内でシリアルに使用するためのものです。そのため、プロトコル内にはトランザクションIDはありません。特定の要求が確実にバインドされるようにするため、特にプロセス間通信を容易にするために、依存パーティは、成功または失敗のためにクライアントを介して送信するURIのnonceまたはトランザクションIDを、ベースURIまたはフラグメントコンポーネントとしてエンコードする必要があります。 「return_to」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-header」を介して承認IDを転送できます。このメカニズムはセキュリティ層を提供しません。
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.
2番目のメカニズムメッセージはサーバーからクライアントへのものであり、これは以下で説明する「authentication_request」です。
The third mechanism message is from client to the server, and it is the fixed message consisting of "=".
3番目のメカニズムメッセージはクライアントからサーバーへのもので、「=」で構成される固定メッセージです。
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.
4番目のメカニズムメッセージは、サーバーからクライアントへのもので、以下では「outcome_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.
initial-response = gs2-header Auth-Identifier Auth-Identifier = Identifier;認証識別子Identifier = URI;識別子はで指定されます。 Sec。 OpenID 2.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.
「gs2-header」の構文とセマンティクスは[RFC5801]で指定されており、ここでは次の制限付きで使用します：「gs2-nonstd-flag」は存在してはいけません。このメカニズムではチャネルバインディングがサポートされていないため、「gs2-cb-flag」は「n」である必要があります。
URI is specified in [RFC3986]. Extensible Resource Identifiers (XRIs) [XRI2.0] MUST NOT be used.
URIは[RFC3986]で指定されています。拡張可能リソース識別子（XRI）[XRI2.0]は使用してはならない（MUST NOT）。
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 2.0仕様[OpenID]のセクション9.1で指定されているように、 "checkid_immediate"または "checkid_setup"の "openid.mode"を含むOpenID認証要求の結果のURLを送信します。
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サーバーからリダイレクトするように、HTTP GETを介して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.
クライアントは、OPに対するユーザー認証と、このSASLメカニズムを介した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によるすべての認証が完了し、応答がクライアントに送信された後、クライアントは、トランザクションで以前に指定されたように（ "return_to"）、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.
依存パーティは、OpenID仕様で指定されているように、HTTP / TLSを介してクライアントから受信した応答を、トランザクションで以前に指定された「return_to」URIを使用して検証します。
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メカニズムの結果を構成し、それに応じてサーバーに状態を設定するために使用する必要があります。また、[RFC4422]のセクション3.6で説明されているように、サーバーがその状態をSASLクライアントに報告するために使用する必要があります。追加データに、サーバーは[SREG1.0]のセクション4にリストされているOpenID Simple Registry（SREG）属性を含めることができます（MAY）。 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
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
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 )
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_codeは、結果が失敗した場合の追加のチャレンジとして送信されます。この場合、プロトコルはロックステップにあるため、クライアントは "="を含む追加の交換を行い、その後サーバーはアプリケーションレベルの結果で応答します。
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).
OpenID SASLメカニズムは、実際にはGSS-APIメカニズムでもあります。 OpenIDユーザーはGSS-APIイニシエーターの役割を果たし、OpenID依存パーティはGSS-APIアクセプターの役割を果たします。 OpenIDプロバイダーはGSS-APIで役割を持たず、OpenIDメカニズムの内部事項と見なされます。メッセージは同じですが、a）クライアントの最初のメッセージのGS2ヘッダーとチャネルバインディングデータは、OpenIDがGSS-APIメカニズムとして使用されている場合は除外されます。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.
OpenID 2.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セキュリティコンテキストでは、mutual_stateフラグ（GSS_C_MUTUAL_FLAG）をTRUEに設定する必要があります。 OpenIDは資格情報の委任をサポートしていません。したがって、OpenIDセキュリティコンテキストでは、deleg_stateフラグ（GSS_C_DELEG_FLAG）を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サーバーIDとネゴシエートされたターゲット名を正常に比較することに依存しています。 TLSチャネルはGSS-APIメカニズムの外部のアプリケーションによって管理されるため、アプリケーションがメカニズムのこの比較を実行できる間、メカニズム自体は名前を確認できません。このため、[RFC6125]で説明されているように、アプリケーションはTLSサーバーIDをターゲット名と一致させる必要があります。
The OpenID mechanism does not support per-message tokens or GSS_Pseudo_random.
OpenIDメカニズムは、メッセージごとのトークンまたはGSS_Pseudo_randomをサポートしていません。
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_SERVICEなどのアクセプターの標準的な一般的な名前の構文をサポートしています（[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_C_NT_USER_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_C_NT_USER_NAMEやGSS_C_NT_HOSTBASED_SERVICEなどの一般的なGSS-API名タイプを使用する必要があります（[RFC2743]のセクション4を参照）。もちろん、エクスポートされた名前トークンは[RFC2743]のセクション3.2に準拠していますが、トークンの「NAME」部分は、OpenID名前正規化ルールへの潜在的な入力文字列として扱う必要があります。たとえば、OpenID識別子「https：//openid.example/」のGSS_C_NT_USER_NAME値は「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)
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
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]で指定されているように、サーバーは資格情報を特定の承認IDにバインドする責任があります。したがって、特定のOpenIDを特定の承認IDにバインドする登録プロセスを事前に実行するか、マッピングが事前定義されている特定の信頼されたOpenIDプロバイダーのみを許可する必要があります。たとえば、承認の目的で「https://example.com/user」が「user」にマッピングされるIdPとRPの間で事前に調整できます。
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のOpenID実装の弱点を利用する目的で、ユーザーまたはホストが悪意のある応答をRPに送信できます。 URLにポート番号を追加して、RPがサイトのポートスキャンを実行できるようにすることが可能です。 URLには、無許可のホストまたはローカルホストが含まれている可能性があります。 URLには、httpやhttps以外のプロトコル（fileや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.
緩和策の1つは、RPが承認されたURIベースのリストを保持することです。 OPは、ベースURIの同じドメインコンポーネントを持つRPにのみリダイレクトする必要があります（SHOULD）。 RPは、失敗した試行で自動的に再試行してはなりません。他の認証試行と同様に、失敗したサイトのログを保持する必要があり、クライアントからのクエリに制限を課す必要があります（SHOULD）。アプリケーションは、それ自体が構成されていないOPと通信するためにブラウザーを呼び出すべきではありません。
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 OpenID Providers will be able to track -- to some extent -- user access to their services and any additional information that OP provides.
OPは、ユーザーがログインする各RPを認識しています。この情報をOPから隠すプロトコルはありません。訪問を追跡することは必須ではありませんが、情報の収集を禁止するものはありません。 SASLサーバーは、OpenIDプロバイダーがサービスへのユーザーアクセスとOPが提供する追加情報をある程度追跡できることを認識しておく必要があります。
IANA has updated the "SASL Mechanisms" registry using the following template, as described in [RFC4422].
[RFC4422]で説明されているように、IANAは次のテンプレートを使用して「SASLメカニズム」レジストリを更新しました。
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
使用目的：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.mechanisms（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 Foundation、「OpenID Authentication 2.0-Final」、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]イーストレイクD.およびA.パニッツ、「予約済みトップレベルDNS名」、BCP 32、RFC 2606、1999年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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-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。、「Generic Security Service Application Program Interface Version 2、Update 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、「Uniform Resource Identifier（URI）：Generic Syntax」、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、「Internationalized Resource Identifiers（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、「Simple Authentication and Security Layer（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、「The Transport Layer Security（TLS）Protocol Version 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 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC5587] Williams, N., "Extended Generic Security Service Mechanism Inquiry APIs", RFC 5587, July 2009.
[RFC5587] Williams、N。、「Extended Generic Security Service Mechanism Inquiry APIs」、RFC 5587、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、「Simple Authentication and Security Layer（SASL）：The Generic Security Service Application Program Interface（GSS-API）Mechanisms in Simple Authentication and Security Layer（SASL）：The GS2 Mechanism Family」、RFC 5801、2010年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）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、2011年3月。
[SREG1.0] OpenID Foundation, "OpenID Simple Registration Extension version 1.0", June 2006, <http://openid.net/sreg/1.0>.
[SREG1.0] OpenID Foundation、「OpenID Simple Registration Extension version 1.0」、2006年6月、<http://openid.net/sreg/1.0>。
[OpReview] "Google Sites OpenID Reference Page", <http://sites.google.com/site/openidreview/resources>.
[OpReview]「Googleサイト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.ローズ、「Post Office Protocol-Version 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 3501、2003年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、「IMAP Extension for Simple Authentication and Security Layer（SASL）Initial Client Response」、RFC 4959、2007年9月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、2011年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 Specification」、World Wide Web Consortium Recommendation 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]リード、D。、エド。およびD. McAlpin、Ed。、「Extensible Resource Identifier（XRI）Syntax V2.0」、OASIS標準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
Eliot Lear Cisco Systems GmbH Richtistrasse 7 CH-8304 Wallisellen Switzerland
Phone: +41 44 878 9200
EMail: lear@cisco.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
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 West Tasman Drive San Jose、CA 95134 USA
Phone: +1 (800) 553-6387
EMail: hmauldin@cisco.com
Simon Josefsson SJD AB Johan Olof Wallins vag 13 171 64 Solna Sweden
Simon Josefsson SJD AB Johan Olof Wallins vag 13171 64 Solnaスウェーデン
EMail: simon@josefsson.org
URI: http://josefsson.org/