OpenID Federation 1.0

Workgroup:
OpenID Connect Working Group

Published:
17 February 2026

Status:
Final

Authors:
R. Hedberg, Ed.
independent
M.B. Jones
Self-Issued Consulting
A.Å. Solberg
Sikt
J. Bradley
Yubico
G. De Marco
independent
V. Dzhuvinov
Connect2id

Abstract

フェデレーションは、互いを信頼する当事者間の合意として表現できる。二者間フェデレーションでは、同じフェデレーションに属する2つの組織の間で直接の信頼を確立できる。多者間フェデレーションでは、二者間の合意が実用的でない場合があり、その場合は第三者によって信頼を媒介できる。これが本仕様で用いられるモデルである。

フェデレーション内の Entity は、相互作用する他の Entity が同じフェデレーションに属していることを信頼できなければならない。また、他の Entity が自らについて公開する情報が、輸送中に改ざんされておらず、フェデレーションのポリシーに従っていることも信頼できなければならない。

本仕様は、多者間フェデレーションを構築するための基本コンポーネントを定義する。また、それらを OpenID Connect および OAuth 2.0 の文脈に適用する方法も定義する。これらのコンポーネントは、信頼を確立する目的で、他のアプリケーション・プロトコルでも使用できる。

1. Introduction

本仕様は、相互にやり取りしたい2つの Entity が、Trust Anchor と呼ばれる信頼された第三者を介して、両者の間に信頼を確立する方法を記述する。Trust Anchor は、Entity についてのステートメントを発行することを主目的とする Entity である。アイデンティティ・フェデレーションは、本仕様を用い、1つ以上の権威レベルによって実現できる。権威の例としては、フェデレーション運用者、組織、組織内の部門、個別サイトが挙げられる。本仕様は、フェデレーションのような動的かつ分散した信頼ネットワークを作るために必要となる、基本的な技術的信頼インフラの構成要素を提供する。

本仕様は、フェデレーション内の Entity 同士が互いをどのように知るようになるか、という点のみに関心を持つことに注意すること。ある組織は、フェデレーション内で複数の Entity によって表現されてもよい。さらに、1つの Entity が複数のフェデレーションに属してもよい。2つの Entity が同じフェデレーションに属していると判断することが、本仕様において両者の間で信頼を確立する基礎である。

もちろん、「trust」という語は日常用法では、Entity とその行為の安全性、信頼性、完全性に対する信頼感も含む。この種の信頼は、過去の実績、セキュリティ認証、透明性のある運用実務といった経験的な証拠を通じて確立されることが多く、それらはセキュリティ標準の遵守および倫理的行動の実績を示す。明確にしておくと、この広い意味での trust は重要ではあるが、本仕様が達成する範囲を大きく超える。

以下は、2つの異なる Trust Anchor を根に持ち、一部のメンバーを共有する2つのフェデレーションの例である。すべての Entity は、少なくとも1つの共通 Trust Anchor を両者の間に持つことにより、他の任意の Entity と相互の信頼を確立できる。図では次の略語を用いる: OpenID Provider (OP)、Relying Party (RP)、Resource Server (RS)、Authorization Server (AS)。

.-----------------.            .-----------------.
|  Trust Anchor A |            |  Trust Anchor B |
'------.--.-------'            '----.--.--.------'
       |  |                         |  |  |
    .--'  '---. .-------------------'  |  |
    |         | |                      |  |
.---v.  .-----v-v------.   .-----------'  |
| OP |  | Intermediate |   |              |
'----'  '--.--.--.-----'   |    .---------v----.
           |  |  |         |    | Intermediate |
   .-------'  |  '------.  |    '---.--.--.----'
   |          |         |  |        |  |  |
.--v-.      .-v--.     .v--v.   .---'  |  '----.
| RP |      | RS |     | OP |   |      |       |
'----'      '----'     '----'   |   .--v-.   .-v--.
                                |   | RP |   | RP |
                                |   '----'   '----'
                                |
                        .-------v------.
                        | Intermediate |
                        '----.--.--.---'
                             |  |  |
                       .-----'  |  '----.
                       |        |       |
                    .--v-.   .--v-.   .-v--.
                    | OP |   | RP |   | AS |
                    '----'   '----'   '----'

Figure 1: Two Coexisting Federations with Some Members in Common

1.1. Requirements Notation and Conventions

本文書におけるキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」は、ここに示すようにすべて大文字で現れる場合に限り、BCP 14 [RFC2119] [RFC8174] に記述されたとおりに解釈される。

本仕様で使用される JSON Web Signature (JWS) [RFC7515] および JSON Web Encryption (JWE) [RFC7516] のデータ構造は、JWS Compact Serialization または JWE Compact Serialization を用いる。JWS JSON Serialization および JWE JSON Serialization は用いない。

1.2. Terminology

本仕様は、[JSON Web Token (JWT)] [RFC7519] で定義される「Claim」「Claim Name」「Claim Value」「JSON Web Token (JWT)」「JWT Claims Set」という用語、[OpenID Connect Core 1.0] [OpenID.Core] で定義される「OpenID Provider (OP)」「Relying Party (RP)」という用語、ならびに [OAuth 2.0] [RFC6749] で定義される「Authorization Endpoint」「Authorization Server (AS)」「Client」「Client Authentication」「Client Identifier」「Client Secret」「Protected Resource」「Redirection URI」「Refresh Token」「Resource Server (RS)」「Token Endpoint」という用語を用いる。

本仕様はさらに次の用語を定義する:

Entity

文脈の中で識別でき、独立した明確な存在として区別できるもの。

Entity Identifier

1つの Entity に束縛された、グローバルに一意な文字列識別子。本仕様で定義されるすべての Entity Identifier は、https スキームを用いる URL であり、host 要素を持ち、port および path 要素を含んでもよい。query parameter または fragment 要素を含んではならない。Profiles は、他種の Entity Identifier と、それに付随する処理規則を定義してもよい。

Trust Anchor

信頼された第三者を表す Entity。

Federation Entity

その Entity から Trust Anchor までの Trust Chain を構築できる Entity。

Entity Statement

Entity がフェデレーションに参加するために必要な情報（自身の metadata、および、それが権威を持つ他の Entity に適用されるポリシーを含む）を含む、署名付き JWT。

Entity Configuration

Entity が自分自身について発行する Entity Statement。Entity の署名鍵と、authority hints のように Trust Chain 解決プロセスを制御するために用いられる追加データを含む。

Subordinate Statement

Superior Entity が、自身の Immediate Subordinate である Entity について発行する Entity Statement。

Entity Type

フェデレーション内で Entity が果たす役割と機能。Entity は少なくとも1つの type を持たなければならず、複数の type を持ってもよい。たとえば、Entity は同時に OpenID Provider と Relying Party の両方であり得る。

Entity Type Identifier

Entity Type のための文字列識別子。

Federation Operator

フェデレーションに対して権威を持つ組織。federation operator は、そのフェデレーション内の Entity のために Trust Anchor を管理する。

Intermediate Entity

Trust Chain の subject（通常は Leaf Entity）と Trust Anchor の間のどこかに位置し、Entity Statement を発行する Entity。本仕様では Intermediate Entity と Intermediate を同義として用いる。

Leaf Entity

Subordinate Entities を持たない Entity。Leaf Entities は通常、OpenID Connect Relying Party や OpenID Provider のようなプロトコル上の役割を担う。本仕様では Leaf Entity と Leaf を同義として用いる。

Subordinate Entity

信頼階層において Superior Entity（Trust Anchor または Intermediate）の下に位置する Entity。両者の間に Intermediates が存在してもよい。本仕様では Subordinate Entity と Subordinate を同義として用いる。

Superior Entity

信頼階層において、1つ以上の Entity（Leaf または Intermediate）の上に位置する Entity。両者の間に Intermediates が存在してもよい。本仕様では Superior Entity と Superior を同義として用いる。

Immediate Subordinate Entity

信頼階層において、Superior Entity の直下に位置し、その間に Intermediates が存在しない Entity。本仕様では Immediate Subordinate Entity と Immediate Subordinate を同義として用いる。

Immediate Superior Entity

信頼階層において、1つ以上の Subordinate Entities の直上に位置し、その間に Intermediates が存在しない Entity。本仕様では Immediate Superior Entity と Immediate Superior を同義として用いる。

Federation Entity Discovery

Trust Chain の subject の Entity Identifier から開始し、選択された Trust Anchor に到達するまで Entity Statements を収集するプロセス。収集した Entity Statements から Trust Chain を構築し検証する。Federation Entity Discovery の結果として、Trust Chain から Trust Chain subject の metadata が構築される。

Trust Chain

チェーンの subject（通常は Leaf Entity）の Entity Configuration から始まり、Trust Anchor で終わる、Entity Statements の列。

Trust Mark

認定機関によって定められた、十分に範囲が限定された信頼要件および／または相互運用性要件の集合に対する適合の表明。各 Trust Mark は Trust Mark type identifier を持つ。

Trust Mark Issuer

Trust Mark を発行する Federation Entity。

Trust Mark Owner

Trust Mark type identifier に対する権利を所有する Entity。

Federation Entity Keys

本仕様で定義される信頼メカニズムが要求する暗号学的署名のために用いられる鍵。フェデレーション参加者は、それぞれの Entity Configuration に公開 Federation Entity Keys を公開する。

Resolved Metadata

Trust Chain の metadata policy を、Trust Chain subject の Entity Configuration 内の metadata に適用した結果として得られる metadata。Resolved Metadata は、Entity と相互作用する際に用いられる metadata である。

2. Overall Architecture

基本コンポーネントは Entity Statement であり、これは暗号学的に署名された [JSON Web Token (JWT)] [RFC7519] である。Entity Statements の集合は、Entity（通常は Leaf Entity）から Trust Anchor までの経路を形成できる。Entity が自分自身について発行する Entity Configurations は、Trust Chain 解決プロセスを制御する。

Leaf または Intermediate Entity の Entity Configuration には、[Section 3.1.2] で説明される authority_hints パラメータにおいて、その Immediate Superiors への1つ以上の参照が含まれる。これらの参照は、各 Immediate Superior の Entity Configuration をダウンロードするために使用できる。Trust Anchor に到達するまで、Federation Entity Discovery の間に1つ以上の Entity Configurations をたどる。

Trust Anchor とその Intermediates は、Immediate Subordinate Entities についての Entity Statements を発行し、これを Subordinate Statements と呼ぶ。Superior と Subordinate の関係を検証する Entity Configurations と Subordinate Statements の列が、Trust Anchor に向かう経路に沿って並ぶことで、Trust Chain の subject（通常は Leaf Entity）が、その Trust Anchor を根とするフェデレーションのメンバーであることの証明を構成する。

Entity Configurations 同士を結び付ける Trust Chain は、[Section 4] に記述されるとおり、各 Entity Configuration の署名によって検証される。

検証済み Trust Chain が得られたら、[Section 6] に記述されるとおりフェデレーションのポリシーを適用し、フェデレーション内における Trust Chain subject の metadata を導出する。

本仕様は信頼オペレーションを扱うものであり、metadata の導出と交換以外のプロトコル・オペレーションは対象外であり、触れない。OpenID Connect の用語で言えば、これらは [OpenID Connect Discovery 1.0] [OpenID.Discovery] および [OpenID Connect Dynamic Client Registration 1.0] [OpenID.Registration] で規定されるプロトコル・オペレーションである。

本仕様の例の多くでは OpenID Connect の構成要素が用いられるが、これは本仕様が OpenID Connect にしか使えないことを意味しない。逆に、他のプロトコルのためのフェデレーションを構築するためにも使用できる。

2.1. Cryptographic Trust Mechanism

本仕様で定義され、参加者間で暗号学的な信頼を確立するために使用されるオブジェクトは、公開鍵暗号により署名付き JWT として保護される。特に、これらのオブジェクトを保護するために用いる鍵は、そのオブジェクトを管理する Entity によって管理され、保護に用いる公開鍵は、それらのオブジェクト自体を通じて配布される。この種の信頼メカニズムは、研究・学術系フェデレーションで10年以上にわたって利用されてきた。

この暗号学的信頼メカニズムは、署名鍵のために Web PKI / TLS [RFC9525] 証明書に依存しないよう、意図的に設計されている。どの TLS 証明書を信頼するかは、どの認証局を信頼するかによってシステム間で大きく異なり、表向き信頼された証明書が侵害された著名な例もある。これらの理由により、本仕様は Web PKI への依存を明示的に避け、自己管理される公開鍵に依拠する。ここでは、その鍵は JSON Web Keys (JWKs) [RFC7517] として表現される。

3. Entity Statement

Entity Statement は、Entity Statement の subject である Entity がフェデレーションに参加するために必要な情報を含む。Entity Statement は署名付き JWT である。JWT の subject は Entity 自身である。JWT の issuer は Entity Statement を発行した当事者である。フェデレーション内のすべての Entity は、自分自身についての Entity Statement（Entity Configuration と呼ぶ）を公開する。フェデレーション内の Superior Entities は、Immediate Subordinate Entities についての Entity Statements（Subordinate Statements と呼ぶ）を公開する。

Entity Statement JWT は、[RFC8725] の Section 3.11 に従い、クロス JWT の混同を防ぐために明示的な型付けが必須であり、typ ヘッダーパラメータを entity-statement+jwt に設定しなければならない。typ ヘッダーパラメータがない Entity Statement、または異なる typ 値を持つ Entity Statement は拒否しなければならない。

Entity Statement は、issuer Entity の秘密鍵のいずれかを用いて [JSON Web Signature (JWS)] [RFC7515] として署名される。実装は、OpenID Connect Core がサポートを要求する（alg 値が RS256 である）RSA SHA-256 アルゴリズムによる署名検証をサポートすることが推奨される。フェデレーションは、別の実装必須アルゴリズムを指定してもよい。Trust Chain には、異なる署名アルゴリズムで署名された Entity Statements が含まれてもよいが、各署名が、使用される信頼フレームワークおよび実装でサポートされる署名アルゴリズムを用いる限りにおいてである。

Entity Statement JWT は、使用した署名鍵の Key ID を値とする kid (Key ID) ヘッダーパラメータを必ず含めなければならない。

3.1. Entity Statement Claims

Entity Statement における Claims を以下に示す。Entity Statements を利用するアプリケーションおよびプロトコルは、追加の Claims を指定し使用してもよい。

3.1.1. Claims that MUST or MAY Appear in both Entity Configurations and Subordinate Statements

iss

REQUIRED. Entity Statement の issuer の Entity Identifier。iss と sub が同一である場合、issuer は自分自身についての Entity Statement（Entity Configuration と呼ぶ）を作成している。

sub

REQUIRED. subject の Entity Identifier。

iat

REQUIRED. 数値。ステートメントが発行された時刻。[RFC7519] に従い、Seconds Since the Epoch で表す。

exp

REQUIRED. 数値。この時刻以降、ステートメントは処理のために受理してはならない。[RFC7519] に従い、Seconds Since the Epoch で表す。

jwks

REQUIRED. subject の Federation Entity の署名鍵の公開部分を表す [JSON Web Key Set (JWKS)] [RFC7517]。対応する秘密鍵は、Entity が自分自身についての Entity Configuration に署名するため、Trust Anchors および Intermediate Entities が Immediate Subordinates についての Subordinate Statements に署名するため、ならびに Trust Mark の署名など Federation Entities による他の署名のために使用される。ただし、[Section 12.2.3] で定義される Explicit Registration Response として返される Entity Statement については、この claim は OPTIONAL であり、それ以外のすべての場合は REQUIRED である。JWK Set 内の各 JWK は、一意な kid (Key ID) 値を持たなければならない。Key ID は、鍵の SHA-256 ハッシュ関数を用いた JWK Thumbprint [RFC7638] とすることが推奨される。

これらの Federation Entity Keys は、他のプロトコルでは使用すべきではない。（OpenID Connect など他のプロトコルで使用される鍵は、そのプロトコルの Entity Type Identifier の metadata 要素で伝達される。たとえば openid_provider および openid_relying_party の Entity Type Identifiers の下にある metadata がそれに該当する。）

metadata

OPTIONAL. Entity が担う役割（Entity Types）を宣言し、それらの Entity Types の metadata を含む JSON オブジェクト。JSON オブジェクトの各メンバー名は Entity Type Identifier であり、各値は、当該 Entity Type の metadata スキーマに従った metadata パラメータを含む JSON オブジェクトでなければならない。

Entity が、1つ以上の Entity Types を伴って1つ以上のフェデレーションに参加する場合、その Entity の Entity Configuration には、対応する各 Entity Type Identifiers ごとに JSON オブジェクト値を持つ metadata Claim を含めなければならない。値が空の JSON オブジェクト {} であっても同様である（当該 Entity Type に関連する metadata がない場合、または Immediate Superiors が必要な metadata を供給する場合）。

Immediate Superior は、Subordinate Statement において metadata Claim を用いることで、Immediate Subordinate の一部またはすべての metadata パラメータを提供してもよい。Subordinate Statement で metadata が用いられる場合、それは subject の Entity Configuration に存在する Entity Types にのみ適用される。さらに、その metadata は Subordinate Statement の subject にのみ適用され、subject の Subordinates には影響しない。Subordinate Statement 内の metadata パラメータは優先され、subject の Entity Configuration 内で同一 Entity Type の下にある同名のパラメータを上書きする。Subordinate Statement に metadata と metadata_policy の両方が現れる場合、[Section 6.1.4.2] に記述されるとおり、表明された metadata は metadata_policy より先に適用しなければならない。

crit

OPTIONAL. Entity Statements は、[Section 13.4] で定義される crit（critical）Claim が理解され処理されることを要求する。この Claim の値である配列に含まれる Claim Names を持つ Entity Statement 内の Claims は、理解され処理されなければならない。本仕様が Entity Statements での使用を規定する Claims は、このリストに含めてはならない。

3.1.2. Claims that MUST or MAY Appear in Entity Configurations but Not in Subordinate Statements

authority_hints

OPTIONAL. Entity の Immediate Superiors である Intermediate Entities または Trust Anchors の Entity Identifiers を表す文字列の配列。この Claim は、Leaf や Intermediate Entities のように、自身の上に少なくとも1つの Superior を持つ Entity の Entity Configurations において REQUIRED である。値には Immediate Superiors の Entity Identifiers を含めなければならず、空配列 [] であってはならない。Superiors を持たない Trust Anchors の Entity Configurations には、この Claim が存在してはならない。

trust_anchor_hints

OPTIONAL. Entity が信頼する Trust Anchors の Entity Identifiers を表す文字列の配列。値は空配列 [] であってはならない。Superiors を持たない Trust Anchors の Entity Configurations には、この Claim が存在してはならない。

trust_marks

OPTIONAL. Trust Mark を表す JSON オブジェクトの配列。各要素が1つの Trust Mark を表す。

trust_mark_type

REQUIRED. Trust Mark の type の識別子。この Claim の値は、このオブジェクト内の trust_mark Claim の値である Trust Mark JWT に含まれる trust_mark_type Claim の値と同一でなければならない。

trust_mark

REQUIRED. Trust Mark を表す署名付き JSON Web Token。

Trust Marks は [Section 7] で記述される。

trust_mark_issuers

OPTIONAL. Trust Anchor は、この Claim を用いて、フェデレーションが信頼する Trust Mark type identifiers と issuers の組み合わせを伝えてもよい。Trust Anchor ではない Entity の Entity Configuration に存在する場合、この Claim は無視しなければならない。これは JSON オブジェクトであり、メンバー名は Trust Mark type identifiers、各値は、その identifier の Trust Marks について認定機関を表すことを信頼された Entity Identifiers の配列である。ある Trust Mark type identifier に続く配列が空である場合、誰でもその identifier の Trust Marks を発行してよい。Trust Marks は [Section 7] で記述される。

trust_mark_owners

OPTIONAL. Federation Operator が、Trust Mark type identifier が Trust Mark Issuer とは異なる Entity によって所有されていることを知っている場合、その知識はこの Claim で表現しなければならない。Trust Anchor ではない Entity の Entity Configuration に存在する場合、この Claim は無視しなければならない。これは JSON オブジェクトであり、メンバー名は Trust Mark type identifiers、各値は次のメンバーを含む JSON オブジェクトである:

sub

REQUIRED. Trust Mark Owner の識別子。

jwks

REQUIRED. 署名に用いられる owner の Federation Entity Keys を含む [JSON Web Key Set (JWKS)] [RFC7517]。

他のメンバーも定義され、使用されてもよい。

3.1.3. Claims that MUST or MAY Appear in Subordinate Statements but Not in Entity Configurations

constraints

OPTIONAL. [Section 6.2] で記述される Trust Chain constraints を定義する JSON オブジェクト。constraints は、この Subordinate Statement の subject である Entity に適用されるだけでなく、それに Subordinate であるすべての Entities にも適用される。

metadata_policy

OPTIONAL. [Section 6.1] で記述される metadata policy を定義する JSON オブジェクト。metadata policy は、この Subordinate Statement の subject である Entity に適用されるだけでなく、それに Subordinate であるすべての Entities にも適用される。Subordinate Entities にまで適用される点が、subject 自身にのみ適用される metadata と metadata_policy を区別する。

metadata_policy_crit

OPTIONAL. [Section 6.1.3.1] で定義される標準のもの以外で、理解され処理されなければならない critical metadata policy operators を指定する文字列の配列。含める場合、値は空配列 [] であってはならない。列挙された policy operators のいずれかが理解・サポートされない場合、その Subordinate Statement、ひいてはそれを含む Trust Chain は無効と見なされなければならない。

source_endpoint

OPTIONAL. [Section 8.1] で規定される、Entity Statement が発行された fetch endpoint URL を含む文字列。このパラメータは、発行権限の federation_fetch_endpoint を発見するために通常必要となる Entity Configuration へのリクエストを省略することで、Subordinate Statements、ひいては Trust Chain の最適化された更新（refresh）を可能にする。endpoint URL が変更された場合などに source_endpoint から Entity Statement を取得できないときは、issuer の Entity Configuration を取得することで、現在の federation_fetch_endpoint の場所を決定できる。

3.1.4. Claims Used in Explicit Registration Requests

aud

OPTIONAL. aud（audience）の値は OP の Entity Identifier でなければならず、他の値を含んではならない。この Claim は Explicit Registration リクエストで使用されるものであり、一般的な Entity Statement Claim ではない。

3.1.5. Claims Used in Explicit Registration Responses

aud

OPTIONAL. aud（audience）の値は RP の Entity Identifier でなければならず、他の値を含んではならない。この Claim は Explicit Registration レスポンスで使用されるものであり、一般的な Entity Statement Claim ではない。

trust_anchor

OPTIONAL. 値は、OP が Explicit Registration リクエストを処理するために選択した Trust Anchor の Entity Identifier でなければならない（[Section 12.2.3] で規定される）。この Claim は Explicit Registration レスポンスに特有であり、一般的な Entity Statement Claim ではない。

3.2. Entity Statement Validation

Entity Statements は以下の方法で検証しなければならない。結果（Entity Statement を受理するか拒否するか）が同じである限り、これらの手順は異なる順序で実行してもよい。

Entity Statement は署名付き JWT でなければならない。
Entity Statement は、値が entity-statement+jwt である typ ヘッダーパラメータを持たなければならない。
Entity Statement は、受理可能な JWS 署名アルゴリズムである値を持つ alg（algorithm）ヘッダーパラメータを持たなければならず、none であってはならない。
Entity Statement が参照する Entity の Entity Identifier は、sub（subject）Claim の値と一致しなければならない。
Entity Statement は、有効な Entity Identifier を値とする iss（issuer）Claim を持たなければならない。
iss（issuer）Claim Value が sub（subject）Claim Value と一致する場合、その Entity Statement は当該 Entity の Entity Configuration である。一致しない場合、その Entity Statement は Subordinate Statement である。Entity Statement が Subordinate Statement の場合、iss Claim Value は、sub Claim の値である Entity Identifier を持つ Entity の Entity Configuration にある authority_hints 配列の値のいずれかと一致しなければならない。そうでなければ Federation グラフは well-formed ではない。
現在時刻は、iat（issued at）Claim が表す時刻より後でなければならない（時計のずれを考慮して小さな猶予を認めてもよい）。
現在時刻は、exp（expiration）Claim が表す時刻より前でなければならない（時計のずれを考慮して小さな猶予を認めてもよい）。
jwks（JWK Set）Claim は必ず存在しなければならず、その値は有効な JWK Set [RFC7517] でなければならない。
発行 Entity の Entity Configuration を取得する。これは、Entity Statement の iss（issuer）Claim に見つかった Issuer Identifier を持つ Entity の Entity Configuration である。iss と sub の Claim Values が一致する場合、これは検証対象の Entity Statement 自身である。そうでない場合、Trust Chain から取得するか、または [Section 9] に記述されるとおりに取得できる。
Entity Statement の kid（Key ID）ヘッダーパラメータ値は、長さ0ではない文字列でなければならず、発行 Entity の Entity Configuration の jwks（JWK Set）Claim にある鍵の kid 値と完全一致しなければならない。
Entity Statement の署名は、kid 値で識別される発行 Entity の鍵を用いて検証できなければならない。
crit Claim が存在する場合、この Claim の値に含まれる各配列要素は、本仕様で定義されていない Entity Statement Claim を表す文字列でなければならず、その Claim は実装によって理解され処理可能でなければならない。
authority_hints Claim が存在する場合、Entity Statement は Entity Configuration でなければならない。その値が [Section 3.1.2] で規定されるとおりに構文的に正しいことを検証する。実装はさらに、Entity が authority_hints 配列に列挙された各 Entity Identifier の Entity の Subordinate であることを検証してもよい。
trust_anchor_hints Claim が存在する場合、Entity Statement は Entity Configuration でなければならない。その値が [Section 3.1.2] で規定されるとおりに構文的に正しいことを検証する。
metadata Claim が存在する場合、その値が構文的に正しく、metadata 値として null を使用していないことを、[Section 5] の規定に従って検証する。
metadata_policy Claim が存在する場合、Entity Statement は Subordinate Statement でなければならない。その値が [Section 6.1] の規定に従って構文的に正しいことを検証する。
metadata_policy_crit Claim が存在する場合、Entity Statement は Subordinate Statement でなければならない。この Claim の値に含まれる各配列要素は、本仕様で定義されていない Metadata Policy operator を表す文字列でなければならず、その operator は実装によって理解され処理可能でなければならない。
constraints Claim が存在する場合、Entity Statement は Subordinate Statement でなければならない。その値が [Section 6.2] の規定に従って構文的に正しいことを検証する。
trust_marks Claim が存在する場合、Entity Statement は Entity Configuration でなければならない。この Claim Value の構文が Claim 定義に適合することを検証する。特に、Claim Value である配列の各要素について、trust_mark_type メンバーが存在し、その値が trust_mark メンバーの値である Trust Mark JWT における trust_mark_type Claim Value と一致することを検証する。構文の検証は、特定の Trust Marks が信頼された当事者によって発行されており信頼されるかどうかの評価とは別である。そのプロセスは [Section 7.3] に記述され、構文検証とは別ステップとして実施してもよい。
trust_mark_issuers Claim が存在する場合、Entity Statement は Entity Configuration でなければならない。その Claim Value が、メンバー名が Trust Mark type identifiers、値が Entity Identifiers の配列である JSON オブジェクトであることを検証する。
trust_mark_owners Claim が存在する場合、Entity Statement は Entity Configuration でなければならない。その Claim Value が、メンバー名が Trust Mark type identifiers、値が sub メンバー（値が Entity Identifier）および jwks メンバー（値が JSON Web Key Set）を含む JSON オブジェクトであることを検証する。
source_endpoint Claim が存在する場合、Entity Statement は Subordinate Statement でなければならない。その Claim Value が URL であることを検証する。実装はさらに、URL に fetch 呼び出しを行い、これが Entity Statement が発行された fetch endpoint であることを検証してもよい。
trust_chain ヘッダーパラメータが存在する場合、その値が [Section 4] で規定されるとおりに、構文的に有効な Trust Chain であることを検証する。Trust Chain の最初のエントリは、この Entity の Entity Configuration でなければならない。実装は、Trust Chain の末尾にある Trust Anchor の Entity Identifier が、デプロイに設定された Trust Anchors のいずれかと一致することを検証すべきである。
peer_trust_chain ヘッダーパラメータが存在する場合、その値が [Section 4] で規定されるとおりに、構文的に有効な Trust Chain であることを検証する。実装は、Trust Chain の末尾にある Trust Anchor の Entity Identifier が、デプロイに設定された Trust Anchors のいずれかと一致することを検証すべきである。
aud Claim が存在する場合、Entity Statement が Explicit Registration リクエストなら値が OP の Entity Identifier であることを、Explicit Registration レスポンスなら値が RP の Entity Identifier であることを検証する。本 Claim は、拡張仕様で別途規定されていない限り、Explicit Registration リクエスト／レスポンスではない Entity Statements に存在してはならない。
trust_anchor Claim が存在する場合、その値が https スキームを用いる URL であることを検証する。実装は、Entity Identifier がデプロイに設定された Trust Anchors のいずれかと一致することを検証すべきである。さらに実装は、その Entity Identifier の Entity Configuration が、設定された Trust Anchor 情報（特に鍵）と整合する情報を含むことを検証すべきである。本 Claim は、拡張仕様で別途規定されていない限り、Explicit Registration レスポンスではない Entity Statements に存在してはならない。

これらの検証手順のいずれかが失敗した場合、Entity Statement は拒否しなければならない。

3.3. Entity Statement Example

以下は、Entity Statement の JWT Claims Set の非規範的な例である。この例には、Entity Statement に対する critical extension jti（JWT ID）と、ポリシー言語に対する1つの critical extension regexp（Regular expression）が含まれる。

{
  "iss": "https://feide.no",
  "sub": "https://ntnu.no",
  "iat": 1516239022,
  "exp": 1516843822,
  "jwks": {
    "keys": \[
      {
        "kty": "RSA",
        "alg": "RS256",
        "use": "sig",
        "kid": "NzbLsXh8uDCcd-6MNwXF4W\_7noWXFZAfHkxZsRGC9Xs",
        "n": "vHOJrp-zLST7FwvzAwelR9Vo...",
        "e": "AQAB"
      }
    \]
  },
  "metadata": {
    "openid\_provider": {
      "issuer": "https://ntnu.no",
      "organization\_name": "NTNU"
    },
    "oauth\_client": {
      "organization\_name": "NTNU"
    }
  },
  "metadata\_policy": {
    "openid\_provider": {
      "id\_token\_signing\_alg\_values\_supported":
        {"subset\_of": \["RS256", "RS384", "RS512"\]},
      "op\_policy\_uri": {
        "regexp":
          "^https:\\/\\/\[\\\\w-\]+\\\\.example\\\\.com\\/\[\\\\w-\]+\\\\.html"}
    },
    "oauth\_client": {
      "grant\_types": {
        "one\_of": \["authorization\_code", "client\_credentials"\]
      }
    }
  },
  "constraints": {
    "max\_path\_length": 2
  },
  "crit": \["jti"\],
  "metadata\_policy\_crit": \["regexp"\],
  "source\_endpoint": "https://feide.no/federation\_api/fetch",
  "jti": "7l2lncFdY6SlhNia"
}

Figure 2: Example Entity Statement JWT Claims Set

4. Trust Chain

ステートメントによって Trust Chain を構成する Entities は、次のように分類される:

Trust Anchor

信頼された第三者を表す Entity。

Leaf

Subordinate Entities を持たない Entity。通常はプロトコル上の役割を担う。たとえば、OpenID Connect のアイデンティティ・フェデレーションでは RP または OP、OAuth 2.0 のフェデレーションでは Client、Authorization Server、または Protected Resource。

Intermediate

Leaf Entity でも Trust Anchor でもないもの。

Trust Chain は、Trust Chain の subject である Entity Configuration から始まり、これは通常 Leaf Entity である。Trust Chain は、Intermediates が Immediate Subordinates について発行する Subordinate Statements を0個以上持ち、Trust Anchor が最上位 Intermediate（Intermediates がある場合）または Trust Chain subject（Intermediates がない場合）について発行する Subordinate Statement を含む。Trust Chain は論理的には常に Trust Anchor の Entity Configuration で終わるが、場合によっては Trust Chain を表す JSON 配列から省略してもよい。

Trust Chain は、チェーン評価時点において Trust Chain subject に適用されるフェデレーションの構成を含む。

単純な例: Federation F のメンバーである Organization A に属する RP がある場合、そのセットアップにおける Trust Chain は次の Entity Statements を含む:

RP 自身が公開する、RP についての Entity Configuration
Organization A が公開する、RP についての Subordinate Statement
F の Trust Anchor が公開する、Organization A についての Subordinate Statement
Trust Anchor 自身が公開する、F の Trust Anchor についての Entity Configuration

Trust Chain 内の Entity Statements を ES[j] と呼ぶことにする。ここで j = 0,...,i であり、0 は最初の Entity Statement のインデックス、i は最後の Entity Statement の0始まりインデックスである。すると:

ES[0]（Trust Chain subject の Entity Configuration）は、ES[0]["jwks"] にある鍵を用いて署名される。
Entity Statement の iss Claim は次のものの sub Claim に等しい。記号的に言い換えると、各 j = 0,...,i-1 について、ES[j]["iss"] == ES[j+1]["sub"]。
Entity Statement は次のものの jwks Claim にある鍵を用いて署名される。記号的に言い換えると、各 j = 0,...,i-1 について、ES[j] は ES[j+1]["jwks"] にある鍵で署名される。
ES[i]（Trust Chain 内の Trust Anchor の Entity Configuration）は、ES[i]["jwks"] にある鍵を用いて署名される。

Trust Anchor の公開鍵は、ES[i]（Trust Anchor の Entity Configuration）および ES[i-1]（Trust Chain 内で Trust Anchor が Immediate Subordinate について発行する Subordinate Statement）の署名検証に用いられる。Trust Chain を検証する必要がある Entities へ Trust Anchor の公開鍵を配布する方法は、本文書では記述しない、安全な out-of-band の方法である。

4.1. Beginning and Ending Trust Chains

Trust Chain は、信頼を確立しようとする Entity の Entity Configuration から始まる。これが Trust Chain の subject である。この Entity は通常、OpenID Provider や OpenID Relying Party のようなプロトコル上の役割を担う。

このような Entities は通常 Leaf Entities であるが、他のトポロジも可能である。たとえば、ある Entity が同時に OpenID Provider と Intermediate Entity であり、OpenID Relying Parties や他の Intermediates がそれに Subordinate である場合がある。これは、Trust Chain の subject が Leaf Entity ではないケースである。

Trust Chain は Trust Anchor の Entity Configuration で終わる。Trust Anchors は通常 Superiors を持たないが、Trust Anchor が別のフェデレーションにおいて Intermediate Entity としても振る舞う場合には Superior を持つ。このことは、フェデレーションの階層が存在する場合に起こる。

したがって、Trust Chain が Superiors を持たない Trust Anchor で終わるのが典型ではあるが、Trust Chain が、Superiors を持つにもかかわらず Trust Anchor である Entity で終わる状況も存在する。

4.2. Trust Chain Example

以下は、Leaf の Entity Configuration と、Intermediate Entity および Trust Anchor が発行する Subordinate Statements からなる Trust Chain の例である。これは、3つの Entities の関係、それらの Entity Configurations、ならびにそれらの Subordinate Statements を示す。Subordinate Statements は、subject の Immediate Superior の federation_fetch_endpoint から取得される。federation_fetch_endpoint の URL は、Immediate Superior の Entity Configuration で発見される。Trust Chain の最初のメンバー（Leaf）は図の下部に、最後のメンバー（Trust Anchor）は図の上部に描かれていることに注意すること。

.----------------.  .---------------------------.         .---------------------------.
| Role           |  | .well-known/              |         | Trust Chain               |
|                |  | openid-federation         |         |                           |
.----------------.  .---------------------------.         .---------------------------.
| .------------. |  | .-----------------------. |         | .-----------------------. |
| |            | |  | | Entity Configuration  | |         | | Entity Configuration  | |
| |Trust Anchor+-+--+->                       +-+---------+->                       | |
| |            | |  | | Federation Entity Keys| |         | | Federation Entity Keys| |
| '-----.------' |  | | Metadata              | |         | | Metadata              | |
|       |        |  | | Trust Mark Issuers    | |         | | Trust Mark Issuers    | |
|       |        |  | |                       | |         | |                       | |
|       |        |  | '-----------------------' |         | '-----------------------' |
|       |        |  |                           |         |                           |
|       |        |  |                           |Fetch    | .-----------------------. |
|       |        |  |                           |Endpoint | | Subordinate Statement | |
|       +--------+--+---------------------------+---------+->                       | |
|                |  |                           |         | | Federation Entity Keys| |
|                |  |                           |         | | Metadata Policy       | |
|                |  |                           |         | | Metadata              | |
|                |  |                           |         | | Constraints           | |
|                |  |                           |         | |                       | |
|                |  |                           |         | '-----------.-----------' |
| .------------. |  | .-----------------------. |         |             |             |
| |            | |  | | Entity Configuration  | |         |             |             |
| |Intermediate+-+--+->                       | |         |             |sub and key  |
| |            | |  | | Federation Entity Keys| |         |             | binding     |
| '------.-----' |  | | Metadata              | |         | .-----------v-----------. |
|        |       |  | | Trust Marks           | |         | | Subordinate Statement | |
|        |       |  | |                       | |         | |                       | |
|        |       |  | |                       | |         | | Federation Entity Keys| |
|        |       |  | '-----------------------' |Fetch    | | Metadata Policy       | |
|        |       |  |                           |Endpoint | | Metadata              | |
|        +-------+--+---------------------------+---------+->                       | |
|                |  |                           |         | '-----------.-----------' |
|                |  |                           |         |             |sub and key  |
|                |  |                           |         |             | binding     |
| .------------. |  | .-----------------------. |         | .-----------v-----------. |
| |            | |  | | Entity Configuration  | |         | | Entity Configuration  | |
| | Leaf       +-+--+->                       +-+---------+->                       | |
| |            | |  | | Federation Entity Keys| |         | | Federation Entity Keys| |
| '------------' |  | | Metadata              | |         | | Metadata              | |
|                |  | | Trust Marks           | |         | | Trust Marks           | |
|                |  | |                       | |         | |                       | |
|                |  | |                       | |         | |                       | |
|                |  | '-----------------------' |         | '-----------------------' |
'----------------'  '---------------------------'         '---------------------------'

Figure 3: Relationships between Federation Entities and Statements Issued in a Trust Chain

4.3. Trust Chain Header Parameter

trust_chain JWS ヘッダーパラメータは、Entity と選択された Trust Anchor の間の Trust Chain を構成する Entity Statements の列を含む JSON 配列である。Trust Chain は通常、このヘッダーパラメータが現れる JWT の subject の Entity Configuration から始まる。しかし場合によっては、[Section 8.3.2] で定義される Resolve Response のように、issuer など別の Entity の Entity Configuration から始まる。JWT の issuer は、Trust Chain の先頭の Entity と JWT の audience が共通に持つ Trust Anchor を選ぶべきである。そうでなければ、issuer は使用する Trust Anchor を自由に選べる。

多くの署名付き JWT は、いくつかの例外を除き、trust_chain JWS ヘッダーパラメータを含んでもよい。Entity Configurations と Subordinate Statements は、Trust Chain の構成要素そのものであるため、trust_chain ヘッダーパラメータを含んではならない。このヘッダーパラメータの使用は OPTIONAL である。

以下は、trust_chain パラメータを持つ JWS ヘッダーの非規範的な例である。

{
  "typ": "...",
  "alg": "RS256",
  "kid": "SUdtUndEWVY2cUFDeDV5NVlBWDhvOXJodVl2am1mNGNtR0pmd",
  "trust_chain": \[
    "eyJ0eXAiOiJlbnRpdHktc3RhdGVtZW50K2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiWjBWRVdtUTRVVFJWZFhNeGRFVnRMVUl3VldWSVRVZDRhekpEVTBrdE5DMXdaWGR2TVRoWWJrTTRUUSJ9.eyJtZXRhZGF0YSI6IHsib3BlbmlkX2NyZWRlbnRpYWxfaXNzdWVyIjogeyJqd2tzIjogeyJrZXlzIjogW3sia3R5IjogIlJTQSIsICJraWQiOiAiUjJSelJYQTBSVkJ5ZHpGT1ZHMWZkV1JUTVRaM1lUUm1ObkUxVjNGZk1FMW9NVVpMZWtsaVkxTllPQSIsICJlIjogIkFRQUIiLCAibiI6ICI1SF9YaDd4Z0RXVHhRVmJKcW1PR3Vyb2tFOGtyMmUxS2dNV2NZT0E3NE9fMVBYZDJ1Z2p5SXE5dDFtVlBTdXd4LXR5U2syUEtwanAtLVdySG4zQTRVS0prdVIxMXpobWRMQnNVOFRPQkJ1NU1aOGF0RHVqZlJ3SUxYZEtzRVhrbHZhQjZQTFQ0emRab2RnQ3MwNUt5MmU1c2I1ejZfQ2lEcWdVVm5XUG1KTE1rZ3BCdFota01kX2xiOVNvb1psbGZVR2xUa3NhdUoyX2dWUS1WcEZVTVhZam9Kak54OTdldWthWW5SRW9DQzNUYV8tOGJjUm9zbHgyeHJJYnVfVUdWcWlwZU4zTlAtbWVmZjlWVFpXWU0zZ21vbHd1cG5NQ1hYaWlrY1I1VVNMVmcwZV9nejZPZm9SVkdLQVdJcFJSTFR6MmFpcXVrVkhaZFpYOXRObXowbXcifV19fSwgImZlZGVyYXRpb25fZW50aXR5IjogeyJvcmdhbml6YXRpb25fbmFtZSI6ICJPcGVuSUQgQ3JlZGVudGlhbCBJc3N1ZXIgZXhhbXBsZSIsICJvcmdhbml6YXRpb25fdXJpIjogImh0dHBzOi8vY3JlZGVudGlhbF9pc3N1ZXIuZXhhbXBsZS5vcmcvaG9tZSIsICJwb2xpY3lfdXJpIjogImh0dHBzOi8vY3JlZGVudGlhbF9pc3N1ZXIuZXhhbXBsZS5vcmcvcG9saWN5IiwgImxvZ29fdXJpIjogImh0dHBzOi8vY3JlZGVudGlhbF9pc3N1ZXIuZXhhbXBsZS5vcmcvc3RhdGljL2xvZ28uc3ZnIiwgImNvbnRhY3RzIjogWyJ0ZWNoQGNyZWRlbnRpYWxfaXNzdWVyLmV4YW1wbGUub3JnIl19fSwgImF1dGhvcml0eV9oaW50cyI6IFsiaHR0cHM6Ly9pbnRlcm1lZGlhdGUuZWlkYXMuZXhhbXBsZS5vcmciXSwgImp3a3MiOiB7ImtleXMiOiBbeyJrdHkiOiAiUlNBIiwgImtpZCI6ICJaMFZFV21RNFVUUlZkWE14ZEVWdExVSXdWV1ZJVFVkNGF6SkRVMGt0TkMxd1pYZHZNVGhZYmtNNFRRIiwgIm4iOiAib0FBcU9wcHc2U3drZzNMZTJESlIzMHh0ZzBuOENrNmtiTDhxMzViZFVGdVBrMDBZaUNLZE9sN2JHQzVGdlBuMnIyZ2lfQkZ3djhscHdreU1ObnJYMHczd0hXTUtVMmdwWEpxLVNnZGVyQXVQZmxHQzgxY04tTGhJM04tQmQwcjF1YThCVktGeXFWdkNpcms3YWNGeVdQa2ZPcGstbTRlVG4tcmtNMzREMUZ1VFdOUDctZXp6T1g3OWx2YXJBVGl5S1Jva205WGRYN05pQ1hPNnkzSDhjRV9BUVE5a2JvSmxkNklHb3gwUFY3dVFvczlkWURlLTFaWDFzWDhKaklMT2IwTDVBeC1VOHI5V3lIX0VkUXVEVW9QMzZMdFN1YlBYaGo5NVpUa0ZrZnhZd3NHUWxmMjJRVmFQWVh1VnVlSmJtejZ1Zk5NSXBpNG1LaDU3Q2JtcmN3IiwgImUiOiAiQVFBQiJ9XX0sICJzdWIiOiAiaHR0cHM6Ly9jcmVkZW50aWFsX2lzc3Vlci5leGFtcGxlLm9yZyIsICJpc3MiOiAiaHR0cHM6Ly9jcmVkZW50aWFsX2lzc3Vlci5leGFtcGxlLm9yZyIsICJpYXQiOiAxNzY3NzEwOTg0LCAiZXhwIjogMTc2ODAxMDk4NH0.KmJD9GmgRppKSX9kqoDVrZHb4nD7W0wvPJru3Iz4U6y-o5IMqlOxtq4LGDYRi2s7qsSCBn8qz1NIADuLnkc9IWAP5CUPXrnhAmqNBI05KqMdVIb\_y0RtDwY7YK0fpBubxCcCiwaZBlTPHGBY72oRnUq3ZU4bOZ9LKNvqBxe9zINMUzCIykh7JUaeMCPP3RW0jBYSjkJwFu-uDKTztVRYTpzmblxTOXGO8djsjruIsNoRiM5uaiUL\_JLiaJPZdQWorKa-PH9RRjTtB88hDSbL7We9oKlRLnOLCG4r6OJoJ1mqDRpbraYz\_RsFqT9IXy5y5hmVcHS0Gc94BSfcgxVxDg",
    "eyJ0eXAiOiJlbnRpdHktc3RhdGVtZW50K2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiYTB0cmVuUmhMWEV5ZUROWmFEa3lXRzQxTmtFMFUyWlNTVWxTUTA0M05rRm5NVkJsWVhWQ1FqVlhhdyJ9.eyJzdWIiOiAiaHR0cHM6Ly9jcmVkZW50aWFsX2lzc3Vlci5leGFtcGxlLm9yZyIsICJqd2tzIjogeyJrZXlzIjogW3sia3R5IjogIlJTQSIsICJraWQiOiAiWjBWRVdtUTRVVFJWZFhNeGRFVnRMVUl3VldWSVRVZDRhekpEVTBrdE5DMXdaWGR2TVRoWWJrTTRUUSIsICJuIjogIm9BQXFPcHB3NlN3a2czTGUyREpSMzB4dGcwbjhDazZrYkw4cTM1YmRVRnVQazAwWWlDS2RPbDdiR0M1RnZQbjJyMmdpX0JGd3Y4bHB3a3lNTm5yWDB3M3dIV01LVTJncFhKcS1TZ2RlckF1UGZsR0M4MWNOLUxoSTNOLUJkMHIxdWE4QlZLRnlxVnZDaXJrN2FjRnlXUGtmT3BrLW00ZVRuLXJrTTM0RDFGdVRXTlA3LWV6ek9YNzlsdmFyQVRpeUtSb2ttOVhkWDdOaUNYTzZ5M0g4Y0VfQVFROWtib0psZDZJR294MFBWN3VRb3M5ZFlEZS0xWlgxc1g4SmpJTE9iMEw1QXgtVThyOVd5SF9FZFF1RFVvUDM2THRTdWJQWGhqOTVaVGtGa2Z4WXdzR1FsZjIyUVZhUFlYdVZ1ZUpibXo2dWZOTUlwaTRtS2g1N0NibXJjdyIsICJlIjogIkFRQUIifV19LCAiaXNzIjogImh0dHBzOi8vaW50ZXJtZWRpYXRlLmVpZGFzLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3Njc3MTA5ODQsICJleHAiOiAxNzY4MDEwOTg0fQ.fUcQI29xFaxfvhOAZINWz3V9J1p-Ju6yyfyVQUmYpOc2j5VKz-jn1CG106gnyYzEPS5D3LMkwvuW1QADmFezgQj9iPpYpCIXn3gVdZbAHUP8RsseTQhm5EGiC11X-7zCA4RqQTuqQTh27fYYYoKkxcmkWeWteqzrFD4Tjw-Ryk0Eey7u9SFErZcZG8pNdpvopSUcUbWg14KG58DU64ssR4KJsZwPRZPfC\_xr5CK4oQeyZF2ds8N-5cGAPRRuN68wlCT4IeYRByxmBZDxhX4e81qJT7eiIB95h-Ka6nY-R63A38IMBSN68MlX1Bt8gE\_rfinTJhL6Y20LWKmeDyhWFg",
    "eyJ0eXAiOiJlbnRpdHktc3RhdGVtZW50K2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiT1ZwU2JHUnVlWE5UWmtrek5FNUJjVkF6TFRsRFVIZHBka05CZVZZM2NYbzNhV1paTm00NFJUZGFXUSJ9.eyJzdWIiOiAiaHR0cHM6Ly9pbnRlcm1lZGlhdGUuZWlkYXMuZXhhbXBsZS5vcmciLCAiandrcyI6IHsia2V5cyI6IFt7Imt0eSI6ICJSU0EiLCAia2lkIjogImEwdHJlblJoTFhFeWVETlphRGt5V0c0MU5rRTBVMlpTU1VsU1EwNDNOa0ZuTVZCbFlYVkNRalZYYXciLCAibiI6ICJ6RmpzV3hBbE1ORFkzZUlqT2djaHVhX2ZRb3ZKeUNxbTM4M3dBV2Q5SDV0YU95QW5XbGx0UlJCV18zOHRycUZTWjl6UW0zdHdvZHllcHM2ZnFSNTdKMHF1NzVPWmdseXAyNUloMnBPWlBOWU5GSEFqSXRhbnNqWHI0RjRtakNfVVBMWmpRc3lHNjA1eGtrWUR4MjlqRF9pa0REN0lwUlA1Yk01ZU5vQVF1d1NMbktSWk43d0lMRjU3eDlSZVZZYnp1TEVUVzZOdzU0Y1Q3aDNMb3ljZ2dxQXdoR0dSR09QUEFlOEFsYjhtUDJBeGE4TWdNLUhhUENISHMwamswVy1zOUNDQ0djdzBfWmV5OWQ3eHFzT21KNnQ0QWUxWnhBTlJ1LU9FanhDSVd2WDl6aEJkeXNtVmp4RWVFY2xYSVltajFsd0JtZ0s0U1VmcVBMUGdYUGc5aVEiLCAiZSI6ICJBUUFCIn1dfSwgImlzcyI6ICJodHRwczovL3RydXN0LWFuY2hvci5leGFtcGxlLm9yZyIsICJpYXQiOiAxNzY3NzEwOTg0LCAiZXhwIjogMTc2ODAxMDk4NH0.IHTiWH2H2n2fVtkn7K\_4GcP-VoSmuz4BWqOn6CtUNaLxUgIWR6FVeaKHdxdabkkMd\_zQk6bG\_K5adF2H45ojoJIFVY8uuwJCOfakfsYbOnKRmsWD4qiINXjFPLg8jVutg0lTNGjxjJRm6I-7bs5hGRJUAwhOGGrfdtnO7qtlBfg6ciHCuyr8Jq0tmYooKrvpbmObxQ7-cPqqnHy0J3My2TDlxtbMarqpSfXHEavjCEV0dXz00JXAuu0Iop2XfrMvZJaQXeLWtZM\_CsBv1-FhVpslLYvlbktwCnV55nnEa06BItcW2ZdpVEVC-GrBcYc2wXIBXLxKjThZ67Z3SMdqpg",
    "eyJ0eXAiOiJlbnRpdHktc3RhdGVtZW50K2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiT1ZwU2JHUnVlWE5UWmtrek5FNUJjVkF6TFRsRFVIZHBka05CZVZZM2NYbzNhV1paTm00NFJUZGFXUSJ9.eyJtZXRhZGF0YSI6IHsiZmVkZXJhdGlvbl9lbnRpdHkiOiB7ImZlZGVyYXRpb25fZmV0Y2hfZW5kcG9pbnQiOiAiaHR0cHM6Ly90cnVzdC1hbmNob3IuZXhhbXBsZS5vcmcvZmV0Y2giLCAiZmVkZXJhdGlvbl9yZXNvbHZlX2VuZHBvaW50IjogImh0dHBzOi8vdHJ1c3QtYW5jaG9yLmV4YW1wbGUub3JnL3Jlc29sdmUiLCAiZmVkZXJhdGlvbl9saXN0X2VuZHBvaW50IjogImh0dHBzOi8vdHJ1c3QtYW5jaG9yLmV4YW1wbGUub3JnL2xpc3QiLCAib3JnYW5pemF0aW9uX25hbWUiOiAiVEEgZXhhbXBsZSIsICJvcmdhbml6YXRpb25fdXJpIjogImh0dHBzOi8vdHJ1c3QtYW5jaG9yLmV4YW1wbGUub3JnL2hvbWUiLCAicG9saWN5X3VyaSI6ICJodHRwczovL3RydXN0LWFuY2hvci5leGFtcGxlLm9yZy9wb2xpY3kiLCAibG9nb191cmkiOiAiaHR0cHM6Ly90cnVzdC1hbmNob3IuZXhhbXBsZS5vcmcvc3RhdGljL2xvZ28uc3ZnIiwgImNvbnRhY3RzIjogWyJ0ZWNoQHRydXN0LWFuY2hvci5leGFtcGxlLm9yZyJdfX0sICJqd2tzIjogeyJrZXlzIjogW3sia3R5IjogIlJTQSIsICJraWQiOiAiT1ZwU2JHUnVlWE5UWmtrek5FNUJjVkF6TFRsRFVIZHBka05CZVZZM2NYbzNhV1paTm00NFJUZGFXUSIsICJuIjogInhDOXBkUHJwMURHNzlQb0wyTmsybGpoTVpnc3dyMUFqTFprcC1KZHN2MTVHYTY3S0FhMUNId0RMQ0JrblZKcHZNb2g0dnFyM0RzYlh1NEFobThFUzY3RlEwUmpUeUNTZXBvREVoNXVtd0dSakQxblhEMTI2dTlGQi10S0xqUFpTaFl5aW5Kd1BaSGp0ekF0U2xjalNfcFg3WjRDQUh1OEhkeHpZb0JDODhOUEszZjBhZmRBY3JxcnM3LVVFWlphODhycVpGZjRYemVZMGdZUVc4cG5TN0h6cU9aNEhLaU1Ld0ZXUnE1WXFVQ2stVkUyZlpsdjIzR3pxd3VyenllaTd2cVZwWXhodFRlTnBmMjZqSWV5T2JhWm5QYTMzUmFVVDNCd2p2bXBROGJEZ0EzUlF3UFhXMFIzTlpzTElfd0Nqc095TVdkMVh6MlJHellRcjVVV2psUSIsICJlIjogIkFRQUIifV19LCAic3ViIjogImh0dHBzOi8vdHJ1c3QtYW5jaG9yLmV4YW1wbGUub3JnIiwgImlzcyI6ICJodHRwczovL3RydXN0LWFuY2hvci5leGFtcGxlLm9yZyIsICJpYXQiOiAxNzY3NzEwOTg0LCAiZXhwIjogMTc2ODAxMDk4NH0.gbpT-NSUz4Psl3wysrNqXXLZ5sYFnH8yB7Mtb6x5Vbwqre5UsHzyS7S9F86hWSfPQT19jofWT4uLFC\_R\_Ct4xa3OZvGSfVEtv9rYtJ8Q2tCM2JYZO1hFCaV6BM9pa5yU93H5SoOVLuK4YxQzmGE7cuHsjOXHbGCexJ0rcC1CTOwK3q1o8YEOa\_0X2KbkEmeQKR1P50oN8c\_GK0NkxT3XLCxb-cVwlG4nsHDe28KBwxjX2DObXXgh5SXj1Mz7dXuv-AtfKcHQ9i479mWVJn86rE4IjHRSp5IIEMsZ5Pn72QVWHGxkwno0TOFTBLtUp9FN9Y36gXiZpfMq9RdyvYbl2w"
  \]
}

Figure 4: Example JWS Header with a trust_chain Parameter

4.4. Peer Trust Chain Header Parameter

peer_trust_chain JWS ヘッダーパラメータは、この Entity が信頼を確立しようとしている Entity と、選択された Trust Anchor の間の Trust Chain を構成する Entity Statements の列を含む JSON 配列である。trust_chain ヘッダーパラメータも存在する場合、両方の Trust Chains に対する Trust Anchor は同一であるべきである。両方の Trust Chains を含めることで、[App-Fed-Linkage] で定義される Federation Integrity および Metadata Integrity の特性を達成できる。

Entity Configurations と Subordinate Statements は、Trust Chain の構成要素そのものであるため、peer_trust_chain ヘッダーパラメータを含んではならない。このヘッダーパラメータの使用は OPTIONAL である。

5. Metadata

このセクションは、Entities に関する metadata を表現し使用する方法を定義する。各 Entity Type に適用される、既存の OpenID Connect および OAuth 2.0 の metadata 標準を使用する。

[Section 3.1.1] で述べたとおり、Entity metadata は Entity Statement の metadata Claim に置かれ、その値は JSON オブジェクトである。このオブジェクトのメンバー名は、[Section 5.1] で規定される Entity Type Identifiers である。各 Entity Type Identifier に続く metadata データ構造は JSON オブジェクトであり、空の JSON オブジェクト {} でもよい。これは、Superiors が必要な metadata 値を供給する場合に起こり得る。

metadata データ構造のトップレベル JSON オブジェクトのメンバーは、null を除く任意の JSON 値を使用してもよい。null の使用は禁止される。これは、null 値を持つメンバーを省略されたメンバーと混同することで起こり得る実装エラーを防ぐためである。

5.1. Entity Type Identifiers

Entity Type Identifier は、フェデレーション参加者の Entity Type と、その Entity Type の metadata 形式を一意に識別する。このセクションは federation_entity Entity Type Identifier と、OpenID Connect および OAuth 2.0 の Federation Entities の identifiers を定義する。

他のプロトコルのユースケースをサポートするため、追加の Entity Type Identifiers を定義してもよい。

5.1.1. Federation Entity

Entity Type Identifier は federation_entity である。

以下で定義される Federation Entity のプロパティのいずれかを含む Entities は、この Entity Type を使用しなければならない。次の Federation Entity プロパティが定義される:

federation_fetch_endpoint

OPTIONAL. [Section 8.1] で記述される fetch endpoint。この URL は https スキームを使用しなければならず、port、path、query parameter 要素を含んでもよいが、fragment 要素を含んではならない。Intermediate Entities と Trust Anchors は federation_fetch_endpoint を公開しなければならない。Leaf Entities は公開してはならない。

federation_list_endpoint

OPTIONAL. [Section 8.2] で記述される list endpoint。この URL は https スキームを使用しなければならず、port、path、query parameter 要素を含んでもよいが、fragment 要素を含んではならない。Intermediate Entities と Trust Anchors は federation_list_endpoint を公開しなければならない。Leaf Entities は公開してはならない。

federation_resolve_endpoint

OPTIONAL. [Section 8.3] で記述される resolve endpoint。この URL は https スキームを使用しなければならず、port、path、query parameter 要素を含んでもよいが、fragment 要素を含んではならない。任意の Federation Entity は federation_resolve_endpoint を公開してもよい。

federation_trust_mark_status_endpoint

OPTIONAL. [Section 8.4] で記述される Trust Mark Status endpoint。Trust Mark Issuers は federation_trust_mark_status_endpoint を公開すべきである。この URL は https スキームを使用しなければならず、port、path、query parameter 要素を含んでもよいが、fragment 要素を含んではならない。

federation_trust_mark_list_endpoint

OPTIONAL. [Section 8.5] で記述される endpoint。この URL は https スキームを使用しなければならず、port、path、query parameter 要素を含んでもよいが、fragment 要素を含んではならない。Trust Mark Issuers は federation_trust_mark_list_endpoint を公開してもよい。

federation_trust_mark_endpoint

OPTIONAL. [Section 8.6] で記述される endpoint。この URL は https スキームを使用しなければならず、port、path、query parameter 要素を含んでもよいが、fragment 要素を含んではならない。Trust Mark Issuers は federation_trust_mark_endpoint を公開してもよい。

federation_historical_keys_endpoint

OPTIONAL. [Section 8.7] で記述される endpoint。この URL は https スキームを使用しなければならず、port、path、query parameter 要素を含んでもよいが、fragment 要素を含んではならない。すべての Federation Entities は federation_historical_keys_endpoint を公開してもよい。

endpoint_auth_signing_alg_values_supported

OPTIONAL. [Section 8.8] で記述されるとおり、フェデレーション endpoints に認証する際に private_key_jwt で使用される [JWT] [RFC7519] の署名のためにサポートされる [JWS] [RFC7515] アルゴリズム（alg 値）のリストを含む JSON 配列。このエントリが省略された場合、デフォルトのアルゴリズムは暗黙に示されない。Servers は RS256 をサポートすべきである。none は使用してはならない。

追加の Federation Entity プロパティも定義され、使用されてもよい。

各 Federation Entity が、[Section 5.2.2] で定義される organization_name Claim を含むことが推奨される。

以下は、federation_entity Entity Type の metadata の非規範的な例である:

"federation_entity": {
  "federation_fetch_endpoint":
    "https://amanita.caesarea.example.com/federation_fetch",
  "federation_list_endpoint":
    "https://amanita.caesarea.example.com/federation_list",
  "federation_trust_mark_status_endpoint": "https://amanita.caesarea.example.com/status",
  "federation_trust_mark_list_endpoint": "https://amanita.caesarea.example.com/trust_marked_list",
  "organization_name": "Ovulo Mushroom",
  "organization_uri": "https://amanita.caesarea.example.com"
}

Figure 5: Example of federation_entity Entity Type

5.1.2. OpenID Connect Relying Party

Entity Type Identifier は openid_relying_party である。

[OpenID Connect Dynamic Client Registration 1.0] [OpenID.Registration] の Section 2、[OpenID.RP.Choices]、および [Section 5.2] で定義されるすべてのパラメータに加え、IANA の「OAuth Dynamic Client Registration Metadata」レジストリ [IANA.OAuth.Parameters] に登録された追加パラメータが適用可能である。ただし、登録レスポンスでのみ使用するためにレジストリで定義されているパラメータ（たとえば client_secret）は除く。

さらに、次の RP metadata パラメータが定義される:

client_registration_types

RECOMMENDED. RP がサポートする client registration types を指定する文字列の配列。本仕様で定義される値は automatic と explicit である。追加の値も、本仕様による制限なく定義・使用してよい。

以下は、RP の Entity Configuration の JWT Claims Set の非規範的な例である:

{
  "iss": "https://rp.sunet.se",
  "sub": "https://rp.sunet.se",
  "iat": 1516239022,
  "exp": 1516843822,
  "metadata": {
    "openid_relying_party": {
      "application_type": "web",
      "redirect_uris": [
        "https://rp.sunet.se/callback"
      ],
      "organization_name": "SUNET",
      "logo_uri": "https://www.sunet.se/sunet/images/32x32.png",
      "grant_types": [
        "authorization_code",
        "implicit"
      ],
      "signed_jwks_uri": "https://rp.sunet.se/signed_jwks.jose",
      "jwks_uri": "https://rp.sunet.se/jwks.json",
      "client_registration_types": ["automatic"]
    }
  },
  "jwks": {
    "keys": [
      {
        "alg": "RS256",
        "e": "AQAB",
        "kid": "Ge7hs3smulgio8glvURJadmj...",
        "kty": "RSA",
        "n": "iE0ZGqI4TNopx52dGHm0EYhl...",
        "use": "sig"
      }
    ]
  },
  "authority_hints": [
    "https://edugain.org/federation"
  ]
}

Figure 6: Example Relying Party Entity Configuration JWT Claims Set

5.1.3. OpenID Connect OpenID Provider

Entity Type Identifier は openid_provider である。

[OpenID Connect Discovery 1.0] [OpenID.Discovery] の Section 3 および [Section 5.2] で定義されるすべてのパラメータに加え、IANA の「OAuth Authorization Server Metadata」レジストリ [IANA.OAuth.Parameters] に登録された追加パラメータが適用可能である。たとえば require_signed_request_object および require_pushed_authorization_requests の metadata パラメータを使用できる。

openid_provider metadata における issuer パラメータ値は、Federation Entity Identifier（Entity Configuration 内の iss パラメータ）と一致しなければならない。

さらに、次の OP metadata パラメータが定義される:

client_registration_types_supported

RECOMMENDED. OP がサポートする client registration types を指定する文字列の配列。本仕様で定義される値は automatic と explicit である。追加の値も、本仕様による制限なく定義・使用してよい。

federation_registration_endpoint

OPTIONAL. OP のフェデレーション固有の Dynamic Client Registration Endpoint の URL。OP が Explicit Client Registration Endpoint をサポートする場合、この URL は https スキームを使用しなければならず、port、path、query parameter 要素を含んでもよいが、fragment 要素を含んではならない。OP が [Section 12.2] に記述される Explicit Client Registration をサポートする場合、この Claim は REQUIRED である。

以下は、OP の Entity Configuration の JWT Claims Set の非規範的な例である:

{
  "iss": "https://op.umu.se",
  "sub": "https://op.umu.se",
  "exp": 1568397247,
  "iat": 1568310847,
  "metadata": {
    "openid_provider": {
      "issuer": "https://op.umu.se",
      "signed_jwks_uri": "https://op.umu.se/signed_jwks.jose",
      "authorization_endpoint": "https://op.umu.se/authorization",
      "client_registration_types_supported": [
        "automatic",
        "explicit"
      ],
      "grant_types_supported": [
        "authorization_code",
        "implicit",
        "urn:ietf:params:oauth:grant-type:jwt-bearer"
      ],
      "id_token_signing_alg_values_supported": [
        "ES256",
        "RS256"
      ],
      "logo_uri": "https://www.umu.se/img/umu-logo-left-neg-SE.svg",
      "op_policy_uri": "https://www.umu.se/en/legal-information/",
      "response_types_supported": [
        "code",
        "code id_token",
        "token"
      ],
      "subject_types_supported": [
        "pairwise",
        "public"
      ],
      "token_endpoint": "https://op.umu.se/token",
      "federation_registration_endpoint": "https://op.umu.se/fedreg",
      "token_endpoint_auth_methods_supported": [
        "client_secret_post",
        "client_secret_basic",
        "client_secret_jwt",
        "private_key_jwt"
      ],
      "pushed_authorization_request_endpoint": "https://op.umu.se/par",
      "request_object_signing_alg_values_supported": [
        "ES256",
        "RS256"
      ],
      "token_endpoint_auth_signing_alg_values_supported": [
        "ES256",
        "RS256"
      ]
    }
  },
  "authority_hints": [
    "https://umu.se"
  ],
  "jwks": {
    "keys": [
      {
        "e": "AQAB",
        "kid": "dEEtRjlzY3djcENuT01wOGxrZlkxb3RIQVJlMTY0...",
        "kty": "RSA",
        "n": "x97YKqc9Cs-DNtFrQ7_vhXoH9bwkDWW6En2jJ044yH..."
      }
    ]
  }
}

Figure 7: Example OpenID Provider Entity Configuration JWT Claims Set

5.1.4. OAuth Authorization Server

Entity Type Identifier は oauth_authorization_server である。

[RFC8414] の Section 2 および [Section 5.2] で定義されるすべてのパラメータに加え、IANA の「OAuth Authorization Server Metadata」レジストリ [IANA.OAuth.Parameters] に登録された追加パラメータが適用可能である。

oauth_authorization_server metadata における issuer パラメータ値は、Federation Entity Identifier（Entity Configuration における iss Claim）と一致しなければならない。

5.1.5. OAuth Client

Entity Type Identifier は oauth_client である。

[OAuth 2.0 Dynamic Client Registration Protocol] [RFC7591] の Section 2 および [Section 5.2] で定義されるすべてのパラメータに加え、IANA の「OAuth Dynamic Client Registration Metadata」レジストリ [IANA.OAuth.Parameters] に登録された追加パラメータが適用可能である。

5.1.6. OAuth Protected Resource

Entity Type Identifier は oauth_resource である。[Section 5.2] で定義されるパラメータが適用可能である。加えて、デプロイは [RFC9728] で定義される protected resource metadata パラメータを使用してもよい。

5.2. Common Metadata Parameters

このセクションは、以下で注記する JWK Sets に関する例外を除き、上記のすべての Entity Types で使用してもよい追加の metadata パラメータを定義する。

5.2.1. Parameters for JWK Sets in Entity Metadata

以下の metadata パラメータは、Entity の Entity Type のための JWK Sets を取得する方法を定義する。これらの鍵は、Entity Statements に署名するために使用される Federation Entity Keys とは別であることに注意すること。Federation Entity Keys は Entity Statement の jwks Claim にあり、metadata Claim の中にはない。これらの JWK Sets のためのパラメータは、federation_entity Entity Type metadata では使用してはならない。

signed_jwks_uri

OPTIONAL. ある Entity Type のための、Entity の JWK Set 文書を payload として持つ署名付き JWT を参照する URL。この URL は https スキームを使用しなければならない。JWT は Federation Entity Key を用いて署名されなければならない。URL からの成功レスポンスは、HTTP ステータスコード 200 と content type application/jwk-set+jwt を使用しなければならない。署名鍵と暗号化鍵の両方が存在する場合、参照される JWK Set 内のすべての鍵について、各鍵の意図された用途を示すために use（public key use）パラメータ値が REQUIRED である。

署名付き JWK Set JWT は、[RFC8725] の Section 3.11 に従い、クロス JWT の混同を防ぐため、typ ヘッダーパラメータを jwk-set+jwt に設定することで明示的に型付けされる。typ ヘッダーパラメータがない署名付き JWK Set JWT、または異なる typ 値を持つものは拒否しなければならない。

署名付き JWK Set JWT は、使用した署名鍵の Key ID を値とする kid（Key ID）ヘッダーパラメータを必ず含めなければならない。

payload で使用する Claims として以下を規定する。keys を除くすべては [RFC7519] で定義される:

keys

REQUIRED. [RFC7517] の Section 5.1 で規定されるとおり、JWK Set に含まれる JWK 値の配列。

iss

REQUIRED. iss（issuer）Claim は、JWT を発行した principal を識別する。

sub

REQUIRED. この Claim は鍵の owner を識別する。issuer と同一であるべきである。

iat

OPTIONAL. 数値。この署名付き JWK Set が発行された時刻。[RFC7519] に従い、Seconds Since the Epoch で表す。

exp

OPTIONAL. 数値。この Claim は、JWT が有効でなくなる時刻を識別する。[RFC7519] に従い、Seconds Since the Epoch で表す。

[RFC7519] にはさらに多くの Claims が定義されるが、このうち aud は issuer が audience を知り得ないため使用すべきではない。nbf と jti はこの文脈では特に有用ではなく、省略すべきである。

上記の Claims と併用して、追加の Claims を定義し使用してもよい。

以下は、署名付き JWK Set の JWT Claims Set の非規範的な例である:

{
  "keys": \[
    {
      "kty": "RSA",
      "kid": "SUdtUndEWVY2cUFDeDV5NVlBWDhvOXJodVl2am1mNGNtR0pmd",
      "n": "y\_Zc8rByfeRIC9fFZrDZ2MGH2ZnxLrc0ZNNwkNet5rwCPYeRF3Sv
            5nihZA9NHkDTEX97dN8hG6ACfeSo6JB2P7heJtmzM8oOBZbmQ90n
            EA\_JCHszkejHaOtDDfxPH6bQLrMlItF4JSUKua301uLB7C8nzTxm
            tF3eAhGCKn8LotEseccxsmzApKRNWhfKDLpKPe9i9PZQhhJaurwD
            kMwbWTAeZbqCScU1o09piuK1JDf2PaDFevioHncZcQO74Obe4nN3
            oNPNAxrMClkZ9s9GMEd5vMqOD4huXlRpHwm9V3oJ3LRutOTxqQLV
            yPucu7eHA7her4FOFAiUk-5SieXL9Q",
      "e": "AQAB"
    },
    {
      "kty": "EC",
      "kid": "MFYycG1raTI4SkZvVDBIMF9CNGw3VEZYUmxQLVN2T21nSWlkd3",
      "crv": "P-256",
      "x": "qAOdPQROkHfZY1daGofOmSNQWpYK8c9G2m2Rbkpbd4c",
      "y": "G\_7fF-T8n2vONKM15Mzj4KR\_shvHBxKGjMosF6FdoPY"
    }
  \],
  "iss": "https://example.org/op",
  "sub": "https://example.org/op",
  "iat": 1618410883
}

Figure 8: Example JWT Claims Set for a Signed JWK Set

jwks_uri

OPTIONAL. ある Entity Type のための Entity の鍵を含む JWK Set 文書を参照する URL。この URL は https スキームを使用しなければならない。署名鍵と暗号化鍵の両方が存在する場合、参照される JWK Set 内のすべての鍵について、各鍵の意図された用途を示すために use（public key use）パラメータ値が REQUIRED である。

jwks

OPTIONAL. ある Entity Type のための Entity の鍵を含む JSON Web Key Set 文書を、値として渡すもの。署名鍵と暗号化鍵の両方が存在する場合、JWK Set 内のすべての鍵について、各鍵の意図された用途を示すために use（public key use）パラメータ値が REQUIRED である。このパラメータは、何らかの理由で signed_jwks_uri パラメータを使用できない参加者が使用することを意図している。jwks を使用する利点として、Entity Type のための Entity の鍵が Trust Chains に記録される点がある。

5.2.1.1. Usage of jwks, jwks_uri, and signed_jwks_uri in Entity Metadata

Entity Configuration が、その OpenID Connect または OAuth 2.0 metadata において jwks、jwks_uri、signed_jwks_uri のうち1つだけを使用することが推奨される。しかし、複数の JWK Set 表現を使用することが望ましい状況もあり得る。たとえば、Entity が複数のフェデレーションに属し、フェデレーションごとに使用すべき JWK Set 表現について異なるポリシーを持つ場合である。また、実装によってはこれらの表現をすべて理解できない可能性がある点にも注意すること。たとえば、jwks_uri は OpenID Connect OP metadata では確実に理解される一方、signed_jwks_uri はすべての OpenID Connect 実装で理解されるとは限らない。そのため、理解される JWK Set 表現も併せて存在している必要がある。

複数の JWK Set 表現を使用する場合、各表現に含まれる鍵は同一であるべきである。ある時点で完全に同一でない場合（鍵のロールオーバーの期間中などに起こり得る）でも、実装は適時にそれらを整合させなければならない。

5.2.2. Informational Metadata Parameters

以下の metadata パラメータは、Entity Type に関して Entity の情報を得るための方法を定義する。

organization_name

OPTIONAL. この Entity を所有する組織を表す、人間が読める名称。owner が自然人である場合、たとえばその人の名前でもよい。この情報は公開されることに注意すること。

display_name

OPTIONAL. End-User に提示するための、Entity の人間が読める名称。

description

OPTIONAL. End-User に提示可能な、この Entity の簡潔な説明（人間が読めるもの）。

keywords

OPTIONAL. この Entity に適用される検索キーワード、タグ、カテゴリ、またはラベルを表す、1つ以上の文字列からなる JSON 配列。

contacts

OPTIONAL. Entity における連絡先担当者を表す、1つ以上の文字列からなる JSON 配列。これらは、名前、e-mail アドレス、説明、電話番号などを含んでもよい。

logo_uri

OPTIONAL. 文字列。この Entity のロゴを指す URL。ロゴを含むファイルは、ウェブ経由で閲覧可能な形式で公開すべきである。

policy_uri

OPTIONAL. この Entity に関連する条件やポリシーの文書の URL。

information_uri

OPTIONAL. End-User が閲覧可能な、この Entity に関する追加情報の文書の URL。

organization_uri

OPTIONAL. この Entity を所有する組織の Web ページの URL。

これらの metadata パラメータは、Entity が使用する任意の Entity Types の metadata に存在してもよい。

6. Federation Policy

6.1. Metadata Policy

Trust Anchors と Intermediate Entities は、自身の Subordinates の metadata に適用されるポリシーを定義してもよい。

フェデレーションは、特定の目的を達成するために metadata policies を利用できる。たとえば、[OpenID Connect] [OpenID.Core] Entities のフェデレーションでは、ある目的は OpenID Providers と Relying Parties が公開する metadata の相互運用性を確保することかもしれない。別の目的は、Entity metadata がセキュリティ・プロファイル（たとえば [FAPI] [FAPI]）に準拠していることを確保することかもしれない。

metadata_policy は、metadata パラメータの JSON 値の型を検査し検証することを意図したものではない点に注意すること。その種の検査は、解決に成功した Trust Chain から Entity metadata を得た後に、アプリケーション層で実施すべきである。

6.1.1. Principles

OpenID Federation は、以下の特性を持つ metadata policies の定義を可能にする:

Hierarchy

ある metadata パラメータに適用された metadata policy は、Trust Chain でそれに従属する Intermediate Entities によって撤回されたり、より緩いものに変更されたりすることはない。

あるフェデレーションの Trust Anchor が別のフェデレーションで Intermediate Entity として振る舞うネストされたフェデレーションにおいても、ポリシーの階層は保持される。

Equal Opportunity

Trust Chain 内のすべての Superior Entities は、合成された metadata policy が論理的に健全になる限り、対等な立場で metadata policies に寄与できる。たとえば、任意の Intermediate は、Superiors が指定した内容に対して、Subordinates の metadata をさらに制限できる。metadata policies の間に衝突を導入する Intermediate は、その Trust Chain が無効と見なされる原因となる。

Specificity and Granularity

metadata と同様に、metadata policy は特定の Entity Type に束縛される。これにより、異なる Entity Types のポリシーは互いに独立し、分離される。

ポリシーは個々の metadata パラメータのレベルで表現される。したがって、ある Entity Type の metadata パラメータに対するポリシーは、他のパラメータに対するポリシーから独立し、分離される。

Trust Anchor または Intermediate Entity が、ある Entity Type のための metadata policy を定義すると、それは Trust Chain における当該 type のすべての Subordinate Entities の metadata に適用される。

ポリシーを定義する場所は Subordinate Statement であり、各 Entity Statement は特定の subject のために発行されるため、フェデレーション権威は、すべての Subordinates に共通の Entity Type metadata policy を定義することも、特定の Subordinates のために特定の Entity Type metadata policies を定義することも選べる。

Operation

ポリシーは、ある metadata パラメータに対して、検査、変更、またはその両方を行うことで機能する。本仕様は [Section 6.1.3.1] で記述される標準 operators の集合を定義する。フェデレーションは、このセクションに示す原則、および [Section 6.1.3] と [Section 6.1.3.2] に準拠する限り、追加の operators を指定し使用してもよい。

Integral Metadata Enforcement

metadata policies の解決と適用は、[Section 10] に記述される Trust Chain 解決プロセスの不可欠な一部である。

これは次を意味する:

Intermediate Entity のポリシーが Superior のポリシーと衝突するなどの理由で、metadata policy の解決がエラーにより失敗する Trust Chain は無効と見なされる。
Resolved Metadata のポリシーに準拠しない Entity metadata を持つ Trust Chain は無効と見なされる。

Determinism

Trust Chain における metadata policies の解決と適用は決定的である。したがって、Trust Anchors と Intermediate Entities は、予測可能で再現可能な結果を示すポリシーを策定できる。

6.1.2. Structure

metadata policies は、[Section 3.1.3] で記述されるとおり、Subordinate Statement の metadata_policy Claim で表現される。Claim Value は JSON オブジェクトであり、そのデータ構造は次の3つのレベルからなる:

Entity Types のための metadata policies。

トップレベルは、1つ以上のメンバーを含み、各メンバーが Entity Type の metadata policy を表す。各メンバー名は、[Section 5.1] で規定される Entity Type Identifier（たとえば openid_relying_party）である。メンバー値は、metadata パラメータ・ポリシーを含む JSON オブジェクトである。
Entity Type のための metadata parameter policies。

第2レベルは、1つ以上のメンバーを含み、各メンバーが Entity Type の metadata パラメータに対するポリシーを表す。各メンバー名は metadata パラメータ名（たとえば id_token_signed_response_alg）である。名前には、[Section 14] で記述される language tag を含んでもよく、その場合、その metadata パラメータ・ポリシーは、指定された language tag を持つ metadata パラメータにのみ適用される。メンバー値は、policy operators を含む JSON オブジェクトである。
Entity Type の metadata parameter policy のための operators。

第3レベルは、1つ以上のメンバーを含み、各メンバーが、[Section 6.1.3] に記述されるとおり、metadata パラメータを検査または変更する operator を表す。各 operator の仕様で定義されるとおり、互いに組み合わせ可能な operators だけが、ここで同時に含められる。

metadata_policy Claim のデータ構造の3つのレベルのいずれにおいても、重複する JSON オブジェクトのメンバー名が存在してはならない。

以下は、id_token_signed_response_alg metadata パラメータに対する単一のポリシーからなり、2つの operators（default と one_of）を使用する OpenID Relying Party の metadata policy の非規範的な例である:

"metadata_policy" : {
  "openid_relying_party": {
    "id_token_signed_response_alg": {
      "default": "ES256",
      "one_of": \["ES256", "ES384", "ES512"\]
    }
  }
}

Figure 9: Example metadata_policy Claim

6.1.3. Operators

metadata policy operator は次の性質を持つ:

一意で、大文字小文字を区別する名前によって識別される。
単一の metadata パラメータに作用する。operator の定義は、その metadata パラメータでサポート必須の JSON 値型を指定しなければならず、サポート任意の JSON 値型も指定してもよい。metadata パラメータがサポートされない JSON 値型を持つ場合、operator は policy error を生成しなければならない。
metadata パラメータに対する作用は、値の検査、値の変更、またはその両方であり得る。operator の作用が値の変更である場合、metadata パラメータを削除してもよい。
operator の作用は、JSON 値によって構成される。operator の定義は、サポート必須の JSON 値型を指定しなければならず、サポート任意の JSON 値型も指定してもよい。operator がサポートされない JSON 値型で構成されている場合、operator は policy error を生成しなければならない。
[Section 6.1.2] および [Section 6.1.4] で記述されるとおり、個別の、またはマージされた metadata パラメータ・ポリシーの両方において、他のどの operators と組み合わせ可能かを宣言しなければならない。組み合わせは無条件の場合も、条件付きの場合もあり得て、条件付きの場合は2つの operators の構成値が特定の基準を満たすことを要求する。許可されない組み合わせは policy error を生成しなければならない。
metadata パラメータに適用される順序（絶対、または同一の metadata パラメータ・ポリシー内の他の operators に対する相対）を宣言しなければならない。値の検査 operators は、一般に値の変更を行う operators の後に適用すべきである。
Trust Chain 内の複数の Subordinate Statement が、同一の operator を用いる Entity Type metadata パラメータのポリシーを持つ場合、operator 値をマージして同一またはより制限的なポリシーを生成できるかどうか、可能ならどの条件で可能かを指定しなければならない。そのような operator 値マージの結果の順序は定義されない。operator がそのようなマージを許可しない場合、policy error を生成しなければならない。
null 値を持つ metadata パラメータを出力してはならない。

JSON の文法には適合するが、[RFC8259] の Section 4 および Section 8 に従う相互運用可能な JSON の使用を表さない metadata パラメータやポリシーは、予測不能な挙動を引き起こし得る点に注意すること。

6.1.3.1. Standard Operators

本仕様は、以下の metadata policy operators を定義する:

6.1.3.1.1. value

Name: value

Action: metadata パラメータは、operator の値に割り当てられなければならない。operator の値が null の場合、metadata パラメータは削除されなければならない。

Metadata parameter JSON values:

Mandatory to support: string, number, boolean, array

Operator JSON values:

Mandatory to support: string, number, boolean, array, null

Combination with other operators in a metadata parameter policy:

add と組み合わせてもよい。その場合、add の値は value の値の subset でなければならない。
value の値が null でない場合に限り default と組み合わせてもよい。
one_of と組み合わせてもよい。その場合、value の値は one_of の値のいずれかでなければならない。
subset_of と組み合わせてもよい。その場合、value の値は subset_of の値の subset でなければならない。
superset_of と組み合わせてもよい。その場合、value の値は superset_of の値の superset でなければならない。
essential と組み合わせてもよい。ただし、value が null で essential が true の場合は除く。

Order of application: 最初

Operator value merge: operator 値が等しい場合にのみ許可される。等しくない場合、policy error を生成しなければならない。

6.1.3.1.2. add

Name: add

Action: この operator の値（1つまたは複数）は metadata パラメータに追加されなければならない。metadata パラメータにすでに存在する値は再度追加してはならない。metadata パラメータが存在しない場合、operator の値で初期化しなければならない。

Metadata parameter JSON values:

Mandatory to support: array of strings
Optional to support: array of objects, array of numbers

Operator JSON values:

Mandatory to support: array of strings
Optional to support: array of objects, array of numbers

Combination with other operators in a metadata parameter policy:

value と組み合わせてもよい。その場合、add の値は value の値の subset でなければならない。
default と組み合わせてもよい。
subset_of と組み合わせてもよい。その場合、add の値は subset_of の値の subset でなければならない。
superset_of と組み合わせてもよい。
essential と組み合わせてもよい。

Order of application: value の後。

Operator value merge: 2つの add operators の値をマージした結果は、値の union である。

6.1.3.1.3. default

Name: default

Action: metadata パラメータが存在しない場合、operator の値に設定しなければならない。metadata パラメータが存在する場合、この operator は影響しない。

Metadata parameter JSON values:

Mandatory to support: string, number, boolean, array

Operator JSON values:

Mandatory to support: string, number, boolean, array

Combination with other operators in a metadata parameter policy:

value の値が null でない場合に限り value と組み合わせてもよい。
add と組み合わせてもよい。
one_of と組み合わせてもよい。
subset_of と組み合わせてもよい。
superset_of と組み合わせてもよい。
essential と組み合わせてもよい。

Order of application: add の後。

Operator value merge: operator 値は等しくなければならない。等しくない場合、policy error を生成しなければならない。

6.1.3.1.4. one_of

Name: one_of

Action: metadata パラメータが存在する場合、その値は operator 値に列挙されたもののいずれかでなければならない。

Metadata parameter JSON values:

Mandatory to support: string
Optional to support: object, number

Operator JSON values:

Mandatory to support: array of strings
Optional to support: array of objects, array of numbers

Combination with other operators in a metadata parameter policy:

value と組み合わせてもよい。その場合、value の値は one_of の値のいずれかでなければならない。
default と組み合わせてもよい。
essential と組み合わせてもよい。

Order of application: default の後。

Operator value merge: 2つの one_of operators の値をマージした結果は、operator 値の intersection である。intersection が空の場合、policy error としなければならない。

6.1.3.1.5. subset_of

Name: subset_of

Action: metadata パラメータが存在する場合、operator の値と metadata パラメータの値の intersection に割り当てられる。結果の intersection は空配列 [] になり得る点に注意すること。また、subset_of は値の検査であるだけでなく、値の変更を行い得る点に注意すること。

Metadata parameter JSON values:

Mandatory to support: array of strings
Optional to support: array of objects, array of numbers

Operator JSON values:

Mandatory to support: array of strings
Optional to support: array of objects, array of numbers

Combination with other operators in a metadata parameter policy:

value と組み合わせてもよい。その場合、value の値は subset_of の値の subset でなければならない。
add と組み合わせてもよい。その場合、add の値は subset_of の値の subset でなければならない。
default と組み合わせてもよい。
superset_of と組み合わせてもよい。その場合、subset_of の値は superset_of の値の superset でなければならない。
essential と組み合わせてもよい。

Order of application: one_of の後。

Operator value merge: 2つの subset_of operators の値をマージした結果は、operator 値の intersection である。結果の intersection は空配列 [] になり得る。

6.1.3.1.6. superset_of

Name: superset_of

Action: metadata パラメータが存在する場合、その値は operator 値で指定されたものを含まなければならない。superset を数学的に定義すると、等号（同一）も含まれる。

Metadata parameter JSON values:

Mandatory to support: array of strings
Optional to support: array of objects, array of numbers

Operator JSON values:

Mandatory to support: array of strings
Optional to support: array of objects, array of numbers

Combination with other operators in a metadata parameter policy:

value と組み合わせてもよい。その場合、value の値は superset_of の値の superset でなければならない。
add と組み合わせてもよい。
default と組み合わせてもよい。
subset_of と組み合わせてもよい。その場合、subset_of の値は superset_of の値の superset でなければならない。
essential と組み合わせてもよい。

Order of application: subset_of の後。

Operator value merge: 2つの superset_of operators の値をマージした結果は、operator 値の union である。

6.1.3.1.7. essential

Name: essential

Action: この operator の値が true の場合、metadata パラメータは存在しなければならない。false の場合、metadata パラメータは任意であり、存在しなくてもよい。essential operator が省略された場合、値が false のものを含めたのと同等である。

Metadata parameter JSON values:

Mandatory to support: string, number, boolean, object, array

Operator JSON values:

Mandatory to support: boolean

Combination with other operators in a metadata parameter policy:

value と組み合わせてもよい。ただし、value が null で essential が true の場合は除く。
他の任意の operator と組み合わせてもよい。

Order of application: 最後

Operator value merge: 2つの essential operators の値をマージした結果は、operator 値の論理和（OR）である。

6.1.3.1.8. Notes on Operators

「集合が等しい」metadata パラメータ・ポリシーは、subset_of と superset_of を同一の配列値で組み合わせることで表現できる。

一部の JSON ライブラリは、JSON オブジェクトの比較に問題を持つ場合がある。この理由により、JSON オブジェクトである metadata 値に対して metadata policy を適用するサポートは、値の比較を要求しない essential operator に対してのみ必須である。JSON 配列に作用し、値の比較を要求する add、one_of、subset_of、superset_of については OPTIONAL である。value と default についても、値のマージやデフォルトの適用が、operator の値と既存値の比較を要求するため OPTIONAL である。

[RFC7591] で定義され、スペース区切りの文字列値の文字列として表現される OAuth 2.0 client metadata パラメータ scope は、default、subset_of、superset_of のような policy operators によって、文字列配列として扱われ処理されるべきである。結果として得られる scope metadata パラメータは、scope パラメータに metadata operators を適用して生成される配列値から取られた、個々の scope 値のスペース区切り文字列である。

以下の表は、essential と subset_of policy operators の組み合わせが、異なる input metadata パラメータ値に対して生成する出力の対応である。最後の行に示すとおり、metadata パラメータが存在せず任意（voluntary）と指定されている場合は、subset_of の検査はスキップされる。

Policy		Metadata Parameter
essential	subset_of	input	output
---	---	---	---
true	[a,b,c]	[a,e]	[a]
false	[a,b,c]	[a,e]	[a]
true	[a,b,c]	[d,e]	[]
false	[a,b,c]	[d,e]	[]
true	[a,b,c]	no parameter	error
false	[a,b,c]	no parameter	no parameter

6.1.3.2. Additional Operators

フェデレーションは、[Section 6.1.1] および [Section 6.1.3] の原則に適合する追加の metadata policy operators を指定し使用してもよい。

追加の operators は、[Section 6.1.3.1] で定義される標準 operators に対する適用順序に関して、以下の規則を遵守しなければならない:

metadata パラメータを変更する追加の operators は、[Section 6.1.3.1.1] で規定される value operator の後に適用されなければならない。
metadata パラメータを検査する追加の operators は、[Section 6.1.3.1.7] で規定される essential operator の前に適用されなければならない。

実装は、理解できない追加の operators を無視しなければならない。ただし、その operator 名が metadata_policy_crit Subordinate Statement Claim に含まれる場合は例外であり、その場合 operator は理解され処理されなければならない。metadata_policy_crit に列挙された追加 operator が理解されない、または処理できない場合、policy error を生成し、Trust Chain は無効と見なされなければならない。

6.1.4. Enforcement

このセクションは、Trust Chain の metadata policy の解決と、それを Trust Chain subject である Federation Entity の metadata に適用する方法を記述する。

metadata policy の解決またはその適用の間に、policy error または他のエラーに遭遇した場合、Trust Chain は無効と見なされなければならない。

6.1.4.1. Resolution

Trust Chain の metadata policy は、チェーンを構成する Subordinate Statements に存在する metadata_policy Claims の列によって決定される。

解決プロセスはまず、[Section 6.1.3.1] で定義される標準のもの以外の policy operators のうち、critical として宣言されているものの名前をすべて収集しなければならない。これは、Trust Chain 内の各 Subordinate Statement を調べ、[Section 3.1.3] で記述される OPTIONAL な metadata_policy_crit Claim を確認し、そこに見つかった operator 名を収集することで行う。

解決プロセスは、Subordinate Statements を反復処理（iteration）することで進む。この反復処理の順序は極めて重要であり、最も Superior な Entity が発行した Subordinate Statement から開始し、Trust Chain subject の Immediate Superior が発行した Subordinate Statement で終了しなければならない。

反復処理中の重要な作業の1つが metadata_policy の検証である。検証は、データ構造が準拠していること、そして各 metadata パラメータ・ポリシーが [Section 6.1.3] に記述され、かつ各 operator の仕様に従った「許可された operator の組み合わせ」のみを含むことを保証しなければならない。また、収集された metadata_policy_crit の値に含まれる名前のうち、理解され処理できない operators が metadata_policy に含まれていないことも保証しなければならない。検証に失敗した場合、policy error を生成しなければならない。

各反復ステップにおいて、Subordinate Statement に metadata_policy Claim が存在するかを確認しなければならない。最初に遭遇した metadata_policy は、上記のとおり検証され、その後に current metadata policy となる。

反復処理で次の subordinate metadata_policy Claim が得られた場合、それは上記のとおり検証され、その後 current metadata policy にマージされなければならない。

マージは、[Section 6.1.2] で記述される metadata_policy データ構造の3つのレベルそれぞれで、トップレベルから開始して行う:

Entity Types の metadata policies
Entity Type の metadata parameter policies
Entity Type の metadata parameter policy の operators

Entity Types の metadata policies のレベルでは、マージは次のとおり進む:

次の subordinate metadata_policy Claim が、current metadata policy にすでに存在する Entity Type の metadata policy を含む場合、それは次の下位レベル（metadata parameter policies）の規則に従ってマージされなければならない。
次の subordinate metadata_policy Claim にあり、current metadata policy に存在しない Entity Type metadata policies は、そこへコピーしなければならない。

metadata parameter policies のレベルでは、マージは次のとおり進む:

metadata パラメータ・ポリシーが current Entity Type metadata policy にすでに存在する場合、それは次の下位レベル（metadata パラメータ・ポリシーの operators）の規則に従ってマージされなければならない。結果の metadata パラメータ・ポリシーに、[Section 6.1.3] に記述され、かつ operator の仕様に従った許可されない組み合わせが含まれる場合、policy error を生成しなければならない。
current Entity Type metadata policy に存在しない subordinate metadata パラメータ・ポリシーは、そこへコピーしなければならない。

operators のレベルでは、マージは次のとおり進む:

operator が current metadata パラメータ・ポリシーにすでに存在する場合、subordinate operator の値は、[Section 6.1.3] に記述され、かつ operator の仕様に従ってマージされなければならない。operator 値のマージが許可されない、またはその他の理由で不成功の場合、policy error を生成しなければならない。
current metadata パラメータ・ポリシーに存在しない subordinate operators は、そこへコピーしなければならない。

metadata_policy Claim を持つそれ以上の Subordinate Statements が見つからない場合、current metadata policy が Trust Chain に対して解決された（resolved）ものとなる。

6.1.4.2. Application

Trust Chain subject についての Subordinate Statement が metadata Claim を含む場合、それはまず、[Section 3.1.1] の Claim 定義で記述されるとおりに適用しなければならない。その後にのみ、Resolved Metadata policy の適用を進められる。

[Section 6.1.4.1] で記述されるプロセスにおいて、metadata_policy Claim を持つ Subordinate Statements が Trust Chain 内に見つからなかった場合、Trust Chain subject の metadata は、その Entity Configuration に見つかる metadata に単純に解決され、Immediate Superior によって提供された metadata パラメータがそれに適用される。

Trust Chain に対して metadata policy が解決された場合、対応する metadata パラメータ・ポリシーが存在するすべての Entity Type metadata と metadata パラメータについて、含まれる policy operators を [Section 6.1.3] に記述され、かつ operator の仕様に従って適用しなければならない。operators は、各 operator に指定された絶対または相対の順序によって決定される列で、metadata パラメータに適用されなければならない。

metadata policies の適用が、違法またはその他の不正な Resolved Metadata を生じさせる場合、その metadata は破損しているものと見なされ、使用してはならない。

Trust Chain subject は、フェデレーション metadata policies の適用によって得られる Resolved Metadata をサポートでき、かつそれに準拠できることを検証する責任を負う。たとえば、結果の Resolved Metadata で要求される暗号アルゴリズムがサポートされているかの確認が含まれ得る。同様に、Trust Chain subject は、自身の Entity Types に必要な metadata パラメータがすべて存在し、Resolved Metadata におけるすべての metadata 値が有効であることを検証しなければならない。metadata policies が変更された場合、Trust Chain subjects はサポートと準拠を再評価する必要があるかもしれない。

6.1.5. Metadata Policy Example

以下は、OpenID relying party のための Trust Chain metadata policies を解決し適用する非規範的な例である。

まず、フェデレーション Trust Anchor の RPs 向け metadata_policy から開始する:

"metadata_policy": {
  "openid_relying_party": {
    "grant_types": {
       "default": \[
        "authorization_code"
      \],
      "subset_of": \[
        "authorization_code",
        "refresh_token"
      \],
      "superset_of": \[
        "authorization_code"
      \]
    },
    "token_endpoint_auth_method": {
      "one_of": \[
        "private_key_jwt",
        "self_signed_tls_client_auth"
      \],
      "essential": true
    },
    "token_endpoint_auth_signing_alg" : {
      "one_of": \[
        "PS256",
        "ES256"
      \]
    },
    "subject_type": {
      "value": "pairwise"
    },
    "contacts": {
      "add": \[
        "helpdesk@federation.example.org"
      \]
    }
  }
}

Figure 10: Example Metadata Policy of a Trust Anchor for RPs

次に、Intermediate 組織の Subordinate RPs 向け metadata_policy と、その Immediate Subordinate RPs のための metadata 値がある:

{
  "metadata_policy": {
    "openid_relying_party": {
      "grant_types": {
        "subset_of": \[
          "authorization_code"
        \]
      },
      "token_endpoint_auth_method": {
        "one_of": \[
          "self_signed_tls_client_auth"
        \]
      },
      "contacts": {
        "add": \[
          "helpdesk@org.example.org"
        \]
      }
    }
  },
  "metadata": {
    "openid_relying_party": {
      "sector_identifier_uri": "https://org.example.org/sector-ids.json",
      "policy_uri": "https://org.example.org/policy.html"
    }
  }
}

Figure 11: Example Metadata Policy and Metadata Values of an Intermediate Entity for RPs

Intermediate Entity の例の RP metadata policy を Trust Anchor の RP metadata policy にマージすると、Trust Chain に対して次のポリシーが生成される:

{
  "grant_types": {
    "default": \[
      "authorization_code"
    \],
    "superset_of": \[
      "authorization_code"
    \],
    "subset_of": \[
      "authorization_code"
    \]
  },
  "token_endpoint_auth_method": {
    "one_of": \[
      "self_signed_tls_client_auth"
    \],
    "essential": true
  },
  "token_endpoint_auth_signing_alg": {
    "one_of": \[
      "PS256",
      "ES256"
    \]
  },
  "subject_type": {
    "value": "pairwise"
  },
  "contacts": {
    "add": \[
      "helpdesk@federation.example.org",
      "helpdesk@org.example.org"
    \]
  }
}

Figure 12: Example Merged Metadata Policy for RPs

Trust Chain subject は Leaf Entity であり、Entity Configuration において次の RP metadata を公開する:

"metadata": {
  "openid_relying_party": {
    "redirect_uris": \[
      "https://rp.example.org/callback"
    \],
    "response_types": \[
      "code"
    \],
    "token_endpoint_auth_method": "self_signed_tls_client_auth",
    "contacts": \[
      "rp_admins@rp.example.org"
    \]
  }
}

Figure 13: Example Entity Configuration RP Metadata

Intermediate Entity が Immediate Subordinates のために指定した metadata 値が Trust Chain subject の metadata に適用される。その後、マージされた metadata policy が適用され、次の結果の RP Resolved Metadata が生成される:

{
  "redirect_uris": \[
    "https://rp.example.org/callback"
  \],
  "grant_types": \[
    "authorization_code"
  \],
  "response_types": \[
    "code"
  \],
  "token_endpoint_auth_method": "self_signed_tls_client_auth",
  "subject_type": "pairwise",
  "sector_identifier_uri": "https://org.example.org/sector-ids.json",
  "policy_uri": "https://org.example.org/policy.html",
  "contacts": \[
    "rp_admins@rp.example.org",
    "helpdesk@federation.example.org",
    "helpdesk@org.example.org"
  \]
}

Figure 14: The Resulting RP Resolved Metadata for the Trust Chain Subject

6.2. Constraints

Trust Anchors と Intermediate Entities は、自身の Subordinates に適用される制約条件（constraining criteria）を定義してもよい。これは [Section 3.1.3] で記述されるとおり、Subordinate Statement の constraints Claim で表現される。

以下の constraint パラメータが定義される:

max_path_length

OPTIONAL. 制約を設定する Entity と Trust Chain subject の間にある Intermediate Entities の最大数を指定する整数。

naming_constraints

OPTIONAL. Subordinate Entities の Entity Identifiers の URIs に対する制約を指定する JSON オブジェクト。制約は、許可される／除外される URI name subtrees の観点で定義される。

allowed_entity_types

OPTIONAL. 文字列の Entity Type Identifiers の配列。Entity Type Identifiers は [Section 5.1] で定義される。この制約は、Subordinate Entities が持つことを許可される Entity Types、ひいては metadata を指定する。

追加の constraint パラメータも定義され、使用されてもよい。理解されない場合、それらは無視しなければならない。

以下は、一連の constraints の非規範的な例である:

{
  "max_path_length": 2,
  "naming_constraints": {
    "permitted": \[
      ".example.com"
    \],
    "excluded": \[
      "east.example.com"
    \]
  },
  "allowed_entity_types": \[
    "openid_provider",
    "openid_relying_party"
  \]
}

Figure 15: Example Set of Constraints

Entity の Trust Chain を解決する際、各 Subordinate Statement の constraints Claim は、存在する場合それぞれ独立に適用しなければならない。constraints の検査のいずれかが失敗した場合、Trust Chain は無効と見なされなければならない。

6.2.1. Max Path Length Constraint

max_path_length 制約は、制約を設定する Trust Anchor または Intermediate と Trust Chain subject の間にある Trust Chain 内で許容される Intermediate Entities の最大数を指定する。

max_path_length 制約が 0 の場合、この Entity と Trust Chain subject の間に Intermediates が現れてもよいことを示す。max_path_length 制約は 0 以上の値を持たなければならない。

max_path_length 制約を省略することは、すでに有効な制約以外に追加の制約がないことを意味する。

4つの Entity Statements からなる Trust Chain があると仮定する:

Leaf Entity (LE) の Entity Configuration
Intermediate 1 (I1) が LE について発行した Subordinate Statement
Intermediate 2 (I2) が I1 について発行した Subordinate Statement
Trust Anchor (TA) が I2 について発行した Subordinate Statement

このとき、Trust Chain は、たとえば次の場合に constraints を満たす:

TA が 2 以上の max_path_length を指定する。
TA が max_path_length に 2 を指定し、I2 が max_path_length に 1 を指定し、I1 が max_path_length 制約を省略する。
TA も I2 も max_path_length 制約を指定せず、I1 が max_path_length を 0 に設定する。

一方、たとえば次の場合、Trust Chain は constraints を満たさない:

TA が max_path_length を 1 に設定する。

6.2.2. Naming Constraints

naming_constraints メンバーは、Trust Chain 内の Subordinate Entities の Entity Identifiers が配置されなければならない URI 名前空間を指定する。

制約は URI name subtrees の観点で定義され、naming_constraints メンバーの中の permitted および／または excluded メンバーを用いる。それぞれは、許可または除外される名前の配列を含む。excluded リスト内の制約に一致する任意の名前は、permitted リストに現れる情報にかかわらず無効である。

本仕様は [RFC5280] の Section 4.2.1.10 で規定されるドメイン名制約の構文を使用する。そこに述べられるとおり、ドメイン名制約は完全修飾ドメイン名として指定されなければならず、host または domain を指定してもよい。例として "host.example.com" と ".example.com" がある。ドメイン名制約がピリオドで始まる場合、1つ以上のラベルで展開してもよい。つまり ".example.com" のドメイン名制約は、host.example.com と my.host.example.com の両方で満たされる。ただし ".example.com" のドメイン名制約は "example.com" では満たされない。ドメイン名制約がピリオドで始まらない場合、それは host を指定する。RFC 5280 と同様に、ドメイン名制約は URI の host 部分に適用される。

6.2.3. Entity Type Constraints

allowed_entity_types 制約は、Trust Chain 内の Subordinate Entities が持つことが許容される metadata Entity Types を指定する。allowed_entity_types 制約がない場合、任意の Entity Type が許可されることを意味する。[Section 5.1.1] で規定される federation_entity Entity Type Identifier は常に許可され、制約に含めてはならない。制約が空配列 [] の場合、federation_entity Entity Type のみが許可されることを意味する。

Trust Chain Resolution の間に allowed_entity_types 制約を適用するために、allowed_entity_types 制約に列挙されていないすべての Entity Types を、subject の Entity Configuration の metadata Claim から削除しなければならない。federation_entity Entity Type は削除してはならない。これは、Metadata Policies を適用する前、かつ、direct superior の Subordinate Statement からの Metadata を適用した後に行わなければならない。

7. Trust Marks

[Section 1.2] の定義に従い、Trust Marks は、認定機関によって定められた基準の集合への適合の表明である。本仕様で使用される Trust Marks は署名付き JWT である。Entity Statements は、[Section 3.1.2] の trust_marks Claim 定義で記述されるとおり、Trust Marks を含んでもよい。

Trust Marks は、Trust Mark Issuer と呼ばれるフェデレーション認定の権限によって署名される。すべての Trust Mark Issuers は、フェデレーション内で Entity によって表現されなければならない。Trust Mark Issuer がフェデレーションによって受け入れられている事実は、Trust Anchor の Entity Configuration にある trust_mark_issuers Claim で表現される。

Trust Mark issuer が Trust Marks に署名するために使用する鍵は、その Federation Entity Keys の集合に含まれる秘密鍵のいずれかでなければならない。

Trust Mark JWTs は、使用した署名鍵の Key ID を値とする kid（Key ID）ヘッダーパラメータを必ず含めなければならない。

フェデレーションは、Entity が Trust Marks を自己署名することを許可してもよい点に注意すること。

Trust Mark JWTs は、[RFC8725] の Section 3.11 に従い、クロス JWT の混同を防ぐため typ ヘッダーパラメータを使用して明示的に型付けされなければならない。typ ヘッダーパラメータ値は、使用される信頼フレームワークが特定種類の Trust Mark のためにより具体的な media type 値を定義していない限り、trust-mark+jwt でなければならない。typ ヘッダーパラメータがない Trust Marks、または認識されない typ 値を持つ Trust Marks は拒否しなければならない。

以下は trust_mark_issuers Claim の非規範的な例である:

"trust_mark_issuers":
{
  "https://openid.net/certification/op": \[\],
  "https://refeds.org/wp-content/uploads/2016/01/Sirtfi-1.0.pdf":
    \["https://swamid.se"\]
}

Figure 16: Example trust_mark_issuers Claim

7.1. Trust Mark Claims

Trust Mark における Claims は次のとおりである:

iss

REQUIRED. 文字列。Trust Mark の issuer の Entity Identifier。

sub

REQUIRED. 文字列。この Trust Mark が適用される Entity の Entity Identifier。

trust_mark_type

REQUIRED. trust_mark_type Claim は、Trust Marks において Trust Mark の type の識別子を提供するために使用される。Trust Mark type identifier は、複数のフェデレーション間で衝突耐性（collision-resistant）を持たなければならない。識別子の値は、それが発行されたフェデレーション、またはその中の trust framework を一意に識別する URL を用いて構築することが推奨される。これは、異なるフェデレーションで発行された Trust Marks が識別子の衝突を起こすことを防ぐために必要である。

iat

REQUIRED. 数値。この Trust Mark が発行された時刻。[RFC7519] に従い、Seconds Since the Epoch で表す。

logo_uri

OPTIONAL. 文字列。発行された Trust Mark のロゴを参照する URL。このフィールドの値は、有効な画像ファイルを指さなければならない。

exp

OPTIONAL. 数値。この Trust Mark が有効でなくなる時刻。[RFC7519] に従い、Seconds Since the Epoch で表す。存在しない場合、Trust Mark は失効しないことを意味する。

ref

OPTIONAL. [Section 13.5] で定義される ref（reference）Claim は、Trust Mark の発行についての人間が読める情報を参照する URL を提供するために Trust Marks で使用される。

delegation

OPTIONAL. [Section 13.6] で定義される delegation Claim は、特定の識別子を持つ Trust Marks を発行する権利を委任するために Trust Marks で使用される。値は [Section 7.2.1] で定義される Trust Mark delegation JWT である。

上記の Claims と併用して、追加の Claims を定義し使用してもよい。

7.2. Trust Mark Delegation

Trust Mark の owner が、管理上または技術上の要件により、何らかの理由で Trust Mark Issuer と一致しないケースがある。例として車両検査を挙げる。車両検査は多くの国で国または地方政府によって義務付けられた手続きであり、安全性、排出、またはその両方を規制に適合させるために車両を検査する。検査を義務付ける主体が検査を実施するわけではなく、代わりに商業会社が検査を実施し、その後 Trust Mark を発行する場合がある。

Trust Mark が owner ではない Trust Mark Issuer によって発行される事実は、Trust Mark に delegation Claim を含めることで表現され、その値は [Section 7.2.1] で定義される Trust Mark delegation JWT である。

Federation Operator が、ある Trust Mark type identifier を持つ Trust Marks が、owner ではない Trust Mark Issuers によって正当に発行され得ることを知っている場合、その owner と Trust Mark type identifier に関する情報は、Trust Anchor の Entity Configuration にある trust_mark_owners Claim に含めなければならない。

以下は trust_mark_owners Claim の非規範的な例である:

"trust_mark_owners":
{
  "https://refeds.org/wp-content/uploads/2016/01/Sirtfi-1.0.pdf":
  {
    "sub": "https://refeds.org/sirtfi",
    "jwks" : {
      "keys": \[
        {
          "alg": "RS256",
          "e": "AQAB",
          "kid": "Jlob6qNFuSHj3sfuntz9C\_9s...",
          "kty": "RSA",
          "n": "\_LioMsSeycE4pELlpPYgZluB...",
          "use": "sig"
        }
      \]
    }
  }
}

Figure 17: Example trust_mark_owners Claim

7.2.1. Trust Mark Delegation JWT

Trust Mark Delegation JWT は、Trust Mark Owner によって発行される署名付き JWT であり、特定の識別子を持つ Trust Marks の正当な委任発行者（delegated issuer）を識別する。

Trust Mark delegation JWT は、[RFC8725] の Section 3.11 に従い、クロス JWT の混同を防ぐため、typ ヘッダーパラメータを trust-mark-delegation+jwt に設定して明示的に型付けされなければならない。typ ヘッダーパラメータがない Trust Mark delegation JWT、または異なる typ 値を持つものは拒否しなければならない。これは Federation Entity Key で署名される。

Trust Mark delegation JWTs は、使用した署名鍵の Key ID を値とする kid（Key ID）ヘッダーパラメータを必ず含めなければならない。

Trust Mark delegation JWT における Claims は次のとおりである:

iss

REQUIRED. 文字列。Trust Mark の owner。

sub

REQUIRED. 文字列。この委任が適用される Entity。

trust_mark_type

REQUIRED. 文字列。Trust Mark の type の識別子。

iat

REQUIRED. 数値。この委任が発行された時刻。[RFC7519] に従い、Seconds Since the Epoch で表す。

exp

OPTIONAL. 数値。この委任が有効でなくなる時刻。[RFC7519] に従い、Seconds Since the Epoch で表す。存在しない場合、この委任は失効しないことを意味する。

ref

OPTIONAL. 文字列。Trust Mark に関連する、人間が読める情報を指す URL。

上記の Claims と併用して、追加の Claims を定義し使用してもよい。

7.2.2. Validating a Trust Mark Delegation

Trust Mark Delegation の検証とは、特定の署名付き JWT によって表現される Trust Mark Delegation インスタンスを検証することを意味する。

以降、「delegation」は Trust Mark Delegation JWT の略記として用いる。下記で参照される Trust Anchor は、Trust Mark Issuer に対する信頼を確立する際に成功裏に使用された Trust Anchor である。

delegation を検証するには、以下の検証ステップを実行しなければならない。以下の検証チェックのいずれかが失敗した場合、検証プロセス全体が失敗し、delegation は無効と見なされることに注意すること。

delegation は署名付き JWT でなければならない。
delegation は、値が trust-mark-delegation+jwt である typ ヘッダーを持たなければならない。
delegation は、受理可能な JWS 署名アルゴリズムである値を持つ alg（algorithm）ヘッダーパラメータを持たなければならず、none であってはならない。
Trust Mark Issuer の Entity Identifier は、delegation における sub の値と一致しなければならない。
Trust Mark Owner の Entity Identifier は、delegation における iss の値と一致しなければならない。
現在時刻は、delegation における iat（issued at）Claim が表す時刻より後でなければならない（時計のずれを考慮して小さな猶予を認めてもよい）。
delegation に exp（expiration）Claim が存在する場合、現在時刻はそれが表す時刻より前でなければならない（時計のずれを考慮して小さな猶予を認めてもよい）。
delegation における trust_mark_type Claim の値は、Trust Mark における trust_mark_type Claim の値と同一でなければならない。
delegation の署名は、ヘッダーパラメータ kid の値で識別される Trust Mark Owner の鍵のいずれかを用いて検証できなければならない。Trust Mark Owner の鍵は、Trust Anchor の Entity Configuration にある trust_mark_owners Claim で見つけられる。

7.3. Validating a Trust Mark

Trust Mark の検証とは、特定の署名付き JWT によって表現される Trust Mark インスタンスを検証することを意味する。これは、特定種類の Trust Mark が存在し得るかどうかを検証することではない。

Trust Mark に対する信頼よりも先に、Trust Mark Issuer に対する信頼がある。Trust Mark Issuer が信頼されないなら Trust Mark は信頼できない。したがって Entity は、下記で定義される Trust Mark 検証プロセスを開始する前に、[Section 10] で定義される手順に従って Trust Mark Issuer に対する信頼を確立しなければならない。

以降、「instance」は Trust Mark instance の略記として用いる。下記で参照される Trust Anchor は、Trust Mark Issuer に対する信頼を確立する際に成功裏に使用された Trust Anchor である。

instance を検証するには、以下の検証ステップを実行しなければならない。以下の検証チェックのいずれかが失敗した場合、検証プロセス全体が失敗し、instance は無効と見なされることに注意すること。

instance は署名付き JWT でなければならない。
instance は、値が trust-mark+jwt である typ ヘッダーを持たなければならない。
instance は、受理可能な JWS 署名アルゴリズムである値を持つ alg（algorithm）ヘッダーパラメータを持たなければならず、none であってはならない。
instance を含む Entity Configuration を持つ Entity の Entity Identifier は、Trust Mark における sub Claim の値と一致しなければならない。
現在時刻は、iat（issued at）Claim が表す時刻より後でなければならない（時計のずれを考慮して小さな猶予を認めてもよい）。
現在時刻は、exp（expiration）Claim が表す時刻より前でなければならない（時計のずれを考慮して小さな猶予を認めてもよい）。
instance の署名は、kid 値で識別される Trust Mark issuer の鍵を用いて検証できなければならない。
instance の trust_mark_type が Trust Anchor の Entity Configuration にある trust_mark_owners Claim に現れる場合、instance は delegation Claim を含まなければならない。
instance に delegation Claim がある場合、その Claim の値は [Section 7.2.2] に従って検証されなければならない。

Trust Marks が失効時刻なしで発行される場合、それらを検証するための仕組み（Trust Mark Status endpoint および／または Trust Marked Entities Listing endpoint など）を提供することが推奨される。

上記の Trust Marks 検証手順の代替として、実装は [Section 8.4] に記述されるとおり Trust Mark Status endpoint を用いて、Trust Mark が有効であり、なおアクティブであることを検証してもよい。

7.4. Trust Mark Examples

Entity Configuration の JWT Claims Set における trust_marks Claim の非規範的な例を以下に示す:

{
  "iss": "https://rp.example.it/spid",
  "sub": "https://rp.example.it/spid",
  "iat": 1516239022,
  "exp": 1516843822,
  "trust_marks": \[
    {
     "trust_mark_type": "https://www.spid.gov.it/certification/rp",
     "trust_mark":
       "eyJ0eXAiOiJ0cnVzdC1tYXJrK2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoia29
        zR20yd3VaaDlER21OeEF0a3VPNDBwUGpwTDMtakNmMU4tcVBPLVllVSJ9.
        eyJpc3MiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdCIsInN1YiI6Imh0dHBzOi8
        vcnAuZXhhbXBsZS5pdC9zcGlkIiwiaWF0IjoxNTc5NjIxMTYwLCJ0cnVzdF9tYX
        JrX3R5cGUiOiJodHRwczovL3d3dy5zcGlkLmdvdi5pdC9jZXJ0aWZpY2F0aW9uL
        3JwIiwibG9nb191cmkiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdC90aGVtZXMv
        Y3VzdG9tL2FnaWQvbG9nby5zdmciLCJyZWYiOiJodHRwczovL2RvY3MuaXRhbGl
        hLml0L2RvY3Mvc3BpZC1jaWUtb2lkYy1kb2NzL2l0L3ZlcnNpb25lLWNvcnJlbn
        RlLyJ9.
        L\_pSh1InEiFAcs3E-1HBM7fNZYwF5ru3UGA\_8yc80dGS3sszfA\_sbj4AoW\_zAJW
        QBdZpjxnHBBmybYXFrfZBcqxcedsrvUYrmbt1nPYxbUE54fRRoZK-sJmVqh1GzS
        an5nOmkxuAtMinU8k\_-aWnPWj83sYe2AzT2mMgkXiz8zhda3jZm8hoxZ4jR6B0Y
        AvbMlq2pPWO5OWKdZhiFRMSprwh0GYluQkK0j1aLNMGXD3keMJd2zEoWX9D7w2f
        XShAA48W3cNhuXyBVnCoum1K4IWK3s\_fx4nIkp6W-V4jCBOpxp7Yo8LZ30o\_xpE
        OzGTIECGWVR86azOAlwVC8XSiAA"
    }
  \],
  "metadata": {
    "openid_relying_party": {
      "application_type": "web",
      "client_registration_types": \["automatic"\],
      "client_name": "https://rp.example.it/spid",
      "contacts": \[
        "ops@rp.example.it"
      \]
    }
  }
}

Figure 18: Trust Mark in an Entity Configuration JWT Claims Set

An RP に対して発行され、国の公共サービス・プロファイルへの適合を証明する Trust Mark payload をデコードした例:

{
  "trust_mark_type": "https://mushrooms.federation.example.com/openid_relying_party/public/",
  "iss": "https://epigeo.tm-issuer.example.it",
  "sub": "https://porcino.example.com/rp",
  "iat": 1579621160,
  "organization_name": "Porcino Mushrooms & Co.",
  "policy_uri": "https://porcino.example.com/privacy_policy",
  "tos_uri": "https://porcino.example.com/info_policy",
  "service_documentation": "https://porcino.example.com/api/v1/get/services",
  "ref": "https://porcino.example.com/documentation/manuale_operativo.pdf"
}

Figure 19: Trust Mark for a National Profile

An RP に対して発行され、未成年ユーザーのデータ管理ルールへの適合を証明する Trust Mark payload をデコードした例:

{
  "trust_mark_type": "https://mushrooms.federation.example.com/openid_relying_party/private/under-age",
  "iss": "https://trustissuer.pinarolo.example.it",
  "sub": "https://vavuso.example.com/rp",
  "iat": 1579621160,
  "organization_name": "Pinarolo Suillus luteus",
  "policy_uri": "https://vavuso.example.com/policy",
  "tos_uri": "https://vavuso.example.com/tos"
}

Figure 20: Trust Mark Issued to an RP

2つの組織の Entities 間で合意が締結されたことを証明する Trust Mark payload をデコードした例:

{
  "trust_mark_type": "https://mushrooms.federation.example.com/arrosto/agreements",
  "iss": "https://agaricaceae.example.it",
  "sub": "https://coppolino.example.com",
  "iat": 1579621160,
  "logo_uri": "https://coppolino.example.com/sgd-cmyk-150dpi-90mm.svg",
  "organization_type": "public",
  "id_code": "123456",
  "email": "info@coppolino.example.com",
  "organization_name#it": "Mazza di Tamburo",
  "policy_uri#it": "https://coppolino.example.com/privacy_policy",
  "tos_uri#it": "https://coppolino.example.com/info_policy",
  "service_documentation": "https://coppolino.example.com/api/v1/get/services",
  "ref": "https://agaricaceae.example.it/documentation/agaricaceae.pdf"
}

Figure 21: Trust Mark Attesting to an Agreement Between Entities

セキュリティ・プロファイルへの適合を主張する Trust Mark payload をデコードした例:

{
  "trust_mark_type": "https://mushrooms.federation.example.com/ottimo/commestibile",
  "iss": "https://cantharellus.cibarius.example.org",
  "sub": "https://gallinaccio.example.com/op",
  "iat": 1579621160,
  "logo_uri": "https://cantharellus.cibarius/static/images/cantharellus-cibarius.svg",
  "ref": "https://cantharellus.cibarius/cantharellus/cibarius"
}

Figure 22: Trust Mark Asserting Conformance to a Security Profile

self-signed Trust Mark をデコードした例:

{
  "trust_mark_type": "https://mushrooms.federation.example.com/trust-marks/self-signed",
  "iss": "https://amanita.muscaria.example.com",
  "sub": "https://amanita.muscaria.example.com",
  "iat": 1579621160,
  "logo_uri": "https://amanita.muscaria.example.com/img/amanita-mus.svg",
  "ref": "https://amanita.muscaria.example.com/uploads/cookbook.zip"
}

Figure 23: Self-Signed Trust Mark

Trust Marks の第三者認定機関（accreditation authority）の例:

{
  "iss": "https://swamid.se",
  "sub": "https://umu.se/op",
  "iat": 1577833200,
  "exp": 1609369200,
  "trust_mark_type": "https://refeds.org/wp-content/uploads/2016/01/Sirtfi-1.0.pdf"
}

Figure 24: Third-Party Accreditation Authority for Trust Marks

7.5. Trust Mark Delegation Example

Trust Mark が、別の Entity を代表して Trust Marks を発行する Entity によって発行される Entity Configuration の JWT Claims Set における trust_marks Claim の非規範的な例を示す。Trust Mark が owner ではない Trust Mark Issuer によって発行される事実は、Trust Mark に delegation Claim を含めることで表現され、その値は署名付き JWT である。

{
  "delegation":
    "eyJ0eXAiOiJ0cnVzdC1tYXJrLWRlbGVnYXRpb24rand0IiwiYWxnIjoiUl
    MyNTYiLCJraWQiOiJrb3NHbTJ3dVpoOURHbU54QXRrdU80MHBQanBMMy1qQ
    2YxTi1xUE8tWWVVIn0.
    eyJzdWIiOiJodHRwczovL3RtaS5leGFtcGxlLm9yZyIsInRydXN0X21hcmt
    fdHlwZSI6Imh0dHBzOi8vcmVmZWRzLm9yZy9zaXJ0ZmkiLCJpc3MiOiJodH
    RwczovL3RtX293bmVyLmV4YW1wbGUub3JnIiwiaWF0IjoxNzI1MTc2MzAyfQ.
    ao0rWGpVjEgpNyFxsKawps8q71eYnp78TzRdY4P52
    CT8QX6etXt-2L2Z1Vw5A6jx2mhjpPwWi\_sOxfiOSA5TugJfN0Gbwj7teTzM
    0IMciuasCWgnLrKyLZjS147ZE50I9e9P8Ot8UQwhmXcLiuwsbDxSdqM4pVp
    75lfWnmzPH0L2pDZG5COFgIgSOAlK3TVMBOR8fziF-VmWNPzAfB0lSc-hjH
    -7q66GyT43o3Exnm6DsoLxyB8bxG99BQltLxURDT90CzM6szGcF3OG64Rbe
    0I4lT\_LAOfvhlrRbT56eK4sJNCsbVbGnDBfFmyfB\_HIeBMGP0L7T5JPMOUU
    9bjIlA",
  "iat": 1725176302,
  "trust_mark_type": "https://refeds.org/sirtfi",
  "sub": "https://entity.example.org",
  "exp": 1727768302,
  "iss": "https://tmi.example.org"
}

Figure 25: Example JWT Claims Set of a Trust Mark using Delegation

上記の "delegation" Claim にある Trust Mark delegation JWT の JWS Header Parameters:

{
  "typ": "trust-mark-delegation+jwt",
  "alg": "RS256",
  "kid": "kosGm2wuZh9DGmNxAtkuO40pPjpL3-jCf1N-qPO-YeU"
}

Figure 26: Trust Mark Delegation JWT JWS Header Parameters

上記の "delegation" Claim にある Trust Mark delegation JWT の JWT Claims Set:

{
  "sub": "https://tmi.example.org",
  "trust_mark_type": "https://refeds.org/sirtfi",
  "iss": "https://tm_owner.example.org",
  "iat": 1725176302
}

Figure 27: Trust Mark Delegation JWT Claim Set

8. Federation Endpoints

Entity の federation endpoints は、[Section 9] で記述される configuration response、または他の手段により見つけられる。

すべての federation endpoints について、最初に規定されたものを超える追加の request parameters を定義し使用してもよい。理解されない場合、それらは無視しなければならない。

8.1. Fetching a Subordinate Statement

fetch endpoint は、Trust Chains を組み立てる際に Subordinate Statements を1つずつ収集するために使用される。Subordinates を持つ Entity は fetch endpoint を公開しなければならない。Entity は、Immediate Subordinates についての Subordinate Statements を、自身の fetch endpoint を通じて公開しなければならない。

fetch endpoint の場所は、[Section 5.1.1] で定義される federation_entity metadata の federation_fetch_endpoint パラメータにより公開される。この endpoint は Trust Chains の構築と検証に使用されるため、その場所は、Superiors からの metadata と metadata policies を適用する前に利用可能でなければならない。したがって、この endpoint は Subordinate Statements ではなく、Entity Configuration metadata に直接公開されなければならない。

Subordinate Statement を fetch するには、問い合わせ先の Entity の identifier（issuer）、その Entity の fetch endpoint、そして Subordinate Statement の subject の Entity Identifier を知る必要がある。issuer は通常、Subordinate Statement の subject の Immediate Superior である。

8.1.1. Fetch Subordinate Statement Request

client authentication を使用しない場合、リクエストは GET メソッドを使用する fetch endpoint への HTTP リクエストでなければならず、次の query parameter を application/x-www-form-urlencoded 形式でエンコードする。リクエストは指定された issuer の fetch endpoint に対して行われる。

sub

REQUIRED. Subordinate Statement を要求している subject の Entity Identifier。

client authentication を使用する場合、リクエストは POST メソッドを使用する HTTP リクエストでなければならず、パラメータは POST body に渡される。

以下は、edugain.org から https://sunet.se についての Subordinate Statement を取得する HTTP GET リクエストの非規範的な例である:

GET /federation_fetch_endpoint?
sub=https%3A%2F%2Fsunet%2Ese HTTP/1.1
Host: edugain.org

Figure 28: API Request for a Subordinate Statement

8.1.2. Fetch Subordinate Statement Response

成功レスポンスは、レスポンスが Entity Statement を含むことを明確にするため、HTTP ステータスコード 200 と content type application/entity-statement+jwt を使用しなければならない。エラーレスポンスの場合は JSON オブジェクトになり、content type は application/json でなければならない。fetch endpoint が要求された sub パラメータのデータを提供できない場合、not_found エラーコードを返すことが推奨される。sub パラメータが Issuing Entity の Entity Identifier を参照している場合、invalid_request エラーコードを返すことが推奨される。エラーレスポンスについては [Section 8.9] を参照。

以下は、fetch response の JWT Claims Set の非規範的な例である:

{
  "iss": "https://edugain.org",
  "sub": "https://sunet.se",
  "exp": 1568397247,
  "iat": 1568310847,
  "source_endpoint": "https://edugain.org/federation_fetch_endpoint",
  "jwks": {
    "keys": \[
      {
        "e": "AQAB",
        "kid": "dEEtRjlzY3djcENuT01wOGxrZlkxb3RIQVJlMTY0...",
        "kty": "RSA",
        "n": "x97YKqc9Cs-DNtFrQ7_vhXoH9bwkDWW6En2jJ044yH..."
      }
    \]
  },
  "metadata":{
    "federation_entity": {
        "organization_name": "SUNET"
    }
  }
  "metadata_policy": {
    "openid_provider": {
      "subject_types_supported": {
        "value": \[
          "pairwise"
        \]
      },
      "token_endpoint_auth_methods_supported": {
        "default": \[
          "private_key_jwt"
        \],
        "subset_of": \[
          "private_key_jwt",
          "client_secret_jwt"
        \],
        "superset_of": \[
          "private_key_jwt"
        \]
      }
    }
  }
}

Figure 29: Fetch Response JWT Claims Set

8.2. Subordinate Listing

listing endpoint は、Trust Anchor、Intermediate、または Trust Mark Issuer として振る舞う Federation Entities によって公開される。この endpoint は、Trust Anchor、Intermediate、または Trust Mark Issuer が Entity Statements を発行する対象である Immediate Subordinates を一覧する。

Trust Mark Issuer として、この endpoint は、下記で定義される Trust Mark filtering を、当該 endpoint を公開する issuer がサポートする場合、Trust Marks が発行され、かつなお有効である Immediate Subordinates を一覧してもよい。

いずれの場合でも、結果に含まれるリストは非常に大きくなり得る。

list endpoint の場所は、[Section 5.1.1] で定義される federation_entity metadata の federation_list_endpoint パラメータにより公開される。この endpoint は Subordinate Statements ではなく、Entity Configuration metadata に直接公開されなければならない。

次の例は、Subordinate listing endpoints を通じて発見・収集された、Trust Anchor、Intermediate Entities、Leaf Entities を含む同一フェデレーションに属する Entities のツリーを示す:

                       +----------------------+
                       |    Trust Anchor      |
                       +----------------------+
       +---------------+ Subordinate Listing  +--------------+
       |               +----------+-----------+              |
       |                          |                          |
       |                          |                          |
       |                          |                          |
       |                          |                          |
       |                          |                          |
+------v-------+       +----------v-----------+       +------v-------+
|     Leaf     |       |     Intermediate     |       |     Leaf     |
+--------------+       +----------------------+       +--------------+
                  +----+ Subordinate Listing  |
                  |    +------------+---------+
                  |                 |
                  |                 |
                  |                 |
       +----------v-----------+     |
       |     Intermediate     |     |
       +----------------------+     |
       | Subordinate Listing  |     |
       +-+---------+----------+     |
         |         |                |
         |         |                |
 +-------v--+     +v--------+    +--v------+
 |  Leaf    |     |  Leaf   |    |  Leaf   |
 +----------+     +---------+    +---------+

Figure 30: Tree of Entities in a Federation Collected through Subordinate Listing Endpoints

8.2.1. Subordinate Listing Request

client authentication を使用しない場合、リクエストは GET メソッドを使用する list endpoint への HTTP リクエストでなければならず、次の query parameters を application/x-www-form-urlencoded 形式でエンコードする。

entity_type

OPTIONAL. このパラメータの値は Entity Type Identifier である。responder が自身の Immediate Subordinates の Entity Types を知っている場合、結果は指定された Entity Type を含むものだけを含むようにフィルタリングされなければならない。entity_type=openid_provider&entity_type=openid_relying_party のように複数の entity_type パラメータがある場合、結果は指定されたすべての Entity Types を含むものだけを含むようにフィルタリングされなければならない。responder がこの機能をサポートしない場合、HTTP ステータスコード 400 と content type application/json を使用し、エラーコード unsupported_parameter を返さなければならない。

trust_marked

OPTIONAL. 真偽値。trust_marked パラメータが存在し、かつ true に設定されている場合、結果には、少なくとも1つの Trust Mark が発行され、かつなお有効である Immediate Subordinates のみが含まれる。responder がこの機能をサポートしない場合、HTTP ステータスコード 400 を使用し、content type を application/json に設定し、エラーコード unsupported_parameter を返さなければならない。

trust_mark_type

OPTIONAL. このパラメータの値は Trust Mark の type の識別子である。responder が指定された Trust Mark type identifier を持つ Trust Marks を発行している場合、レスポンス内のリストは、その Trust Mark type identifier が発行され、かつなお有効である Immediate Subordinates のみを含むようにフィルタリングされる。responder がこの機能をサポートしない場合、HTTP ステータスコード 400 を使用し、content type を application/json に設定し、エラーコード unsupported_parameter を返さなければならない。

intermediate

OPTIONAL. 真偽値。intermediate パラメータが存在し、かつ true に設定されている場合、responder が自身の Immediate Subordinates が Intermediates であるかどうかを知っているなら、結果はそれに従ってフィルタリングされなければならない。responder がこの機能をサポートしない場合、HTTP ステータスコード 400 と content type application/json を使用し、エラーコード unsupported_parameter を返さなければならない。

client authentication を使用する場合、リクエストは POST メソッドを使用する HTTP リクエストでなければならず、パラメータは POST body に渡される。

以下は、Immediate Subordinates のリストに対する HTTP GET リクエストの非規範的な例である:

GET /list HTTP/1.1
Host: sunet.se

Figure 31: Subordinate Listing Request

8.2.2. Subordinate Listing Response

成功レスポンスは、HTTP ステータスコード 200 と content type application/json を使用し、既知の Entity Identifiers を含む JSON 配列を含まなければならない。

エラーレスポンスは [Section 8.9] で定義されるとおりである。

以下は、Immediate Subordinate Entities を含むレスポンスの非規範的な例である:

200 OK
Content-Type: application/json

\[
  "https://ntnu.andreas.labs.uninett.no",
  "https://blackboard.ntnu.no/openid/callback",
  "https://serviceprovider.andreas.labs.uninett.no/application17"
\]

Figure 32: Subordinate Listing Response

8.3. Resolve Entity

Entity は、resolve endpoint を使用して、ある Entity の Resolved Metadata、使用された Trust Chain、そして Trust Marks を取得してもよい。resolver は subject の Entity Configuration を取得し、subject の Entity Configuration から始まり指定された Trust Anchor の Entity Configuration で終わる Trust Chain を組み立て、Trust Chain を検証し、その後 Trust Chain に存在するすべてのポリシーを subject の metadata に適用する。

resolver は、Federation 内で認識される識別子を持つ Trust Marks が存在する場合、それらがアクティブであることを必ず検証しなければならない。レスポンス集合は、検証済みの Trust Marks のみを含まなければならない。

resolve endpoint の場所は、[Section 5.1.1] で定義される federation_entity metadata の federation_resolve_endpoint パラメータにより公開される。

8.3.1. Resolve Request

client authentication を使用しない場合、リクエストは GET メソッドを使用する resolve endpoint への HTTP リクエストでなければならず、次の query parameters を application/x-www-form-urlencoded 形式でエンコードする。

sub

REQUIRED. resolved data を要求している Entity の Entity Identifier。

trust_anchor

REQUIRED. metadata を解決する際に resolve endpoint が使用しなければならない Trust Anchor。値は Entity Identifier である。

trust_anchor request parameter は複数回出現してもよく、その場合 resolver は、与えられた Trust Anchor 値のいずれかを用いた successful resolve response を返してもよい。

entity_type

OPTIONAL. 解決対象の特定の Entity Type。値は [Section 5.1] で規定される Entity Type Identifier である。このパラメータが存在しない場合、すべての Entity Types が返される。

entity_type request parameter は複数回出現してもよく、その場合、entity_type パラメータ値に含まれる Entity Type Identifier ごとに、その Entity Type のデータが返される。

client authentication を使用する場合、リクエストは POST メソッドを使用する HTTP リクエストでなければならず、パラメータは POST body に渡される。

以下は Resolve Request の非規範的な例である:

GET /resolve?
sub=https%3A%2F%2Fop.example.it%2Fspid&
entity_type=openid_provider&
trust_anchor=https%3A%2F%2Fswamid.se HTTP/1.1
Host: sunet.se

Figure 33: Resolve Request

8.3.2. Resolve Response

成功レスポンスは、HTTP ステータスコード 200 と content type application/resolve-response+jwt を使用し、Resolved Metadata と検証済み Trust Marks を含まなければならない。

レスポンスは署名付き JWT であり、[RFC8725] の Section 3.11 に従い、クロス JWT の混同を防ぐため、typ ヘッダーパラメータを resolve-response+jwt に設定して明示的に型付けされる。typ ヘッダーパラメータがない resolve responses、または異なる typ 値を持つものは拒否しなければならない。これは Federation Entity Key で署名される。

resolve response JWT は、使用した署名鍵の Key ID を値とする kid（Key ID）ヘッダーパラメータを必ず含めなければならない。

resolve response JWT は、subject から Trust Anchor への Trust Chain を trust_chain パラメータで返さなければならない。

resolve response はまた、[Section 4.3] で規定される trust_chain JWS ヘッダーパラメータにおいて、issuer から Trust Anchor への Trust Chain を返してもよい。これが存在する場合、その Trust Chain の Trust Anchor は、関連する request の trust_anchor パラメータで要求された Trust Anchor と一致しなければならない。

resolve response の中で自身の Trust Chain を提供する issuer は、レスポンスの subject と同一のフェデレーションに属することを明確にする。したがって、issuer と subject の両方の Trust Chains が利用でき、かつ Federation Historical Keys endpoint が Trust Anchor によって提供される場合、resolve response は長期の attestation となり、将来 Federation Keys が変更されても常に検証可能になる。

レスポンスは、要求側が [Section 8.8] に記述されるとおり認証されている場合にのみ aud Claim を含めるべきであり、その場合、値は要求側の Entity Identifier でなければならず、他の値を含めてはならない。

resolve response における Claims は次のとおりである:

iss

REQUIRED. 文字列。resolve response の issuer の Entity Identifier。

sub

REQUIRED. 文字列。resolve response の subject の Entity Identifier。

iat

REQUIRED. 数値。この resolution が発行された時刻。[RFC7519] に従い、Seconds Since the Epoch で表す。

exp

REQUIRED. 数値。この resolution が有効でなくなる時刻。[RFC7519] に従い、Seconds Since the Epoch で表す。これは、resolve response の導出元となった Trust Chain の exp 値、およびレスポンスに含まれる Trust Mark の exp 値（存在する場合）の最小値でなければならない。

metadata

REQUIRED. 要求された type に従う subject の Resolved Metadata を含む JSON オブジェクトであり、[Section 3.1.1] で定義される metadata 形式で表現される。

trust_chain

REQUIRED. subject から開始し、選択された Trust Anchor で終わる Trust Chain を構成する Entity Statements の列を含む配列。

trust_marks

OPTIONAL. 各要素が Trust Mark を表すオブジェクトの配列。[Section 3.1.2] で定義されるとおりである。Trust Anchor が、そのような Trust Marks を発行することを信頼している Trust Mark issuers によって発行された、有効な Trust Marks のみが resolver response に現れてもよい。

上記の Claims と併用して、追加の Claims を定義し使用してもよい。

エラーレスポンスは [Section 8.9] で定義されるとおりである。

以下は resolve response の JWT Claims Set の非規範的な例である:

{
  "iss": "https://resolver.spid.gov.it",
  "sub": "https://op.example.it/spid",
  "iat": 1516239022,
  "exp": 1516843822,
  "metadata": {
    "openid_provider": {
      "contacts": \["legal@example.it", "technical@example.it"\],
      "logo_uri":
        "https://op.example.it/static/img/op-logo.svg",
      "op_policy_uri":
        "https://op.example.it/en/about-the-website/legal-information",
      "federation_registration_endpoint": "https://op.example.it/spid/fedreg",
      "authorization_endpoint":
        "https://op.example.it/spid/authorization",
      "token_endpoint": "https://op.example.it/spid/token",
      "response_types_supported": \[
        "code",
        "code id_token",
        "token"
      \],
      "grant_types_supported": \[
        "authorization_code",
        "urn:ietf:params:oauth:grant-type:jwt-bearer"
      \],
      "subject_types_supported": \["pairwise"\],
      "id_token_signing_alg_values_supported": \["RS256"\],
      "issuer": "https://op.example.it/spid",
      "jwks": {
        "keys": \[
          {
            "kty": "RSA",
            "use": "sig",
            "n": "1Ta-sE ...",
            "e": "AQAB",
            "kid": "FANFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs"
          }
        \]
      }
    }
  },
  "trust_marks": \[
    {"trust_mark_type": "https://www.spid.gov.it/certification/op/",
     "trust_mark":
       "eyJ0eXAiOiJ0cnVzdC1tYXJrK2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiOH
        hzdUtXaVZmd1NnSG9mMVRlNE9VZGN5NHE3ZEpyS2ZGUmxPNXhoSElhMCJ9.
        eyJpc3MiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdCIsInN1YiI6Imh0dHBzOi
        8vb3AuZXhhbXBsZS5pdC9zcGlkIiwiaWF0IjoxNTc5NjIxMTYwLCJ0cnVzdF9t
        YXJrX3R5cGUiOiJodHRwczovL3d3dy5zcGlkLmdvdi5pdC9jZXJ0aWZpY2F0aW
        9uL29wLyIsImxvZ29fdXJpIjoiaHR0cHM6Ly93d3cuYWdpZC5nb3YuaXQvdGhl
        bWVzL2N1c3RvbS9hZ2lkL2xvZ28uc3ZnIiwicmVmIjoiaHR0cHM6Ly9kb2NzLm
        l0YWxpYS5pdC9pdGFsaWEvc3BpZC9zcGlkLXJlZ29sZS10ZWNuaWNoZS1vaWRj
        L2l0L3N0YWJpbGUvaW5kZXguaHRtbCJ9.
        xyz-PDQ_..."
    }
  \],
  "trust_chain" : \[
    "eyJhbGciOiJSUzI1NiIsImtpZCI6Ims1NEhRdERpYnlHY3M5WldWTWZ2aUhm ...",
    "eyJhbGciOiJSUzI1NiIsImtpZCI6IkJYdmZybG5oQU11SFIwN2FqVW1BY0JS ...",
    "eyJhbGciOiJSUzI1NiIsImtpZCI6IkJYdmZybG5oQU11SFIwN2FqVW1BY0JS ..."
  \]
}

Figure 34: Resolve Response JWT Claims Set

8.3.3. Trust Considerations

本仕様の基本的な前提は、Entity は Trust Anchor と自身の能力以外のいかなる party にも direct trust を持つべきではない、という点である。しかし Entities は、他の Entities に対してある種の推移的な信頼（transitive trust）を確立してもよい。たとえば Trust Anchor は、自身の Immediate Subordinates が誰であるかを述べ、Entities はそれらを信頼することを選べる。party が、他の Entity の resolve サービスを使用してフェデレーション・データを取得する場合、その party は、resolver が暗号学的に保護された metadata の検証を正しく実行し、真正な結果を提供することを信頼している。

8.4. Trust Mark Status

これにより、Entity に対して発行された Trust Mark Instance が現在もアクティブであるかどうかを判定できる。クエリは Trust Mark Issuer に送信しなければならない。

Trust Mark Status endpoint の場所は、[Section 5.1.1] で定義される federation_entity metadata の federation_trust_mark_status_endpoint パラメータにより公開される。この endpoint は Subordinate Statements ではなく、Entity Configuration metadata に直接公開されなければならない。

8.4.1. Trust Mark Status Request

リクエストは POST メソッドを使用する Trust Mark Status endpoint への HTTP リクエストでなければならず、次のパラメータを application/x-www-form-urlencoded 形式でエンコードする。

trust_mark

REQUIRED. 検証される Trust Mark。

client authentication を使用する場合、リクエストは POST メソッドを使用する HTTP リクエストでなければならず、パラメータは POST body に渡される。

以下は Trust Mark Status request の非規範的な例である:

POST /federation_trust_mark_status_endpoint HTTP/1.1
Host: op.example.org
Content-Type: application/x-www-form-urlencoded

trust_mark=eyJ0eXAiOiJ0cnVzdC1tYXJrK2p3dCIsImFsZyI6 ...

Figure 35: Trust Mark Status Request

8.4.2. Trust Mark Status Response

成功レスポンスは、HTTP ステータスコード 200 と content type application/trust-mark-status-response+jwt を用いなければならず、Trust Mark Status Response である署名付き JWT を含める。¶

Trust Mark Status Response は署名付き JWT であり、[[RFC8725]] の Section 3.11 に従い、JWT 間の混同（cross-JWT confusion）を防ぐために、typ ヘッダーパラメータを trust-mark-status-response+jwt に設定して明示的に型付けされる。typ ヘッダーパラメータがない、または異なる typ 値を持つ Trust Mark Status Response は拒否しなければならない。これは Federation Entity Key で署名される。¶

Trust Mark Status Response JWT は、署名に使用した鍵の Key ID を値とする kid（Key ID）ヘッダーパラメータを含めなければならない。¶

Trust Mark Status JWT の JWT Claims Set は JSON オブジェクトであり、次の Claims を含む。¶

iss
REQUIRED. 文字列。Trust Mark Status JWT の発行者の Entity Identifier。¶

iat
REQUIRED. 数値。この Trust Mark Status JWT が発行された時刻。これは [[RFC7519]] に従い、Seconds Since the Epoch として表現される。¶

trust_mark
REQUIRED. 文字列。このステータス応答が対象としている Trust Mark JWT。¶

status
REQUIRED. 大文字小文字を区別する文字列。Trust Mark の状態を示す。この仕様で定義される値は次のとおり。¶
- active
  Trust Mark は有効である。¶
- expired
  Trust Mark は期限切れである。¶
- revoked
  Trust Mark は失効（取り消し）された。¶
- invalid
  署名検証に失敗した、または別のエラーが検出された。¶

上記に加えて、追加の status 値が定義・利用されてもよい。¶

上記に加えて、追加の Trust Mark Status JWT Claims が定義・利用されてもよい。¶

以下は、status が active の応答における JWT Claims Set の非規範的な例である。¶

{
  "iss": "https://www.agid.gov.it",
  "trust_mark": "eyJ0eXAiOiJ0cnVzdC1tYXJrK2p3dCIsImFsZyI6IlJTMjU2Iiwia2
    lkIjoia29zR20yd3VaaDlER21OeEF0a3VPNDBwUGpwTDMtakNmMU4tcVBPLVllVSJ9.
    eyJpc3MiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdCIsInN1YiI6Imh0dHBzOi8
    vcnAuZXhhbXBsZS5pdC9zcGlkIiwiaWF0IjoxNTc5NjIxMTYwLCJ0cnVzdF9tYX
    JrX3R5cGUiOiJodHRwczovL3d3dy5zcGlkLmdvdi5pdC9jZXJ0aWZpY2F0aW9uL
    3JwIiwibG9nb191cmkiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdC90aGVtZXMv
    Y3VzdG9tL2FnaWQvbG9nby5zdmciLCJyZWYiOiJodHRwczovL2RvY3MuaXRhbGl
    hLml0L2RvY3Mvc3BpZC1jaWUtb2lkYy1kb2NzL2l0L3ZlcnNpb25lLWNvcnJlbn
    RlLyJ9.
    L_pSh1InEiFAcs3E-1HBM7fNZYwF5ru3UGA_8yc80dGS3sszfA_sbj4AoW_zAJW
    QBdZpjxnHBBmybYXFrfZBcqxcedsrvUYrmbt1nPYxbUE54fRRoZK-sJmVqh1GzS
    an5nOmkxuAtMinU8k_-aWnPWj83sYe2AzT2mMgkXiz8zhda3jZm8hoxZ4jR6B0Y
    AvbMlq2pPWO5OWKdZhiFRMSprwh0GYluQkK0j1aLNMGXD3keMJd2zEoWX9D7w2f
    XShAA48W3cNhuXyBVnCoum1K4IWK3s_fx4nIkp6W-V4jCBOpxp7Yo8LZ30o_xpE
    OzGTIECGWVR86azOAlwVC8XSiAA",
  "iat": 1759897995,
  "status": "active"
}

Figure 36: Active Trust Mark Status Response JWT Claims Set

以下は、status が revoked の応答における JWT Claims Set の非規範的な例である。¶

{
  "iss": "https://www.agid.gov.it",
  "trust_mark": "eyJ0eXAiOiJ0cnVzdC1tYXJrK2p3dCIsImFsZyI6IlJTMjU2Iiwia2
    lkIjoia29zR20yd3VaaDlER21OeEF0a3VPNDBwUGpwTDMtakNmMU4tcVBPLVllVSJ9.
    eyJpc3MiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdCIsInN1YiI6Imh0dHBzOi8
    vcnAuZXhhbXBsZS5pdC9zcGlkIiwiaWF0IjoxNTc5NjIxMTYwLCJ0cnVzdF9tYX
    JrX3R5cGUiOiJodHRwczovL3d3dy5zcGlkLmdvdi5pdC9jZXJ0aWZpY2F0aW9uL
    3JwIiwibG9nb191cmkiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdC90aGVtZXMv
    Y3VzdG9tL2FnaWQvbG9nby5zdmciLCJyZWYiOiJodHRwczovL2RvY3MuaXRhbGl
    hLml0L2RvY3Mvc3BpZC1jaWUtb2lkYy1kb2NzL2l0L3ZlcnNpb25lLWNvcnJlbn
    RlLyJ9.
    L_pSh1InEiFAcs3E-1HBM7fNZYwF5ru3UGA_8yc80dGS3sszfA_sbj4AoW_zAJW
    QBdZpjxnHBBmybYXFrfZBcqxcedsrvUYrmbt1nPYxbUE54fRRoZK-sJmVqh1GzS
    an5nOmkxuAtMinU8k_-aWnPWj83sYe2AzT2mMgkXiz8zhda3jZm8hoxZ4jR6B0Y
    AvbMlq2pPWO5OWKdZhiFRMSprwh0GYluQkK0j1aLNMGXD3keMJd2zEoWX9D7w2f
    XShAA48W3cNhuXyBVnCoum1K4IWK3s_fx4nIkp6W-V4jCBOpxp7Yo8LZ30o_xpE
    OzGTIECGWVR86azOAlwVC8XSiAA",
  "iat": 1759898057,
  "status": "revoked"
}

Figure 37: Revoked Trust Mark Status Response JWT Claims Set

Trust Mark Status リクエストに対するエラーレスポンスは Section 8.9 で定義されるとおりである。¶

Trust Mark Issuer が、未知の Trust Mark（発行していない、または把握していないもの）の status に関するリクエストを受け取った場合、HTTP ステータスコード 404（Not found）で応答しなければならない。¶

8.5. Trust Mark 付与済み Entity の一覧

Trust Marked Entities Listing endpoint は Trust Mark Issuer により公開され、Trust Mark が発行され、かつ現在も有効であるすべての Entity を列挙する。¶

Trust Marked Entities Listing endpoint の場所は、Section 5.1.1 で定義される federation_trust_mark_list_endpoint パラメータにより、Entity の federation_entity metadata 内で公開される。¶

8.5.1. Trust Mark 付与済み Entity の一覧リクエスト

client authentication を用いない場合、リクエストは GET メソッドの HTTP リクエストでなければならず、次のクエリパラメータを application/x-www-form-urlencoded 形式でエンコードして一覧 endpoint に送る。¶

trust_mark_type
REQUIRED. Trust Mark の型の識別子。応答者が指定された Trust Mark type identifier の Trust Mark を発行している場合、レスポンス内の一覧は、その Trust Mark type identifier が発行され、かつ現在も有効である Entity のみを含むようにフィルタされる。¶

sub
OPTIONAL. Trust Mark が発行された先の Entity の Entity Identifier。レスポンスで得られる一覧は、この値に一致する Entity のみにフィルタされなければならない。¶

client authentication を用いる場合、リクエストは POST メソッドの HTTP リクエストでなければならず、パラメータは POST body で渡されなければならない。¶

以下は、Trust Mark 付与済み Entity の一覧に対する HTTP GET リクエストの非規範的な例である。¶

GET /trust_marked_list?trust_mark_type=https%3A%2F%2Ffederation.example.org%2Fopenid_relying_party%2Fprivate%2Funder-age HTTP/1.1
Host: trust-mark-issuer.example.org

Figure 38: Trust Marked Entities Listing Request

8.5.2. Trust Mark 付与済み Entity の一覧レスポンス

成功レスポンスは、HTTP ステータスコード 200 と content type application/json を用いなければならず、Entity Identifier の JSON 配列を含む。¶

エラーレスポンスは Section 8.9 で定義されるとおりである。¶

以下は、Trust Mark 付与済み Entity を含むレスポンスの非規範的な例である。¶

200 OK
Content-Type: application/json

[
  "https://blackboard.ntnu.no/openid/rp",
  "https://that-rp.example.org"
]

Figure 39: Trust Marked Entities Listing Response

8.6. Trust Mark Endpoint

Trust Mark endpoint は、Trust Mark Issuer により公開され、subject に Trust Mark を提供する。¶

Trust Mark endpoint の場所は、Section 5.1.1 で定義される federation_trust_mark_endpoint パラメータにより、Entity の federation_entity metadata 内で公開される。¶

8.6.1. Trust Mark リクエスト

client authentication を用いない場合、リクエストは GET メソッドの HTTP リクエストでなければならず、次のクエリパラメータを application/x-www-form-urlencoded 形式でエンコードして送る。¶

trust_mark_type
REQUIRED. Trust Mark の型の識別子。¶

sub
REQUIRED. Trust Mark が発行される先の Entity の Entity Identifier。¶

client authentication を用いる場合、リクエストは POST メソッドの HTTP リクエストでなければならず、パラメータは POST body で渡されなければならない。Trust Mark endpoint は、sub パラメータで示されるとおり、Trust Mark の subject ではない client からの認証済みリクエストを許可してもよい。ユースケースの例として、Federation Entity が別の Entity の Trust Mark を取得できるようにすることが挙げられる。¶

以下は、特定の Trust Mark type identifier と subject を指定して Trust Mark を取得する HTTP リクエストの非規範的な例である。¶

GET /trust_mark?trust_mark_type=https%3A%2F%2Fwww.spid.gov.it%2Fcertification%2Frp&sub=https%3A%2F%2Frp.example.it%2Fspid HTTP/1.1
Host: tuber.cert.example.org

Figure 40: Trust Mark Request

8.6.2. Trust Mark レスポンス

成功レスポンスは、HTTP ステータスコード 200 と content type application/trust-mark+jwt を用いなければならず、Trust Mark を含む。¶

指定された Entity が指定された Trust Mark を持たない場合、レスポンスはエラーレスポンスであり、HTTP ステータスコード 404 を用いなければならない。¶

以下は、指定された Entity の Trust Mark を含むレスポンスの非規範的な例である（値中の改行は表示目的のみによる）。¶

200 OK
Content-Type: application/trust-mark+jwt

eyJ0eXAiOiJ0cnVzdC1tYXJrK2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoia29zR20yd3Va
aDlER21OeEF0a3VPNDBwUGpwTDMtakNmMU4tcVBPLVllVSJ9.
eyJpc3MiOiJodHRwczovL3d3dy5hZ2lkLmdvdi5pdCIsInN1YiI6Imh0dHBzOi8vcnAuZXhh
bXBsZS5pdC9zcGlkIiwiaWF0IjoxNTc5NjIxMTYwLCJ0cnVzdF9tYXJrX3R5cGUiOiJodHRw
czovL3d3dy5zcGlkLmdvdi5pdC9jZXJ0aWZpY2F0aW9uL3JwIiwibG9nb191cmkiOiJodHRw
czovL3d3dy5hZ2lkLmdvdi5pdC90aGVtZXMvY3VzdG9tL2FnaWQvbG9nby5zdmciLCJyZWYi
OiJodHRwczovL2RvY3MuaXRhbGlhLml0L2RvY3Mvc3BpZC1jaWUtb2lkYy1kb2NzL2l0L3Zl
cnNpb25lLWNvcnJlbnRlLyJ9.
L_pSh1InEiFAcs3E-1HBM7fNZYwF5ru3UGA_8yc80dGS3sszfA_sbj4AoW_zAJWQBdZpjxnH
BBmybYXFrfZBcqxcedsrvUYrmbt1nPYxbUE54fRRoZK-sJmVqh1GzSan5nOmkxuAtMinU8k_
-aWnPWj83sYe2AzT2mMgkXiz8zhda3jZm8hoxZ4jR6B0YAvbMlq2pPWO5OWKdZhiFRMSprwh
0GYluQkK0j1aLNMGXD3keMJd2zEoWX9D7w2fXShAA48W3cNhuXyBVnCoum1K4IWK3s_fx4nI
kp6W-V4jCBOpxp7Yo8LZ30o_xpEOzGTIECGWVR86azOAlwVC8XSiAA

Figure 41: Trust Mark Response

8.7. Federation Historical Keys Endpoint

各 Federation Entity は、Section 5.1.1 で定義される historical keys endpoint において、過去に使用した Federation Entity Keys を公開してもよい。この endpoint の目的は、鍵ローテーション後に、当該 Federation Entity が署名したステートメントについて、鍵ローテーション後も否認防止（non-repudiation）を提供できるよう、過去に使用した鍵の一覧を提供することである。この endpoint はさらに、鍵の撤回（retraction）の理由、およびそれらが期限切れ（expired）か失効（revoked）か、失効理由を含めて開示する。¶

期限切れの鍵は、期限切れ後に発見された鍵漏えい（key compromise）を示すため、後から追加で revoked としてマークされうる点に留意すること。¶

歴史鍵（historical keys）の公開は、鍵がセキュリティ上の理由で revoked にならない限り、鍵の期限切れ後も Trust Chains が検証可能であり、信頼判断（trust decisions）への入力として利用可能であり続けることを保証する。¶

8.7.1. Federation Historical Keys リクエスト

client authentication を用いない場合、リクエストは federation historical keys endpoint への GET メソッドの HTTP リクエストでなければならない。¶

client authentication を用いる場合、リクエストは POST メソッドの HTTP リクエストでなければならず、client authentication のパラメータは POST body に渡されなければならない。¶

以下は、historical keys リクエストの非規範的な例である。¶

GET /federation_historical_keys HTTP/1.1
Host: trust-anchor.example.com

Figure 42: Federation Historical Keys Request

8.7.2. Federation Historical Keys レスポンス

レスポンスは historical keys を含む署名付き JWK Set である。これは Federation Entity Key で署名される。署名付き JWK Set は、その payload に JWK Set [[RFC7517]] を持つ署名付き JWT である。成功レスポンスは HTTP ステータスコード 200 と content type application/jwk-set+jwt を用いなければならない。¶

historical keys JWT は、[[RFC8725]] の Section 3.11 に従い、JWT 間の混同（cross-JWT confusion）を防ぐために、typ ヘッダーパラメータを jwk-set+jwt に設定して明示的に型付けされる。typ ヘッダーパラメータがない、または異なる typ 値を持つ historical keys JWT は拒否しなければならない。¶

historical keys JWT は、署名に使用した鍵の Key ID を値とする kid（Key ID）ヘッダーパラメータを含めなければならない。¶

historical keys JWT の Claims は次のとおり。¶

iss
REQUIRED. 文字列。Entity の Entity Identifier。¶

iat
REQUIRED. 数値。この historical keys JWT が発行された時刻。これは [[RFC7519]] に従い、Seconds Since the Epoch として表現される。¶

keys
REQUIRED. JWK 形式で Entity の署名鍵を含む JSON オブジェクトの配列。¶

keys Claim 内の JWK は次のパラメータを用いる。¶

kid
REQUIRED. 特定の鍵に一致させるためのパラメータ。Key ID は、SHA-256 ハッシュ関数を用いた JWK Thumbprint [[RFC7638]] とすることが推奨される。¶

iat
OPTIONAL. 数値。この鍵が発行された時刻。これは [[RFC7519]] に従い、Seconds Since the Epoch として表現される。¶

exp
REQUIRED. 数値。鍵の有効期限。これは [[RFC7519]] に従い、Seconds Since the Epoch として表現される。この時刻以降、その鍵は有効とみなしてはならない。¶

revoked
OPTIONAL. 以下で定義されるとおり、失効（revocation）のプロパティを含む JSON オブジェクト。¶
- revoked_at
  REQUIRED. 鍵が失効された、または失効とみなさなければならない時刻。これは [[RFC7519]] における iat Claim で定義される時刻形式を用いる。¶
- reason
  OPTIONAL. 鍵の失効理由を識別する文字列。Section 8.7.3 で定義される。¶

revoked オブジェクトの追加メンバーが定義・利用されてもよい。¶

上記の Claims に加えて、追加の Claims が定義され、それらと組み合わせて利用されてもよい。¶

keys Claim 内の JWK は nbf パラメータを含んでもよい。Historical Keys の用途では、iat と exp で鍵の生存期間（lifetime）を確立するのに十分であり、nbf は通常は冗長である。しかし、発行時点では直ちに有効にならない鍵を発行することを選ぶ profile に向けて登録されている。その定義は次のとおり。¶

nbf
OPTIONAL. この時刻より前は鍵が有効ではない時刻。これは [[RFC7519]] における nbf Claim で定義される時刻形式を用いる。¶

以下は、historical keys レスポンスにおける JWT Claims Set の非規範的な例である。¶

{
  "iss": "https://trust-anchor.federation.example.com",
  "iat": 1666335600,
  "keys": [
    {
      "kty": "RSA",
      "n": "5s4qi ...",
      "e": "AQAB",
      "kid": "2HnoFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs",
      "iat": 1661151600,
      "exp": 1677052800
    },
    {
      "kty": "RSA",
      "n": "ng5jr ...",
      "e": "AQAB",
      "kid": "8KnoFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMJJr",
      "iat": 1647932400,
      "exp": 1663830000,
      "revoked": {
        "revoked_at": 1661151600,
        "reason": "compromised"
      }
    }
  ]
}

Figure 43: Federation Historical Keys Response JWT Claims Set

8.7.3. Federation Historical Keys の失効理由

Federation Entities は、Federation Entity Key の失効理由を示す際に、意味のある reason 値を用いることが強く推奨される。reason は unspecified を用いる代わりに、省略されてもよい。¶

以下に reason 値の定義を示す。¶

次の表は Federation Entity Keys の失効理由を定義する。これらの理由は [[RFC5280]] の Section 5.3.1 に着想を得ている。¶

Reason	Description
unspecified	JWK の状態変更に関する一般的、または特定されない理由。
compromised	秘密鍵が漏えいしたと考えられる。
superseded	JWK はもはや有効ではない。

federation は、利用している信頼またはセキュリティの枠組みに応じて、追加の理由を指定し利用してもよい。¶

8.7.4. Federation Historical Keys Endpoint の設計理由

Federation Historical Keys endpoint は、Federation Entity Keys が、期限切れまたは失効により変更された場合に、過去の Trust Chains を検証するという課題を解決する。¶

Federation Historical Keys endpoint は、Entity が過去に使用していた公開鍵の一覧を公開する。これらの鍵は、過去に作られた Trust Chains を、Entity の Entity Configuration にもはや公開されていない Entity keys で検証するために必要である。¶

Federation Historical Keys endpoint のレスポンスは、期限切れおよび失効したすべての Entity keys を証明する署名付き JWT を含む。¶

Trust Chain を構成する Entity Statements に含まれる属性に基づき、Leaf Entities が過去に OpenID Connect のリクエストおよびレスポンスの署名処理に用いていた、非 federation の公開鍵を検証できる可能性もある。たとえば、Leaf について発行された Entity Statement は、Leaf の Entity Types に対する jwks Claim を、その metadata または metadata_policy Claims の中に含んでもよい。¶

簡単な例：次の Trust Chain では、Federation Intermediate が、Leaf について発行した Subordinate Statement の中で、Leaf の OpenID Connect RP jwks を証明する。結果として、Trust Chain は Leaf の OpenID Connect RP JWK Set を含み、Request Objects の過去の署名および、Leaf が RP として発行したその他の署名付き JWT の履歴署名を検証するのに必要となる。この例の Trust Chain は次を含む。¶

RP により公開された RP に関する Entity Configuration。¶
Organization A により公開された RP に関する Subordinate Statement。metadata または metadata_policy に jwks Claim を含み、Leaf の OpenID Connect RP jwks を証明する。¶
Federation F により公開された Organization A に関する Subordinate Statement。¶

8.8. Federation Endpoints における Client Authentication

既定では、いずれの federation endpoint においても client authentication は用いられない。federation は、特定の federation endpoint において client authentication を OPTIONAL、REQUIRED、または禁止とすることを選べる。¶

client authentication がサポートされる場合、federation endpoints に対する既定の client authentication method は private_key_jwt である。この client authentication method は [OpenID Connect Core 1.0] の Section 9 に記述されている。client authentication JWT は Federation Entity Key で署名されなければならない。JWT の audience は、認証先となる federation endpoint を持つ Entity の Entity Identifier でなければならない。その endpoint は、自身の Entity Identifier 以外の audience 値を含む JWT を受け入れてはならない。client authentication を用いる場合、リクエストは POST メソッドの HTTP リクエストでなければならず、client authentication と endpoint リクエストパラメータを POST body に渡さなければならない。federation は他の client authentication methods を用いることも選べる。¶

8.8.1. Federation Endpoints の Client Authentication Metadata

client authentication をサポートする他の OAuth および OpenID endpoints と同様に、この仕様は各 endpoint がサポートする client authentication methods を示す metadata parameters を定義する。これらは主に、[OpenID Connect Discovery 1.0] の Section 3 で定義される token_endpoint_auth_methods_supported metadata 値に対応する。¶

具体的には、Section 5.1.1 で定義される各 federation endpoints について、*_auth_methods という名前のパラメータが定義される。ここで * は federation endpoint 名（federation_fetch_endpoint, federation_list_endpoint, ..., federation_historical_keys_endpoint）を表す。¶

*_auth_methods metadata parameters は、Token Endpoint に対する token_endpoint_auth_methods_supported と同様に、これら endpoints がサポートする client authentication methods を列挙する。さらに、値 none は、当該 endpoint で client authentication が不要であることを示すために用いられてもよい。¶

したがって、たとえば次の metadata 宣言は、federation_trust_mark_endpoint において private_key_jwt による認証済みリクエストが REQUIRED であることを示す。¶

"federation_trust_mark_endpoint_auth_methods": ["private_key_jwt"]

Figure 44: Declaring that Client Authentication is REQUIRED at an Endpoint

省略された場合、これら methods の既定値は ["none"] であり、未認証リクエストのみが受け入れられることを示す。¶

endpoint_auth_signing_alg_values_supported metadata parameter は、Token Endpoint に対する token_endpoint_auth_signing_alg_values_supported と同様に、これら endpoints がサポートする client authentication の署名アルゴリズムを列挙する。¶

8.9. エラーレスポンス

リクエストが不正形式である、またはリクエスト処理中にエラーが発生した場合、レスポンスボディは content type application/json の JSON オブジェクトであるべきである。 [[RFC6749]] に従い、次の標準化されたエラーフォーマットを用いるべきである。¶

error
REQUIRED. IANA の "OAuth Extensions Error Registry" におけるエラーコード [[IANA.OAuth.Parameters]] が用いられてもよい。特に、この仕様は次の既存のエラーコードを用いる。¶
- invalid_request
  リクエストが不完全、または現行仕様に準拠しない。HTTP レスポンスステータスコードは 400（Bad Request）であるべきである。¶
- server_error
  サーバが予期しない状態に遭遇し、リクエストを処理できなかった。HTTP レスポンスステータスコードは 5xx の範囲（例：500 Internal Server Error）であるべきである。¶
- temporarily_unavailable
  federation endpoint をホストするサーバが、一時的な過負荷またはメンテナンスにより、現在リクエストを処理できない。HTTP レスポンスステータスコードは 503（Service Unavailable）であるべきである。¶

この仕様は、次のエラーコードも定義する。¶

invalid_client
Client が認可されない、または federation の有効な参加者ではない。HTTP レスポンスステータスコードは 401（Unauthorized）であるべきである。¶

invalid_issuer
endpoint が要求された issuer を提供できない。HTTP レスポンスステータスコードは 404（Not Found）であるべきである。¶

invalid_subject
endpoint が要求された subject を提供できない。HTTP レスポンスステータスコードは 404（Not Found）であるべきである。¶

invalid_trust_anchor
Trust Anchor が見つからない、または利用できない。HTTP レスポンスステータスコードは 404（Not Found）であるべきである。¶

invalid_trust_chain
Trust Chain を検証できない。HTTP レスポンスステータスコードは 400（Bad Request）であるべきである。¶

invalid_metadata
metadata または Metadata Policy の値が不正、または競合している。HTTP レスポンスステータスコードは 400（Bad Request）であるべきである。¶

not_found
要求された Entity Identifier が見つからない。HTTP レスポンスステータスコードは 404（Not Found）であるべきである。¶

unsupported_parameter
サーバが要求されたパラメータをサポートしない。HTTP レスポンスステータスコードは 400（Bad Request）であるべきである。¶

error_description
REQUIRED. 開発者が発生したエラーを理解するのを支援するための追加情報を提供する、人間可読なテキスト。¶

以下は、エラーレスポンスの非規範的な例である。¶

400 Bad request
Content-Type: application/json

{
  "error": "invalid_request",
  "error_description":
    "Required request parameter [sub] was missing."
}

Figure 45: Example Error Response

9. Federation Entity Configuration 情報の取得

すべての Trust Anchor および Intermediate Federation Entities の Entity Configuration は、その configuration endpoint で公開されなければならず、Leaf Entities の Entity Configuration もそこで公開されるべきである。その場所は、Entity Identifier に文字列 /.well-known/openid-federation を連結することで決定される（Entity Identifier は https scheme を用い、host component を含まなければならず、port および path components を含んでもよい）。たとえば、Entity Identifier が https://entity.example の場合、その configuration endpoint は https://entity.example/.well-known/openid-federation である。Entity Identifier が末尾に "/" を含む場合、/.well-known/openid-federation を連結する前に、その "/" は取り除かなければならない。¶

さらに、Entity Type Identifier federation_entity を含む任意の Entity Configuration は、その configuration endpoint で公開されなければならない。¶

Leaf Federation Entities は configuration endpoints で Entity Configuration 文書を利用可能にするべきであるが、例外として、client registration method の結果としてサーバが client の Entity Configuration を保持している client は、公開を省略してもよい。たとえば、Explicit Registration を用いる RP は、client registration 中に RP の Entity Configuration を OP に POST するため、OP は RP から必要な情報をすべて保持している。この仕様の profile は、Entity Type Identifier federation_entity を用いない Leaf Entities に対する他の例外や、それらに伴う処理規則を定義してもよい。¶

9.1. Federation Entity Configuration リクエスト

Entity Configuration 文書は、先に指定したパスに対して HTTP GET リクエストで問い合わせなければならない。¶

この例では、要求者は Entity https://op.sunet.se に対して、次のリクエストを行い Entity Configuration を取得する。¶

GET /.well-known/openid-federation HTTP/1.1
Host: op.sunet.se

Figure 46: Request for Entity Configuration

9.2. Federation Entity Configuration レスポンス

レスポンスは Entity Configuration である。Entity が Intermediate Entity または Trust Anchor の場合、レスポンスは Federation Entity（federation_entity）の metadata を含まなければならない。¶

成功レスポンスは、レスポンスが Entity Statement を含むことを明確にするために、HTTP ステータスコード 200 と content type application/entity-statement+jwt を用いなければならない。エラーの場合、レスポンスは Section 8.9 で定義されるとおりである。¶

以下は、Intermediate Entity からのレスポンスにおける JWT Claims Set の非規範的な例である。¶

{
  "iss": "https://sunet.se",
  "sub": "https://sunet.se",
  "iat": 1516239022,
  "exp": 1516843822,
  "metadata": {
    "federation_entity": {
      "contacts": ["ops@sunet.se"],
      "federation_fetch_endpoint": "https://sunet.se/fetch",
      "organization_uri": "https://www.sunet.se",
      "organization_name": "SUNET"
    },
  "jwks": {
    "keys": [
      {
        "alg": "RS256",
        "e": "AQAB",
        "kid": "O-wFRGNsy0-4SR2jbXYwDHy6...",
        "kty": "RSA",
        "n": "Qo3n0N0Gv7L8T9I_2sAMc0I4...",
        "use": "sig"
      }
    ]
  },
  "authority_hints": [
    "https://edugain.org"
  ]
}

Figure 47: Entity Configuration Response JWT Claims Set for an Intermediate

The following is a non-normative example JWT Claims Set for a response from an OpenID Provider Entity:¶

{
  "iss": "https://op.sunet.se",
  "sub": "https://op.sunet.se",
  "iat": 1516239022,
  "exp": 1516843822,
  "metadata": {
    "openid_provider": {
      "issuer": "https://op.sunet.se",
      "signed_jwks_uri": "https://op.sunet.se/jwks.jose",
      "authorization_endpoint": "https://op.sunet.se/authorization",
      "client_registration_types_supported": [
        "automatic",
        "explicit"
      ],
      "grant_types_supported": [
        "authorization_code"
      ],
      "id_token_signing_alg_values_supported": [
        "ES256",
        "RS256"
      ],
      "contacts": ["ops@sunet.se"],
      "organization_uri": "https://www.sunet.se",
      "organization_name": "SUNET",
      "logo_uri": "https://www.sunet.se/sunet/images/32x32.png",
      "op_policy_uri": "https://www.sunet.se/en/website/legal-information/",
      "response_types_supported": [
        "code"
      ],
      "subject_types_supported": [
        "pairwise",
        "public"
      ],
      "token_endpoint": "https://op.sunet.se/token",
      "federation_registration_endpoint": "https://op.sunet.se/fedreg",
      "token_endpoint_auth_methods_supported": [
        "private_key_jwt"
      ]
    }
  },
  "jwks": {
    "keys": [
      {
        "alg": "RS256",
        "e": "AQAB",
        "kid": "yHozfrAd5G-pnmG4e1jCXpfc...",
        "kty": "RSA",
        "n": "HIoSq4wkZiEkJDTPHiv7torK...",
        "use": "sig"
      }
    ]
  },
  "authority_hints": [
    "https://sunet.se"
  ]
}

Figure 48: Entity Configuration Response JWT Claims Set for an OP

10. 信頼チェーンとメタデータの解決

別の Entity（Party B）と信頼関係を確立したい Entity（Party A）は、Party B の Entity Identifier と、Trust Anchors の Entity Identifiers の一覧およびそれらの公開署名鍵の一覧を持たなければならない。Party A はまず、Party B から 1 つ以上の Trust Anchors へ至る少なくとも 1 本の信頼チェーンを確立するのに十分な Entity Statements を取得しなければならない。その後、Party A は Trust Chains を独立に検証しなければならず、複数の有効な Trust Chains が存在し、かつアプリケーションが必要とする場合には、使用する 1 つを選択しなければならない。¶

信頼された第三者に Trust Chain の評価を委任するために、別の Entity（Party B）と信頼関係を確立したい Entity（Party A）は、Section 8.3 で定義される resolve endpoint を用いてもよい。¶

10.1. 信頼チェーンを確立するための Entity Statements の取得

状況によっては、Party A は Party B の Entity Configuration を渡されることもあれば、自身で取得しなければならないこともある。取得が必要な場合、Party A は Party B の Entity Identifier に基づき、Section 9 で記述されるプロセスを用いる。¶

次のステップは、authority_hints に列挙された Intermediates のリストを順にたどり、未知の Trust Anchor で終わる authority hints は無視しつつ、各 Intermediate から Entity Configuration を要求することである。受領した Entity Configuration に authority hint が含まれている場合、このプロセスを繰り返す。¶

すべての Intermediates と Trust Anchor の一覧が得られたら、Section 8.1 で定義される各 fetch endpoints を用いて、Intermediates と Party B についての Entity Statements を取得する。¶

ループを防ぐため、Federation participants は、このプロセス中にすでに取得済みの Entity Statements を取得しようとしてはならない。ループが検出された場合、それに至った authority hint は用いてはならない。¶

成功した操作は、1 つ以上の Entity Statements のリストを返す。自己署名の Entity Statement で終端する各リストは Trust Anchor により発行される。¶

Party B から、信頼された Trust Anchors の少なくとも 1 つへ至る経路が存在しない場合、リストは空になり、Party B の情報に対して信頼を確立する方法は存在しない。この場合に Party A がどう扱うかは、この仕様のスコープ外である。¶

以下のシーケンス図は、OP が RP について行う信頼評価における、RP、OP、Trust Anchor 間の相互作用を表す。直前の説明との対応として、この図では Party A は OP、Party B は RP である。¶

+-----+                         +-----+                             +--------------+
| RP  |                         | OP  |                             | Trust Anchor |
+-----+                         +-----+                             +--------------+
   |                               |                                        |
   | Entity Configuration Request  |                                        |
   |<------------------------------|                                        |
   |                               |                                        |
   | Entity Configuration Response |                                        |
   |------------------------------>|                                        |
   |                               |                                        |
   |                               | Evaluates authority_hints              |
   |                               |--------------------------              |
   |                               |                         |              |
   |                               |<-------------------------              |
   |                               |                                        |
   |                               | Entity Configuration Request           |
   |                               |--------------------------------------->|
   |                               |                                        |
   |                               |        Entity Configuration Response   |
   |                               |<---------------------------------------|
   |                               |                                        |
   |                               | Obtains Fetch Endpoint                 |
   |                               |-----------------------                 |
   |                               |                      |                 |
   |                               |<----------------------                 |
   |                               |                                        |
   |                               | Request Subordinate Statement about RP |
   |                               |--------------------------------------->|
   |                               |                                        |
   |                               |        Subordinate Statement about RP  |
   |                               |<---------------------------------------|
   |                               |                                        |
   |                               | Evaluates the Trust Chain              |
   |                               |--------------------------              |
   |                               |                         |              |
   |                               |<-------------------------              |
   |                               |                                        |
   |                               | Applies Metadata Policies              |
   |                               |--------------------------              |
   |                               |                         |              |
   |                               |<-------------------------              |
   |                               |                                        |
   |                               | Applies Constraints                    |
   |                               |--------------------                    |
   |                               |                   |                    |
   |                               |<-------------------                    |
   |                               |                                        |
   |                               | Derives the RP's Resolved Metadata     |
   |                               |-----------------------------------     |
   |                               |                                  |     |
   |                               |<----------------------------------     |

Figure 49: Resolving Trust Chain and Metadata from the Perspective of an OP

10.2. 信頼チェーンの検証

Section 4 で記述されるとおり、Trust Chain は順序付けられた Entity Statements のリストから成る。したがって、Party A が Entity Statements の集合をどのように取得したとしても、ここで Party A は、その集合が当該セクションに示される規則に従った適切な Trust Chain であることを検証しなければならない。¶

Trust Chain 内の Entity Statements を ES[j] と呼ぶことにし、j = 0,...,i とする。ここで 0 は最初の Entity Statement のインデックスであり、i は最後の Entity Statement の 0 始まりインデックスである。Trust Chain を検証するために、次を行わなければならない。¶

各 Entity Statement ES[j]（j = 0,..,i）について:¶
- ステートメントが必須 Claims をすべて含むことを検証する。¶
- iat が過去の値であることを検証する。¶
- exp が未来の値であることを検証する。¶
ES[0]（Trust Chain の subject の Entity Configuration）について、iss == sub を検証する。¶
ES[0] について、その署名が ES[0]["jwks"] 内の公開鍵で検証できることを検証する。¶
各 j = 0,...,i-1 について、ES[j]["iss"] == ES[j+1]["sub"] を検証する。¶
各 j = 0,...,i-1 について、ES[j] の署名が ES[j+1]["jwks"] 内の公開鍵で検証できることを検証する。¶
ES[i]（Trust Anchor の Entity Configuration）について、issuer が Trust Anchor の Entity Identifier に一致することを検証する。¶
ES[i] について、その署名が Trust Anchor の公開鍵で検証できることを検証する。¶

署名検証は、ステートメントの正しさやタイムスタンプの正しさの検証よりも、はるかにコストの高い操作である。そのため実装者は、他のチェックがすべて完了するまで署名を検証しないことを選んでもよい。¶

Federation participants は、Section 10.4 に従い、期限切れになるまで Entity Statements と署名検証結果をキャッシュしてもよい。¶

前述の検証の後、Section 6.1.4 で記述されるとおり、metadata は Trust Chain の subject に対して解決されなければならない。さらに、Section 6.2 で説明されるとおり、Trust Chain の各 Subordinate Statement に対して constraints を適用しなければならない。¶

10.3. 有効な信頼チェーンのうち 1 つを選ぶ

複数の有効な Trust Chains が見つかった場合、Party A はどれを用いるか決定する必要がある。単純な規則の 1 つは、長いチェーンより短いチェーンを優先することである。Federation participants は、ローカルポリシーに従って他の規則に従ってもよい。¶

10.4. 信頼チェーンの有効期限の計算

Trust Chain 内の各 Entity Statement は署名され、かつ有効期限（exp）を持たなければならない。Trust Chain 全体の有効期限は、Trust Chain 内の最小の（exp）値である。¶

10.5. 一時的な信頼チェーン検証エラー

federation topology が更新されている場合、たとえば Leaf Entities の集合が新しい Intermediate Entity に移動された場合、Trust Chain の検証が一時的に失敗することがある。一定時間経過後に再試行すると状況が解決する場合がある。¶

10.6. Resolver を用いた信頼チェーンとメタデータの解決

上記の方法を用いて Entity（Party B）の Trust Chain を解決する代替手段として、Section 8.3 で記述される resolve endpoint を用いる方法がある。これにより、信頼を確立したい Entity（Party A）が自ら行わなければならなかった作業を、resolver が代行できる。¶

11. メタデータの更新、鍵ロールオーバー、失効

この仕様は、metadata と公開鍵を滑らかに更新できるようにする。¶

Section 10.4 で記述されるとおり、各 Trust Chain には有効期限がある。Federation participants は、有効期限が切れたときに Trust Chain を更新することをサポートしなければならない。参加者がどれくらいの頻度で Trust Chain を再評価するかは、何かが変更されたことをどれほど速く検知したいかに依存する。¶

11.1. Federation 鍵ロールオーバー

Entity Configuration の有効期限（exp）は、その jwks メンバーから更新された Federation Keys の集合を取得するために、どれくらいの頻度で再取得する必要があるかを制御するために用いられる。¶

11.2. Trust Anchor の鍵ロールオーバー

Trust Anchor は、自身についての Entity Configuration を公開しなければならない。この Entity Configuration に設定される有効期限（exp）は、federation participants が妥当な間隔でそれを再取得することを保証するように選ばれるべきである。Trust Anchor が署名鍵をロールオーバーする際には、次を行う必要がある。¶

新しい鍵を、Trust Anchor の署名鍵を表す jwks として、その Entity Configuration に追加する。¶
すべての Subordinates が新しい鍵を取得できるようにするために十分な期間、古い鍵を用いて Entity Configuration と Entity Statements への署名を継続する。¶
新しい鍵で署名するよう切り替える。¶
妥当な期間の後、古い鍵を削除する。妥当とみなされる期間は、Trust Anchor のセキュリティプロファイルとリスク評価に依存する。¶

11.3. Trust Anchor 鍵の冗長取得

Federation Operators は、管理する Trust Anchors の公開鍵を、それら Trust Anchors の Entity Configurations とは独立に取得する手段を提供することが推奨される。これは、Entity Configurations から公開鍵を取得する基盤となる Web PKI [[RFC9525]] インフラが侵害された場合に備え、冗長性を提供することを意図している。¶

Federation Operator により指定された独立の仕組みで取得した鍵は、Trust Anchor の Entity Configuration で取得した鍵と比較されるべきである。一致しない場合は、両方を再取得するべきである。それでも一致しない場合、セキュリティまたは設定上の問題を示唆する。そうした場合の適切な是正手順は Federation Operator により規定されるべきである。¶

11.4. 失効

federation の参加者は、定期的かつ頻繁に Trust Chain を確認することが想定されているため、この仕様は失効（revocation）プロセスを定義しない。特定の federation は異なる選択をしてもよく、その場合は独自の失効プロセスを定義する必要がある。¶

12. OpenID Connect の Client 登録

このセクションは、この仕様で定義される仕組みを、事前の明示的な設定や登録が存在しない RP と OP の間で信頼関係を確立するためにどのように用いるかを記述する。Trust Chains を用いる 2 つの client registration methods（Automatic Registration と Explicit Registration）を定義する（Section 10 参照）。federation は、client registration のために他の適切な方法を用いてもよい。¶

OpenID Connect Entities を含む federation は、サポートする client registration methods について合意するべきである。¶

Automatic Registration と Explicit Registration は、OpenID Connect 以外の OAuth 2.0 の profile に対しても利用できる点に留意すること。その場合、Entity Type Identifiers openid_relying_party と openid_provider を用いるのではなく、oauth_client と oauth_authorization_server、または利用する特定の OAuth 2.0 profile に対して定義された他の Entity Type Identifiers を用いる。¶

両方の方法を用いる場合、trust_anchor_hints の値は、RP と OP が共有する Trust Anchors を決定するために用いられる。Trust Chains を構築する際、可能であれば RPs は OP と共通の Trust Anchor を選ぶべきである。¶

12.1. Automatic Registration

Automatic Registration は、OP に対する事前の登録ステップなしに、RP が Authentication Requests を行えるようにする。OP は Authentication Request に含まれる Client ID から RP の Entity Configuration を解決し、Section 10 で定義されるプロセスに従う。¶

RP は Authentication Request を送信する前に、Section 10 で規定されるとおり、OP に対する Trust Chain と metadata の解決を実行しなければならない。解決が成功しない場合、RP は OP との追加の相互作用を試みてはならない。¶

Automatic Registration には次の特性がある。¶

OP とのすべての相互作用において、RP は自身の Entity Identifier を Client ID として用いる。OP は Section 9 で記述されるとおり、Entity Identifier から導出される URL から RP の Entity Configuration を取得する。¶
Authentication Request の前に登録ステップが存在しないため、Automatic Registration を用いる場合、リクエストを認証するために非対称暗号を用いなければならない。非対称暗号でリクエストを認証するため、OP は RP に Client Secret を割り当てず、登録プロセスの結果としてそれを返すこともない。¶

Automatic Registration をサポートする OP は、その client_registration_types_supported metadata parameter に automatic キーワードを含めなければならない。¶

12.1.1. Authentication Request

Authentication Request は、[OpenID Connect Core 1.0] の Section 6 と、[The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)] [[RFC9101]] に記述されるとおり、Request Object を値渡しまたは参照渡しで渡すことにより実行される。または、[Pushed Authorization Requests] [[RFC9126]] に記述される pushed authorization request を用いる。¶

Authentication requests は、以下で記述されるいずれかの方法を用いて、要求元 Entity が Entity の RP keys を制御していることを示さなければならない。これを満たさない authentication requests の試行は拒否されなければならない。¶

デプロイメントは、request object を参照渡し（request_uri リクエストパラメータ）で渡すことをサポートしない選択をしてもよい。これを許可すると、攻撃者が OAuth 2.0 Authorization Servers または OpenID Providers に対して DoS 攻撃を行いやすくなるためである。これは、request_uri_parameter_supported OP metadata parameter を false に設定することで行える。リクエストパラメータが大きすぎてクエリパラメータとして値渡しするのが現実的でない場合、代わりに HTTP POST で送信するか、Section 12.1.1.2 で記述される [Pushed Authorization Request] [[RFC9126]] を用いて送信できる。¶

12.1.1.1. Request Object の使用

Authorization Endpoint または Pushed Authorization Request Endpoint で Request Object を用いる場合、request パラメータの値は JWT であり、その Claims は [OpenID Connect Core 1.0] の Section 3.1.2 で指定されるリクエストパラメータである。JWT は署名されなければならず、暗号化されてもよい。Request Object では次のパラメータを用いる。¶

aud
REQUIRED. "aud"（audience）の値は OP の Entity Identifier でなければならず、他の値を含んではならない。¶

client_id
REQUIRED. client_id の値は RP の Entity Identifier でなければならない。¶

iss
REQUIRED. iss の値は RP の Entity Identifier でなければならない。¶

sub
MUST NOT be present. これにより、private_key_jwt client authentication のためのステートメントの再利用を防ぐ。¶

jti
REQUIRED. JWT ID。JWT の一意識別子であり、Request Object の再利用を防ぐために用いられる。Request Object は、当事者間で再利用条件が交渉された場合を除き、1 回だけ用いられなければならない。そのような交渉はこの仕様のスコープ外である。¶

exp
REQUIRED. 数値。この時刻以降、JWT は処理のために受け入れられてはならない有効期限。これは [[RFC7519]] に従い、Seconds Since the Epoch として表現される。¶

iat
OPTIONAL. 数値。この Request Object が発行された時刻。これは [[RFC7519]] に従い、Seconds Since the Epoch として表現される。¶

trust_chain
OPTIONAL. リクエストを行う RP と、選択された Trust Anchor の間を構成する Trust Chain をなす Entity Statements のシーケンスを含む配列。RP と OP が同一 federation の一部である場合、RP は OP と共通の Trust Anchor を選択しなければならない。そうでない場合、RP は利用する Trust Anchor を自由に選べる。¶

NOTE: Section 4.3 で指定される trust_chain header parameter の利用は、このパラメータの利用より RECOMMENDED である。このパラメータは歴史的理由により残されている。¶

12.1.1.1.1. Trust Chain を含む Authorization Request

authentication request に trust_chain header parameter が用いられる場合、Relying Party は、選択された Trust Anchor との信頼関係を証明する Entity Statements のシーケンスを OP に知らせる。¶

Trust Chain はサイズが大きいため、リクエストには HTTP POST メソッド、request_uri、または [Pushed Authorization Request] [[RFC9126]] を用いる必要があるかもしれない。¶

以下は、Request Object における header parameters と JWT Claims Set の非規範的な例である。¶

{
  "typ": "oauth-authz-req+jwt",
  "alg": "RS256",
  "kid": "kid-that-points-to-a-jwk-contained-in-the-trust-chain",
  "trust_chain" : [
    "eyJhbGciOiJSUzI1NiIsImtpZCI6Ims1NEhRdERpYnlHY3M5WldWTWZ2aUhm ...",
    "eyJhbGciOiJSUzI1NiIsImtpZCI6IkJYdmZybG5oQU11SFIwN2FqVW1BY0JS ...",
    "eyJhbGciOiJSUzI1NiIsImtpZCI6IkJYdmZybG5oQU11SFIwN2FqVW1BY0JS ..."
  ]
}
.
{
  "aud": "https://op.example.org",
  "client_id": "https://rp.example.com",
  "exp": 1589699162,
  "iat": 1589699102,
  "iss": "https://rp.example.com",
  "jti": "4d3ec0f81f134ee9a97e0449be6d32be",
  "nonce": "4LX0mFMxdBjkGmtx7a8WIOnB",
  "redirect_uri": "https://rp.example.com/authz_cb",
  "response_type": "code",
  "scope": "openid profile email address phone",
  "state": "YmX8PM9I7WbNoMnnieKKBiptVW0sP2OZ"
}

Figure 50: Request Object JWT Claims Set

以下は、request パラメータを用いた Authentication Request の非規範的な例である（値中の改行は表示目的のみによる）。¶

Host: server.example.com
GET /authorize?
    redirect_uri=https%3A%2F%2Frp.example.com%2Fauthz_cb
    &scope=openid+profile+email+address+phone
    &response_type=code
    &client_id=https%3A%2F%2Frp.example.com
    &request=eyJ0eXAiOiJvYXV0aC1hdXRoei1yZXErand0IiwiYWxnIjoiUlMyNTYiLCJ
        raWQiOiJOX19EOThJdkI4TmFlLWt3QTZuck90LWlwVGhqSGtEeDM3bmljRE1IM04
        0In0.
        eyJhdWQiOiJodHRwczovL29wLmV4YW1wbGUub3JnIiwiY2xpZW50X2lkIjoiaHR0
        cHM6Ly9ycC5leGFtcGxlLmNvbSIsImV4cCI6MTU4OTY5OTE2MiwiaWF0IjoxNTg5
        Njk5MTAyLCJpc3MiOiJodHRwczovL3JwLmV4YW1wbGUuY29tIiwianRpIjoiNGQz
        ZWMwZjgxZjEzNGVlOWE5N2UwNDQ5YmU2ZDMyYmUiLCJub25jZSI6IjRMWDBtRk14
        ZEJqa0dtdHg3YThXSU9uQiIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vcnAuZXhh
        bXBsZS5jb20vYXV0aHpfY2IiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInNjb3Bl
        Ijoib3BlbmlkIHByb2ZpbGUgZW1haWwgYWRkcmVzcyBwaG9uZSIsInN0YXRlIjoi
        WW1YOFBNOUk3V2JOb01ubmllS0tCaXB0Vlcwc1AyT1oiLCJ0cnVzdF9jaGFpbiI6
        WyJleUpoYkdjaU9pSlNVekkxTmlJc0ltdHBaQ0k2SW1zMU5FaFJkRVJwWW5sSFkz
        TTVXbGRXVFdaMmFVaG0gLi4uIiwiZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJ
        NklrSllkbVp5Ykc1b1FVMTFTRkl3TjJGcVZXMUJZMEpTIC4uLiIsImV5SmhiR2Np
        T2lKU1V6STFOaUlzSW10cFpDSTZJa0pZZG1aeWJHNW9RVTExU0ZJd04yRnFWVzFC
        WTBKUyAuLi4iXX0.
        Rv0isfuku0FcRFintgxgKDk7EnhFkpQRg3Tm6N6fCHAHEKFxVVdjy4
        9JboJtxKcQVZKN9TKn3lEYM1wtF1e9PQrNt4HZ21ICfnzxXuNx1F5SY1GXCU2n2y
        FVKtz3N0YkAFbTStzy-sPRTXB0stLBJH74RoPiLs2c6dDvrwEv__GA7oGkg2gWt6
        VDvnfDpnvFi3ZEUR1J8MOeW_VFsayrT9sNjyjsz62Po4LzvQKQMKxq0dNwPNYuuS
        fUmb-YvmFguxDb3weYl8WS-
        48EIkP1h4b_KGU9x9n7a1fUOHrS02ATQZmaL8jUil7yLJqx5MiCsPr4pCAXV0doA
        4pwhs_FIw HTTP/1.1

Figure 51: Authentication Request using Request Object

trust_chain header parameter が含まれる場合、RP が選択した Trust Anchor と OP の間の Trust Chain を提供するために、peer_trust_chain header parameter も含めてもよい。Peer Trust Chain には、登録時に OP が用いるよう RP が選んだ metadata と policy の値が含まれる。両方の Trust Chains で選択される Trust Anchors は同一でなければならない。両方の Trust Chains を含めることで、[[App-Fed-Linkage]] で定義される Federation Integrity と Metadata Integrity の性質を達成できる。¶

12.1.1.1.2. Authentication Request の処理

OP が受信した Authentication Request について、OP が OpenID Federation をサポートし、受信した Client ID が有効な URL であり、かつ OP がその Client ID を既知の client として登録していない場合、OP は要求元に関連する Trust Chains を解決するべきである。¶

RP は、Section 4.3 で定義される trust_chain header parameter を用いて、Request Object に自身から選択した Trust Anchor までの Trust Chain を含めてもよい。OP が RP に対する有効な登録を持たない、または登録が期限切れの場合、OP は受け取った Trust Chain を、RP の Entity から Trust Anchor へ向かう経路選択のヒントとして用いてもよい。OP は、提供された Trust Chain 内のステートメントを評価して、Federation Entity Discovery 手順をより効率化してもよい。特に、RP の Entity Configuration が複数の authority hints を含む場合に有用である。OP がすでに RP に対する有効な登録を持つ場合、受け取った Trust Chain を用いて RP の登録を更新してもよい。¶

Trust Chain は、OP がそのすべてのステートメントを検証したうえで、依拠されうる。これは、ステートメントが URL から取得された場合でも、Request Object 内の trust_chain リクエストパラメータにより提供された場合でも同様である。いずれの場合でも、OP は Trust Chain に含まれるすべての Entity Statement を含め、Trust Chain を完全に検証しなければならない。¶

同様に、RP は Section 4.4 で定義される peer_trust_chain header parameter を用いて、OP から RP が選択した Trust Anchor までの Trust Chain を Request Object に含めてもよい。OP は、登録時に RP が選択した metadata と policy の値を用いるべきである。両方の Trust Chains を含めることで、[[App-Fed-Linkage]] で定義される Federation Integrity と Metadata Integrity の性質を達成できる。¶

RP が Request Object に trust_chain header parameter を含めない場合、OP が何らかの理由で提供された Trust Chain を用いないと判断した場合、または OP がこの機能をサポートしない場合、OP は Section 10.1 で記述されるとおり、RP の Entity Configuration から開始して、可能な Trust Chains を検証し、Entity Type openid_relying_party の RP metadata を解決しなければならない。¶

さらに OP は、RP の Resolved Metadata が、client metadata 仕様である [OpenID Connect Dynamic Client Registration 1.0] [[OpenID.Registration]] に準拠していることを検証するべきである。¶

OP が RP の metadata を得たら、client が実際に Authentication Request を送信した当人であることを、Request Object の署名を検証することで確認しなければならない。検証には、client が openid_relying_party Entity Type の metadata として公開した鍵素材を用いる。署名が検証できない場合、OP はリクエストを拒否しなければならない。¶

12.1.1.2. Pushed Authorization の使用

[Pushed Authorization Requests] [[RFC9126]] は、authentication request parameters を AS に直接 push し、その対価として 1 回限り使用の request_uri を受け取るための、相互運用可能な方法を提供する。標準の PAR metadata parameters は、その利用を示すために RP と OP の metadata で用いられる。¶

Automatic Registration で PAR を用いる場合、Request Object を PAR パラメータとして用いなければならない（Request Object は Section 12.1.1.1 で記述されるとおり）。または、RP の秘密鍵のいずれかの所持を証明する PAR endpoint 用の client authentication method を用いなければならない。さらに、対応する公開鍵は、Entity の RP JWK Set [[RFC7517]] に含まれなければならない。¶

適用可能な PAR client authentication methods は次の 2 つである。¶

[OpenID Connect Core 1.0] の Section 9 における private_key_jwt の記述に従う JWT Client authentication。この場合、client authentication JWT の audience は OP の Entity Identifier でなければならず、他の値を含んではならない。¶
[[RFC8705]] の Section 2.2 に記述される、自己署名証明書を用いる mTLS。この場合、自己署名証明書は、Entity の RP JWK Set に含まれる鍵の x5c Claim の値として存在しなければならない。この場合、サーバは証明書チェーンの検証を省略しなければならない。¶

OP への Pushed Authorization Request は次のようになりうる。¶

POST /par HTTP/1.1
Host: op.example.org
Content-Type: application/x-www-form-urlencoded

redirect_uri=https%3A%2F%2Frp.example.com%2Fauthz_cb
&scope=openid+profile+email+address+phone
&response_type=code
&nonce=4LX0mFMxdBjkGmtx7a8WIOnB
&state=YmX8PM9I7WbNoMnnieKKBiptVW0sP2OZ
&client_id=https%3A%2F%2Frp.example.com
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
  client-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6ImRVTjJ
  hMDF3Umtoa1NXcGxRVGh2Y1ZCSU5VSXdUVWRPVUZVMlRtVnJTbW
  hFUVhnelpYbHBUemRRTkEifQ.
  eyJzdWIiOiAiaHR0cHM6Ly9ycC5leGFtcGxlLmNvbSIsICJpc3M
  iOiAiaHR0cHM6Ly9ycC5leGFtcGxlLmNvbSIsICJpYXQiOiAxNT
  g5NzA0NzAxLCAiZXhwIjogMTU4OTcwNDc2MSwgImF1ZCI6ICJod
  HRwczovL29wLmV4YW1wbGUub3JnIiwgImp0aSI6ICIzOWQ1YWU1
  NTJkOWM0OGYwYjkxMmRjNTU2OGVkNTBkNiJ9.
  oUt9Knx_lxb4V2S0tyNFH
  CNZeP7sImBy5XDsFxv1cUpGkAojNXSy2dnU5HEzscMgNW4wguz6
  KDkC01aq5OfN04SuVItS66bsx0h4Gs7grKAp_51bClzreBVzU4g
  _-dFTgF15T9VLIgM_juFNPA_g4Lx7Eb5r37rWTUrzXdmfxeou0X
  FC2p9BIqItU3m9gmH0ojdBCUX5Up0iDsys6_npYomqitAcvaBRD
  PiuUBa5Iar9HVR-H7FMAr7aq7s-dH5gx2CHIfM3-qlc2-_Apsy0
  BrQl6VePR6j-3q6JCWvNw7l4_F2UpHeanHb31fLKQbK-1yoXDNz
  DwA7B0ZqmuSmMFQ

Figure 52: Pushed Authorization Request to the OP

12.1.1.2.1. Pushed Authentication Request の処理

Section 12.1.1.1.2 で指定される要件は、[Pushed Authorization Requests] [[RFC9126]] にも適用される。¶

OP が RP の metadata を得たら、client が openid_relying_party Entity Type Identifier のために公開された鍵を使用していることを検証しなければならない。RP が検証できない場合、OP はリクエストを拒否しなければならない。¶

検証手段は、使用される client authentication method に依存する。¶

private_key_jwt
この method が用いられる場合、OP は、RP がその metadata として公開した鍵素材を用いて、署名付き JWT の署名を検証する。認証が成功した場合、登録は有効である。署名付き JWT の audience は Authorization Server の Entity Identifier でなければならず、他の値を含んではならない。¶

self_signed_tls_client_auth
自己署名証明書を用いる mTLS が用いられる場合、証明書は、RP の鍵を含む JWK Set の中の鍵に対する x5c Claim の値として存在しなければならない。¶

12.1.2. Successful Authentication Response

Automatic Registration を用いる場合の成功した authentication request へのレスポンスは、[[OpenID.Core]] で定義される成功した authentication responses と同一である。これは、Client の redirection URI に送信される、成功した OAuth 2.0 authorization response である。¶

12.1.3. Authentication Error Response

Automatic Registration を用いる場合の失敗した authentication request へのエラーレスポンスは、[[OpenID.Core]] で定義されるエラー authentication responses と同一である。これは、リクエストに [Pushed Authorization Request] [[RFC9126]] が用いられた場合を除き、Client の redirection URI に送信される OAuth 2.0 authorization error response である。¶

ただし、[[OpenID.Core]] と [[RFC6749]] の双方と同様に、redirection URI が不正である場合、リダイレクトは行われてはならず、代わりに Authorization Server はユーザーインターフェース上で End-User にエラーを通知するべきである。Authorization Server は、redirection URI が open redirector の構成要素として使われている可能性があると判断する理由がある場合にも、同様にすることを選んでもよい。¶

OP が RP との信頼を確立できない、または RP metadata が不正である、あるいは metadata policy と衝突すると判断した場合、OP は redirection URI を不正として扱い、リダイレクトを行ってはならない。これは、信頼が確立できなかった理由に関するエラーコードである invalid_trust_anchor、invalid_trust_chain、invalid_metadata は、Client の redirection URI ではなく、[Pushed Authorization Request] [[RFC9126]] のエラーレスポンスとしてのみ返されるべきであることを意味する。¶

IANA の "OAuth Extensions Error Registry" レジストリ [[IANA.OAuth.Parameters]] に含まれるエラーコードに加えて、この仕様は Section 8.9 のエラーコードも定義しており、それらも用いられてもよい。¶

以下は、authentication error response の非規範的な例である。¶

HTTP/1.1 302 Found
  Location: https://client.example.org/cb?
    error=consent_required
    &error_description=
      Consent%20by%20the%20End-User%20required
    &state=af0ifjsldkj

Figure 53: Authentication Error Response

12.1.4. Automatic Registration と Client Authentication

Automatic Registration を用いる場合、client が用いられる client authentication methods は、RP Metadata parameters（[[OpenID.RP.Choices]] で定義される token_endpoint_auth_methods_supported パラメータ、または token_endpoint_auth_method パラメータ）を用いて OP に宣言される。OP が用いられるものも、同様に OP Metadata parameters を用いて RP に宣言される。しかし、RP と OP の双方がサポートする methods が複数ある場合、Automatic Registration が発生する時点ではそれが宣言されないため、OP は RP がどれを選ぶかを事前に知ることができない。¶

OPs は、相互にサポートされる任意の client authentication method を受け入れるべきであり、RPs は相互にサポートされる methods のみを用いなければならない。ある種の OP は、以後の相互作用でも RP が常に同じ client authentication method を用いることを前提とする実装になっている可能性があるため、RP がそうすることで相互運用性が改善される場合がある点に留意すること。¶

12.1.5. Automatic Registration の他の利用可能性

Automatic Registration は、Section 12 で述べたとおり、OpenID Connect を超えた OAuth 2.0 のユースケースにも用いられるよう設計されている。たとえば、素の OAuth 2.0 [[RFC6749]] や FAPI [[FAPI]] を用いるエコシステムは Automatic Registration を活用できる。¶

また、Client ID の値が Entity Identifiers である場合、OAuth 2.0 デプロイメントにおいて、Authorization Endpoint と Token Endpoint 以外の endpoints、たとえば Pushed Authorization Request (PAR) Endpoint や Introspection Endpoint で Automatic Registration を用いる client を識別するために利用できる点にも留意すること。そうした特定のシナリオを記述することは、この仕様のスコープ外である。¶

12.2. Explicit Registration

この方法では、RP は、[[OpenID.Registration]] と同様の専用の登録リクエストにより、OP との client registration を確立する。ただし自身の metadata を提出する代わりに、RP は自身の Entity Configuration または Trust Chain 全体を提出する。Explicit Registration が完了すると、RP は OP に対して通常の OpenID authentication requests を行える。¶

Explicit Registration をサポートする OP は、その client_registration_types_supported metadata parameter に explicit キーワードを含め、Explicit Registration requests を受け取る URL として federation_registration_endpoint metadata parameter を設定しなければならない。¶

Explicit Registration は、OP デプロイメントの [OpenID Connect Dynamic Client Registration 1.0] [[OpenID.Registration]] endpoint の上に実装するのに適している。Automatic Registration とは対照的に、OP が Client ID、場合によっては Client Secret、および他の metadata parameters をプロビジョニングできる。¶

Explicit Registration の例は Appendix A.3.2 に示される。¶

12.2.1. Explicit Client 登録リクエスト

RP は次のとおり Explicit Client Registration を行う。¶

RP が OP と共通する Trust Anchors の集合を決定したら、続行したい部分集合を選ぶ。これは 1 つの Trust Anchor でもよく、複数でもよい。RP は Section 10 で規定されるとおり、OP に対する Trust Chain と metadata の解決を実行しなければならない。解決が成功しない場合、RP はリクエストを中止しなければならない。¶
この Trust Anchors の部分集合を用いて、RP は利用可能な hints から authority_hints の集合を選ぶ。各 hint は、Trust Chain の収集の開始点として用いられた場合に、部分集合内の少なくとも 1 つの Trust Anchor へ至らなければならない。RP が OP と共通する Trust Anchor を複数持つ場合、RP は続行する Trust Anchors の部分集合を選ばなければならない。部分集合は 1 つの Trust Anchor だけでもよく、複数を含んでもよい。¶
次に RP は自身の Entity Configuration を構築する。このとき選択される metadata statement は OP の metadata の影響を受け、含める authority_hints は上記プロセスで選ばれる。RP は Immediate Superiors から 1 つ以上の authority_hints を選ばなければならない。そうして、各 hint は、Trust Chain 収集の開始点として用いられた場合に、上で選択した部分集合内の少なくとも 1 つの Trust Anchor へ至るようにしなければならない。¶
RP は、自身についての Trust Chain の中に自身の Entity Configuration を含めてもよい。これには 2 つの方法がある。第一は、Registration Request が、リクエストを行う RP と選択された Trust Anchor の間を構成する Trust Chain をなす Entity Statements のシーケンスを含む配列を含む方法である。第二は、Section 4.3 で指定される trust_chain header parameter を用いる方法である。¶
- NOTE: リクエスト JWT における trust_chain header parameter の利用は、第一の構文より RECOMMENDED である。第一の構文は歴史的理由により残されている。¶
RP は自身の Entity Configuration に自身の metadata を含め、上で選択した authority_hints を用いなければならない。¶
RP は、OP の Resolved Metadata に準拠するよう metadata parameters を選ぶべきであり、それにより OP への登録が成功することを保証する。提出された RP metadata が OP の metadata に準拠しない場合、OP はエラーレスポンスで拒否するのではなく、準拠するように修正することを選んでもよい点に留意すること。¶
Entity Configuration または Trust Chain 全体を、HTTP POST により federation_registration_endpoint に送信する。Entity Configuration または Trust Chain は POST body 全体である。RP は、保有する現在の Federation Entity Key を用いて自身の Entity Configuration に署名しなければならない。¶
Registration Request の content type は、要求元の Entity Configuration である場合は application/entity-statement+jwt でなければならない。そうでなく Trust Chain の場合、Registration Request の content type は application/trust-chain+json でなければならない。RP は、RP に至る Trust Chain の中に自身の Entity Configuration を含めてもよい。この場合、登録リクエストは、RP と RP が選択した Trust Anchor の間を構成する Trust Chain をなすステートメントのシーケンスからなる配列を含む。¶
リクエストが RP の Entity Configuration である場合、RP が選択した Trust Anchor と RP の間の Trust Chain を提供するために、trust_chain header parameter を含めてもよい。これは、Trust Chain を request body として提供するのと等価である。trust_chain header parameter が含まれる場合、RP が選択した Trust Anchor と OP の間の Trust Chain を提供するために、peer_trust_chain header parameter も含めてもよい。Peer Trust Chain には、登録時に OP が用いるよう RP が選んだ metadata と policy の値が含まれる。request body が Trust Chain の場合、peer_trust_chain header parameter を用いてはならない。両方の Trust Chains で選択される Trust Anchors は同一でなければならない。両方の Trust Chains を含めることで、[[App-Fed-Linkage]] で定義される Federation Integrity と Metadata Integrity の性質を達成できる。¶

Explicit Registration requests で用いる Entity Configuration Claims として、次が指定される。詳細な説明は Section 3 にある。¶

iss
REQUIRED. 値は RP の Entity Identifier でなければならない。¶

sub
REQUIRED. 値は RP の Entity Identifier でなければならない。¶

iat
REQUIRED.¶

exp
REQUIRED.¶

jwks
REQUIRED.¶

aud
REQUIRED. "aud"（audience）の値は OP の Entity Identifier でなければならず、他の値を含んではならない。この Claim は Explicit Registration requests で用いられる。一般の Entity Statement Claim ではない。¶

authority_hints
REQUIRED.¶

metadata
REQUIRED. openid_relying_party Entity Type Identifier の下に RP metadata を含まなければならない。¶

crit
OPTIONAL.¶

trust_marks
OPTIONAL.¶

リクエストは、POST メソッドを用いて、OP の federation_registration_endpoint への HTTP リクエストでなければならない。¶

RP が Entity Configuration を提出する場合、リクエストの content type は application/entity-statement+jwt でなければならない。RP が Trust Chain を提出する場合、content type は application/trust-chain+json でなければならない。¶

12.2.2. Processing Explicit Client Registration Request by OP

OP はリクエストを次のとおり処理する。¶

登録リクエストを受信したら、OP は content type を検査し、それが Entity Configuration を含むのか、Trust Chain 全体を含むのかを判断しなければならない。¶
OP は、RP の explicit registration request JWT を検証しなければならない。通常の Entity Statement の検証規則がすべて適用される。加えて、aud（audience）Claim の値が OP の Entity Identifier でない場合、リクエストは拒否されなければならない。¶
リクエスト内に、RP から Trust Anchor への Trust Chain が提供されていない場合、OP は提供された Entity Configuration を用いて、RP の Entity Configuration の authority_hints から始まる Trust Chains を収集・評価し、Federation Entity Discovery を完了しなければならない。少なくとも 1 つの Trust Chain を検証した後、OP は受信した Entity Configuration の署名を検証しなければならない。OP が受け入れ可能な Trust Chain を複数見つけた場合、その中から 1 つを選び、以後の処理に用いなければならない。¶
request body が Trust Chain の場合、OP は、Federation Entity Discovery の実行に必要な HTTP 呼び出しを節約するために Trust Chain 内のステートメントを評価してもよい。特に、RP が自身の Entity Configuration に複数の authority hint を含めた場合に有用である。そうでない場合、OP は Trust Chain から RP の Entity Configuration を抽出し、Entity Configuration のみを受信したかのように Step 3 に従って処理しなければならない。¶
リクエストの Entity Configuration において trust_chain header parameter を用いて Trust Chain が提供される場合、OP も同様に、Federation Entity Discovery の実行に必要な HTTP 呼び出しを節約するために Trust Chain 内のステートメントを評価してもよい。この場合、Trust Chain 内の RP の Entity Configuration は、RP から Trust Anchor への経路が存在することを確立するためにのみ用いられる点に留意すること。登録リクエストの処理で用いられるのは、RP が OP 向けに調整している可能性がある、リクエスト Entity Configuration 内の metadata 等である。提供された Trust Chain を用いない場合、OP はリクエスト Entity Configuration を用いて Step 3 に従って処理しなければならない。¶
リクエストが peer_trust_chain header parameter を用いて、RP が選択した Trust Anchor への OP からの Trust Chain を含める場合、それが OP から始まることを検証すること。さらに、RP から Trust Anchor への Trust chain が提供されている場合、それと同じ Trust Anchor で終わることを検証すること。OP は、登録時に RP が選択した metadata と policy の値を用いるべきである。¶
この時点で、OP が要求元 RP に対する既存の client registration をすでに持っていることが判明した場合、その登録は無効化されなければならない。無効化の正確なタイミングは OP の裁量である。これは、登録リクエストの処理中に RP が開始した同時並行の OpenID authentication requests の完了を確実にしたい場合があるためである。¶
- OP は、過去の RP 署名を検証し、過去の RP データに対して他の暗号処理を行うために、無効化された登録から client credentials および鍵素材を保持してもよい。¶
OP は、RP の Resolved Metadata を用いて、自身の OP metadata およびその他の適用可能なポリシーに準拠した client registration を作成する。¶
- OP は、RP の Entity Identifier とは異なる client_id を RP にプロビジョニングしてもよい。これにより、Explicit Registration を、OP デプロイメントの [OpenID Connect Dynamic Client Registration 1.0] [[OpenID.Registration]] endpoint の上に実装できる。¶
- RP に client_secret がプロビジョニングされる場合、それは RP に返される registration Entity Statement の有効期限より前に期限切れになってはならない。¶
- OP は、RP が登録を更新するための想定手段が新たな Explicit Registration リクエストであるため、registration_access_token と registration_client_uri を RP にプロビジョニングすべきではない。何らかの目的（例：登録済み metadata を独立に確認できるようにする）で RP に registration_access_token をプロビジョニングする場合、そのトークンは登録の変更を許可してはならない。¶
- OP は、受信した RP metadata を、自身の OP metadata および他のポリシーに準拠させるために、たとえば不正または未サポートのパラメータを置換するなどして修正してもよい。OP が RP metadata を受け入れない、または準拠させるために修正したくない場合、OP は、[[OpenID.Registration]] の Section 3.3 で規定される invalid_client_metadata または invalid_redirect_uri などの適切なエラーを伴う client registration error response を返さなければならない。¶
OP は、作成した registration に有効期限を割り当てなければならない。この時刻は、OP がリクエスト処理に選択した Trust Chain の有効期限を超えてはならない。¶

12.2.3. Successful Explicit Client Registration Response

OP が RP の client registration を作成した場合、OP は Entity Statement の形式で成功レスポンスを構築しなければならない。¶

OP は、その Entity Statement の trust_anchor Claim を、リクエスト処理に選択した Trust Anchor に設定しなければならない。authority_hints Claim は、選択された Trust Chain における RP の Immediate Superior に設定されなければならない。¶

OP は exp Claim を、作成した registration の有効期限に設定しなければならない。OP は、Section 12.2.6 で説明されるとおり、それより前に registration を無効化することを選んでもよい。¶

OP は、metadata Claim により、RP のために作成した client registration を表現しなければならない。すなわち、openid_relying_party Entity Type Identifier の下に metadata parameters を配置する。これらのパラメータは、RP にプロビジョニングされた client_id を含まなければならない。RP に credentials（例：client_secret）がプロビジョニングされた場合、それらも含めなければならない。¶

OP は、RP によるレスポンス処理を簡素化するために、既定値を持つ metadata parameters（例：既定値が client_secret_basic の token_endpoint_auth_method）を含めるべきである。¶

OP は、保有する現在の Federation Entity Key を用いて registration Entity Statement に署名しなければならない。¶

Explicit Registration responses で用いられる Entity Statement Claims は、Section 3 で指定されるとおり次のとおり。¶

iss
REQUIRED. 値は OP の Entity Identifier でなければならない。¶

sub
REQUIRED. 値は RP の Entity Identifier でなければならない。¶

iat
REQUIRED. このステートメントが発行された時刻。¶

exp
REQUIRED. この時刻以降、ステートメントは処理のために受け入れられてはならない有効期限。¶

jwks
OPTIONAL. 存在する場合、受信した RP の Entity Configuration にある jwks Entity Statement Claim の逐語的コピーでなければならない。これは同名の RP metadata parameter とは異なる点に留意すること。¶

aud
REQUIRED. "aud"（audience）の値は RP の Entity Identifier でなければならず、他の値を含んではならない。この Claim は Explicit Registration responses で用いられる。一般の Entity Statement Claim ではない。¶

trust_anchor
REQUIRED. 値は、OP が Explicit Registration リクエストの処理に選択した Trust Anchor の Entity Identifier でなければならない。RP が選択した Trust Anchor への完全な Trust Chains が、リクエストおよび／または peer_trust_chain header parameter により提供された場合、これはそれら Trust Chains のルートにある Trust Anchors と一致しなければならない。この Claim は Explicit Registration responses に固有であり、一般の Entity Statement Claim ではない。¶

authority_hints
REQUIRED. 単一要素配列でなければならず、その値は、OP がリクエスト処理に選択した Trust Chain における RP の Immediate Superior を参照しなければならない。¶

metadata
REQUIRED. openid_relying_party Entity Type Identifier の下に、登録済みの RP metadata を含まなければならない。¶

crit
OPTIONAL. Section 3.1.1 で指定されるとおり、理解され処理されなければならない Claims の集合。¶

成功レスポンスは、HTTP ステータスコード 200 と content type application/explicit-registration-response+jwt を持たなければならない。さらに、レスポンスの typ ヘッダーパラメータの値は、cross-JWT confusion を防ぐために（[[RFC8725]] の Section 3.11 に従い）、explicit-registration-response+jwt（entity-statement+jwt ではなく）でなければならない。¶

12.2.4. Explicit Client Registration Error Response

client registration error の場合、レスポンスは Section 8.9 で定義されるとおりであり、同セクションで定義される errors、ならびに [[OpenID.Registration]] の Section 3.3 および [[RFC7591]] の Section 3.2.2 で定義される errors を用いてもよい。¶

12.2.5. Processing Explicit Client Registration Response by RP

レスポンスが成功を示す場合、RP はその内容が有効な Entity Statement であり、かつ OP により発行されていることを検証しなければならない。¶
- RP は、OP が用いた署名用 Federation Entity Key が、RP が Explicit Registration リクエストを準備した際に OP について成功裏に解決した Trust Chain において、OP の Immediate Superior が OP について発行した Subordinate Statement の jwks Claim に存在することを確実にしなければならない。¶
RP は、aud（audience）Claim の値が自身の Entity Identifier であることを検証しなければならない。¶
RP は、trust_anchor が自身の Trust Anchors の 1 つを表すことを検証しなければならない。RP が選択した Trust Anchor への完全な Trust Chains が、リクエストおよび／または peer_trust_chain header parameter により提供された場合、RP はこれがそれら Trust Chains のルートにある Trust Anchors と一致することを検証しなければならない。¶
RP は、Explicit Registration リクエストで指定した authority_hints の少なくとも 1 つが、OP が trust_anchor Claim に設定した Trust Anchor へ至ることを検証しなければならない。¶
RP はまず、OP において登録された情報が、リクエストと同じ集合の Entity Types を含むことを確実にしなければならない。次に、レスポンスの Claim trust_anchor を Trust Anchor の Entity Identifier とし、authority_hints を Trust Chain 収集の開始点として Trust Chain を収集した後、RP は、Section 6.1.4.1 で指定されるとおり、解決された policies を受信した metadata に適用することで、各 entity type のレスポンス metadata が有効であることを検証するべきである。¶
受信した registration Entity Statement が上記チェックに合格しない場合、RP はそれを拒否しなければならない。RP は、一時的な例外（例：Entity metadata または metadata policy の最近の変更により metadata が一時的に不整合となっている）を回避するために、Explicit Registration リクエストを再試行することを選んでもよい。¶

12.2.6. Explicit Client Registration の有効期間

RP は、registration Entity Statement の exp Claim を利用して、client registration を更新するための適切な戦略を立てられる。RP の実装者は、OP において RP の登録が期限切れになっていると、OpenID Connect の authentication requests、token requests、UserInfo requests が失敗しうる点に留意すべきである。有効期限の前に RP の登録を更新することで、こうしたエラーの発生を防ぎ、End-User 体験が損なわれないことを確実にできる。¶

OP は、RP の registration Entity Statement に示される有効期限より前に client registration を無効化してもよい。理由の例として、RP を登録するのに用いられた federation から OP が離脱する場合が挙げられる。¶

12.3. 登録の有効性と信頼の再評価

OP における Automatic または Explicit Registration の有効期間は、OP が登録作成に用いた Trust Chain の lifetime を超えてはならない。OP は、より早い時刻に登録を期限切れにすることを選んでもよいし、Trust Chain が有効期限に達する前に、登録済み RP について Trust Chain を追加で定期的に再評価することを選んでもよい。¶

同様に、Automatic または Explicit Registration を得た RP は、OP に対する信頼を確立するために RP が用いた Trust Chain の有効期限を過ぎて、それを用いてはならない。Automatic Registration を用いる RP の場合、OP へのリクエストを継続する前に、OP への信頼が成功裏に再評価されなければならない。Explicit Registration を用いる RP の場合、RP は登録を成功裏に更新しなければならない。RP は、Trust Chain が有効期限に達する前に、OP について Trust Chain を追加で定期的に再評価することを選んでもよい。¶

12.4. Automatic Registration と Explicit Registration の違い

Automatic Registration と Explicit Registration の主な違いは次のとおり。¶

Automatic Registration では Authentication Request の前に登録ステップがないのに対し、Explicit Registration では登録ステップが存在する（[OpenID Connect Dynamic Client Registration 1.0] [[OpenID.Registration]] と [OAuth 2.0 Dynamic Client Registration] [[RFC7591]] も、事前の登録ステップを採用している）。¶
Automatic Registration では Client ID の値が RP の Entity Identifier であり RP により OP に提供されるのに対し、Explicit Registration では Client ID は OP により割り当てられ RP に提供される。¶
Automatic Registration では、Client は、RP が Entity Configuration の公開鍵の 1 つに対応する秘密鍵を制御していることを証明することにより認証される。これに対し Explicit Registration では、Client Secret の利用を含め、Client を認証するためのより広い選択肢が利用可能である。¶

12.5. リクエスト内の Trust Chains の設計理由

Automatic と Explicit の双方の Client Registration は、要求者が自身に関して計算し、リクエスト内に埋め込んだ Trust Chain を提出することをサポートする。これは次の利点をもたらす。¶

OP が古くなった RP metadata を用いてしまう問題を解決する。こうした stale data は、OP が有効期限に達していない Trust Chain からキャッシュした RP metadata を用いるときに発生しうる。RP は、リクエストに trust_chain header parameter または trust_chain リクエストパラメータを含めることで変更が起きたことを OP に通知でき、OP が Client Registration を更新し、stale metadata による一時的な故障の可能性を防げる。¶
Trust Chain を構築するためにどの信頼経路を辿るべきかについて、検証可能なヒントを OP に渡せる。これは、RP が複数の Trust Anchors を持つ、または Trust Chain の解決が行き止まりに至りうる複雑な federation において、OP による RP の Federation Entity Discovery のコストを削減しうる。¶
Trust Marks を含む場合もある Entity Configuration を直接渡せるため、OP が RP の /.well-known/openid-federation endpoint へ HTTP リクエストを行う必要を省ける。¶

双方はまた、RP が選択した Trust Anchor と OP の間の Trust Chain を提供する Peer Trust Chain の提出もサポートする。Section 4.4 で記述されるとおり、両方の Trust Chains を含めることで、[[App-Fed-Linkage]] で定義される Federation Integrity と Metadata Integrity の性質を達成できる。¶

13. 汎用 JWT Claims

このセクションは、多くの異なる JWT profiles で利用されるよう設計された、汎用 JWT Claims を定義する。これらは、この仕様で定義される特定種別の JWT でも用いられる。¶

13.1. "jwks" (JSON Web Key Set) Claim

jwks（JSON Web Key Set）Claim の値は、[[RFC7517]] で定義される JWK Set である。これは暗号鍵の集合を伝達するために用いられる。この Claim の使用は OPTIONAL である。¶

たとえば jwks（JSON Web Key Set）Claim は、アプリケーションの署名鍵の集合を表すために用いられうる。この仕様では、Section 3.1.1 で指定されるとおり、Entity Statement に署名するために用いられる公開鍵を表すためにこの Claim を用いる。¶

13.2. "metadata" Claim

metadata Claim は、JWT に関する metadata を伝達するために用いられる。その値は JSON オブジェクトである。含まれる metadata の詳細はアプリケーション固有である。この Claim の使用は OPTIONAL である。¶

たとえば metadata Claim は、API 記述における endpoint URLs とアルゴリズム識別子の集合を表すために用いられうる。この仕様では、Section 3.1.1 で指定されるとおり、Entity に関する metadata を表すためにこの Claim を用いる。¶

13.3. "constraints" Claim

constraints Claim は、JWT に関する constraints を伝達するために用いられる。その値は JSON オブジェクトである。含まれる constraints の詳細はアプリケーション固有である。この Claim の使用は OPTIONAL である。¶

たとえば、この Claim は、この仕様において Section 3.1.3 で指定されるとおり、Entity に対する Trust Chain の constraints を表すために用いられる。¶

13.4. "crit" (Critical) Claim

crit（critical）Claim は、この種別の JWT で利用することが指定される Claims の集合に対して、理解され処理されなければならない拡張が用いられていることを示す。これは、理解され処理されなければならない拡張 JOSE ヘッダーパラメータのために crit ヘッダーパラメータが用いられるのと同じ方法で用いられる。その値は配列であり、拡張を用いる Claims として JWT 内に存在する Claim Names を列挙する。列挙された Claims のいずれかが受信者により理解・サポートされない場合、JWT は無効である。生成者は、この種別の JWT で利用することがすでに指定されている Claim Names、重複名、または JWT 内の Claim Names として出現しない名前を crit リストに含めてはならない。生成者は、空配列 [] を crit 値として用いてはならない。この Claim の使用は OPTIONAL である。¶

[[RFC7519]] の Section 4 は、「JWT の特定のアプリケーションでは、実装がある種の claims を特定の方法で理解し処理することを要求する。しかし、そのような要求がない場合、実装が理解しない claims はすべて無視されなければならない」と述べている。したがって、crit（critical）Claim を有効にするには、それを用いる特定種別の JWT の定義において、上の記述で許可されるとおり crit が理解され処理されなければならないことを指定しなければならない。¶

この仕様では、Section 3.1.1 で指定されるとおり、Entity Statements において用いられる際に、この仕様で定義されないが理解され処理されなければならない Claims を識別するためにこの Claim を用いる。¶

13.5. "ref" (Reference) Claim

ref（reference）Claim は、JWT に関連するリソースの URI を伝達するために用いられる。これは、JWT において HTML の href プロパティが果たす役割に類似する。参照されるリソースの内容の性質は一般にアプリケーション固有である。ref の値は、URI 値を含む大文字小文字を区別する文字列である。この Claim の使用は OPTIONAL である。¶

たとえば、当事者間の契約を参照する JWT は、契約条項を読めるリソースを参照するために ref（reference）Claim を用いられうる。この仕様では、Section 7.1 で指定されるとおり、Trust Mark の発行に関する人間可読な情報を参照する URL を提供するためにこの Claim を用いる。¶

13.6. "delegation" Claim

delegation Claim は、Claim 値で参照される party に権限が委任されていることを表す。delegation の値は、StringOrURI 値を含む大文字小文字を区別する文字列である。この Claim の使用は OPTIONAL である。¶

たとえば delegation Claim は、参照される party が subject に代わって法的文書に署名できることを表すために用いられうる。この仕様では、Section 7.1 で指定されるとおり、特定の識別子を持つ Trust Marks を発行する権利の委任を表すためにこの Claim を用いる。¶

delegation Claim は、既存の act Claim [[IANA.JWT.Claims]] とは、構文的にも意味的にも異なる点に留意すること。act は JSON オブジェクトであるのに対し、delegation は StringOrURI である。意味的には、Section 7.2.1 で定義される Delegation JWT は、issuer による署名を伴い、委任する権利を暗号学的に証明する。署名を伴わない act Claim は、これを達成できない。¶

13.7. "logo_uri" (Logo URI) Claim

logo_uri Claim の値は、JWT に関連するロゴを参照する URI である。この Claim の使用は OPTIONAL である。¶

たとえば logo_uri Claim は、ユーザーインターフェースで表示するために、組織のロゴを取得する場所を表すために用いられうる。この仕様では、Section 7.1 で指定されるとおり、Entity のロゴを参照する URL を伝達するためにこの Claim を用いる。¶

14. Claims の言語と文字体系

人間可読な Claim Values、および人間可読な値を参照する Claim Values は、複数の言語および文字体系で表現されてもよい。この仕様は、[OpenID Connect Core 1.0] の Section 5.2 で定義されるのと同じ方法で、そのような表現を可能にする。¶

OpenID Connect Core で記述されるとおり、言語と文字体系を指定するために、[[RFC5646]] による BCP47 の language tags を、# 文字で区切ってメンバー名に付加する。たとえば family_name#ja-Kana-JP は、日本語のカタカナによる姓を表し、これは一般に、family_name#ja-Hani-JP として表される同じ名前の漢字表現の読みを索引化・表現するために用いられる。¶

language tags は、人間可読な値を含む、またはそれらを参照する任意のデータ構造（metadata parameters や Trust Mark parameters を含む）で用いられる。たとえば、organization_name と organization_name#de は metadata 内に同時に現れうる。¶

15. Media Types

この仕様は、[[RFC2046]] の次の media types を定義する。¶

15.1. "application/entity-statement+jwt" Media Type

application/entity-statement+jwt media type は、関連する内容が Section 3 で定義される Entity Statement であることを示すために用いられる。この media type にはパラメータは用いられない。¶

15.2. "application/trust-mark+jwt" Media Type

application/trust-mark+jwt media type は、関連する内容が Section 7 で定義される Trust Mark であることを示すために用いられる。この media type にはパラメータは用いられない。¶

15.3. "application/resolve-response+jwt" Media Type

application/resolve-response+jwt media type は、関連する内容が Section 8.3.2 で定義される Resolve Response であることを示すために用いられる。この media type にはパラメータは用いられない。¶

15.4. "application/trust-chain+json" Media Type

application/trust-chain+json media type は、Section 4 で定義される Trust Chain を表す JSON 配列であることを示すために用いられる。この media type にはパラメータは用いられない。¶

15.5. "application/trust-mark-delegation+jwt" Media Type

application/trust-mark-delegation+jwt media type は、Section 7.2.1 で定義される Trust Mark delegation であることを示すために用いられる。この media type にはパラメータは用いられない。¶

15.6. "application/jwk-set+jwt" Media Type

application/jwk-set+jwt media type は、Section 8.7.2 で定義される署名付き JWK Set であることを示すために用いられる。この media type にはパラメータは用いられない。¶

15.7. "application/trust-mark-status-response+jwt" Media Type

application/trust-mark-status-response+jwt media type は、Section 8.4.2 で定義される Trust Mark Status Response であることを示すために用いられる。この media type にはパラメータは用いられない。¶

15.8. "application/explicit-registration-response+jwt" Media Type

application/explicit-registration-response+jwt media type は、Section 12.2.3 で定義される Explicit Registration response であることを示すために用いられる。この media type にはパラメータは用いられない。¶

16. 文字列操作

一部の OpenID Federation メッセージの処理では、メッセージ中の値を他の値と比較する必要がある。たとえば、iss Claim の Entity Identifier は sub Claim の Entity Identifier と比較されうる。しかし、Unicode 文字列 [[UNICODE]] の比較には重大なセキュリティ上の含意がある。¶

したがって、JSON 文字列と他の Unicode 文字列の比較は、以下のとおり実施されなければならない。¶

JSON に適用されたエスケープを除去し、Unicode コードポイントの配列を得る。¶
Unicode Normalization [[USA15]] は、JSON 文字列にも、比較対象となる文字列にも、いかなる時点でも適用されてはならない。¶
2 つの文字列の比較は、Unicode コードポイント同士の等価性（code point to code point equality）比較として実施されなければならない。¶

これは、[OpenID Connect Core 1.0] の Section 14 で指定される比較手順と同一である点に留意すること。¶

17. 実装上の考慮事項

このセクションは、federation の実装者および運用者に対し、その federation において考慮すべき状況や性質についてのガイダンスを提供する。¶

17.1. Federation のトポロジ

Entities 間に複数の信頼経路（trust paths）が存在する Federation topology を構築することは可能である。この仕様はそれを禁止しないが、運用者が認識しておくべき曖昧さを生みうる。¶

次の Federation topology を考える。¶

              .--------------.
              | Trust Anchor |
              '--.---.-----.-'
                 |   |     |
              .--'   '--.  '---------------.
              |         |                  |
.-------------v--.   .--v-------------.    |
| Intermediate 1 |   | Intermediate 2 |    |
'-------------.--'   '--.-------------'    |
              |         |                .-v--.
              |         |                | OP |
           .--v---------v---.            '----'
           | Intermediate 3 |
           '-------.--------'
                   |
                   |
                 .-v--.
                 | RP |
                 '----'

Figure 54: Example Topology with Multiple Trust Paths between Entities

この topology では、RP と Trust Anchor の間に複数の信頼経路が存在し、それらの間で複数の異なる Trust Chains が構築されうる。Intermediate 1 と Intermediate 2 の metadata policies が異なる場合、Trust Chain の構築時にどちらの Intermediate を用いるかによって、RP の Resolved Metadata が異なりうる。そうした差異の中には無害なものもあるが、失敗を引き起こしうるものもある。¶

どの信頼経路が選ばれて Trust Chain が構築されても意図どおりに機能する topology と metadata policies をデプロイするのは Federation architects の仕事である。もちろん、潜在的な曖昧さを避ける 1 つの方法は、2 つの Entities の間に複数経路を持たない木（tree）だけの topology を用いることである。木ではない topology も許容されるが、意識的に慎重に用いるべきである。¶

Federation topology にループが含まれている場合でも、Section 10.1 により義務付けられるとおり、それらから構築される Trust Chains はループを含んではならない。¶

17.2. Federation Discovery と Trust Chain 解決パターン

このセクションは、federation 内の entities を発見し、Trust Chains を解決するために、実装が用いられるさまざまなパターンを記述する。ここで重要なのは、関連するが異なる 2 つの概念を区別することである。¶

Discovery：federation の一部である entities を見つけるプロセス。典型的には、利用可能な service providers のディレクトリやカタログを構築するために用いられる。¶
Trust Chain Resolution：Section 10 で記述されるとおり、既知の entity から Trust Anchor までの Trust Chain を構築し検証するプロセス。この仕様では、このプロセスは Federation Entity Discovery とも呼ばれる（Section 1.2 の定義による）。¶

これらのパターンは discovery と Trust Chain 解決の双方を含みうるが、目的は異なり、ユースケースに応じて独立に用いられうる。たとえば OpenID Providers のディレクトリを構築する discovery サービスは、発見したすべての entity について Trust Chains を解決せずに entity identifiers を収集できる。実際の Trust Chain 解決は後段、たとえば RP と OP が authentication 取引を行う際に、Section 10 で記述される Trust Chain 解決プロセスを用いて行われうる。¶

実装は次のパターンの 1 つ以上をサポートしてもよい。¶

Bottom-Up Trust Chain Resolution（Section 17.2.1）：Section 10 で記述されるとおり、既知の entity identifier から開始して Trust Chains を解決する。¶
Top-Down Discovery（Section 17.2.2）：Trust Anchor から開始して階層を下へ辿り、federation 内の entities を見つける。¶
Single Point of Trust Resolution（Section 17.2.3）：Resolve Endpoint を実装する信頼された resolver に Trust Chain 解決を委任する。¶

Federation operators は、異なるユースケースや統合シナリオに対応するために、複数のパターンをサポートすることを選んでもよい。サポートするパターンの選択は、federation の使いやすさや、効果的に統合できるアプリケーションの種類に影響する。¶

17.2.1. Bottom-Up Trust Chain Resolution

Bottom-up Trust Chain resolution は、Section 10 で記述されるプロセスであり（Terminology セクションの定義も参照）、Federation Entity Discovery とも呼ばれる。このプロセスは、既知の Entity Identifier から開始し、federation の階層を上へ辿って Trust Anchor に到達するまで Trust Chain を構築する。このパターンは、未知の entities を見つけるという意味での discovery ではなく、既知の entity に対する信頼解決である。¶

このパターンは、ある entity が、Entity Identifier がすでに既知である別の entity の信頼性を検証する必要があるときに用いられる。典型的には次の用途で用いられる。¶

OpenID Providers が authentication requests において Relying Parties を検証する。¶
Resource servers が Client の信頼性を検証する。¶
既知の相手からの受信リクエストを検証する任意の Entity。¶
連携環境における動的な信頼確立。¶

bottom-up の Trust Chain 解決プロセスは、Section 10 で記述されるとおり次のステップに従う。¶

subject entity の Entity Configuration から開始する（提供されるか、Section 9 で定義されるプロセスで取得される）。¶
authority_hints を用いて immediate superior entities を特定する。¶
各 Superior Entity の Entity Configuration を取得する。¶
Section 8.1.1 で定義される Fetch Endpoints を用いて、subject entity に関する Subordinate Statements を取得する。¶
Trust Anchor に到達するまで階層を再帰的に上へ辿る。¶
完全な Trust Chain を構築し検証する。¶
federation policies を適用して Resolved Metadata を導出する。¶

17.2.2. Top-Down Discovery

Top-down discovery は、既知の Trust Anchor から開始し、federation の階層を下へ辿ることで、federation の一部である entities を見つけるプロセスである。このパターンは、entity identifiers を事前に必ずしも知らない状況で、利用可能な entities、特に特定の Entity Types の entities を発見することが目的である場合に用いられる。¶

このパターンは、特に次の用途で有用である。¶

Relying Parties が OpenID Providers を探すための service discovery。¶
Clients が特定の service types を探すための resource discovery。¶
federation の閲覧・探索。¶
provider directories や catalogs の構築（例：WAYF services、Seamless Access）。¶

top-down discovery プロセスは次のステップに従う。¶

発見者が信頼する既知の Trust Anchor から開始する。¶
Section 8.2 で定義される list endpoint を用いて Immediate Subordinate entities を発見する。¶
entity_type パラメータでフィルタして、プロトコル固有の providers（例：openid_provider）を見つける。¶
Intermediate entities については、subordinates を再帰的に辿る。¶
発見した entities の Entity Identifiers を収集し、必要に応じて Entity Configurations も収集する。¶

top-down discovery が Trust Chain 解決を含むかどうかはユースケースに依存する点に留意すること。たとえばログイン時にユーザーが選択するための OpenID Providers のディレクトリを構築する場合、discovery サービスはすべての発見済み entities について Trust Chains を解決せずに、entity identifiers と基本 metadata を収集できる。しかし、ディレクトリに含める前に entities が federation に正しく登録されていることを検証する必要がある場合、discovery プロセスの一部として Trust Chain 解決を行うことを選んでもよい。¶

17.2.3. Single Point of Trust Resolution

Single point of trust resolution は、Section 8.3 で定義される Resolve Endpoint を実装する信頼された resolver に、Trust Chain 解決プロセス全体を委任する。このパターンにより、entities は Trust Chain 解決の複雑さを専門サービスにオフロードできる。¶

このパターンは次の用途で有用である。¶

Trust Chain 解決の複雑さをオフロードしたい entities。¶
集約された trust evaluation サービス。¶
Resolved Metadata のキャッシュによる性能最適化。¶
軽量 client の統合簡素化。¶

このパターンは、subject entity の Entity Identifier が事前に既知であることを要する点に留意すること。federation 内の未知 entities を見つけるという意味での discovery 機能は提供しない。¶

single point of trust resolution プロセスは次のステップに従う。¶

Resolve Endpoint を持つ信頼された resolver を特定する。¶
subject Entity Identifier と Trust Anchor を resolver に提示する。¶
resolver は内部で完全な Trust Chain 解決（bottom-up パターン）を実行する。¶
resolver は Resolved Metadata と Trust Marks を返す。¶
必要に応じて resolver 自身の Trust Chain を検証する。¶
プロトコル処理に Resolved Metadata を用いる。¶

17.3. Trust Anchors と Resolvers はセットである

federation に resolver が 1 つしか存在しない場合、その entity は Trust Anchor と Resolver の両方であるべきである。そうであれば、resolver の利用者は resolver の Trust Chains を収集・評価する必要がなくなる。Trust Anchor は定義上信頼されており、かつその entity が Resolver としても機能するなら、そのサービスも暗黙に信頼される。¶

17.4. 1 Entity、1 サービス

entity が Trust Anchor と Resolver の両サービスを提供できるようにすることとは別に、各 entity に 1 つのことだけをさせるのには良い理由がある。理由は、後になって、federation 間で特定のサービスを共有することがはるかに容易になるためである。¶

17.5. Trust Mark のポリシー

Entity Statement における trust marks の検証は、3 つの部分に分けられる。¶

Validating Trust Marks in the Context of Validating an Entity Statement

[Section 3.2] の Entity Statement Validation に関する記述によれば、Trust Mark の検証は、trust_mark_type 値の整合を含め、Claim Value の構文を検証することに限定される。¶

Validating a Specific Trust Mark

これは [Section 7.3] で記述される内容である。Trust Mark を検証するために、entity は、Trust Mark Issuer から、entity が信頼する Trust Anchor までの Trust Chain を見つけなければならない。これは、後でアプリケーションプロトコルに用いられる federation がどれかとは無関係である。¶

Deciding which Trust Marks to Use

federation は、特定の基準に一致する Trust Marks だけを用いるべきである、というポリシーを持ってもよい。¶

そのような基準の例として、Trust Mark の trust_mark_type が Trust Anchor の trust_mark_issuers に列挙されていなければならず、かつそうであるなら、そのインスタンスの iss が対応する Entity Identifiers の一覧に現れるべきである、というものがある。なお、その一覧は空リストでありうるが、これは当該 trust_mark_type の Trust Mark を誰でも発行できることを意味する。そのような Trust Marks は、Entity Configuration が別の federation に関連付けられた Trust Marks を含む場合や、特定の目的または特定の Entity の audience を意図した Trust Marks である場合など、さまざまな理由で現れうる。¶

Entity は、federation 内で認識されない Trust Marks であっても、かつ、認定機関（accreditation authority）が out-of-band の仕組みで確立されている場合には、自身の裁量で提示された Trust Marks を利用することを選んでもよい。¶

17.6. 関連仕様

これらの関連仕様は、この仕様で定義される機能を、プロトコル非依存とプロトコル固有の別々の仕様へリファクタリングする。2 つの仕様を合わせるとこの仕様と等価であり、新しい機能は追加されず、何も削除されない。したがって、それらはこの仕様と相互に置き換えて利用できる。¶

[OpenID Federation 1.1] [[OpenID.Federation-1.1]] は、この仕様で定義されるプロトコル非依存の機能を含む。これには Entity Statements、Trust Chains、Metadata、Policies、Trust Marks、Federation Endpoints が含まれる。¶
[OpenID Federation for OpenID Connect 1.1] [[OpenID.Federation.Connect-1.1]] は、この仕様で定義されるプロトコル固有の機能を含む。これには OpenID Connect と OAuth 2.0 Entities の Entity Type Identifiers と Metadata、ならびに Client Registration フローが含まれる。¶

18. セキュリティ上の考慮事項

18.1. Denial-of-Service 攻撃の防止

この仕様で定義されるいくつかのインターフェースは Denial-of-Service（DoS）攻撃に利用されうる。特に、resolve endpoint（Section 8.3）、Explicit Client Registration（Section 12.2）、Automatic Client Registration（Section 12.1）は、HTTP 伝播攻撃（HTTP propagation attacks）のベクターとして悪用されうる。以下は、そのような攻撃がどのように起きるかの説明と、それを防ぐ対策である。¶

対向者（adversary）は、自身の Entity Configuration に何百もの偽の authority_hints を提供することで、Federation Entity Discovery の仕組みを悪用し、多数の HTTP リクエストを伝播させうる。対向者が制御する RP が OP に authorization request を送る状況を想像してほしい。対向者が細工した各リクエストに対し、OP は、対向者の Entity Configuration に対する 1 つのリクエストと、authority_hints に含まれる各 URL に対する追加のリクエストを生成する。¶

これらの endpoints が提供される場合、[[RFC4732]] で述べられるものを含む、以下のような適切な防御策が必要である。¶

実装は、検査する authority_hints の数に上限を設定すべきである。これは、対向者が Entity Configuration に大量の偽 authority_hints を定義する攻撃から保護するためである。¶

Entities は、Section 12.1.1.1 で説明されるとおり、リクエストに Trust Chain を含めることを要求されうる。静的 Trust Chain は、事前に定義された信頼経路を与えるため、Federation Entity Discovery を実行する必要がない。この場合、Trust Chain は Trust Anchor の公開鍵で静的に検証できるため、伝播攻撃は防止される。¶

Trust Mark は、その issuer の公開鍵を用いて静的に検証できる。Trust Marks の静的検証は、伝播攻撃に対するフィルターを表す。OpenID Provider（OP）が Entity Configuration の中で少なくとも 1 つの有効な Trust Mark を発見した場合、それはリクエストを開始した Relying Party の信頼性の証拠として機能しうる。Trust Mark は任意であるため、それを要求するかどうかの判断は federation 実装の裁量であり、federation は特定のニーズに応じて Trust Marks を定義し要求してもよい。¶

resolve endpoint で Client authentication が要求されない場合、受信リクエストが自動的に Trust Chains の収集（Federation Entity Discovery プロセス）と評価をトリガしてはならない。代わりに、resolve endpoint は、未認証 Client リクエストに対して、すでに評価され信頼できると判断された Entities に関するキャッシュ済み情報のみで応答すべきである。この場合、Federation Entity Discovery プロセスの開始は、resolve endpoint の既定動作であってはならない。¶

request_uri リクエストパラメータを用いて request objects を参照渡しすることは、Section 12.1.1 で記述されるとおり、一部のデプロイメントではサポートされない場合がある。これは、攻撃者が OPs に対して攻撃者の制御下にある任意の内容を取得させうる仕組みを排除するためである。¶

18.2. 署名されないエラーメッセージ

このプロトコルの基本的な設計目標の 1 つは、メッセージを end-to-end に保護することである。これは TLS を要求するだけでは達成できない。なぜなら TLS は、多くの場合 end-to-end ではなく、HTTPS から HTTP への Reverse Proxy で終端するためである。したがって、署名されないエラーメッセージを許すことは、DoS 攻撃を行いたい者にとっての攻撃ベクターを開く。これは OpenID Federation に固有ではなく、HTTPS から HTTP の reverse proxies が用いられる他のプロトコルでも同様に妥当である。¶

19. プライバシー上の考慮事項

実装者は、これらのプライバシー上の考慮事項を認識すべきである。¶

19.1. Entity Statement のプライバシー考慮事項

Entity Statements は、個人間や特定のビジネスアプリケーションのためではなく、federation 内の組織 entities 間の信頼関係を確立するよう設計されている。Know Your Customer や Anti-Money Laundering プロセスのために必要となる個人または法人の信頼・評判評価は、それらの目的に合わせた専用のプラットフォームで管理されるべきである。Entity Statements は公開インフラを用いて信頼関係を促進するため、federation の運用と組織間の信頼確立に必要な最小限の情報に限定されるべきである。¶

19.2. Trust Mark Status のプライバシー考慮事項

Trust Mark Status endpoint は、Trust Marks の状態をリアルタイムで問い合わせることを可能にする。Fetch endpoint と同様に、Trust Mark Status endpoint がいかなる client authentication method にもより保護されていない場合、Trust Marks を検証するリクエストは、Entities 間の実際の相互作用や関係を必ずしも示さない可能性がある。単に日常的なネットワーク検査や discovery プロセスの一部である可能性があるためである。これは、Trust Mark issuers が IPv4/IPv6 アドレスや DNS Whois エントリのような標準的なネットワーク診断ツールを通じて、他の Entities に関する Trust Marks を評価している Entities を追跡できてしまう可能性がある。追跡リスクを緩和するために、実装は短命な Trust Marks を用いることができる。または、sub パラメータではなく trust_mark_type パラメータのみを用いた Trust Marked Entities Listing（Section 8.5）を用いることで、Trust Mark Status endpoint を使う必要性を減らせる。¶

19.3. Fetch Endpoint のプライバシー考慮事項

Fetch endpoint は、Subordinate Statements をリアルタイムで問い合わせることを可能にする。Trust Mark Status の検証と同様に、federation インフラが公開され広く閲覧可能であり、かつ endpoints がいかなる client authentication method にもより保護されていない場合、Subordinate Statements を取得するリクエストは、Entities 間の実際の相互作用や関係を必ずしも示さない可能性がある。単に日常的なネットワーク検査や discovery プロセスの一部である可能性があるためである。しかし、これは、Trust Anchors または Intermediates が、IPv4/IPv6 アドレスや DNS Whois エントリのような標準的なネットワーク診断ツールを通じて、他の Entities との信頼関係を評価している Entities を追跡できてしまう可能性がある。Entities が他の Entities を検査・相互作用することに伴う追跡リスクを緩和するため、実装者は、適切な場合には静的かつ短命な Trust Chains の利用を検討すべきである。これは、Subordinate Statements をリアルタイムで取得する必要性を減らせる。¶

20. IANA Considerations

20.1. OAuth Dynamic Client Registration Metadata Registration

この仕様は、[[RFC7591]] により確立された IANA の "OAuth Dynamic Client Registration Metadata" レジストリ [[IANA.OAuth.Parameters]] に、次の client metadata エントリを登録する。¶

Client Metadata Name: client_registration_types¶
Client Metadata Description: RP が使用したい client registration types を指定する文字列配列¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.1.2¶

Client Metadata Name: signed_jwks_uri¶
Client Metadata Description: payload として client の JWK Set 文書を持つ、署名済み JWT を参照する URL¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.1¶

Client Metadata Name: organization_name¶
Client Metadata Description: この client を所有する組織を表す人間可読な名称¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

Client Metadata Name: description¶
Client Metadata Description: End-User に提示できる、この client の人間可読な簡潔な説明¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

Client Metadata Name: keywords¶
Client Metadata Description: この client に適用される検索キーワード、タグ、カテゴリ、ラベルを表す 1 つ以上の文字列からなる JSON 配列¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

Client Metadata Name: information_uri¶
Client Metadata Description: End-User が閲覧できる、この client に関する追加情報のドキュメントの URL¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

Client Metadata Name: organization_uri¶
Client Metadata Description: この client を所有する組織の Web ページの URL¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

20.2. OAuth Authorization Server Metadata Registration

この仕様は、[[RFC8414]] により確立された IANA の "OAuth Authorization Server Metadata" レジストリ [[IANA.OAuth.Parameters]] に、次の metadata エントリを登録する。¶

Metadata Name: client_registration_types_supported¶
Metadata Description: サポートされる Client Registration Types¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.1.3¶

Metadata Name: federation_registration_endpoint¶
Metadata Description: Federation Registration Endpoint¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.1.3¶

Metadata Name: signed_jwks_uri¶
Metadata Description: payload として当該 authorization server の JWK Set 文書を持つ、署名済み JWT を参照する URL¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.1¶

Metadata Name: jwks¶
Metadata Description: JSON Web Key Set 文書（値渡し）¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.1¶

Metadata Name: organization_name¶
Metadata Description: この authorization server を所有する組織を表す人間可読な名称¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

Metadata Name: display_name¶
Metadata Description: End-User に提示される authorization server の人間可読な名称¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

Metadata Name: description¶
Metadata Description: End-User に提示できる、この authorization server の人間可読な簡潔な説明¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

Metadata Name: keywords¶
Metadata Description: この authorization server に適用される検索キーワード、タグ、カテゴリ、ラベルを表す 1 つ以上の文字列からなる JSON 配列¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

Metadata Name: contacts¶
Metadata Description: この authorization server の責任者への連絡方法（典型的にはメールアドレス）を表す文字列の配列¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

Metadata Name: logo_uri¶
Metadata Description: この authorization server を所有する組織のロゴを参照する URL¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

Metadata Name: information_uri¶
Metadata Description: End-User が閲覧できる、この authorization server に関する追加情報のドキュメントの URL¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

Metadata Name: organization_uri¶
Metadata Description: この authorization server を所有する組織の Web ページの URL¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

20.3. OAuth Protected Resource Metadata Registration

この仕様は、[[RFC9728]] により確立された IANA の "OAuth Protected Resource Metadata" レジストリ [[IANA.OAuth.Parameters]] に、次の protected resource metadata エントリを登録する。¶

Metadata Name: signed_jwks_uri¶
Metadata Description: payload として protected resource の JWK Set 文書を持つ、署名済み JWT を参照する URL¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.1¶

Metadata Name: jwks¶
Metadata Description: JSON Web Key Set 文書（値渡し）¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.1¶

Metadata Name: organization_name¶
Metadata Description: この protected resource を所有する組織を表す人間可読な名称¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

Metadata Name: description¶
Metadata Description: End-User に提示できる、この protected resource の人間可読な簡潔な説明¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

Metadata Name: keywords¶
Metadata Description: この protected resource に適用される検索キーワード、タグ、カテゴリ、ラベルを表す 1 つ以上の文字列からなる JSON 配列¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

Metadata Name: contacts¶
Metadata Description: この protected resource の責任者への連絡方法（典型的にはメールアドレス）を表す文字列の配列¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

Metadata Name: logo_uri¶
Metadata Description: この protected resource を所有する組織のロゴを参照する URL¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

Metadata Name: organization_uri¶
Metadata Description: この protected resource を所有する組織の Web ページの URL¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.2¶

20.4. OAuth Parameters Registration

この仕様は、[[RFC6749]] により確立された IANA の "OAuth Parameters" レジストリ [[IANA.OAuth.Parameters]] に、次のパラメータを登録する。¶

Parameter Name: trust_chain¶
Parameter Usage Location: authorization request¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 12.1.1.1¶

20.5. OAuth Extensions Error Registration

この仕様は、[[RFC6749]] により確立された IANA の "OAuth Extensions Error Registry" レジストリ [[IANA.OAuth.Parameters]] に、次の値を登録する。¶

Name: invalid_client¶
Usage Location: authorization endpoint¶
Protocol Extension: OpenID Federation¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Reference: この仕様の Section 8.9¶

Name: invalid_issuer¶
Usage Location: authorization endpoint¶
Protocol Extension: OpenID Federation¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Reference: この仕様の Section 8.9¶

Name: invalid_subject¶
Usage Location: authorization endpoint¶
Protocol Extension: OpenID Federation¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Reference: この仕様の Section 8.9¶

Name: invalid_trust_anchor¶
Usage Location: authorization endpoint¶
Protocol Extension: OpenID Federation¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Reference: この仕様の Section 8.9¶

Name: invalid_trust_chain¶
Usage Location: authorization endpoint¶
Protocol Extension: OpenID Federation¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Reference: この仕様の Section 8.9¶

Name: invalid_metadata¶
Usage Location: authorization endpoint¶
Protocol Extension: OpenID Federation¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Reference: この仕様の Section 8.9¶

Name: not_found¶
Usage Location: authorization endpoint¶
Protocol Extension: OpenID Federation¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Reference: この仕様の Section 8.9¶

Name: unsupported_parameter¶
Usage Location: authorization endpoint¶
Protocol Extension: OpenID Federation¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Reference: この仕様の Section 8.9¶

20.6. JSON Web Signature and Encryption Header Parameters Registration

この仕様は、[[RFC7515]] により確立された IANA の "JSON Web Signature and Encryption Header Parameters" レジストリ [[IANA.JOSE]] に、次の JWS header parameters を登録する。¶

Header Parameter Name: trust_chain¶
Header Parameter Description: OpenID Federation Trust Chain¶
Header Parameter Usage Location: JWS¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 4.3¶

Header Parameter Name: peer_trust_chain¶
Header Parameter Description: OpenID Federation Peer Trust Chain¶
Header Parameter Usage Location: JWS¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 4.4¶

20.7. JSON Web Key Parameters Registration

この仕様は、[[RFC7517]] により確立された IANA の "JSON Web Key Parameters" レジストリ [[IANA.JOSE]] に、次のパラメータを登録する。¶

Parameter Name: iat¶
Parameter Description: Issued At（RFC 7519 で定義）¶
Used with "kty" Value(s): *¶
Parameter Information Class: Public¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 8.7.2¶

Parameter Name: nbf¶
Parameter Description: Not Before（RFC 7519 で定義）¶
Used with "kty" Value(s): *¶
Parameter Information Class: Public¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 8.7.2¶

Parameter Name: exp¶
Parameter Description: Expiration Time（RFC 7519 で定義）¶
Used with "kty" Value(s): *¶
Parameter Information Class: Public¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 8.7.2¶

Parameter Name: revoked¶
Parameter Description: Revoked Key Properties¶
Used with "kty" Value(s): *¶
Parameter Information Class: Public¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 8.7.2¶

20.8. JSON Web Token Claims Registration

この仕様は、[[RFC7519]] により確立された IANA の "JSON Web Token Claims" レジストリ [[IANA.JWT.Claims]] に、次の Claims を登録する。¶

Claim Name: jwks¶
Claim Description: JSON Web Key Set¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 13.1¶

Claim Name: metadata¶
Claim Description: Metadata object¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 13.2¶

Claim Name: constraints¶
Claim Description: Constraints object¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 13.3¶

Claim Name: crit¶
Claim Description: この種別の JWT に対する拡張により定義され、この JWT に含まれる Claims のうち、理解され処理されなければならない Claims のリスト¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 13.4¶

Claim Name: ref¶
Claim Description: Reference¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 13.5¶

Claim Name: delegation¶
Claim Description: Delegation¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 13.6¶

Claim Name: logo_uri¶
Claim Description: ロゴを参照する URI¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 13.7¶

Claim Name: authority_hints¶
Claim Description: Authority Hints¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 3.1.2¶

Claim Name: trust_anchor_hints¶
Claim Description: Trust Anchor Hints¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 3.1.2¶

Claim Name: trust_marks¶
Claim Description: Trust Marks¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 3.1.2¶

Claim Name: trust_mark_issuers¶
Claim Description: Trust Mark Issuers¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 3.1.2¶

Claim Name: trust_mark_owners¶
Claim Description: Trust Mark Owners¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 3.1.2¶

Claim Name: metadata_policy¶
Claim Description: Metadata Policy object¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 3.1.3¶

Claim Name: metadata_policy_crit¶
Claim Description: Critical Metadata Policy Operators¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 3.1.3¶

Claim Name: source_endpoint¶
Claim Description: Source Endpoint URL¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 3.1.3¶

Claim Name: keys¶
Claim Description: JWK Set 内の JWK 値の配列¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 5.2.1¶

Claim Name: trust_mark_type¶
Claim Description: Trust Mark Type Identifier¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 7.1¶

Claim Name: trust_chain¶
Claim Description: Trust Chain¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 8.3.2¶

Claim Name: trust_anchor¶
Claim Description: Trust Anchor ID¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): この仕様の Section 12.2.3¶

20.9. Well-Known URI Registration

この仕様は、[[RFC5785]] により確立された IANA の "Well-Known URIs" レジストリ [[IANA.well-known]] に、次の well-known URI を登録する。¶

URI suffix: openid-federation¶
Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification document: この仕様の Section 9¶
Related information: （なし）¶

20.10. Media Type Registration

この仕様は、[[RFC6838]] で記述される方法に従って、IANA の "Media Types" レジストリ [[IANA.MediaTypes]] に、[[RFC2046]] の次の media types を登録する。¶

Type name: application¶
Subtype name: entity-statement+jwt¶
Required parameters: n/a¶
Optional parameters: n/a¶
Encoding considerations: binary。Entity Statement は JWT である。JWT 値は、ピリオド（'.'）文字で区切られた base64url エンコード値（空文字列である場合もある）の連なりとしてエンコードされる。¶
Security considerations: この仕様の Section 18 を参照¶
Interoperability considerations: n/a¶
Published specification: この仕様の Section 15.1¶
Applications that use this media type: この仕様を使用するアプリケーション¶
Fragment identifier considerations: n/a¶
Additional information:¶
- Magic number(s): n/a¶
- File extension(s): n/a¶
- Macintosh file type code(s): n/a¶
Person & email address to contact for further information:¶
- Michael B. Jones, michael_b_jones@hotmail.com¶
Intended usage: COMMON¶
Restrictions on usage: none¶
Author: Michael B. Jones, michael_b_jones@hotmail.com¶
Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Provisional registration? No¶

Type name: application¶
Subtype name: trust-mark+jwt¶
Required parameters: n/a¶
Optional parameters: n/a¶
Encoding considerations: binary。Trust Mark は JWT である。JWT 値は、ピリオド（'.'）文字で区切られた base64url エンコード値（空文字列である場合もある）の連なりとしてエンコードされる。¶
Security considerations: この仕様の Section 18 を参照¶
Interoperability considerations: n/a¶
Published specification: この仕様の Section 15.2¶
Applications that use this media type: この仕様を使用するアプリケーション¶
Fragment identifier considerations: n/a¶
Additional information:¶
- Magic number(s): n/a¶
- File extension(s): n/a¶
- Macintosh file type code(s): n/a¶
Person & email address to contact for further information:¶
- Michael B. Jones, michael_b_jones@hotmail.com¶
Intended usage: COMMON¶
Restrictions on usage: none¶
Author: Michael B. Jones, michael_b_jones@hotmail.com¶
Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Provisional registration? No¶

Type name: application¶
Subtype name: resolve-response+jwt¶
Required parameters: n/a¶
Optional parameters: n/a¶
Encoding considerations: binary。Entity Resolve Response は署名済み JWT である。JWT 値は、ピリオド（'.'）文字で区切られた base64url エンコード値（空文字列である場合もある）の連なりとしてエンコードされる。¶
Security considerations: この仕様の Section 18 を参照¶
Interoperability considerations: n/a¶
Published specification: この仕様の Section 15.3¶
Applications that use this media type: この仕様を使用するアプリケーション¶
Fragment identifier considerations: n/a¶
Additional information:¶
- Magic number(s): n/a¶
- File extension(s): n/a¶
- Macintosh file type code(s): n/a¶
Person & email address to contact for further information:¶
- Michael B. Jones, michael_b_jones@hotmail.com¶
Intended usage: COMMON¶
Restrictions on usage: none¶
Author: Michael B. Jones, michael_b_jones@hotmail.com¶
Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Provisional registration? No¶

Type name: application¶
Subtype name: trust-chain+json¶
Required parameters: n/a¶
Optional parameters: n/a¶
Encoding considerations: binary。Trust Chain は JWT の JSON 配列である。JWT 値は、ピリオド（'.'）文字で区切られた base64url エンコード値（空文字列である場合もある）の連なりとしてエンコードされる。¶
Security considerations: この仕様の Section 18 を参照¶
Interoperability considerations: n/a¶
Published specification: この仕様の Section 15.4¶
Applications that use this media type: この仕様を使用するアプリケーション¶
Fragment identifier considerations: n/a¶
Additional information:¶
- Magic number(s): n/a¶
- File extension(s): n/a¶
- Macintosh file type code(s): n/a¶
Person & email address to contact for further information:¶
- Michael B. Jones, michael_b_jones@hotmail.com¶
Intended usage: COMMON¶
Restrictions on usage: none¶
Author: Michael B. Jones, michael_b_jones@hotmail.com¶
Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Provisional registration? No¶

Type name: application¶
Subtype name: trust-mark-delegation+jwt¶
Required parameters: n/a¶
Optional parameters: n/a¶
Encoding considerations: binary。Trust Mark delegation は署名済み JWT である。JWT 値は、ピリオド（'.'）文字で区切られた base64url エンコード値（空文字列である場合もある）の連なりとしてエンコードされる。¶
Security considerations: この仕様の Section 18 を参照¶
Interoperability considerations: n/a¶
Published specification: この仕様の Section 15.5¶
Applications that use this media type: この仕様を使用するアプリケーション¶
Fragment identifier considerations: n/a¶
Additional information:¶
- Magic number(s): n/a¶
- File extension(s): n/a¶
- Macintosh file type code(s): n/a¶
Person & email address to contact for further information:¶
- Roland Hedberg, roland@catalogix.se¶
Intended usage: COMMON¶
Restrictions on usage: none¶
Author: Roland Hedberg, roland@catalogix.se¶
Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Provisional registration? No¶

Type name: application¶
Subtype name: jwk-set+jwt¶
Required parameters: n/a¶
Optional parameters: n/a¶
Encoding considerations: binary。署名付き JWK Set は署名済み JWT である。JWT 値は、ピリオド（'.'）文字で区切られた base64url エンコード値（空文字列である場合もある）の連なりとしてエンコードされる。¶
Security considerations: この仕様の Section 18 を参照¶
Interoperability considerations: n/a¶
Published specification: この仕様の Section 15.6¶
Applications that use this media type: この仕様を使用するアプリケーション¶
Fragment identifier considerations: n/a¶
Additional information:¶
- Magic number(s): n/a¶
- File extension(s): n/a¶
- Macintosh file type code(s): n/a¶
Person & email address to contact for further information:¶
- Michael B. Jones, michael_b_jones@hotmail.com¶
Intended usage: COMMON¶
Restrictions on usage: none¶
Author: Michael B. Jones, michael_b_jones@hotmail.com¶
Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Provisional registration? No¶

Type name: application¶
Subtype name: trust-mark-status-response+jwt¶
Required parameters: n/a¶
Optional parameters: n/a¶
Encoding considerations: binary。Trust Mark Status Response は署名済み JWT である。JWT 値は、ピリオド（'.'）文字で区切られた base64url エンコード値（空文字列である場合もある）の連なりとしてエンコードされる。¶
Security considerations: この仕様の Section 18 を参照¶
Interoperability considerations: n/a¶
Published specification: この仕様の Section 15.7¶
Applications that use this media type: この仕様を使用するアプリケーション¶
Fragment identifier considerations: n/a¶
Additional information:¶
- Magic number(s): n/a¶
- File extension(s): n/a¶
- Macintosh file type code(s): n/a¶
Person & email address to contact for further information:¶
- Michael B. Jones, michael_b_jones@hotmail.com¶
Intended usage: COMMON¶
Restrictions on usage: none¶
Author: Michael B. Jones, michael_b_jones@hotmail.com¶
Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Provisional registration? No¶

Type name: application¶
Subtype name: explicit-registration-response+jwt¶
Required parameters: n/a¶
Optional parameters: n/a¶
Encoding considerations: binary。Explicit Registration response は署名済み JWT である。JWT 値は、ピリオド（'.'）文字で区切られた base64url エンコード値（空文字列である場合もある）の連なりとしてエンコードされる。¶
Security considerations: この仕様の Section 18 を参照¶
Interoperability considerations: n/a¶
Published specification: この仕様の Section 15.8¶
Applications that use this media type: この仕様を使用するアプリケーション¶
Fragment identifier considerations: n/a¶
Additional information:¶
- Magic number(s): n/a¶
- File extension(s): n/a¶
- Macintosh file type code(s): n/a¶
Person & email address to contact for further information:¶
- Michael B. Jones, michael_b_jones@hotmail.com¶
Intended usage: COMMON¶
Restrictions on usage: none¶
Author: Michael B. Jones, michael_b_jones@hotmail.com¶
Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Provisional registration? No¶

21. 参考文献

21.1. 規定参照文献

[OpenID.Core]

Sakimura, N., Bradley, J., Jones, M.B., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", 15 December 2023, https://openid.net/specs/openid-connect-core-1_0.html.

[OpenID.Discovery]

Sakimura, N., Bradley, J., Jones, M.B., and E. Jay, "OpenID Connect Discovery 1.0", 15 December 2023, https://openid.net/specs/openid-connect-discovery-1_0.html.

[OpenID.Registration]

Sakimura, N., Bradley, J., and M.B. Jones, "OpenID Connect Dynamic Client Registration 1.0", 15 December 2023, https://openid.net/specs/openid-connect-registration-1_0.html.

[OpenID.RP.Choices]

Jones, M.B., Hedberg, R., Bradley, J., and F. Skokan, "OpenID Connect Relying Party Metadata Choices 1.0", 8 January 2026, https://openid.net/specs/openid-connect-rp-metadata-choices-1_0.html.

[RFC2119]

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

[RFC4732]

Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, DOI 10.17487/RFC4732, December 2006, https://www.rfc-editor.org/info/rfc4732.

[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, DOI 10.17487/RFC5280, May 2008, https://www.rfc-editor.org/info/rfc5280.

[RFC5646]

Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, https://www.rfc-editor.org/info/rfc5646.

[RFC6749]

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

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, https://www.rfc-editor.org/info/rfc7515.

[RFC7516]

Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, https://www.rfc-editor.org/info/rfc7516.

[RFC7517]

Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, https://www.rfc-editor.org/info/rfc7517.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, https://www.rfc-editor.org/info/rfc7519.

[RFC7591]

Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, https://www.rfc-editor.org/info/rfc7591.

[RFC7638]

Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, https://www.rfc-editor.org/info/rfc7638.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, https://www.rfc-editor.org/info/rfc8259.

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, https://www.rfc-editor.org/info/rfc8414.

[RFC8705]

Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, https://www.rfc-editor.org/info/rfc8705.

[RFC9101]

Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)", RFC 9101, DOI 10.17487/RFC9101, August 2021, https://www.rfc-editor.org/info/rfc9101.

[RFC9126]

Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, https://www.rfc-editor.org/info/rfc9126.

[RFC9728]

Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, https://www.rfc-editor.org/info/rfc9728.

[UNICODE]

The Unicode Consortium, "The Unicode Standard", http://www.unicode.org/versions/latest/.

[USA15]

Whistler, K., "Unicode Normalization Forms", Unicode Standard Annex 15, 30 July 2025, https://www.unicode.org/reports/tr15/.

21.2. 参考参照文献

[App-Fed-Linkage]

Dzhuvinov, V., "How to link an application protocol to an OpenID Federation 1.0 trust layer", 4 December 2024, https://connect2id.com/blog/how-to-link-an-app-protocol-to-an-openid-federation-trust-layer.

[FAPI]

Sakimura, N., Bradley, J., and E. Jay, "Financial-grade API Security Profile 1.0 - Part 2: Advanced", 12 March 2021, https://openid.net/specs/openid-financial-api-part-2-1_0.html.

[IANA.JOSE]

IANA, "JSON Object Signing and Encryption (JOSE)", https://www.iana.org/assignments/jose.

[IANA.JWT.Claims]

IANA, "JSON Web Token Claims", https://www.iana.org/assignments/jwt.

[IANA.MediaTypes]

IANA, "Media Types", https://www.iana.org/assignments/media-types.

[IANA.OAuth.Parameters]

IANA, "OAuth Parameters", https://www.iana.org/assignments/oauth-parameters.

[IANA.well-known]

IANA, "Well-Known URIs", https://www.iana.org/assignments/well-known-uris.

[OpenID.Federation-1.1]

Hedberg, R., Jones, M.B., Ed., De Marco, G., Solberg, A.Å., Bradley, J., and V. Dzhuvinov, "OpenID Federation 1.1", 17 February 2026, https://openid.net/specs/openid-federation-1_1.html.

[OpenID.Federation.Connect-1.1]

Hedberg, R., Jones, M.B., Ed., De Marco, G., Solberg, A.Å., Bradley, J., and V. Dzhuvinov, "OpenID Federation for OpenID Connect 1.1", 17 February 2026, https://openid.net/specs/openid-federation-connect-1_1.html.

[RFC2046]

Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, https://www.rfc-editor.org/info/rfc2046.

[RFC5785]

Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, https://www.rfc-editor.org/info/rfc5785.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, https://www.rfc-editor.org/info/rfc6838.

[RFC8725]

Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, https://www.rfc-editor.org/info/rfc8725.

[RFC9525]

Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, https://www.rfc-editor.org/info/rfc9525.

Appendix A. Trust Chains の構築と利用の例

次を仮定しよう。LIGO プロジェクトは、eduGAIN のすべての OP に対して、自身の wiki へのアクセスを提供したい。LIGO は InCommon federation に登録されている。¶

次は eduGAIN Trust Anchor の下にある federation を示す。¶

                    eduGAIN
                       |
    +------------------+------------------+
    |                                     |
 SWAMID                               InCommon
    |                                     |
  umu.se                                  |
    |                                     |
op.umu.se                           wiki.ligo.org

Figure 55: Participants in the eduGAIN Federation

SWAMID と InCommon は、どちらもそれ自体で identity federations である。また、どちらも eduGAIN federation のメンバーであるという共通点を持つ。¶

SWAMID と InCommon は、Entities を登録する方法が異なる。SWAMID は組織を登録し、その組織に属する Entities を組織が登録できるようにする。一方で InCommon は、すべての Entities を直接登録し、いかなる organization Entity の下にも置かない。したがって、federations における深さが異なる。¶

Umeå University の研究者が LIGO Wiki にログインしたいと仮定しよう。Wiki では、その研究者は、home identity provider（op.umu.se）を見つけるために、何らかの discovery service を利用する。¶

Wiki の RP 部分が、どの OP と話すべきかを把握したら、OP についていくつかのことを見つけなければならない。そうした情報はすべて metadata の中に見つけられる。しかし、metadata を見つけるだけでは十分ではなく、RP はその metadata を信頼しなければならない。¶

回り道をして、federation を構築するために何が必要かから始めよう。¶

Appendix A.1. Federation のセットアップ

これは federation インフラをセットアップするための手順である。¶

Trust Anchor の署名鍵を生成する。これらは公開鍵・秘密鍵のペアでなければならない。¶
Federation Entity Keys を用いて JWTs/Entity Statements に署名できる署名サービスをセットアップする。¶
署名済み Entity Statements を公開できる web services をセットアップする。1 つは federation の Entity Identifier に対応する URL に対して Entity Configuration を返すもの、もう 1 つは Section 8.1.1 で記述される fetch endpoint を提供するもの。¶

これらの要件が満たされたら、Federation Operator は federation に Entities を追加できる。Entity を追加するとは、要するに次のことに行き着く。¶

Entity に対して、federation の Entity Identifier と、federation operator が Entity Statements に署名するために用いる鍵ペアの公開部分を提供する。¶
Entity の Entity Identifier と、Entity が自身の Entity Configuration で公開する予定の JWK Set を取得する。¶

federation operator が Entities を追加し始める前に、その federation に参加できるのは誰か、そして federation のレイアウトはどうあるべきかについてのポリシーが必要である。InCommon のような 1 層の federation にするのか、SWAMID federation のような 2 層にするのか、あるいは多層 federation にするのか。federation はまた、Section 6 で記述される federation policy framework を用いて、他のポリシーを実装することも検討したいだろう。¶

federation が整ったら、物事が動き始める。¶

Appendix A.2. LIGO Wiki が OP の metadata を発見する

Federation Entity Discovery は、RP が Section 9 で定義されるプロセスを用いて、OP の Entity（この場合は https://op.umu.se）の Entity Configuration を取得することから始まる一連のステップである。その後に続くステップは次のとおりである。¶

authority hints を用いて Immediate Superior Entities を取り出す。¶
そのような各 Entity について Entity Configuration を取得する。これは Section 9 で定義されるプロセスを用いる。¶
Section 8.1.1 に従い、各 Immediate Superior の fetch endpoint を用いて、Immediate Subordinate Entity に関する Subordinate Statements を取得する。¶

これを何回繰り返す必要があるかは、federation の深さに依存する。以下に示すのは、上記で説明した federation セットアップを用いて、OP の metadata を見つけるために RP が取る必要がある各ステップの結果である。¶

Trust Chain を構築する際には、Trust Chain subject の Entity Configuration とともに、各 Immediate Superior が自身の Immediate Subordinates について発行した Subordinate Statements が用いられる。¶

Intermediates の Entity Configurations は Trust Chain の一部ではない。¶

Appendix A.2.1. https://op.umu.se の Entity Configuration

LIGO WIKI RP は、Section 9 で定義されるプロセスを用いて、OP（op.umu.se）から Entity Configuration を取得する。¶

結果はこの Entity Configuration である。¶

{
  "authority_hints": [
    "https://umu.se"
  ],
  "exp": 1568397247,
  "iat": 1568310847,
  "iss": "https://op.umu.se",
  "sub": "https://op.umu.se",
  "jwks": {
    "keys": [
      {
        "e": "AQAB",
        "kid": "dEEtRjlzY3djcENuT01wOGxrZlkxb3RIQVJlMTY0...",
        "kty": "RSA",
        "n": "x97YKqc9Cs-DNtFrQ7_vhXoH9bwkDWW6En2jJ044yH..."
      }
    ]
  },
  "metadata": {
    "openid_provider": {
      "issuer": "https://op.umu.se",
      "signed_jwks_uri": "https://op.umu.se/jwks.jose",
      "authorization_endpoint": "https://op.umu.se/authorization",
      "client_registration_types_supported": [
        "automatic",
        "explicit"
      ],
      "request_parameter_supported": true,
      "grant_types_supported": [
        "authorization_code",
        "implicit",
        "urn:ietf:params:oauth:grant-type:jwt-bearer"
      ],
      "id_token_signing_alg_values_supported": [
        "ES256",
        "RS256"
      ],
      "logo_uri": "https://www.umu.se/img/umu-logo-left-neg-SE.svg",
      "op_policy_uri": "https://www.umu.se/en/website/legal-information/",
      "response_types_supported": [
        "code",
        "code id_token",
        "token"
      ],
      "subject_types_supported": [
        "pairwise",
        "public"
      ],
      "token_endpoint": "https://op.umu.se/token",
      "federation_registration_endpoint": "https://op.umu.se/fedreg",
      "token_endpoint_auth_methods_supported": [
        "client_secret_post",
        "client_secret_basic",
        "client_secret_jwt",
        "private_key_jwt"
      ]
    }
  }
}

Figure 56: Entity Configuration Issued by https://op.umu.se

authority_hints は Intermediate Entity https://umu.se を指している。したがって、それが次のステップである。¶

この Entity Configuration は Trust Chain の最初のリンクである。¶

Appendix A.2.2. https://umu.se の Entity Configuration

LIGO RP は Section 9 で定義されるプロセスを用いて、https://umu.se から Entity Configuration を取得する。¶

リクエストは次のようになる。¶

GET /.well-known/openid-federation HTTP/1.1
Host: umu.se

Figure 57: Entity Configuration Issued by https://umu.se

そして GET は次を返す。¶

{
  "authority_hints": [
    "https://swamid.se"
  ],
  "exp": 1568397247,
  "iat": 1568310847,
  "iss": "https://umu.se",
  "sub": "https://umu.se",
  "jwks": {
    "keys": [
      {
        "e": "AQAB",
        "kid": "endwNUZrNTJsX2NyQlp4bjhVcTFTTVltR2gxV2RV...",
        "kty": "RSA",
        "n": "vXdXzZwQo0hxRSmZEcDIsnpg-CMEkor50SOG-1XUlM..."
      }
    ]
  },
  "metadata": {
    "federation_entity": {
      "contacts": [
        "ops@umu.se"
      ],
      "federation_fetch_endpoint": "https://umu.se/openid/fedapi",
      "organization_uri": "https://www.umu.se",
      "organization_name": "UmU"
    }
  }
}

Figure 58: Entity Configuration JWT Claims Set

このプロセスでこの Entity Configuration から用いられる情報は federation_fetch_endpoint だけであり、これは次のステップで用いられる。¶

Appendix A.2.3. https://umu.se により https://op.umu.se について公開された Subordinate Statement

RP は、Section 8.1.1 で定義されるとおり、https://umu.se が提供する fetch endpoint を用いて https://op.umu.se に関する情報を取得する。¶

リクエストは次のようになる。¶

GET /openid/fedapi?sub=https%3A%2F%2Fop.umu.se&
iss=https%3A%2F%2Fumu.se HTTP/1.1
Host: umu.se

Figure 59: Request Subordinate Statement from https://umu.se about https://op.umu.se

そして結果は次である。¶

{
  "exp": 1568397247,
  "iat": 1568310847,
  "iss": "https://umu.se",
  "sub": "https://op.umu.se",
  "source_endpoint": "https://umu.se/openid/fedapi",
  "jwks": {
    "keys": [
      {
        "e": "AQAB",
        "kid": "dEEtRjlzY3djcENuT01wOGxrZlkxb3RIQVJlMTY0...",
        "kty": "RSA",
        "n": "x97YKqc9Cs-DNtFrQ7_vhXoH9bwkDWW6En2jJ044yH..."
      }
    ]
  },
  "metadata_policy": {
    "openid_provider": {
      "contacts": {
        "add": [
          "ops@swamid.se"
        ]
      },
      "organization_name": {
        "value": "University of Umeå"
      },
      "subject_types_supported": {
        "value": [
          "pairwise"
        ]
      },
      "token_endpoint_auth_methods_supported": {
        "default": [
          "private_key_jwt"
        ],
        "subset_of": [
          "private_key_jwt",
          "client_secret_jwt"
        ],
        "superset_of": [
          "private_key_jwt"
        ]
      }
    }
  }
}

Figure 60: Subordinate Statement Issued by https://umu.se about https://op.umu.se

この Subordinate Statement は Trust Chain の 2 番目のリンクである。¶

Appendix A.2.4. https://swamid.se の Entity Configuration

LIGO Wiki RP は Section 9 で定義されるプロセスを用いて、https://swamid.se から Entity Configuration を取得する。¶

リクエストは次のようになる。¶

GET /.well-known/openid-federation HTTP/1.1
Host: swamid.se

Figure 61: Request Entity Configuration from https://swamid.se

そして GET は次を返す。¶

{
  "authority_hints": [
    "https://edugain.geant.org"
  ],
  "exp": 1568397247,
  "iat": 1568310847,
  "iss": "https://swamid.se",
  "sub": "https://swamid.se",
  "jwks": {
    "keys": [
      {
        "e": "AQAB",
        "kid": "N1pQTzFxUXZ1RXVsUkVuMG5uMnVDSURGRVdhUzdO...",
        "kty": "RSA",
        "n": "3EQc6cR_GSBq9km9-WCHY_lWJZWkcn0M05TGtH6D9S..."
      }
    ]
  },
  "metadata": {
    "federation_entity": {
      "contacts": [
        "ops@swamid.se"
      ],
      "federation_fetch_endpoint": "https://swamid.se/fedapi",
      "organization_uri": "https://www.sunet.se/swamid/",
      "organization_name": "SWAMID"
    }
  }
}

Figure 62: Entity Configuration Issued by https://swamid.se

このプロセスでこの Entity Configuration から用いられる情報は federation_fetch_endpoint だけであり、これは次のステップで用いられる。¶

Appendix A.2.5. https://swamid.se により https://umu.se について公開された Subordinate Statement

LIGO Wiki RP は、Section 8.1.1 で定義されるとおり、https://swamid.se が提供する fetch endpoint を用いて https://umu.se に関する情報を取得する。¶

リクエストは次のようになる。¶

GET /fedapi?sub=https%3A%2F%2Fumu.se&
iss=https%3A%2F%2Fswamid.se HTTP/1.1
Host: swamid.se

Figure 63: Request to https://swamid.se for Subordinate Statement about https://umu.se

そして結果は次である。¶

{
  "exp": 1568397247,
  "iat": 1568310847,
  "iss": "https://swamid.se",
  "sub": "https://umu.se",
  "source_endpoint": "https://swamid.se/fedapi",
  "jwks": {
    "keys": [
      {
        "e": "AQAB",
        "kid": "endwNUZrNTJsX2NyQlp4bjhVcTFTTVltR2gxV2RV...",
        "kty": "RSA",
        "n": "vXdXzZwQo0hxRSmZEcDIsnpg-CMEkor50SOG-1XUlM..."
      }
    ]
  },
  "metadata_policy": {
    "openid_provider": {
      "id_token_signing_alg_values_supported": {
        "subset_of": [
          "RS256",
          "ES256",
          "ES384",
          "ES512"
        ]
      },
      "token_endpoint_auth_methods_supported": {
        "subset_of": [
          "client_secret_jwt",
          "private_key_jwt"
        ]
      },
      "userinfo_signing_alg_values_supported": {
        "subset_of": [
          "ES256",
          "ES384",
          "ES512"
        ]
      }
    }
  }
}

Figure 64: Subordinate Statement Issued by https://swamid.se about https://umu.se

この Subordinate Statement は Trust Chain の 3 番目のリンクである。¶

この Subordinate Statement の issuer が、LIGO Wiki RP がアクセスできる Trust Anchors の一覧に含まれていないと仮定すると、さらに 1 ステップ進む必要がある。¶

A.2.6. https://edugain.geant.org の Entity Configuration

RP は、Section 9 で定義されるプロセスを用いて、https://edugain.geant.org から Entity Configuration を取得する。¶

リクエストは次のようになる。¶

GET /.well-known/openid-federation HTTP/1.1
Host: edugain.geant.org

Figure 65: Entity Configuration Requested from https://edugain.geant.org

そして GET は次を返す。¶

{
  "exp": 1568397247,
  "iat": 1568310847,
  "iss": "https://edugain.geant.org",
  "sub": "https://edugain.geant.org",
  "jwks": {
    "keys": [
      {
        "e": "AQAB",
        "kid": "Sl9DcjFxR3hrRGdabUNIR21KT3dvdWMyc2VUM2Fr...",
        "kty": "RSA",
        "n": "xKlwocDXUw-mrvDSO4oRrTRrVuTwotoBFpozvlq-1q..."
      }
    ]
  },
  "metadata": {
    "federation_entity": {
      "federation_fetch_endpoint": "https://geant.org/edugain/api"
    }
  }
}

Figure 66: Entity Configuration issued by https://edugain.geant.org

Trust Anchor の Entity Configuration の中で、Relying Party は federation_fetch_endpoint を探し、Trust Anchor の更新された Federation Entity Keys を取得する。Federation 内の各 Entity は、いつでも Federation Entity Keys、または他の属性を変更できる。詳しくは Section 11.2 を参照のこと。¶

A.2.7. https://edugain.geant.org により https://swamid.se について公開された Subordinate Statement

LIGO Wiki の RP は、Section 8.1.1 で定義されるとおり、https://edugain.geant.org の fetch endpoint を用いて "https://swamid.se" に関する情報を取得する。¶

リクエストは次のようになる。¶

GET /edugain/api?sub=https%3A%2F%2Fswamid.se&
iss=https%3A%2F%2Fedugain.geant.org HTTP/1.1
Host: geant.org

Figure 67: Request to https://edugain.geant.org for Subordinate Statement about https://swamid.se

そして結果は次である。¶

{
  "exp": 1568397247,
  "iat": 1568310847,
  "iss": "https://edugain.geant.org",
  "sub": "https://swamid.se",
  "source_endpoint": "https://edugain.geant.org/edugain/api",
  "jwks": {
    "keys": [
      {
        "e": "AQAB",
        "kid": "N1pQTzFxUXZ1RXVsUkVuMG5uMnVDSURGRVdhUzdO...",
        "kty": "RSA",
        "n": "3EQc6cR_GSBq9km9-WCHY_lWJZWkcn0M05TGtH6D9S..."
      }
    ]
  },
  "metadata_policy": {
    "openid_provider": {
      "contacts": {
        "add": ["ops@edugain.geant.org"]
      }
    },
    "openid_relying_party": {
      "contacts": {
        "add": ["ops@edugain.geant.org"]
      }
    }
  }
}

Figure 68: Subordinate Statement issued by https://edugain.geant.org about https://swamid.se

この statement の issuer が、LIGO Wiki RP がアクセスできる Trust Anchors の一覧に含まれていると仮定すると、この Subordinate Statement は Trust Chain の 4 番目のリンクになる。Trust Anchor の Entity Configuration も Trust Chain に含めてもよい。その場合、それは 5 番目かつ最後のリンクになる。¶

これで Trust Chain のすべてのメンバーを取得した。整理すると、次の Entity Statements を取得した。¶

Leaf Entity https://op.umu.se の Entity Configuration — Trust Chain の最初のリンク¶
https://umu.se の Entity Configuration — Trust Chain には含まれない¶
https://umu.se が https://op.umu.se について発行した Subordinate Statement — Trust Chain の 2 番目のリンク¶
https://swamid.se の Entity Configuration — Trust Chain には含まれない¶
https://swamid.se が https://umu.se について発行した Subordinate Statement — Trust Chain の 3 番目のリンク¶
https://edugain.geant.org の Entity Configuration — 任意で、Trust Chain の 5 番目かつ最後のリンク¶
https://edugain.geant.org が https://swamid.se について発行した Subordinate Statement — Trust Chain の 4 番目のリンク¶

LIGO Wiki RP が、何らかの安全な out-of-band な方法で提供を受けた Trust Anchor の公開鍵を用いることで、Section 10.2 で記述されるとおりに Trust Chain を検証できる。¶

A.2.8. https://op.umu.se の OP Resolved Metadata

チェーンを検証したら、LIGO Wiki RP は次のステップに進める。¶

Immediate Superiors がそれぞれ自身の Immediate Subordinates について発行した 3 つの Subordinate Statements から得られる metadata policies を結合し、Leaf Entity が提示した metadata statement に結合済みポリシーを適用すると、openid_provider Entity Type に対する次の Resolved Metadata が得られる。¶

{
  "authorization_endpoint": "https://op.umu.se/authorization",
  "contacts": [
    "ops@swamid.se",
    "ops@edugain.geant.org"
  ],
  "federation_registration_endpoint": "https://op.umu.se/fedreg",
  "client_registration_types_supported": [
    "automatic",
    "explicit"
  ],
  "grant_types_supported": [
    "authorization_code",
    "implicit",
    "urn:ietf:params:oauth:grant-type:jwt-bearer"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256",
    "ES256"
  ],
  "issuer": "https://op.umu.se",
  "signed_jwks_uri": "https://op.umu.se/jwks.jose",
  "logo_uri": "https://www.umu.se/img/umu-logo-left-neg-SE.svg",
  "organization_name": "University of Umeå",
  "op_policy_uri": "https://www.umu.se/en/website/legal-information/",
  "request_parameter_supported": true,
  "response_types_supported": [
    "code",
    "code id_token",
    "token"
  ],
  "subject_types_supported": [
    "pairwise"
  ],
  "token_endpoint": "https://op.umu.se/token",
  "token_endpoint_auth_methods_supported": [
    "private_key_jwt",
    "client_secret_jwt"
  ]
}

Figure 69: OP Resolved Metadata Derived from Trust Chain by Applying Metadata Policies

これで Provider Discovery プロセスの終端に到達した。¶

Appendix A.3. Client Registration メソッドの例

Section 12 は、client registration を実行する 2 つの方法を定義している。¶

Automatic

将来の通信で client がどの機能を用いるべきかについて、RP と OP の間で交渉は行われない。選択された Trust Chain の metadata policies によってフィルタされた、RP が公開した metadata が、使用される metadata を定義する。¶

Explicit

RP は federation_registration_endpoint にアクセスし、そこで RP の metadata を提供する。OP は、Trust Chain がすでに定義しているものに加えて、追加の制約を付与する metadata policy を返してもよい。¶

Appendix A.3.1. RP が Authentication Request を送る（Automatic Client Registration）

LIGO Wiki の RP はいかなる登録も行わず、直接 Authentication Request の送信に進む。¶

そのような Authentication Request の例を以下に示す。¶

GET /openid/authorization?
  request=eyJ0eXAiOiJvYXV0aC1hdXRoei1yZXErand0IiwiYWxnIjoiU
    lMyNTYiLCJraWQiOiJkVU4yYTAxd1JraGtTV3BsUVRodmNWQklOVUl3
    VFVkT1VGVTJUbVZyU21oRVFYZ3paWGxwVHpkUU5BIn0.
    eyJyZXNwb25zZV90eXBlIjogImNvZGUiLCAic2NvcGUiOiAib3Blbml
    kIHByb2ZpbGUgZW1haWwiLCAiY2xpZW50X2lkIjogImh0dHBzOi8vd2
    lraS5saWdvLm9yZyIsICJzdGF0ZSI6ICIyZmY3ZTU4OS0zODQ4LTQ2Z
    GEtYTNkMi05NDllMTIzNWU2NzEiLCAibm9uY2UiOiAiZjU4MWExODYt
    YWNhNC00NmIzLTk0ZmMtODA0ODQwODNlYjJjIiwgInJlZGlyZWN0X3V
    yaSI6ICJodHRwczovL3dpa2kubGlnby5vcmcvb3BlbmlkL2NhbGxiYW
    NrIiwgImlzcyI6ICJodHRwczovL3dpa2kubGlnby5vcmciLCAiaWF0I
    jogMTU5MzU4ODA4NSwgImF1ZCI6ICJodHRwczovL29wLnVtdS5zZSJ9
    .cRwSFNcDx6VsacAQDcIx
    5OAt_Pj30I_uUKRh04N4QJd6MZ0f50sETRv8uspSt9fMa-5yV3uzthX
    _v8OtQrV33gW1vzgOSRCdHgeCN40StbzjFk102seDwtU_Uzrcsy7KrX
    YSBp8U0dBDjuxC6h18L8ExjeR-NFjcrhy0wwua7Tnb4QqtN0QCia6DD
    8QBNVTL1Ga0YPmMdT25wS26wug23IgpbZB20VUosmMGgGtS5yCI5AwK
    Bhozv-oBH5KxxHzH1Oss-RkIGiQnjRnaWwEOTITmfZWra1eHP254wFF
    2se-EnWtz1q2XwsD9NSsOEJwWJPirPPJaKso8ng6qrrOSgw
  &response_type=code
  &client_id=https%3A%2F%2Fwiki.ligo.org
  &redirect_uri=https%3A%2F%2Fwiki.ligo.org/openid/callback
  &scope=openid+profile+email
  HTTP/1.1
Host: op.umu.se

Figure 70: Authentication Request using Automatic Client Registration

この Authentication Request を受信した OP は、RP がすでに登録済みでない限り、RP と動的に取得し、信頼関係を確立し始める。¶

Appendix A.3.1.1. OP が Entity Statements を取得する

OP は、RP（wiki.ligo.org）についての Trust Chain を確立する必要がある。この例の OP は、2 つの federation の公開鍵で設定されている。¶

https://edugain.geant.org¶
https://swamid.se¶

OP は、Section 9 で記述されるプロセスを用いて Entity Configuration を取得し、Client Identifier https://wiki.ligo.org の metadata 解決を開始する。¶

このプロセスは Appendix A.2 で記述されたものと同じであり、結果として次の Entity Statements からなる Trust Chain になる。¶

Leaf Entity https://wiki.ligo.org の Entity Configuration¶
https://incommon.org が https://wiki.ligo.org について発行した Subordinate Statement¶
https://edugain.geant.org が https://incommon.org について発行した Subordinate Statement¶

Appendix A.3.1.2. OP が RP metadata を評価する

LIGO Wiki RP が、何らかの安全な out-of-band な方法で提供を受けた Trust Anchor の公開鍵を用いることで、Section 10.2 で記述されるとおりに Trust Chain を検証できる。¶

ここでは Entity Statements 全体は列挙せず、metadata と metadata_policy の部分だけを列挙する。metadata policies は 2 つある。¶

edugain.geant.org:

"metadata_policy": {
  "openid_provider": {
    "contacts": {
      "add": ["ops@edugain.geant.org"]
    }
  },
  "openid_relying_party": {
    "contacts": {
      "add": ["ops@edugain.geant.org"]
    }
  }
}

Figure 71: Metadata Policies Related to Multiple Metadata Types

incommon.org:

"metadata_policy": {
  "openid_relying_party": {
    "application_type": {
      "one_of": [
        "web",
        "native"
      ]
    },
    "contacts": {
      "add": ["ops@incommon.org"]
    },
    "grant_types": {
      "subset_of": [
        "authorization_code",
        "refresh_token"
      ]
    }
  }
}

Figure 72: Metadata Policy Related to the RP

次に、これらを結合し、wiki.ligo.org の metadata に適用する。¶

"metadata": {
  "openid_relying_party": {
    "application_type": "web",
    "client_name": "LIGO Wiki",
    "contacts": [
      "ops@ligo.org"
    ],
    "grant_types": [
      "authorization_code",
      "refresh_token"
    ],
    "id_token_signing_alg_values_supported": ["ES256", "PS256", "RS256"],
    "signed_jwks_uri": "https://wiki.ligo.org/jwks.jose",
    "redirect_uris": [
      "https://wiki.ligo.org/openid/callback"
    ],
    "response_types": [
      "code"
    ],
    "subject_type": "public",
    "token_endpoint_auth_method": "private_key_jwt"
  }
}

Figure 73: Combined Metadata with Metadata Policy Yet to be Applied

最終結果は次である。¶

"metadata": {
  "openid_relying_party": {
    "application_type": "web",
    "client_name": "LIGO Wiki",
    "contacts": [
      "ops@ligo.org",
      "ops@edugain.geant.org",
      "ops@incommon.org"
    ],
    "grant_types": [
      "refresh_token",
      "authorization_code"
    ],
    "id_token_signing_alg_values_supported": ["ES256", "PS256", "RS256"],
    "signed_jwks_uri": "https://wiki.ligo.org/jwks.jose",
    "redirect_uris": [
      "https://wiki.ligo.org/openid/callback"
    ],
    "response_types": [
      "code"
    ],
    "subject_type": "public",
    "token_endpoint_auth_method": "private_key_jwt"
  }
}

Figure 74: Resolved Metadata After Metadata Policy has been Applied

Trust Chain と最終的な Relying Party metadata を取得したら、OpenID Provider は、signed_jwks_uri endpoint で利用可能な公開鍵を用いて、Authentication Request に含まれる Request Object の署名を検証するために必要なものをすべて揃えたことになる。¶

Appendix A.3.2. RP が Client Registration から開始する（Explicit Client Registration）

ここでは、LIGO Wiki の RP は OP（op.umu.se）の federation_registration_endpoint に Explicit Registration request を送る。リクエストには RP の Entity Configuration が含まれる。¶

RP の Entity Configuration に対する JWT Claims Set の例は次のとおりである。¶

{
  "iss": "https://wiki.ligo.org",
  "sub": "https://wiki.ligo.org",
  "iat": 1676045527,
  "exp": 1676063610,
  "aud": "https://op.umu.se",
  "metadata": {
    "openid_relying_party": {
      "application_type": "web",
      "client_name": "LIGO Wiki",
      "contacts": ["ops@ligo.org"],
      "grant_types": ["authorization_code"],
      "id_token_signed_response_alg": "RS256",
      "signed_jwks_uri": "https://wiki.ligo.org/jwks.jose",
      "redirect_uris": [
        "https://wiki.ligo.org/openid/callback"
      ],
      "response_types": ["code"],
      "subject_type": "public"
    }
  },
  "jwks": {
    "keys": [
      {
        "kty": "RSA",
        "use": "sig",
        "kid": "U2JTWHY0VFg0a2FEVVdTaHptVDJsNDNiSDk5MXRBVEtNSFVkeXZwb",
        "e": "AQAB",
        "n": "4AZjgqFwMhTVSLrpzzNcwaCyVD88C_Hb3Bmor97vH-2AzldhuVb8K..."
      }
    ]
  },
  "authority_hints": ["https://incommon.org"]
}

Figure 75: RP's Entity Configuration JWT Claims Set

OP は RP の Entity Configuration を受け取り、Appendix A.2 に示されたステップの並びに従って処理を進める。¶

OP は Appendix A.3.1.2 で説明したものと同じ RP metadata を正常に解決する。次に、自身の OP metadata とその他の適用可能なポリシーに準拠する形で RP を登録し、その結果を registration Entity Statement で返す。¶

OP が refresh tokens をサポートしないと仮定すると、OP は authorization_code grant type のみに対して RP を登録する。これは RP に返される metadata に反映される。¶

返される metadata には、client_id、client_secret、および OP が RP のためにプロビジョニングした他のパラメータも含まれる。¶

成功した explicit client registration の後、OP から RP に返される registration Entity Statement の JWT Claims Set の例を次に示す。¶

{
  "iss": "https://op.umu.se",
  "sub": "https://wiki.ligo.org",
  "aud": "https://wiki.ligo.org",
  "iat": 1601457619,
  "exp": 1601544019,
  "trust_anchor": "https://edugain.geant.org",
  "metadata": {
    "openid_relying_party": {
      "client_id": "m3GyHw",
      "client_secret_expires_at": 1604049619,
      "client_secret": "cb44eed577f3b5edf3e08362d47a0dc44630b3dc6ea99f7a79205",
      "client_id_issued_at": 1601457619,
      "application_type": "web",
      "client_name": "LIGO Wiki",
      "contacts": [
        "ops@edugain.geant.org",
        "ops@incommon.org",
        "ops@ligo.org"
      ],
      "grant_types": [
        "authorization_code"
      ],
      "id_token_signed_response_alg": "RS256",
      "signed_jwks_uri": "https://wiki.ligo.org/jwks.jose",
      "redirect_uris": [
        "https://wiki.ligo.org/openid/callback"
      ],
      "response_types": [
        "code"
      ],
      "subject_type": "public"
    }
  },
  "authority_hints": [
    "https://incommon.org"
  ],
  "jwks": {
    "keys": [
      {
        "kty": "RSA",
        "use": "sig",
        "kid": "U2JTWHY0VFg0a2FEVVdTaHptVDJsNDNiSDk5MXRBVEtNSFVkeXZwb",
        "e": "AQAB",
        "n": "4AZjgqFwMhTVSLrpzzNcwaCyVD88C_Hb3Bmor97vH-2AzldhuVb8K..."
      },
      {
        "kty": "EC",
        "use": "sig",
        "kid": "LWtFcklLOGdrW",
        "crv": "P-256",
        "x": "X2S1dFE7zokQDST0bfHdlOWxOc8FC1l4_sG1Kwa4l4s",
        "y": "812nU6OCKxgc2ZgSPt_dkXbYldG_smHJi4wXByDHc6g"
      }
    ]
  }
}

Figure 76: JWT Claims Set of Registration Entity Statement Returned by OP to RP after Explicit Client Registration

Appendix B. 通知

OpenID Foundation（OIDF）は、あらゆる Contributor、developer、implementer、またはその他の関心を持つ当事者に対して、非独占的で、ロイヤリティフリーで、全世界に適用される著作権ライセンスを付与する。このライセンスは、この Implementers Draft、Final Specification、または Final Specification Incorporating Errata Corrections を複製し、派生著作物を作成し、配布し、実演し、表示することを許諾する。ただし、目的は (i) 仕様の開発、ならびに (ii) そのような文書に基づく Implementers Drafts、Final Specifications、Final Specification Incorporating Errata Corrections の実装に限られる。また、OIDF を素材の出所として明記することが求められるが、その明記は OIDF による推奨（endorsement）を示すものであってはならない。¶

本仕様で記述される技術は、OpenID Foundation のメンバーやその他を含む、さまざまなソースからの貢献により提供された。OpenID Foundation は、技術が配布可能であることを確保するための手順を踏んできたが、本仕様で記述される技術の実装または利用に関して主張され得る知的財産権またはその他の権利の有効性や範囲、また、そのような権利の下でのライセンスが利用可能かどうか、またはどの程度利用可能かについて、いかなる立場も取らない。さらに、OpenID Foundation は、そのような権利を特定するための独自の努力を行ったことも表明しない。OpenID Foundation および本仕様の contributor は、本仕様に関して、商品性、非侵害、特定目的への適合性、権原を含む（ただしこれらに限られない）いかなる保証（明示、黙示、その他）も行わず（またここに明示的に否認し）、本仕様の実装に伴うリスク全体は implementer が負うものとする。OpenID の知的財産権ポリシー（openid.net に掲載）は、contributors に対して、他の contributors および implementers に対し、一定の特許請求を主張しないという特許の約束を提供することを求める。OpenID は、本仕様を実施するために必要となり得る技術をカバーする著作権、特許、特許出願、またはその他の専有権が存在する場合には、あらゆる関係者が OpenID の注意を喚起することを歓迎する。¶

Acknowledgements

The authors wish to acknowledge the contributions of the following individuals and organizations to this specification: Marcus Almgren, Patrick Amrein, Pål Axelsson, Pasquale Barbaro, Ralph Bragg, Peter Brand, Brian Campbell, David Chadwick, Michele D'Amico, Kushal Das, Andrii Deinega, Erick Domingues, Heather Flanagan, Michael Fraser, Samuel Gulliksson, Joseph Heenan, Pedram Hosseyni, Marko Ivančić, Łukasz Jaromin, Leif Johansson, Takahiko Kawasaki, Ralf Küsters, Torsten Lodderstedt, Josh Mandel, Francesco Marino, John Melati, Alexey Melnikov, Henri Mikkonen, Aaron Parecki, Eduardo Perottoni, Chris Phillips, Roberto Polli, Justin Richer, Jouke Roorda, Nat Sakimura, Mischa Sallé, Stefan Santesson, Marcos Sanz, Michael Schwartz, Giada Sciarretta, Amir Sharif, Yaron Sheffer, Sean Turner, Davide Vaghetti, Niels van Dijk, Luiky Vasconcelos, Elaine Wooton, Tim Würtele, Kristina Yasuda, Gabriel Zachmann, the JRA3T3 task force of GEANT4-2, and the SIROS Foundation.¶

Authors' Addresses

Roland Hedberg (editor)

independent

Email: roland@catalogix.se

Michael B. Jones

Self-Issued Consulting

Email: michael_b_jones@hotmail.com

URI: https://self-issued.info/

Andreas Åkre Solberg

Sikt

Email: Andreas.Solberg@sikt.no

URI: https://www.linkedin.com/in/andreassolberg/

John Bradley

Yubico

Email: ve7jtb@ve7jtb.com

URI: https://www.linkedin.com/in/ve7jtb/

Giuseppe De Marco

independent

Email: demarcog83@gmail.com

URI: https://www.linkedin.com/in/giuseppe-de-marco-bb054245/

Vladimir Dzhuvinov

Connect2id

Email: vladimir@connect2id.com

URI: https://www.linkedin.com/in/vladimirdzhuvinov/****

OpenID Federation 1.0

Abstract

Table of Contents

1. Introduction

1.1. Requirements Notation and Conventions

1.2. Terminology

2. Overall Architecture

2.1. Cryptographic Trust Mechanism

3. Entity Statement

3.1. Entity Statement Claims

3.1.1. Claims that MUST or MAY Appear in both Entity Configurations and Subordinate Statements

3.1.2. Claims that MUST or MAY Appear in Entity Configurations but Not in Subordinate Statements

3.1.3. Claims that MUST or MAY Appear in Subordinate Statements but Not in Entity Configurations

3.1.4. Claims Used in Explicit Registration Requests

3.1.5. Claims Used in Explicit Registration Responses

3.2. Entity Statement Validation

3.3. Entity Statement Example

4. Trust Chain

4.1. Beginning and Ending Trust Chains

4.2. Trust Chain Example

4.3. Trust Chain Header Parameter

4.4. Peer Trust Chain Header Parameter

5. Metadata

5.1. Entity Type Identifiers

5.1.1. Federation Entity

5.1.2. OpenID Connect Relying Party

5.1.3. OpenID Connect OpenID Provider

5.1.4. OAuth Authorization Server

5.1.5. OAuth Client

5.1.6. OAuth Protected Resource

5.2. Common Metadata Parameters

5.2.1. Parameters for JWK Sets in Entity Metadata

5.2.1.1. Usage of jwks, jwks_uri, and signed_jwks_uri in Entity Metadata

5.2.2. Informational Metadata Parameters

6. Federation Policy

6.1. Metadata Policy

6.1.1. Principles

6.1.2. Structure

6.1.3. Operators

6.1.3.1. Standard Operators

6.1.3.1.1. value

6.1.3.1.2. add

6.1.3.1.3. default

6.1.3.1.4. one_of

6.1.3.1.5. subset_of

6.1.3.1.6. superset_of

6.1.3.1.7. essential

6.1.3.1.8. Notes on Operators

6.1.3.2. Additional Operators

6.1.4. Enforcement

6.1.4.1. Resolution

6.1.4.2. Application

6.1.5. Metadata Policy Example

6.2. Constraints

6.2.1. Max Path Length Constraint

6.2.2. Naming Constraints

6.2.3. Entity Type Constraints

7. Trust Marks

7.1. Trust Mark Claims

7.2. Trust Mark Delegation

7.2.1. Trust Mark Delegation JWT

7.2.2. Validating a Trust Mark Delegation

7.3. Validating a Trust Mark

7.4. Trust Mark Examples

7.5. Trust Mark Delegation Example

8. Federation Endpoints

8.1. Fetching a Subordinate Statement

8.1.1. Fetch Subordinate Statement Request

8.1.2. Fetch Subordinate Statement Response

8.2. Subordinate Listing

8.2.1. Subordinate Listing Request

8.2.2. Subordinate Listing Response

8.3. Resolve Entity

8.3.1. Resolve Request

8.3.2. Resolve Response

8.3.3. Trust Considerations

8.4. Trust Mark Status

8.4.1. Trust Mark Status Request

8.4.2. Trust Mark Status Response

8.5. Trust Mark 付与済み Entity の一覧