RFC 7522 - Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7522
タイトル : RFC 7522 - OAuth 2.0クライアント認証および許可付与のためのSecurity Assertion Markup Language（SAML）2.0プロファイル
翻訳編集 : 自動生成

[要約] RFC 7522は、OAuth 2.0クライアント認証および認可グラントに対するSecurity Assertion Markup Language (SAML) 2.0プロファイルを定義しています。この文書の目的は、SAML 2.0アサーションを使用してOAuth 2.0トークンエンドポイントに対してクライアント認証と認可グラントを行う方法を規定することです。このプロファイルは、既存のSAML 2.0アイデンティティフェデレーションインフラストラクチャをOAuth 2.0認証フレームワークに統合したい場合に利用されます。関連するRFCには、OAuth 2.0を定義するRFC 6749や、OAuth 2.0の使用を拡張するその他のRFCが含まれます。

Internet Engineering Task Force (IETF)                       B. Campbell
Request for Comments: 7522                                 Ping Identity
Category: Standards Track                                   C. Mortimore
ISSN: 2070-1721                                               Salesforce
                                                                M. Jones
                                                               Microsoft
                                                                May 2015

Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants

OAuth 2.0クライアント認証および許可付与のためのSecurity Assertion Markup Language（SAML）2.0プロファイル

Abstract

概要

This specification defines the use of a Security Assertion Markup Language (SAML) 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for client authentication.

この仕様では、OAuth 2.0アクセストークンをリクエストするための手段として、およびクライアント認証のための手段として、セキュリティアサーションマークアップ言語（SAML）2.0 Bearerアサーションの使用を定義しています。

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/rfc7522.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7522で入手できます。

著作権表示

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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   4
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  HTTP Parameter Bindings for Transporting Assertions . . . . .   4
     2.1.  Using SAML Assertions as Authorization Grants . . . . . .   4
     2.2.  Using SAML Assertions for Client Authentication . . . . .   5
   3.  Assertion Format and Processing Requirements  . . . . . . . .   6
     3.1.  Authorization Grant Processing  . . . . . . . . . . . . .   8
     3.2.  Client Authentication Processing  . . . . . . . . . . . .   9
   4.  Authorization Grant Example . . . . . . . . . . . . . . . . .   9
   5.  Interoperability Considerations . . . . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Sub-Namespace Registration of
           urn:ietf:params:oauth:grant-type:saml2-bearer . . . . . .  12
     8.2.  Sub-Namespace Registration of
           urn:ietf:params:oauth:client-assertion-type:saml2-bearer   13
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1. Introduction

1. はじめに

The Security Assertion Markup Language (SAML) 2.0 [OASIS.saml-core-2.0-os] is an XML-based framework that allows identity and security information to be shared across security domains. The SAML specification, while primarily targeted at providing cross domain Web browser single sign-on (SSO), was also designed to be modular and extensible to facilitate use in other contexts.

Security Assertion Markup Language（SAML）2.0 [OASIS.saml-core-2.0-os]は、IDとセキュリティ情報をセキュリティドメイン間で共有できるようにするXMLベースのフレームワークです。 SAML仕様は、主にクロスドメインWebブラウザのシングルサインオン（SSO）を提供することを目的としていますが、モジュール化され、他のコンテキストでの使用を容易にするために拡張できるようにも設計されています。

The Assertion, an XML security token, is a fundamental construct of SAML that is often adopted for use in other protocols and specifications. (Some examples include [OASIS.WSS-SAMLTokenProfile] and [OASIS.WS-Fed].) An Assertion is generally issued by an Identity Provider and consumed by a Service Provider that relies on its content to identify the Assertion's subject for security-related purposes.

XMLセキュリティトークンであるアサーションはSAMLの基本的な構成要素であり、他のプロトコルや仕様での使用によく採用されています。（一部の例には、[OASIS.WSS-SAMLTokenProfile]および[OASIS.WS-Fed]が含まれます。）アサーションは通常、アイデンティティプロバイダーによって発行され、セキュリティ関連のアサーションのサブジェクトを識別するためにそのコンテンツに依存するサービスプロバイダーによって消費されます。目的。

The OAuth 2.0 Authorization Framework [RFC6749] provides a method for making authenticated HTTP requests to a resource using an access token. Access tokens are issued to third-party clients by an authorization server (AS) with the (sometimes implicit) approval of the resource owner. In OAuth, an authorization grant is an abstract term used to describe intermediate credentials that represent the resource owner authorization. An authorization grant is used by the client to obtain an access token. Several authorization grant types are defined to support a wide range of client types and user experiences. OAuth also allows for the definition of new extension grant types to support additional clients or to provide a bridge between OAuth and other trust frameworks. Finally, OAuth allows the definition of additional authentication mechanisms to be used by clients when interacting with the authorization server.

OAuth 2.0 Authorization Framework [RFC6749]は、アクセストークンを使用してリソースへの認証済みHTTPリクエストを作成する方法を提供します。アクセストークンは、リソース所有者の（暗黙的な）承認を伴う承認サーバー（AS）によってサードパーティのクライアントに発行されます。 OAuthでは、許可付与は、リソース所有者の許可を表す中間資格情報を説明するために使用される抽象的な用語です。認可付与は、アクセストークンを取得するためにクライアントによって使用されます。さまざまなクライアントタイプとユーザーエクスペリエンスをサポートするために、いくつかの承認付与タイプが定義されています。 OAuthでは、追加のクライアントをサポートするため、またはOAuthと他の信頼フレームワーク間のブリッジを提供するために、新しい拡張付与タイプを定義することもできます。最後に、OAuthを使用すると、追加の認証メカニズムを定義して、承認サーバーとやり取りするときにクライアントが使用できます。

"Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7521] is an abstract extension to OAuth 2.0 that provides a general framework for the use of assertions as client credentials and/or authorization grants with OAuth 2.0. This specification profiles the OAuth Assertion Framework [RFC7521] to define an extension grant type that uses a SAML 2.0 Bearer Assertion to request an OAuth 2.0 access token as well as for use as client credentials. The format and processing rules for the SAML Assertion defined in this specification are intentionally similar, though not identical, to those in the Web Browser SSO profile defined in the SAML Profiles [OASIS.saml-profiles-2.0-os] specification. This specification is reusing, to the extent reasonable, concepts and patterns from that well-established profile.

「OAuth 2.0クライアント認証および承認付与のためのアサーションフレームワーク」[RFC7521]は、OAuth 2.0の抽象拡張であり、OAuth 2.0でクライアント資格情報または認可付与としてアサーションを使用するための一般的なフレームワークを提供します。この仕様は、OAuthアサーションフレームワーク[RFC7521]のプロファイルを作成して、SAML 2.0ベアラーアサーションを使用してOAuth 2.0アクセストークンをリクエストし、クライアント資格情報として使用する拡張付与タイプを定義します。この仕様で定義されているSAMLアサーションの形式と処理ルールは、SAMLプロファイル[OASIS.saml-profiles-2.0-os]仕様で定義されているWebブラウザーSSOプロファイルのフォーマットと処理ルールと同じですが、意図的に同じです。この仕様は、その十分に確立されたプロファイルの概念とパターンを、合理的な範囲で再利用しています。

This document defines how a SAML Assertion can be used to request an access token when a client wishes to utilize an existing trust relationship, expressed through the semantics of the SAML Assertion, without a direct user approval step at the authorization server. It also defines how a SAML Assertion can be used as a client authentication mechanism. The use of an Assertion for client authentication is orthogonal to and separable from using an Assertion as an authorization grant. They can be used either in combination or separately. Client assertion authentication is nothing more than an alternative way for a client to authenticate to the token endpoint, and it must be used in conjunction with some grant type to form a complete and meaningful protocol request. Assertion authorization grants may be used with or without client authentication or identification. Whether or not client authentication is needed in conjunction with an assertion authorization grant, as well as the supported types of client authentication, are policy decisions at the discretion of the authorization server.

このドキュメントでは、クライアントが既存の信頼関係を利用したい場合に、SAMLアサーションを使用してアクセストークンをリクエストする方法を定義します。SAMLアサーションのセマンティクスにより、認可サーバーでの直接のユーザー承認ステップなしで表現されます。また、SAMLアサーションをクライアント認証メカニズムとして使用する方法も定義します。クライアント認証にアサーションを使用することは、アサーションを許可付与として使用することと直交しており、分離できます。これらは組み合わせて、または別々に使用できます。クライアントアサーション認証は、クライアントがトークンエンドポイントに対して認証するための代替方法に過ぎず、完全かつ意味のあるプロトコル要求を形成するために、いくつかの許可タイプと組み合わせて使用する必要があります。アサーション許可付与は、クライアント認証または識別の有無にかかわらず使用できます。アサーション許可の付与とともにクライアント認証が必要かどうか、およびサポートされているクライアント認証のタイプは、許可サーバーの裁量によるポリシー決定です。

The process by which the client obtains the SAML Assertion, prior to exchanging it with the authorization server or using it for client authentication, is out of scope.

許可サーバーと交換する前、またはクライアント認証に使用する前に、クライアントがSAMLアサーションを取得するプロセスは範囲外です。

1.1. Notational Conventions

1.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]で説明されているように解釈されます。

Unless otherwise noted, all the protocol parameter names and values are case sensitive.

特に明記しない限り、すべてのプロトコルパラメータの名前と値は大文字と小文字が区別されます。

1.2. Terminology

1.2. 用語

All terms are as defined in the following specifications: "The OAuth 2.0 Authorization Framework" [RFC6749], the OAuth Assertion Framework [RFC7521], and "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0" [OASIS.saml-core-2.0-os].

すべての用語は次の仕様で定義されています。「OAuth 2.0承認フレームワーク」[RFC6749]、OAuthアサーションフレームワーク[RFC7521]、および「OASISセキュリティアサーションマークアップ言語（SAML）V2.0のアサーションとプロトコル」[OASIS .saml-core-2.0-os]。

2. HTTP Parameter Bindings for Transporting Assertions

2. アサーションを転送するためのHTTPパラメータバインディング

The OAuth Assertion Framework [RFC7521] defines generic HTTP parameters for transporting assertions during interactions with a token endpoint. This section defines specific parameters and treatments of those parameters for use with SAML 2.0 Bearer Assertions.

OAuthアサーションフレームワーク[RFC7521]は、トークンエンドポイントとの対話中にアサーションを転送するための一般的なHTTPパラメータを定義します。このセクションでは、SAML 2.0ベアラーアサーションで使用するための特定のパラメーターとそれらのパラメーターの処理を定義します。

2.1. Using SAML Assertions as Authorization Grants

2.1. 認可付与としてのSAMLアサーションの使用

To use a SAML Bearer Assertion as an authorization grant, the client uses an access token request as defined in Section 4 of the OAuth Assertion Framework [RFC7521] with the following specific parameter values and encodings.

SAML Bearerアサーションを許可付与として使用するには、クライアントは、OAuthアサーションフレームワーク[RFC7521]のセクション4で定義されているアクセストークンリクエストを使用して、次の特定のパラメーター値とエンコードを指定します。

The value of the "grant_type" parameter is "urn:ietf:params:oauth:grant-type:saml2-bearer".

「grant_type」パラメーターの値は「urn：ietf：params：oauth：grant-type：saml2-bearer」です。

The value of the "assertion" parameter contains a single SAML 2.0 Assertion. It MUST NOT contain more than one SAML 2.0 Assertion. The SAML Assertion XML data MUST be encoded using base64url, where the encoding adheres to the definition in Section 5 of RFC 4648 [RFC4648] and where the padding bits are set to zero. To avoid the need for subsequent encoding steps (by "application/x-www-form-urlencoded" [W3C.REC-html401-19991224], for example), the base64url-encoded data MUST NOT be line wrapped and pad characters ("=") MUST NOT be included.

「assertion」パラメーターの値には、単一のSAML 2.0アサーションが含まれています。複数のSAML 2.0アサーションを含めることはできません。 SAMLアサーションXMLデータはbase64urlを使用してエンコードする必要があります。エンコードはRFC 4648 [RFC4648]のセクション5の定義に準拠し、パディングビットはゼロに設定されます。以降のエンコード手順の必要性を回避するために（たとえば、「application / x-www-form-urlencoded」[W3C.REC-html401-19991224]によって）、base64urlでエンコードされたデータは、行を折り返して文字を埋めてはなりません（ " = "）は含めないでください。

The "scope" parameter may be used, as defined in the OAuth Assertion Framework [RFC7521], to indicate the requested scope.

OAuthアサーションフレームワーク[RFC7521]で定義されている「スコープ」パラメーターを使用して、リクエストされたスコープを示すことができます。

Authentication of the client is optional, as described in Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the "client_id" is only needed when a form of client authentication that relies on the parameter is used.

OAuth 2.0 [RFC6749]のセクション3.2.1で説明されているように、クライアントの認証はオプションです。そのため、「client_id」は、パラメーターに依存するクライアント認証の形式が使用される場合にのみ必要です。

The following example demonstrates an access token request with an Assertion as an authorization grant (with extra line breaks for display purposes only):

次の例は、承認付与としてアサーションを使用したアクセストークンリクエストを示しています（表示目的でのみ改行が追加されています）。

     POST /token.oauth2 HTTP/1.1
     Host: as.example.com
     Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer& assertion=PHNhbWxwOl...[omitted for brevity]...ZT4

grant_type = urn％3Aietf％3Aparams％3Aoauth％3Agrant-type％3Asaml2-bearer＆assertion = PHNhbWxwOl ... [簡潔にするために省略] ... ZT4

2.2. Using SAML Assertions for Client Authentication

2.2. クライアント認証のためのSAMLアサーションの使用

To use a SAML Bearer Assertion for client authentication, the client uses the following parameter values and encodings.

クライアント認証にSAML Bearerアサーションを使用するには、クライアントは次のパラメーター値とエンコーディングを使用します。

The value of the "client_assertion_type" parameter is "urn:ietf:params:oauth:client-assertion-type:saml2-bearer".

「client_assertion_type」パラメーターの値は「urn：ietf：params：oauth：client-assertion-type：saml2-bearer」です。

The value of the "client_assertion" parameter MUST contain a single SAML 2.0 Assertion. The SAML Assertion XML data MUST be encoded using base64url, where the encoding adheres to the definition in Section 5 of RFC 4648 [RFC4648] and where the padding bits are set to zero. To avoid the need for subsequent encoding steps (by "application/x-www-form-urlencoded" [W3C.REC-html401-19991224], for example), the base64url-encoded data SHOULD NOT be line wrapped and pad characters ("=") SHOULD NOT be included.

「client_assertion」パラメータの値には、単一のSAML 2.0アサーションが含まれている必要があります。 SAMLアサーションXMLデータはbase64urlを使用してエンコードする必要があります。エンコードはRFC 4648 [RFC4648]のセクション5の定義に準拠し、パディングビットはゼロに設定されます。後続のエンコード手順の必要性を回避するには（「application / x-www-form-urlencoded」[W3C.REC-html401-19991224]など）、base64urlでエンコードされたデータは、行を折り返して文字を埋めないでください（ " = "）は含めないでください。

The following example demonstrates a client authenticating using an Assertion during the presentation of an authorization code grant in an access token request (with extra line breaks for display purposes only):

以下の例は、アクセストークンリクエストでの認証コード付与の提示中にアサーションを使用してクライアントを認証する方法を示しています（表示目的でのみ改行が追加されています）。

     POST /token.oauth2 HTTP/1.1
     Host: as.example.com
     Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code& code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4& client_assertion_type=urn%3Aietf%3Aparams%3Aoauth %3Aclient-assertion-type%3Asaml2-bearer& client_assertion=PHNhbW...[omitted for brevity]...ZT

grant_type = authorization_code＆code = n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4＆client_assertion_type = urn％3Aietf％3Aparams％3Aoauth％3Aclient-assertion-type％3Asaml2-bearer＆client_assertion = PHNhbTity ... Zmitted for ...

3. Assertion Format and Processing Requirements

3. アサーション形式と処理要件

In order to issue an access token response as described in OAuth 2.0 [RFC6749] or to rely on an Assertion for client authentication, the authorization server MUST validate the Assertion according to the criteria below. Application of additional restrictions and policy are at the discretion of the authorization server.

OAuth 2.0 [RFC6749]で説明されているアクセストークン応答を発行するため、またはクライアント認証をアサーションに依存させるために、承認サーバーは以下の基準に従ってアサーションを検証する必要があります。追加の制限およびポリシーの適用は、許可サーバーの裁量に委ねられています。

1. The Assertion's <Issuer> element MUST contain a unique identifier for the entity that issued the Assertion. In the absence of an application profile specifying otherwise, compliant applications MUST compare Issuer values using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 [RFC3986].

1. アサーションの<Issuer>要素には、アサーションを発行したエンティティの一意の識別子が含まれている必要があります。特に指定しないアプリケーションプロファイルがない場合、準拠するアプリケーションは、RFC 3986 [RFC3986]のセクション6.2.1で定義されている単純な文字列比較メソッドを使用して発行者の値を比較する必要があります。

2. The Assertion MUST contain a <Conditions> element with an <AudienceRestriction> element with an <Audience> element that identifies the authorization server as an intended audience. Section 2.5.1.4 of "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0" [OASIS.saml-core-2.0-os] defines the <AudienceRestriction> and <Audience> elements and, in addition to the URI references discussed there, the token endpoint URL of the authorization server MAY be used as a URI that identifies the authorization server as an intended audience. The authorization server MUST reject any Assertion that does not contain its own identity as the intended audience. In the absence of an application profile specifying otherwise, compliant applications MUST compare the Audience values using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 [RFC3986]. As noted in Section 5, the precise strings to be used as the Audience for a given authorization server must be configured out of band by the authorization server and the issuer of the Assertion.

2. アサーションには、<AudienceRestriction>要素を含む<Conditions>要素と、承認サーバーを目的のオーディエンスとして識別する<Audience>要素を含める必要があります。「OASISセキュリティアサーションマークアップ言語（SAML）V2.0のアサーションとプロトコル」のセクション2.5.1.4 [OASIS.saml-core-2.0-os]は、<AudienceRestriction>および<Audience>要素を定義し、さらにそこで言及されているURI参照では、承認サーバーのトークンエンドポイントURLは、承認サーバーを対象ユーザーとして識別するURIとして使用できます。承認サーバーは、対象となるオーディエンスとして自身のIDを含まないアサーションを拒否する必要があります。特に指定しないアプリケーションプロファイルがない場合、準拠するアプリケーションは、RFC 3986 [RFC3986]のセクション6.2.1で定義されている単純な文字列比較メソッドを使用して、オーディエンス値を比較する必要があります。セクション5で述べたように、特定の承認サーバーのオーディエンスとして使用される正確な文字列は、承認サーバーとアサーションの発行者によって帯域外で構成する必要があります。

3. The Assertion MUST contain a <Subject> element identifying the principal that is the subject of the Assertion. Additional information identifying the subject/principal MAY be included in an <AttributeStatement>.

3. アサーションには、アサーションのサブジェクトであるプリンシパルを識別する<Subject>要素を含める必要があります。サブジェクト/プリンシパルを識別する追加情報を<AttributeStatement>に含めることができます。

A. For the authorization grant, the Subject typically identifies an authorized accessor for which the access token is being requested (i.e., the resource owner or an authorized delegate), but in some cases, it may be a pseudonymous identifier or other value denoting an anonymous user.

A.承認付与の場合、サブジェクトは通常、アクセストークンが要求されている承認済みアクセサー（つまり、リソース所有者または承認済み委任者）を識別しますが、場合によっては、匿名の識別子またはその他の匿名ユーザー。

B. For client authentication, the Subject MUST be the "client_id" of the OAuth client.

B.クライアント認証の場合、サブジェクトはOAuthクライアントの「client_id」である必要があります。

4. The Assertion MUST have an expiry that limits the time window during which it can be used. The expiry can be expressed either as the NotOnOrAfter attribute of the <Conditions> element or as the NotOnOrAfter attribute of a suitable <SubjectConfirmationData> element.

4. アサーションには、それを使用できる時間枠を制限する有効期限が必要です。有効期限は、<Conditions>要素のNotOnOrAfter属性として、または適切な<SubjectConfirmationData>要素のNotOnOrAfter属性として表現できます。

5. The <Subject> element MUST contain at least one <SubjectConfirmation> element that has a Method attribute with a value of "urn:oasis:names:tc:SAML:2.0:cm:bearer". If the Assertion does not have a suitable NotOnOrAfter attribute on the <Conditions> element, the <SubjectConfirmation> element MUST contain a <SubjectConfirmationData> element. When present, the <SubjectConfirmationData> element MUST have a Recipient attribute with a value indicating the token endpoint URL of the authorization server (or an acceptable alias). The authorization server MUST verify that the value of the Recipient attribute matches the token endpoint URL (or an acceptable alias) to which the Assertion was delivered. The <SubjectConfirmationData> element MUST have a NotOnOrAfter attribute that limits the window during which the Assertion can be confirmed. The <SubjectConfirmationData> element MAY also contain an Address attribute limiting the client address from which the Assertion can be delivered. Verification of the Address is at the discretion of the authorization server.

5. <Subject>要素には、「urn：oasis：names：tc：SAML：2.0：cm：bearer」の値を持つMethod属性を持つ<SubjectConfirmation>要素が少なくとも1つ含まれている必要があります。アサーションの<Conditions>要素に適切なNotOnOrAfter属性がない場合、<SubjectConfirmation>要素には<SubjectConfirmationData>要素が含まれている必要があります。存在する場合、<SubjectConfirmationData>要素には、承認サーバーのトークンエンドポイントURL（または受け入れ可能なエイリアス）を示す値を持つRecipient属性が必要です。承認サーバーは、Recipient属性の値が、アサーションが配信されたトークンエンドポイントURL（または受け入れ可能なエイリアス）と一致することを確認する必要があります。 <SubjectConfirmationData>要素には、アサーションを確認できるウィンドウを制限するNotOnOrAfter属性が必要です。 <SubjectConfirmationData>要素には、アサーションを配信できるクライアントアドレスを制限するAddress属性も含まれる場合があります。アドレスの確認は、許可サーバーの裁量に任されています。

6. The authorization server MUST reject the entire Assertion if the NotOnOrAfter instant on the <Conditions> element has passed (subject to allowable clock skew between systems). The authorization server MUST reject the <SubjectConfirmation> (but MAY still use the rest of the Assertion) if the NotOnOrAfter instant on the <SubjectConfirmationData> has passed (subject to allowable clock skew). Note that the authorization server may reject Assertions with a NotOnOrAfter instant that is unreasonably far in the future. The authorization server MAY ensure that Bearer Assertions are not replayed, by maintaining the set of used ID values for the length of time for which the Assertion would be considered valid based on the applicable NotOnOrAfter instant.

6. <Conditions>要素のNotOnOrAfterインスタントが渡された場合、認証サーバーはアサーション全体を拒否する必要があります（システム間の許容クロックスキューが条件です）。 <SubjectConfirmationData>のNotOnOrAfterインスタントが通過した場合（許可されたクロックスキューに従う）、承認サーバーは<SubjectConfirmation>を拒否する必要があります（ただし、アサーションの残りの部分を引き続き使用できます）。認可サーバーは、NotOnOrAfterのインスタントが不当に遠いアサーションを拒否する可能性があることに注意してください。承認サーバーは、適用されるNotOnOrAfterインスタントに基づいてアサーションが有効であると見なされる期間、使用されたID値のセットを維持することにより、ベアラアサーションが再生されないようにすることができます。

7. If the Assertion issuer directly authenticated the subject, the Assertion SHOULD contain a single <AuthnStatement> representing that authentication event. If the Assertion was issued with the intention that the client act autonomously on behalf of the subject, an <AuthnStatement> SHOULD NOT be included and the client presenting the Assertion SHOULD be identified in the <NameID> or similar element in the <SubjectConfirmation> element, or by other available means like "SAML V2.0 Condition for Delegation Restriction" [OASIS.saml-deleg-cs].

7. アサーション発行者がサブジェクトを直接認証した場合、アサーションはその認証イベントを表す単一の<AuthnStatement>を含む必要があります（SHOULD）。クライアントがサブジェクトに代わって自律的に行動することを意図してアサーションが発行された場合、<AuthnStatement>を含めるべきではなく（SHOULD NOT）、アサーションを提示するクライアントを<SubjectConfirmation>要素の<NameID>または同様の要素で識別する必要があります、または「委任制限のSAML V2.0条件」[OASIS.saml-deleg-cs]などの他の利用可能な手段。

8. Other statements, in particular <AttributeStatement> elements, MAY be included in the Assertion.

8. 他のステートメント、特に<AttributeStatement>要素は、アサーションに含めることができます。

9. The Assertion MUST be digitally signed or have a Message Authentication Code (MAC) applied by the issuer. The authorization server MUST reject Assertions with an invalid signature or MAC.

9. アサーションはデジタル署名されているか、発行者によって適用されたメッセージ認証コード（MAC）を持っている必要があります。承認サーバーは、無効な署名またはMACを持つアサーションを拒否する必要があります。

10. Encrypted elements MAY appear in place of their plaintext counterparts as defined in [OASIS.saml-core-2.0-os].

10. 暗号化された要素は、[OASIS.saml-core-2.0-os]で定義されている平文の対応物の代わりに表示される場合があります。

11. The authorization server MUST reject an Assertion that is not valid in all other respects per [OASIS.saml-core-2.0-os], such as (but not limited to) all content within the Conditions element including the NotOnOrAfter and NotBefore attributes, unknown condition types, etc.

11. 承認サーバーは、NotOnOrAfterおよびNotBefore属性を含む、Conditions要素内のすべてのコンテンツ（ただし、これらに限定されません）など、[OASIS.saml-core-2.0-os]に従って他のすべての点で無効なアサーションを拒否する必要があります、不明条件タイプなど

3.1. Authorization Grant Processing

3.1. 認可付与処理

Assertion authorization grants may be used with or without client authentication or identification. Whether or not client authentication is needed in conjunction with an Assertion authorization grant, as well as the supported types of client authentication, are policy decisions at the discretion of the authorization server. However, if client credentials are present in the request, the authorization server MUST validate them.

アサーション許可付与は、クライアント認証または識別の有無にかかわらず使用できます。アサーション許可付与とともにクライアント認証が必要かどうか、およびサポートされているタイプのクライアント認証は、許可サーバーの裁量でのポリシー決定です。ただし、クライアント資格情報がリクエストに存在する場合、承認サーバーはそれらを検証する必要があります。

If the Assertion is not valid (including if its subject confirmation requirements cannot be met), the authorization server constructs an error response as defined in OAuth 2.0 [RFC6749]. The value of the "error" parameter MUST be the "invalid_grant" error code. The authorization server MAY include additional information regarding the reasons the Assertion was considered invalid using the "error_description" or "error_uri" parameters.

アサーションが有効でない場合（サブジェクトの確認要件を満たせない場合を含む）、承認サーバーはOAuth 2.0 [RFC6749]で定義されているエラー応答を作成します。「error」パラメータの値は、「invalid_grant」エラーコードである必要があります。許可サーバーは、「error_description」または「error_uri」パラメーターを使用して、アサーションが無効と見なされた理由に関する追加情報を含めることができます。

For example:

例えば：

     HTTP/1.1 400 Bad Request
     Content-Type: application/json
     Cache-Control: no-store

     {
       "error":"invalid_grant",
       "error_description":"Audience validation failed"
     }

3.2. Client Authentication Processing

3.2. クライアント認証処理

If the client Assertion is not valid (including if its subject confirmation requirements cannot be met), the authorization server constructs an error response as defined in OAuth 2.0 [RFC6749]. The value of the "error" parameter MUST be the "invalid_client" error code. The authorization server MAY include additional information regarding the reasons the Assertion was considered invalid using the "error_description" or "error_uri" parameters.

クライアントのアサーションが有効でない場合（サブジェクトの確認要件を満たせない場合を含む）、承認サーバーはOAuth 2.0 [RFC6749]で定義されているエラー応答を作成します。「error」パラメータの値は、「invalid_client」エラーコードである必要があります。許可サーバーは、「error_description」または「error_uri」パラメーターを使用して、アサーションが無効と見なされた理由に関する追加情報を含めることができます。

4. Authorization Grant Example

4. 認可付与の例

The following examples illustrate what a conforming Assertion and an access token request would look like.

次の例は、準拠するアサーションとアクセストークンリクエストがどのようになるかを示しています。

The example shows an assertion issued and signed by the SAML Identity Provider identified as "https://saml-idp.example.com". The subject of the Assertion is identified by email address as "brian@example.com", who authenticated to the Identity Provider by means of a digital signature where the key was validated as part of an X.509 Public Key Infrastructure. The intended audience of the Assertion is "https://saml-sp.example.net", which is an identifier for a SAML Service Provider with which the authorization server identifies itself. The Assertion is sent as part of an access token request to the authorization server's token endpoint at "https://authz.example.net/token.oauth2".

この例は、「https://saml-idp.example.com」として識別されるSAML IDプロバイダーによって発行および署名されたアサーションを示しています。アサーションの件名は、電子メールアドレスによって「brian@example.com」として識別され、X.509公開鍵インフラストラクチャの一部として鍵が検証されたデジタル署名によってIDプロバイダーに認証されました。アサーションの対象読者は「https://saml-sp.example.net」です。これは、承認サーバーがそれ自体を識別するSAMLサービスプロバイダーの識別子です。アサーションは、アクセストークンリクエストの一部として、「https://authz.example.net/token.oauth2」にある認証サーバーのトークンエンドポイントに送信されます。

Below is an example SAML 2.0 Assertion (whitespace formatting is for display purposes only):

以下はSAML 2.0アサーションの例です（空白のフォーマットは表示目的のみです）：

     <Assertion IssueInstant="2010-10-01T20:07:34.619Z"
       ID="ef1xsbZxPV2oqjd7HTLRLIBlBb7"
       Version="2.0"
       xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
      <Issuer>https://saml-idp.example.com</Issuer>
      <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
       [...omitted for brevity...]
      </ds:Signature>
      <Subject>
       <NameID
        Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
        brian@example.com
       </NameID>
       <SubjectConfirmation
         Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData
          NotOnOrAfter="2010-10-01T20:12:34.619Z"
          Recipient="https://authz.example.net/token.oauth2"/>
        </SubjectConfirmation>
       </Subject>
       <Conditions>
         <AudienceRestriction>
           <Audience>https://saml-sp.example.net</Audience>
         </AudienceRestriction>
       </Conditions>
       <AuthnStatement AuthnInstant="2010-10-01T20:07:34.371Z">
         <AuthnContext>
           <AuthnContextClassRef>
             urn:oasis:names:tc:SAML:2.0:ac:classes:X509
           </AuthnContextClassRef>
         </AuthnContext>
       </AuthnStatement>
     </Assertion>

Figure 1: Example SAML 2.0 Assertion

図1：SAML 2.0アサーションの例

To present the Assertion shown in the previous example as part of an access token request, for example, the client might make the following HTTPS request (with extra line breaks for display purposes only):

たとえば、前の例で示したアサーションをアクセストークンリクエストの一部として提示するには、クライアントが次のHTTPSリクエストを行う場合があります（表示目的でのみ改行を追加します）。

     POST /token.oauth2 HTTP/1.1
     Host: authz.example.net
     Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2- bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-

grant_type = urn％3Aietf％3Aparams％3Aoauth％3Agrant-type％3Asaml2-bearer＆assertion = PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU [...省略されたために省略...] aG5TdBccbcpbcbcbcb3cbdbcb3cbdbcbcbcbcbcbcbcbcbbcbdbcbcbcbcbdbcbcbcbcbbcbdbcbcbcbcbdcbcbcbdbcbcbbfbfbfbfbfbfbfbfbfcfbfcfbfdcfbfdfdfdfdfdはじめと付け

Figure 2: Example Request

図2：リクエストの例

5. Interoperability Considerations

5. 相互運用性に関する考慮事項

Agreement between system entities regarding identifiers, keys, and endpoints is required in order to achieve interoperable deployments of this profile. Specific items that require agreement are as follows: values for the Issuer and Audience identifiers, the location of the token endpoint, the key used to apply and verify the digital signature over the Assertion, one-time use restrictions on Assertions, maximum Assertion lifetime allowed, and the specific Subject and attribute requirements of the Assertion. The exchange of such information is explicitly out of scope for this specification, and typical deployment of it will be done alongside existing SAML Web SSO deployments that have already established a means of exchanging such information. "Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0" [OASIS.saml-metadata-2.0-os] specifies one common method of exchanging SAML-related information about system entities.

このプロファイルの相互運用可能な展開を実現するには、識別子、キー、およびエンドポイントに関するシステムエンティティ間の合意が必要です。同意が必要な具体的な項目は次のとおりです。発行者とオーディエンスの識別子の値、トークンエンドポイントの場所、アサーションに対するデジタル署名の適用と検証に使用されるキー、アサーションに対する1回限りの使用制限、許可される最大のアサーションライフタイム、およびアサーションの特定のサブジェクトと属性の要件。そのような情報の交換は、この仕様の範囲外であることは明白であり、その典型的な配備は、そのような情報を交換する手段をすでに確立している既存のSAML Web SSO配備と並行して行われます。「OASISセキュリティアサーションマークアップ言語（SAML）V2.0のメタデータ」[OASIS.saml-metadata-2.0-os]は、システムエンティティに関するSAML関連情報を交換する一般的な方法の1つを規定しています。

The RSA-SHA256 algorithm, from [RFC6931], is a mandatory-to-implement XML signature algorithm for this profile.

[RFC6931]のRSA-SHA256アルゴリズムは、このプロファイルの実装が必須のXML署名アルゴリズムです。

6. Security Considerations

6. セキュリティに関する考慮事項

The security considerations described within the following specifications are all applicable to this document: "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7521], "The OAuth 2.0 Authorization Framework" [RFC6749], and "Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0" [OASIS.saml-sec-consider-2.0-os].

次の仕様で説明されているセキュリティの考慮事項は、すべてこのドキュメントに適用されます。「OAuth 2.0クライアント認証および許可付与のアサーションフレームワーク」[RFC7521]、「OAuth 2.0許可フレームワーク」[RFC6749]、および「セキュリティとプライバシーに関する考慮事項OASIS Security Assertion Markup Language（SAML）V2.0 "[OASIS.saml-sec-consider-2.0-os]。

The specification does not mandate replay protection for the SAML Assertion usage for either the authorization grant or for client authentication. It is an optional feature, which implementations may employ at their own discretion.

仕様では、許可付与またはクライアント認証のいずれかのSAMLアサーションの使用に対するリプレイ保護を義務付けていません。これはオプション機能であり、実装は独自の裁量で使用できます。

7. Privacy Considerations

7. プライバシーに関する考慮事項

A SAML Assertion may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties, should only be transmitted over encrypted channels, such as Transport Layer Security (TLS). In cases where it is desirable to prevent disclosure of certain information to the client, the Subject and/or individual attributes of a SAML Assertion should be encrypted to the authorization server.

SAMLアサーションにはプライバシーに敏感な情報が含まれている可能性があり、意図しない関係者へのそのような情報の開示を防ぐために、トランスポート層セキュリティ（TLS）などの暗号化チャネルでのみ送信する必要があります。特定の情報がクライアントに開示されないようにすることが望ましい場合は、SAMLアサーションのサブジェクトまたは個々の属性、あるいはその両方を認証サーバーに暗号化する必要があります。

Deployments should determine the minimum amount of information necessary to complete the exchange and include only that information in an Assertion (typically by limiting what information is included in an <AttributeStatement> or by omitting it altogether). In some cases, the Subject can be a value representing an anonymous or pseudonymous user, as described in Section 6.3.1 of the OAuth Assertion Framework [RFC7521].

デプロイメントでは、交換を完了するために必要な最小限の情報を決定し、その情報のみをアサーションに含める必要があります（通常、<AttributeStatement>に含まれる情報を制限するか、完全に省略します）。場合によっては、OAuthアサーションフレームワーク[RFC7521]のセクション6.3.1で説明されているように、サブジェクトが匿名または偽名のユーザーを表す値になることがあります。

8. IANA Considerations

8. IANAに関する考慮事項

8.1.  Sub-Namespace Registration of
      urn:ietf:params:oauth:grant-type:saml2-bearer

This section registers the value "grant-type:saml2-bearer" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" [RFC6755].

このセクションは、「OAuthのIETF URNサブ名前空間」[RFC6755]によって確立されたIANA「OAuth URI」レジストリに値「grant-type：saml2-bearer」を登録します。

o URN: urn:ietf:params:oauth:grant-type:saml2-bearer

o URN：urn：ietf：params：oauth：grant-type：saml2-bearer

o Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0

o 一般名：OAuth 2.0のSAML 2.0ベアラーアサーション付与タイププロファイル

o Change Controller: IESG

o コントローラーの変更：IESG

o Specification Document: RFC 7522

o 仕様書：RFC 7522

8.2.  Sub-Namespace Registration of
      urn:ietf:params:oauth:client-assertion-type:saml2-bearer

This section registers the value "client-assertion-type:saml2-bearer" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" [RFC6755].

このセクションは、「Anauth for UAuth Sub-Namespace for OAuth」[RFC6755]によって確立されたIANA「OAuth URI」レジストリに値「client-assertion-type：saml2-bearer」を登録します。

o URN: urn:ietf:params:oauth:client-assertion-type:saml2-bearer

o URN：urn：ietf：params：oauth：client-assertion-type：saml2-bearer

o Common Name: SAML 2.0 Bearer Assertion Profile for OAuth 2.0 Client Authentication

o 一般名：OAuth 2.0クライアント認証用のSAML 2.0ベアラーアサーションプロファイル

o Change Controller: IESG

o コントローラーの変更：IESG

o Specification Document: RFC 7522

o 仕様書：RFC 7522

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March 2005, <http://docs.oasis-open.org/ security/saml/v2.0/saml-core-2.0-os.pdf>.

[OASIS.saml-core-2.0-os] Cantor、S.、Kemp、J.、Philpott、R.、and E. Maler、 "Assertions and Protocols for the OASIS Security Assertion Markup Language（SAML）V2.0"、 OASIS標準saml-core-2.0-os、2005年3月、<http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf>。

[OASIS.saml-deleg-cs] Cantor, S., Ed., "SAML V2.0 Condition for Delegation Restriction Version 1", Committee Specification 01, November 2009, <http://docs.oasis-open.org/ security/saml/Post2.0/sstc-saml-delegation-cs-01.html>.

[OASIS.saml-deleg-cs] Cantor、S.、Ed。、 "SAML V2.0 Condition for Delegation Restriction Version 1"、Committee Specification 01、November 2009、<http://docs.oasis-open.org/ security / saml / Post2.0 / sstc-saml-delegation-cs-01.html>。

[OASIS.saml-sec-consider-2.0-os] Hirsch, F., Philpott, R., and E. Maler, "Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-sec-consider-2.0-os, March 2005, <http://docs.oasis-open.org/security/saml/v2.0/ saml-sec-consider-2.0-os.pdf>.

[OASIS.saml-sec-consider-2.0-os] Hirsch、F.、Philpott、R。、およびE. Maler、「OASIS Security Assertion Markup Language（SAML）V2.0のセキュリティとプライバシーに関する考慮事項」、OASIS標準saml-sec-consider-2.0-os、2005年3月、<http://docs.oasis-open.org/security/saml/v2.0/ saml-sec-consider-2.0-os.pdf>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.

[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.

[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<http://www.rfc-editor.org/info/rfc4648>。

[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>.

[RFC6749] Hardt、D。、編、「The OAuth 2.0 Authorization Framework」、RFC 6749、DOI 10.17487 / RFC6749、2012年10月、<http://www.rfc-editor.org/info/rfc6749>。

[RFC6931] Eastlake 3rd, D., "Additional XML Security Uniform Resource Identifiers (URIs)", RFC 6931, DOI 10.17487/RFC6931, April 2013, <http://www.rfc-editor.org/info/rfc6931>.

[RFC6931] Eastlake 3rd、D。、「Additional XML Security Uniform Resource Identifiers（URIs）」、RFC 6931、DOI 10.17487 / RFC6931、2013年4月、<http://www.rfc-editor.org/info/rfc6931>。

[RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, May 2015, <http://www.rfc-editor.org/info/rfc7521>.

[RFC7521] Campbell、B.、Mortimore、C.、Jones、M。、およびY. Goland、「OAuth 2.0クライアント認証および許可付与のためのアサーションフレームワーク」、RFC 7521、DOI 10.17487 / RFC7521、2015年5月、<http： //www.rfc-editor.org/info/rfc7521>。

9.2. Informative References

9.2. 参考引用

[OASIS.WS-Fed] Goodner, M. and A. Nadalin, "Web Services Federation Language (WS-Federation) Version 1.2", OASIS Standard, May 2009, <http://docs.oasis-open.org/wsfed/ federation/v1.2/os/ws-federation-1.2-spec-os.html>.

[OASIS.WS-Fed] Goodner、M。およびA. Nadalin、「Webサービスフェデレーション言語（WS-Federation）バージョン1.2」、OASIS標準、2009年5月、<http://docs.oasis-open.org/wsfed / federation / v1.2 / os / ws-federation-1.2-spec-os.html>。

[OASIS.WSS-SAMLTokenProfile] Monzillo, R., Kaler, C., Nadalin, T., Hallam-Baker, P., and C. Milono, "Web Services Security SAML Token Profile Version 1.1.1", OASIS Standard, May 2012, <http://docs.oasis-open.org/wss-m/wss/v1.1.1/ wss-SAMLTokenProfile-v1.1.1.html>.

[OASIS.WSS-SAMLTokenProfile] Monzillo、R.、Kaler、C.、Nadalin、T.、Hallam-Baker、P.、and C. Milono、 "Web Services Security SAML Token Profile Version 1.1.1"、OASIS Standard、 2012年5月、<http://docs.oasis-open.org/wss-m/wss/v1.1.1/ wss-SAMLTokenProfile-v1.1.1.html>。

[OASIS.saml-metadata-2.0-os] Cantor, S., Moreh, J., Philpott, R., and E. Maler, "Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March 2005, <http://docs.oasis-open.org/security/saml/v2.0/ saml-metadata-2.0-os.pdf>.

[OASIS.saml-metadata-2.0-os] Cantor、S.、Moreh、J.、Philpott、R.、and E. Maler、 "Metadata for the OASIS Security Assertion Markup Language（SAML）V2.0"、OASIS Standard saml-metadata-2.0-os、2005年3月、<http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf>。

[OASIS.saml-profiles-2.0-os] Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard OASIS.saml-profiles-2.0-os, March 2005, <http://docs.oasis-open.org/security/saml/v2.0/ saml-profiles-2.0-os.pdf>.

[OASIS.saml-profiles-2.0-os] Hughes、J.、Cantor、S.、Hodges、J.、Hirsch、F.、Mishra、P.、Philpott、R.、and E. Maler、 "Profiles for the OASISセキュリティアサーションマークアップ言語（SAML）V2.0」、OASIS標準OASIS.saml-profiles-2.0-os、2005年3月、<http://docs.oasis-open.org/security/saml/v2.0/ saml -profiles-2.0-os.pdf>。

[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, <http://www.rfc-editor.org/info/rfc6755>.

[RFC6755] Campbell、B.およびH. Tschofenig、「An OTF URN Sub-Namespace for OAuth」、RFC 6755、DOI 10.17487 / RFC6755、2012年10月、<http://www.rfc-editor.org/info/rfc6755 >。

[W3C.REC-html401-19991224] Raggett, D., Hors, A., 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] Raggett、D.、Hors、A。、および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>。

Acknowledgements

謝辞

The following people contributed wording and concepts to this document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran Hammer, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten Lodderstedt, Susan Harper, Scott Tomilson, Scott Cantor, Hannes Tschofenig, David Waite, Phil Hunt, and Mukesh Bhatnagar.

次の人々がこの文書に文言と概念を寄稿しました：ポールマドセン、パトリックハーディング、ピーターモティコウスキー、エランハマー、ピーターサンタンドレ、イアンバーネット、エリックファゼンディン、トルステンロダーシュテット、スーザンハーパー、スコットトミルソン、スコットカンター、ハンネスツショフェニグ、デビッドウェイト、フィル・ハント、ムケシュ・バトナガール。

Authors' Addresses

著者のアドレス

Brian Campbell Ping Identity

ブライアンキャンベルピンアイデンティティ

   EMail: brian.d.campbell@gmail.com

Chuck Mortimore Salesforce.com

チャック・モーティモアSalesforce.com

   EMail: cmortimore@salesforce.com

Michael B. Jones Microsoft

マイケルB.ジョーンズマイクロソフト

   EMail: mbj@microsoft.com
   URI:   http://self-issued.info/