Skip to content

OpenID Federation 1.0 - draft 46

WorkgroupOpenID Connect Working Group\ Published2025幎12月4日\ 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 の文脈でそれらを適甚する方法も定矩する。これらのコンポヌネントは、信頌確立を目的ずしお他のアプリケヌションプロトコルでも利甚できる。

Table of Contents

1. Introduction

本仕様は、盞互にやり取りしたい2぀のEntityが、Trust Anchor ず呌ばれる信頌された第䞉者を介しお、どのようにしお䞡者の間で信頌を確立できるかを蚘述する。Trust Anchor は、Entityに぀いおのステヌトメントを発行するこずを䞻目的ずするEntityである。アむデンティティ・フェデレヌションは、本仕様を甚いお、1段以䞊の暩嚁レベルにより実珟できる。暩嚁の䟋ずしお、フェデレヌション運甚者、組織、組織内の郚門、個別サむトがある。本仕様は、フェデレヌションのような動的か぀分散した信頌ネットワヌクを䜜るために必芁ずなる、基本的な技術的信頌むンフラの構成芁玠を提䟛する。

本仕様が扱うのは、フェデレヌション内のEntity同士が互いをどのように知るか、ずいう点に限られる点に泚意するこず。1぀の組織は、フェデレヌション内で耇数のEntityずしお衚珟されおもよい。さらに、1぀のEntityは耇数のフェデレヌションに属しおもよい。2぀のEntityが同䞀フェデレヌションに属するこずを刀定するこずが、本仕様における䞡者の間の信頌確立の基瀎ずなる。

もちろん、「trust」ずいう語は日垞甚語ずしお、゚ンティティずその行為のセキュリティ、信頌性、完党性に察する確信を含む意味でも甚いられる。この皮のtrustは、過去の実瞟、セキュリティ認蚌、透明性の高い運甚慣行などの経隓的蚌拠によっお確立されるこずが倚く、これらはセキュリティ暙準ぞの準拠や倫理的な行動を継続しおきた実瞟を瀺す。明確にしおおくず、このより広い意味でのtrustは重芁ではあるが、本仕様が達成する範囲を倧きく超える。

以䞋は、2぀の異なるTrust Anchorを根ずしお、䞀郚のメンバヌを共有する2぀のフェデレヌションの䟋である。各Entityは、共通のTrust Anchorを少なくずも1぀持぀こずによっお、他の任意の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」「Grant Type」「Protected Resource」「Redirection URI」「Refresh Token」「Resource Server (RS)」「Token Endpoint」ずいう甚語を䜿甚する。

本仕様はさらに、次の甚語を定矩する

  • Entity個別か぀独立した存圚を持ち、ある文脈においお識別できるもの。
  • Entity Identifier1぀のEntityに結び付けられた、グロヌバルに䞀意な文字列識別子。本仕様で定矩されるすべおのEntity Identifierは、httpsスキヌムを䜿甚し、host芁玠を持぀URLであり、port芁玠およびpath芁玠を含んでもよい。query parameter芁玠たたはfragment芁玠を含んではならない。本仕様のプロファむルは、他皮のEntity Identifierおよびそれに付随する凊理芏則を定矩しおもよい。
  • Trust Anchor信頌された第䞉者を衚すEntity。
  • Federation EntityEntityからTrust AnchorたでのTrust Chainを構成できるEntity。
  • Entity StatementEntityがフェデレヌション耇数可に参加するために必芁な情報を含む、眲名付きJWT。これには、自己に関するメタデヌタ、および圓該Entityが暩嚁を持぀他のEntityに適甚されるポリシヌが含たれる。
  • Entity ConfigurationEntityが自己に぀いお発行したEntity Statement。Entityの眲名鍵ず、authority hints など、Trust Chain解決プロセスを制埡するために甚いられる远加デヌタを含む。
  • Subordinate StatementSuperior Entity が、その Immediate Subordinate であるEntityに぀いお発行するEntity Statement。
  • Entity Typeフェデレヌション内でEntityが担う圹割および機胜。Entityは少なくずも1぀の型でなければならず、耇数の型であっおもよい。䟋えば、Entityは同時に OpenID Provider ず Relying Party の䞡方になり埗る。
  • Entity Type IdentifierEntity Type を衚す文字列識別子。
  • Federation Operatorフェデレヌションに察しお暩嚁を持぀組織。フェデレヌション運甚者は、自身のフェデレヌション内のEntityのために Trust Anchor耇数可を管理する。
  • Intermediate EntityTrust Anchor によっお発行されたものず Trust Chain の察象通垞は Leaf Entityによっお発行されたものの間のどこかに珟れるEntity Statementを発行するEntity。本仕様では Intermediate Entity ず Intermediate は同矩で甚いる。
  • Leaf EntitySubordinate Entities を持たないEntity。Leaf Entityは通垞、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 の察象の Entity Identifier から開始し、遞択された Trust Anchor に到達するたでEntity Statementsを収集するプロセス。収集したEntity Statementsから Trust Chain を構築しお怜蚌する。Federation Entity Discovery の結果ずしお、Trust Chain から察象のメタデヌタが構築される。
  • Trust ChainTrust Chain の察象ずなるEntity Configuration通垞は Leaf Entityから開始し、Trust Anchor で終わる、Entity Statements の列。
  • Trust Mark認定機関によっお定められた、適切にスコヌプされた信頌およびたたは盞互運甚性芁件の集合に察する適合を瀺すステヌトメント。各Trust Markは Trust Mark type identifier を持぀。
  • Trust Mark IssuerTrust Marks を発行する Federation Entity。
  • Trust Mark OwnerTrust Mark type identifier に察する暩利を所有するEntity。
  • Federation Entity Keys本仕様で定矩される信頌メカニズムに必芁な暗号眲名に甚いる鍵。Federation の参加者はそれぞれ、自身の公開 Federation Entity Keys を Entity Configuration に公開する。
  • Resolved MetadataTrust Chain における metadata policy を、Trust Chain 察象の Entity Configuration 内の metadata に適甚した結果埗られるメタデヌタ。Resolved Metadata は、Entityずやり取りする際に䜿甚されるメタデヌタである。

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 には、セクション3.2で説明される authority_hints パラメヌタにおいお、Immediate Superiors ぞの参照が1぀以䞊含たれる。これらの参照は、各 Immediate Superior の Entity Configuration をダりンロヌドするために利甚できる。Federation Entity Discovery の間、Trust Anchor に到達するたで、1぀以䞊の Entity Configurations が順に蟿られる。

Trust Anchor ずその Intermediates は、Immediate Subordinate Entities に぀いおの Entity Statements を発行し、これらを Subordinate Statements ず呌ぶ。Superior ず Subordinate の関係を怜蚌する Entity Configurations ず Subordinate Statements の列が、Trust Anchor に向かう経路に沿っお、Trust Chain の察象通垞は Leaf Entityが Trust Anchor を根ずするフェデレヌションのメンバヌであるこずの蚌明を圢成する。

Entity Configurations 同士を結び付ける Trust Chain は、セクション4で述べるずおり、各 Entity Configuration の眲名によっお怜蚌される。

怜蚌枈みの Trust Chain が埗られたら、フェデレヌションのポリシヌが適甚され、セクション6で述べるずおり、フェデレヌション内の Trust Chain 察象のメタデヌタが導出される。

本仕様は信頌操䜜を扱うメタデヌタ導出および亀換以倖のプロトコル操䜜は扱わないし、察象にも含めない。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 の察象である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 JWTs は、[RFC8725] のセクション3.11に埓い、JWT間の混同を防ぐため、typ ヘッダヌパラメヌタを entity-statement+jwt に蚭定しお明瀺的に型付けしなければならない。typ ヘッダヌパラメヌタがない、たたは異なる typ 倀を持぀ Entity Statements は拒吊しなければならない。

Entity Statement は、issuer Entity の秘密鍵のいずれかを甚いお JSON Web Signature (JWS) [RFC7515] ずしお眲名される。実装は、OpenID Connect Core がサポヌトを芁求しおいるためalg 倀が RS256、RSA SHA-256 アルゎリズムによる眲名怜蚌をサポヌトするこずが望たしい。フェデレヌションは、実装必須のアルゎリズムずしお別のものを指定しおもよい。Trust Chain には異なる眲名アルゎリズムで眲名された Entity Statements を含められる点に泚意するこず。各眲名が、䜿甚䞭の信頌フレヌムワヌクおよび実装がサポヌトする眲名アルゎリズムを甚いおいる限り、このこずは蚱容される。

Entity Statement JWTs は、䜿甚した眲名鍵の Key ID に等しい倀を持぀ kidKey IDヘッダヌパラメヌタを含たなければならない。

Entity Statement に含たれる Claims を以䞋に瀺す。Entity Statements を利甚するアプリケヌションおよびプロトコルは、远加の Claims を指定しお䜿甚しおもよい。

3.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 によっお行われるその他の眲名のために䜿甚される。ただし、本Claimはセクション12.2.3で定矩される Explicit Registration Response ずしお返される Entity Statement では OPTIONAL であり、それ以倖のすべおの堎合は REQUIRED である。JWK Set 内の各JWKは䞀意の kidKey ID倀を持たなければならない。Key IDは、鍵のSHA-256ハッシュ関数を甚いた JWK Thumbprint [RFC7638] にするこずが掚奚される。

    これらの Federation Entity Keys は、他のプロトコルでは䜿甚しないこずが望たしい。OpenID Connect など他のプロトコルで䜿甚する鍵は、openid_provider および openid_relying_party の Entity Type Identifiers 配䞋の metadata など、圓該プロトコルの Entity Type Identifiers のメタデヌタ芁玠で䌝達される。

  • metadata\ OPTIONAL。Entityが担う圹割Entity Typesを宣蚀し、それらの Entity Types のメタデヌタを含むJSONオブゞェクト。JSONオブゞェクトの各メンバヌ名は Entity Type Identifier であり、各倀は、その Entity Type のメタデヌタスキヌマに埓ったメタデヌタパラメヌタを含むJSONオブゞェクトでなければならない。

    Entityが1぀以䞊の Entity Types を䌎っお1぀以䞊のフェデレヌションに参加する堎合、その Entity Configuration は、察応する各 Entity Type Identifiers ごずに、JSONオブゞェクト倀を持぀ metadata Claim を含たなければならない。倀が空のJSONオブゞェクト {} であっおもEntity Type に関連メタデヌタがない堎合、たたは Immediate Superiors が必芁なメタデヌタを提䟛する堎合、含めなければならない。

    Immediate Superior は、Subordinate Statement の metadata Claim を䜿甚しお、Immediate Subordinate に察しお遞択したメタデヌタパラメヌタ、たたはすべおのメタデヌタパラメヌタを提䟛しおもよい。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 の䞡方が珟れる堎合、セクション6.1.4.2で述べるずおり、述べられた metadata を metadata_policy の前に適甚しなければならない。

  • crit\ OPTIONAL。Entity Statements は、セクション13.4で定矩される critcriticalClaim が理解され凊理されるこずを芁求する。本Claimの倀である配列に含たれる Claim Names を持぀ Claims は理解され凊理されなければならない。本仕様が Entity Statements での䜿甚を指定する Claims は、このリストに含めおはならない。

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

  • authority_hints\ OPTIONAL。Intermediate Entities たたは Trust Anchors の Entity IdentifiersEntityの Immediate Superiorsを衚す文字列の配列。本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オブゞェクトである配列。

    • trust_mark_type\ REQUIRED。Trust Mark の型の識別子。本Claimの倀は、このオブゞェクト内の trust_mark Claim の倀である Trust Mark JWT に含たれる trust_mark_type Claim の倀ず同䞀でなければならない。
    • trust_mark\ REQUIRED。Trust Mark を衚す眲名付き JSON Web Token。

    Trust Marks はセクション7で説明する。

  • trust_mark_issuers\ OPTIONAL。Trust Anchor は、本Claimを甚いお、どの Trust Mark type identifiers ず issuers の組み合わせがフェデレヌションから信頌されおいるかを瀺しおもよい。本Claimは、Trust Anchor ではないEntityの Entity Configuration に存圚しおいおも無芖しなければならない。これはJSONオブゞェクトであり、メンバヌ名は Trust Mark type identifiers、各察応する倀は、その識別子を持぀ Trust Marks の認定機関を代衚するものずしお信頌される Entity Identifiers の配列である。Trust Mark type identifier に続く配列が空の堎合、その識別子を持぀ Trust Marks は誰でも発行しおよい。Trust Marks はセクション7で説明する。

  • trust_mark_owners\ OPTIONAL。Federation Operator が、Trust Mark type identifier が Trust Mark Issuer ずは異なるEntityにより所有されおいるこずを知っおいる堎合、その知識は本Claimで衚珟しなければならない。本Claimは、Trust Anchor ではないEntityの Entity Configuration に存圚しおいおも無芖しなければならない。これはJSONオブゞェクトであり、メンバヌ名は Trust Mark type identifiers、各察応する倀は次のメンバヌを含むJSONオブゞェクトである

    • sub\ REQUIRED。Trust Mark Owner の Identifier。
    • jwks\ REQUIRED。眲名に甚いられる所有者の Federation Entity Keys を含む JSON Web Key Set (JWKS) [RFC7517]。

    他のメンバヌも定矩しお䜿甚しおよい。

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

  • constraints\ OPTIONAL。セクション6.2で説明される Trust Chain 制玄を定矩するJSONオブゞェクト。制玄は、この Subordinate Statement の subject であるEntityだけでなく、それに埓属するすべおのEntityにも適甚される。
  • metadata_policy\ OPTIONAL。セクション6.1で説明されるメタデヌタポリシヌを定矩するJSONオブゞェクト。メタデヌタポリシヌは、この Subordinate Statement の subject であるEntityだけでなく、それに埓属するすべおのEntityにも適甚される。Subordinate Entities に適甚される点が、subject 自身にのみ適甚される metadata ず、metadata_policy を区別する。
  • metadata_policy_crit\ OPTIONAL。セクション6.1.3.1で定矩される暙準のもの以倖で、理解し凊理しなければならない重芁なメタデヌタポリシヌ挔算子を指定する文字列配列。含める堎合、その倀は空配列 [] であっおはならない。列挙されたポリシヌ挔算子のいずれかが理解されサポヌトされおいない堎合、Subordinate Statement、ひいおはそれを含む Trust Chain は無効ず芋なさなければならない。
  • source_endpoint\ OPTIONAL。セクション8.1で芏定されるずおり、Entity Statement が発行された取埗甚゚ンドポむントURLを含む文字列。このパラメヌタにより、発行暩嚁の federation_fetch_endpoint を発芋するために通垞必芁ずなる Entity Configuration ぞのリク゚ストを省略し、Subordinate Statements、ひいおは Trust Chain を最適化しお曎新できる。゚ンドポむントURLが倉曎されおいる堎合など、source_endpoint から Entity Statement を取埗できないずきは、issuer の Entity Configuration を取埗するこずにより、珟圚の federation_fetch_endpoint の堎所を特定できる。

3.4. Claims Used in Explicit Registration Requests

  • aud\ OPTIONAL。"aud"audienceの倀は OP の Entity Identifier でなければならず、他の倀を含んではならない。本Claimは Explicit Registration requests で䜿甚される䞀般的な Entity Statement Claim ではない。

3.5. Claims Used in Explicit Registration Responses

  • aud\ OPTIONAL。"aud"audienceの倀は RP の Entity Identifier でなければならず、他の倀を含んではならない。本Claimは Explicit Registration responses で䜿甚される䞀般的な Entity Statement Claim ではない。
  • trust_anchor\ OPTIONAL。その倀は、セクション12.2.3で芏定されるずおり、OPが Explicit Registration request を凊理するために遞択した Trust Anchor の Entity Identifier でなければならない。本Claimは Explicit Registration responses に固有である䞀般的な Entity Statement Claim ではない。

3.6. 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 グラフは敎圢匏ではない。
  • 珟圚時刻は、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 から、たたはセクション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 でなければならない。セクション3.2で芏定されるずおり、その倀が構文的に正しいこずを確認する。実装はさらに、authority_hints 配列に列挙された各 Entity Identifier を持぀Entityの Subordinate であるこずを怜蚌しおもよい。
  • trust_anchor_hints Claim が存圚する堎合、Entity Statement は Entity Configuration でなければならない。セクション3.2で芏定されるずおり、その倀が構文的に正しいこずを確認する。
  • metadata Claim が存圚する堎合、セクション5で芏定されるずおり、その倀が構文的に正しいこず、metadata の倀ずしお null を䜿甚しおいないこずを確認する。
  • metadata_policy Claim が存圚する堎合、Entity Statement は Subordinate Statement でなければならない。セクション6.1で芏定されるずおり、その倀が構文的に正しいこずを確認する。
  • metadata_policy_crit Claim が存圚する堎合、Entity Statement は Subordinate Statement でなければならない。このClaimの倀の各配列芁玠は、本仕様で定矩されおいない Metadata Policy 挔算子を衚す文字列でなければならず、その挔算子は理解され、実装で凊理できなければならない。
  • constraints Claim が存圚する堎合、Entity Statement は Subordinate Statement でなければならない。セクション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 が信頌された圓事者により発行され、信頌されおいるかどうかの評䟡ずは別であるそのプロセスはセクション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オブゞェクトを倀ずするJSONオブゞェクトであるこずを怜蚌する。
  • source_endpoint Claim が存圚する堎合、Entity Statement は Subordinate Statement でなければならない。そのClaim Value がURLであるこずを怜蚌する。実装はさらに、このURLぞの取埗呌び出しを行い、これが Entity Statement が発行された取埗゚ンドポむントであるこずを怜蚌しおもよい。
  • aud Claim が存圚する堎合、Entity Statement が Explicit Registration request であるなら倀がOPの Entity Identifier であるこずを怜蚌し、たたは Entity Statement が Explicit Registration request であるなら倀がRPの Entity Identifier であるこずを怜蚌する。本Claimは、拡匵でその䜿甚が別途指定されおいる堎合を陀き、Explicit Registration requests たたは responses ではない Entity Statements に存圚しおはならない。
  • trust_anchor Claim が存圚する堎合、その倀が https スキヌムを䜿甚するURLであるこずを怜蚌する。実装は、その Entity Identifier がデプロむメントに蚭定された Trust Anchors のいずれかず䞀臎するこずを怜蚌するこずが望たしい。さらに、実装は、その Entity Identifier の Entity Configuration が、蚭定された Trust Anchor 情報特に鍵ず互換の情報を含むこずを怜蚌するこずが望たしい。本Claimは、拡匵でその䜿甚が別途指定されおいる堎合を陀き、Explicit Registration responses ではない Entity Statements に存圚しおはならない。
  • trust_chain ヘッダヌパラメヌタが存圚する堎合、セクション4で芏定されるずおり、その倀が構文的に劥圓な Trust Chain であるこずを怜蚌する。Trust Chain の最初の゚ントリは、このEntityの Entity Configuration でなければならない。実装は、Trust Chain の末尟にある Trust Anchor の Entity Identifier が、デプロむメントに蚭定された Trust Anchors のいずれかず䞀臎するこずを怜蚌するこずが望たしい。
  • peer_trust_chain ヘッダヌパラメヌタが存圚する堎合、セクション4で芏定されるずおり、その倀が構文的に劥圓な Trust Chain であるこずを怜蚌する。実装は、Trust Chain の末尟にある Trust Anchor の Entity Identifier が、デプロむメントに蚭定された Trust Anchors のいずれかず䞀臎するこずを怜蚌するこずが望たしい。

これらの怜蚌手順のいずれかが倱敗した堎合、Entity Statement は拒吊しなければならない。

3.7. Entity Statement Examples

以䞋は、Entity Statement の JWT Claims Set の非芏範的な䟋である。この䟋には、Entity Statement に察する critical extension である jtiJWT IDず、ポリシヌ蚀語に察する critical extension である regexpRegular expressionが1぀含たれおいる。

{
  "iss": "https://feide.no",
  "sub": "https://ntnu.no",
  "iat": 1516239022,
  "exp": 1516298022,
  "jwks": {
    "keys": [
      {
        "kty": "RSA",
        "alg": "RS256",
        "use": "sig",
        "kid": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
        "n": "pnXBOusEANuug6ewezb9J_...",
        "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

以䞋は、trust_mark_owners Claim Value の非芏範的な䟋である

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

Figure 3: Example trust_mark_owners Claim Value

以䞋は、trust_mark_issuers Claim Value の非芏範的な䟋である

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

Figure 4: Example trust_mark_issuers Claim Value

4. Trust Chain

Trust Chain を構成するステヌトメントを持぀Entityは、次のように分類される

  • Trust Anchor信頌された第䞉者を衚すEntity。
  • LeafOpenID Connect のアむデンティティ・フェデレヌションでは RP たたは OP、OAuth 2.0 のフェデレヌションでは Client、Authorization Server、たたは Protected Resource。
  • IntermediateLeaf Entity でも Trust Anchor でもないEntity。

Trust Chain は、Trust Chain の察象である Entity Configuration から始たり、これは通垞 Leaf Entity である。Trust Chain は、Intermediates が Immediate Subordinates に぀いお発行する Subordinate Statements を0個以䞊持ち、Trust Anchor が最䞊䜍 IntermediateIntermediates がある堎合たたは Trust Chain の察象Intermediates がない堎合に぀いお発行する Subordinate Statement を含む。Trust Chain は、堎合によっおは Trust Chain を衚すJSON配列から省略されおもよいが、論理的には垞に Trust Anchor の Entity Configuration で終わる。

Trust Chain には、評䟡時点においお Trust Chain の察象に適甚されるフェデレヌションの構成が含たれる。

簡単な䟋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 察象の Entity Configurationは、ES[0]["jwks"] 内の鍵を甚いお眲名される。
  • Entity Statement の iss Claim は、次の Entity Statement の sub Claim に等しい。蚘号的に蚀い換えるず、各 j = 0,...,i-1 に぀いお、ES[j]["iss"] == ES[j+1]["sub"]。
  • Entity Statement は、次の 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 における Immediate Subordinate に぀いおの Trust Anchor の Subordinate Statementの眲名怜蚌に甚いられる。Trust Anchor の公開鍵は、Trust Chain を怜蚌する必芁があるEntityに察しお、本曞で説明されない安党なアりト・オブ・バンドの方法で配垃される。

4.1. Beginning and Ending Trust Chains

Trust Chain は、信頌を確立しようずしおいる Entity の Entity Configuration から始たる。これが Trust Chain の subject である。この Entity は通垞、OpenID Provider や OpenID Relying Party のようなプロトコル䞊の圹割を担う。

このような Entity は通垞 Leaf Entity だが、他のトポロゞヌもあり埗る。䟋えば、ある 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 ずしおも機胜する堎合、Trust Anchor は Superior を持぀こずになる。これは、フェデレヌションが階局化されおいる堎合に該圓する。

したがっお、Trust Chain が Superiors を持たない Trust Anchor で終わるのが䞀般的ではあるものの、Trust Chain が Superior Entities を持぀ Trust Anchor で終わる状況も存圚する。

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 5: Relationships between Federation Entities and Statements Issued in a Trust Chain

4.3. Trust Chain Header Parameter

trust_chain JWS header parameter は、Entity ず遞択された Trust Anchor の間の Trust Chain を構成する Entity Statements の䞊びを含むJSON配列である。通垞、Trust Chain は、このヘッダヌパラメヌタが珟れるJWTの subject の Entity Configuration から始たる。しかし、セクション8.3.2で定矩される Resolve Response の堎合のように、Trust Chain が issuer など別の Entity の Entity Configuration から始たるこずもある。JWTの issuer は、Trust Chain の先頭にある Entity ずJWTの audience が共通に持぀ Trust Anchor を遞択するこずが望たしい。そうでない堎合でも、issuer は䜿甚する Trust Anchor を自由に遞択できる。いく぀かの䟋倖を陀き、ほずんどの眲名付きJWTは trust_chain JWS header parameter を含めおもよい。Entity Configurations ず Subordinate Statements は、Trust Chain の䞍可欠な構成芁玠であるため、trust_chain header parameter を含んではならない。このヘッダヌパラメヌタの䜿甚は OPTIONAL である。

以䞋は、trust_chain パラメヌタを持぀JWSヘッダヌの非芏範的な䟋である。

{
  "typ": "...",
  "alg": "RS256",
  "kid": "SUdtUndEWVY2cUFDeDV5NVlBWDhvOXJodVl2am1mNGNtR0pmd",
  "trust_chain": [
    "eyJ0eXAiOiJlbnRpdHktc3RhdGVtZW50K2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiVUdaSGF6aHVZalpoT0Y5amNUaHBWa05KU1VkWWQxVnlaR1JGVXpWd09FVXlSMDQwU2tjMk1XMXVPQSJ9.eyJtZXRhZGF0YSI6IHsib3BlbmlkX2NyZWRlbnRpYWxfaXNzdWVyIjogeyJqd2tzIjogeyJrZXlzIjogW3sia3R5IjogIlJTQSIsICJraWQiOiAiUjJSelJYQTBSVkJ5ZHpGT1ZHMWZkV1JUTVRaM1lUUm1ObkUxVjNGZk1FMW9NVVpMZWtsaVkxTllPQSIsICJlIjogIkFRQUIiLCAibiI6ICI1SF9YaDd4Z0RXVHhRVmJKcW1PR3Vyb2tFOGtyMmUxS2dNV2NZT0E3NE9fMVBYZDJ1Z2p5SXE5dDFtVlBTdXd4LXR5U2syUEtwanAtLVdySG4zQTRVS0prdVIxMXpobWRMQnNVOFRPQkJ1NU1aOGF0RHVqZlJ3SUxYZEtzRVhrbHZhQjZQTFQ0emRab2RnQ3MwNUt5MmU1c2I1ejZfQ2lEcWdVVm5XUG1KTE1rZ3BCdFota01kX2xiOVNvb1psbGZVR2xUa3NhdUoyX2dWUS1WcEZVTVhZam9Kak54OTdldWthWW5SRW9DQzNUYV8tOGJjUm9zbHgyeHJJYnVfVUdWcWlwZU4zTlAtbWVmZjlWVFpXWU0zZ21vbHd1cG5NQ1hYaWlrY1I1VVNMVmcwZV9nejZPZm9SVkdLQVdJcFJSTFR6MmFpcXVrVkhaZFpYOXRObXowbXcifV19fSwgImZlZGVyYXRpb25fZW50aXR5IjogeyJvcmdhbml6YXRpb25fbmFtZSI6ICJPcGVuSUQgQ3JlZGVudGlhbCBJc3N1ZXIgZXhhbXBsZSIsICJvcmdhbml6YXRpb25fdXJpIjogImh0dHBzOi8vY3JlZGVudGlhbF9pc3N1ZXIuZXhhbXBsZS5vcmcvaG9tZSIsICJwb2xpY3lfdXJpIjogImh0dHBzOi8vY3JlZGVudGlhbF9pc3N1ZXIuZXhhbXBsZS5vcmcvcG9saWN5IiwgImxvZ29fdXJpIjogImh0dHBzOi8vY3JlZGVudGlhbF9pc3N1ZXIuZXhhbXBsZS5vcmcvc3RhdGljL2xvZ28uc3ZnIiwgImNvbnRhY3RzIjogWyJ0ZWNoQGNyZWRlbnRpYWxfaXNzdWVyLmV4YW1wbGUub3JnIl19fSwgImF1dGhvcml0eV9oaW50cyI6IFsiaHR0cHM6Ly9pbnRlcm1lZGlhdGUuZWlkYXMuZXhhbXBsZS5vcmciXSwgImp3a3MiOiB7ImtleXMiOiBbeyJrdHkiOiAiUlNBIiwgImtpZCI6ICJNR281VVY4dGIwRkpha2xEVm10aFpuTmpZWE50V1hvd1J6aG9OVzQwTTBkTVJqTlRTRWd3TWpNeE9BIiwgIm4iOiAielVITzlvQWJUOXg4TWhGNEdTY0JPU3BkaVRoMGM3dWh0eFo3WG9vRFMxckZyQXRXVUNRLV9nUUFjVmVsMEFjcUIxdEoyQmFTaEdobkdsX1ZVYTlqSXE5WkJpc2xQZS1tZ01STFFYNm1HdnhKR19Gb0FRQ3BOUGNXRWRCT21uNUFkVGxXeTFoYk9mMlY5YV9TUzdKeUpnaVJJMXBodm43bmhyNVVmMFRUX1B2NzJsS0tBZ3drUmdEOXZtWVRSOFBTSzF3b2d6WVJSMFYwYVg2M3I5Xy0wb2ZZN3hRRXIwR2xVY2dqZlVyS0dzS0JJNWswalQtQlIxdXpxaWJVSHlsblQ5UXBNajhBQ0docmktYXRnb2t0Z1ZtNklUTmJXYTBCcnIyMWVLVUpKaHZ1eGVQTUxhUDVPdUoxRy1CanhxakNwOHJGaTB0bWJOU0pWanNiUlplQ3lRIiwgImUiOiAiQVFBQiJ9XX0sICJzdWIiOiAiaHR0cHM6Ly9jcmVkZW50aWFsX2lzc3Vlci5leGFtcGxlLm9yZyIsICJpc3MiOiAiaHR0cHM6Ly9pbnRlcm1lZGlhdGUuZWlkYXMuZXhhbXBsZS5vcmciLCAiaWF0IjogMTc1ODUyNzgxOCwgImV4cCI6IDE3NTg4Mjc4MTh9.W3fbv3JrAxcDsV0MHk00MzcgC1DddTrzkRN8vdT1IRwq3qy9NtsiC2532oInHoxxjlKBu7D8cqF9yG0Tb1v4gk_tejyUo0M9xJqyz32RU2iZP0lpbNHHUDrMxuGv1wPDap2mKisRgbb7pxm6dx_aaIrydhx0uKDM6EwX1RzpMxJeqNMeLK9992_xyCZvsi3kVGRCJDSqd-rXBS_2LFWKUViC1_5GcsWAkRABBgRDeARqQah3FvJVWiAcNv2Te2k6SMW1MNVCT7Q3uf3c2vVuaVA1OwY_wUTrkfFRjKEOmU1sgZ1TndxJKQW0XZZmTxcoJfmrjmCyxtteucYznESMnw",
    "eyJ0eXAiOiJlbnRpdHktc3RhdGVtZW50K2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiVUdaSGF6aHVZalpoT0Y5amNUaHBWa05KU1VkWWQxVnlaR1JGVXpWd09FVXlSMDQwU2tjMk1XMXVPQSJ9.eyJzdWIiOiAiaHR0cHM6Ly9jcmVkZW50aWFsX2lzc3Vlci5leGFtcGxlLm9yZyIsICJqd2tzIjogeyJrZXlzIjogW3sia3R5IjogIlJTQSIsICJraWQiOiAiTUdvNVVWOHRiMEZKYWtsRFZtdGhabk5qWVhOdFdYb3dSemhvTlc0ME0wZE1Sak5UU0Vnd01qTXhPQSIsICJuIjogInpVSE85b0FiVDl4OE1oRjRHU2NCT1NwZGlUaDBjN3VodHhaN1hvb0RTMXJGckF0V1VDUS1fZ1FBY1ZlbDBBY3FCMXRKMkJhU2hHaG5HbF9WVWE5aklxOVpCaXNsUGUtbWdNUkxRWDZtR3Z4SkdfRm9BUUNwTlBjV0VkQk9tbjVBZFRsV3kxaGJPZjJWOWFfU1M3SnlKZ2lSSTFwaHZuN25ocjVVZjBUVF9QdjcybEtLQWd3a1JnRDl2bVlUUjhQU0sxd29nellSUjBWMGFYNjNyOV8tMG9mWTd4UUVyMEdsVWNnamZVcktHc0tCSTVrMGpULUJSMXV6cWliVUh5bG5UOVFwTWo4QUNHaHJpLWF0Z29rdGdWbTZJVE5iV2EwQnJyMjFlS1VKSmh2dXhlUE1MYVA1T3VKMUctQmp4cWpDcDhyRmkwdG1iTlNKVmpzYlJaZUN5USIsICJlIjogIkFRQUIifV19LCAiaXNzIjogImh0dHBzOi8vaW50ZXJtZWRpYXRlLmVpZGFzLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3NTg1Mjc4MTgsICJleHAiOiAxNzU4ODI3ODE4fQ.hF0ABpYlQBPzeMJrANe-5VOStDbZrEFdYVnNVwRgxphCMEMyoBfHDVv9kQceJtKqKbzFyFFCiO6QPY-GGt-eI37YxdzG5F8GCr9hBXfoUtTSiWaEop3B0AVXH0SelRO5zvN8W2SlR0rPTJ75kLv2vaVbgES_IzMhneteRvx2HGvCxOdvA4kermxkFT7MSP3YGyuNGJ4JAEvLXT6TmL9wiitGJ3SO34ImWZ4uI9zmSzWqvRIFKZ05dD2_RVybJbKQcOuRS3Th2yn0uq4YPzPw-Na2mw0FcYXMKQhq-SvdkI4Rt4eQMbIyyminMuTxrdIeQD6-rvSOxUTjF31sjnekvA",
    "eyJ0eXAiOiJlbnRpdHktc3RhdGVtZW50K2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiTjFsNWVWWTJhMmszU0ZCSGNtcFRjMVJJYkZGM1R6VmlZbkp2VTBNNGJuaE1ZMXBxTkdod01VcEZTUSJ9.eyJzdWIiOiAiaHR0cHM6Ly9pbnRlcm1lZGlhdGUuZWlkYXMuZXhhbXBsZS5vcmciLCAiandrcyI6IHsia2V5cyI6IFt7Imt0eSI6ICJSU0EiLCAia2lkIjogIlVHWkhhemh1WWpaaE9GOWpjVGhwVmtOSlNVZFlkMVZ5WkdSRlV6VndPRVV5UjA0MFNrYzJNVzF1T0EiLCAibiI6ICJvTlhGczdmajR5Q0k2TUotS3JSbDM0WkpBbGR1N2x3ZE5rdHk2N1FHTUx5Wmh6dFpkT0VYV2w3Z1ZRUldIeUM3M01kTGlhU1VJUFB0R2daak5iSVJEUDF0UDFJZWlObU52bmhWTnNCbWNiVjhLRUNkXy1GRGlYWDRTT0VNU0ItNXVhTGpsay1VTGpZajdwZGhPSjJqcWdIQ1dHMmFhMkozYXdUY25zSXc1NDF0YVdoc2NGZlZIT0ktMVZnbzVCTDdmRGdEakRLcGtpeGg4SE5PUVVQTXJrMWdZb2tiakt3V0RKZXphUndtamVNWldOczB1aTFvdmlFWW0xQzRfTVNSWW8wUEVOWHk0QmQ2QzVHLTVTanZyNU83U1dLN19GUWpsY09yZXhrUERyNmdQQWZHZVZnNW1CblJYOGp3b1l0TnlMal94SlpSRGZKMDdjTTRfNXl4cVEiLCAiZSI6ICJBUUFCIn1dfSwgImlzcyI6ICJodHRwczovL3RydXN0LWFuY2hvci5leGFtcGxlLm9yZyIsICJpYXQiOiAxNzU4NTI3ODE4LCAiZXhwIjogMTc1ODgyNzgxOH0.G3DP1Nqt8UTXwes0ozKzADd1KmAYl0K0DhyjQMJOKR7pgqYp_S91ObMKPrBJDh1Mnpy7mpHICUM23pUEMFt7v_-MdqjPTOG5ebrxqjFtemizFk6iHWvwhCcheQIsNMRXf-y64Ox6SgBVXP_JaKHtA_YInTQB9-_bdb-mWvwpOlvvGH-l5Hl7TQten_IoewT9bfC62UkOmKzn0L1VlVFtYn9R7sRFUtnfcqsvvRLIHNfJwaJi-lpODgNv2l7arHssS_FmfX5ZN-3WylJJbZhtkFku1ITKx7c4bvGsZSvEx9m_ixGJYunfD-iKWAmfE1suc6X-ywR7dgdp_BBpMvytlg",
    "eyJ0eXAiOiJlbnRpdHktc3RhdGVtZW50K2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiTjFsNWVWWTJhMmszU0ZCSGNtcFRjMVJJYkZGM1R6VmlZbkp2VTBNNGJuaE1ZMXBxTkdod01VcEZTUSJ9.eyJtZXRhZGF0YSI6IHsiZmVkZXJhdGlvbl9lbnRpdHkiOiB7ImZlZGVyYXRpb25fZmV0Y2hfZW5kcG9pbnQiOiAiaHR0cHM6Ly90cnVzdC1hbmNob3IuZXhhbXBsZS5vcmcvZmV0Y2giLCAiZmVkZXJhdGlvbl9yZXNvbHZlX2VuZHBvaW50IjogImh0dHBzOi8vdHJ1c3QtYW5jaG9yLmV4YW1wbGUub3JnL3Jlc29sdmUiLCAiZmVkZXJhdGlvbl9saXN0X2VuZHBvaW50IjogImh0dHBzOi8vdHJ1c3QtYW5jaG9yLmV4YW1wbGUub3JnL2xpc3QiLCAib3JnYW5pemF0aW9uX25hbWUiOiAiVEEgZXhhbXBsZSIsICJvcmdhbml6YXRpb25fdXJpIjogImh0dHBzOi8vdHJ1c3QtYW5jaG9yLmV4YW1wbGUub3JnL2hvbWUiLCAicG9saWN5X3VyaSI6ICJodHRwczovL3RydXN0LWFuY2hvci5leGFtcGxlLm9yZy9wb2xpY3kiLCAibG9nb191cmkiOiAiaHR0cHM6Ly90cnVzdC1hbmNob3IuZXhhbXBsZS5vcmcvc3RhdGljL2xvZ28uc3ZnIiwgImNvbnRhY3RzIjogWyJ0ZWNoQHRydXN0LWFuY2hvci5leGFtcGxlLm9yZyJdfX0sICJjb25zdHJhaW50cyI6IHsibWF4X3BhdGhfbGVuZ3RoIjogMX0sICJqd2tzIjogeyJrZXlzIjogW3sia3R5IjogIlJTQSIsICJraWQiOiAiTjFsNWVWWTJhMmszU0ZCSGNtcFRjMVJJYkZGM1R6VmlZbkp2VTBNNGJuaE1ZMXBxTkdod01VcEZTUSIsICJuIjogIm9pcm5UMEVjMkNva2JPZFJQT0VlbTI0SXc5LXhUeW5DcGwtOWx0cjBQclNUTEJXbHp6VW1IbzNBS25qemttNUg4MmxudVRMVTd1Skd3a0tqMjJaeklCMmFiMDIzendEX09rdDRaOXFyeW1kZUFYc0MtYXFhcVQ5RjZjZjFsbUJVczBvQXlwdWlTSnh1bU5WSVVucF9wbWhvbjlfR3NHUnlYcnJnT3lJclNKZ2hoX3p4RXREb3BnN0NQb3Q3Mmk3QlRpd0U1cXp0MFhGOHBnczM2VndYM0F3WnNMVkhpaGo0WVNUYXlYUUV3aUszMDUxRnhXXzVCbWNIRXJxM0J5WkU0UmZOSjBzbU96Z1NwMEtET0dkVjUwNHR5cTZJS1BjM04ybkhJd3hjUl9NbmczaWlfVWlFVXFYVEkwYkk5TlY4VHV4VWtrUldRcFZab0w5T3V2am9NUSIsICJlIjogIkFRQUIifV19LCAic3ViIjogImh0dHBzOi8vdHJ1c3QtYW5jaG9yLmV4YW1wbGUub3JnIiwgImlzcyI6ICJodHRwczovL3RydXN0LWFuY2hvci5leGFtcGxlLm9yZyIsICJpYXQiOiAxNzU4NTI3ODE4LCAiZXhwIjogMTc1ODgyNzgxOH0.lYDvz35LPE0V6nVUfO6Qwe8-AVQ9HBBeup-hg79HPAV-PqGa9dI9YX7GMiwb_khVGL8ASLfru4pFjlk4kjvgWj6u-ZXmWeElo48rAubCTtHKU8XOkHhvPXp04havTUevTCs3J0rBZKiJBLCBS9046yTrLPP8yN2hh_wR_3YExfW9O6w5tuEkghP4pQHZbWVZjE2pXTd-iIL5OFOWF_3050bAMTUQP_XUH5ZAPlj2-_qyDmARM9sh83SMDFwWkSqsDQDrOpWs1Uy7uT_iwqgPBuMSwUl9s4iRV-_CJy3IOdP0DCJOM3IyTWoHSlcMotEKGLmf4zTSnABr9PCPc5Bgrg"
  ]
}

Figure 6: Example JWS Header with a trust_chain Parameter

4.4. Peer Trust Chain Header Parameter

peer_trust_chain JWS header parameter は、圓該Entityが信頌を確立しようずしおいる盞手の Entity ず、遞択された Trust Anchor の間の Trust Chain を構成する Entity Statements の䞊びを含むJSON配列である。trust_chain header parameter も存圚する堎合、䞡方の Trust Chains の Trust Anchor は同䞀であるこずが望たしい。䞡方の Trust Chains を含めるこずで、[App-Fed-Linkage] で定矩される Federation Integrity および Metadata Integrity の特性を達成できる。Entity Configurations ず Subordinate Statements は、Trust Chain の䞍可欠な構成芁玠であるため、peer_trust_chain header parameter を含んではならない。このヘッダヌパラメヌタの䜿甚は OPTIONAL である。

5. Metadata

本セクションは、Entities に関する metadata の衚珟方法ず䜿甚方法を定矩する。各 Entity Type に適甚可胜な、既存の OpenID Connect および OAuth 2.0 の metadata 暙準を䜿甚する。

セクション3.1で述べたずおり、Entity の metadata は Entity Statement の metadata Claim に眮かれ、その倀はJSONオブゞェクトである。このオブゞェクトのメンバヌ名は、セクション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 のための識別子を定矩する。

OpenID Connect および OAuth 2.0 のフェデレヌションの範囲倖のナヌスケヌスを支揎するために、远加の Entity Type Identifiers を定矩しおもよい。

5.1.1. Federation Entity

Entity Type Identifier は federation_entity である。

以䞋で定矩される Federation Entity のプロパティのいずれかを含む Entities は、この Entity Type を䜿甚しなければならない。次の Federation Entity プロパティを定矩する

federation_fetch_endpoint\ OPTIONAL。セクション8.1で蚘述される fetch endpoint。このURLは https スキヌムを䜿甚しなければならず、port、path、query parameter を含んでもよいfragment を含んではならない。Intermediate Entities ず Trust Anchors は federation_fetch_endpoint を公開しなければならない。Leaf Entities は公開しおはならない。

federation_list_endpoint\ OPTIONAL。セクション8.2で蚘述される list endpoint。このURLは https スキヌムを䜿甚しなければならず、port、path、query parameter を含んでもよいfragment を含んではならない。Intermediate Entities ず Trust Anchors は federation_list_endpoint を公開しなければならない。Leaf Entities は公開しおはならない。

federation_resolve_endpoint\ OPTIONAL。セクション8.3で蚘述される resolve endpoint。このURLは https スキヌムを䜿甚しなければならず、port、path、query parameter を含んでもよいfragment を含んではならない。任意の federation Entity は federation_resolve_endpoint を公開しおもよい。

federation_trust_mark_status_endpoint\ OPTIONAL。セクション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。セクション8.5で蚘述される endpoint。このURLは https スキヌムを䜿甚しなければならず、port、path、query parameter を含んでもよいfragment を含んではならない。Trust Mark Issuers は federation_trust_mark_list_endpoint を公開しおもよい。

federation_trust_mark_endpoint\ OPTIONAL。セクション8.6で蚘述される endpoint。このURLは https スキヌムを䜿甚しなければならず、port、path、query parameter を含んでもよいfragment を含んではならない。Trust Mark Issuers は federation_trust_mark_endpoint を公開しおもよい。

federation_historical_keys_endpoint\ OPTIONAL。セクション8.7で蚘述される endpoint。このURLは https スキヌムを䜿甚しなければならず、port、path、query parameter を含んでもよいfragment を含んではならない。すべおの Federation Entities は federation_historical_keys_endpoint を公開しおもよい。

endpoint_auth_signing_alg_values_supported\ OPTIONAL。セクション8.8で述べるずおり、federation endpoints に察しお認蚌する際に private_key_jwt で䜿甚されるJWTに眲名するためにサポヌトする JWS アルゎリズムalg 倀の䞀芧を含むJSON配列。この゚ントリが省略されおも、デフォルトのアルゎリズムは暗黙に瀺されない。サヌバヌは RS256 をサポヌトするこずが望たしい。none の倀は䜿甚しおはならない。

远加の Federation Entity プロパティを定矩しお䜿甚しおもよい。

各 Federation Entity が、セクション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 7: 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 のセクション2、[OpenID.RP.Choices]、およびセクション5.2で定矩されるすべおのパラメヌタが適甚される。さらに、IANA の “OAuth Dynamic Client Registration Metadata” レゞストリに登録された远加パラメヌタも適甚される。ただし、registration responses でのみ䜿甚するためにレゞストリで定矩されおいるパラメヌタ䟋client_secretは陀く。

加えお、次のRP metadata パラメヌタを定矩する

client_registration_types\ RECOMMENDED。RPがサポヌトする client registration types を指定する文字列配列。本仕様で定矩する倀は automatic ず explicit である。本仕様による制限なしに、远加の倀を定矩しお䜿甚しおもよい。

以䞋は、RPの Entity Configuration の JWT Claims Set の非芏範的な䟋である

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

Figure 8: 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 のセクション3、およびセクション5.2で定矩されるすべおのパラメヌタが適甚される。さらに、IANA の “OAuth Authorization Server Metadata” レゞストリに登録された远加パラメヌタも適甚される。䟋えば、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 を含んではならない。セクション12.2で蚘述される Explicit Client Registration をOPがサポヌトする堎合、この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/openid/signed_jwks.jose",
      "authorization_endpoint": "https://op.umu.se/openid/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/openid/token",
      "federation_registration_endpoint": "https://op.umu.se/openid/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/openid/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 9: Example OpenID Provider Entity Configuration JWT Claims Set

5.1.4. OAuth Authorization Server

Entity Type Identifier は oauth_authorization_server である。

[RFC8414] のセクション2およびセクション5.2で定矩されるすべおのパラメヌタが適甚される。さらに、IANA の “OAuth Authorization Server Metadata” レゞストリに登録された远加パラメヌタも適甚される。

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 のセクション2およびセクション5.2で定矩されるすべおのパラメヌタが適甚される。さらに、IANA の “OAuth Dynamic Client Registration Metadata” レゞストリに登録された远加パラメヌタも適甚される。

5.1.6. OAuth Protected Resource

Entity Type Identifier は oauth_resource である。セクション5.2で定矩されるパラメヌタが適甚される。加えお、デプロむメントは [RFC9728] で定矩される protected resource metadata パラメヌタを䜿甚しおもよい。

5.2. Common Metadata Parameters

本セクションは、以䞋に蚘す JWK Sets に関する䟋倖を陀き、䞊蚘すべおの Entity Types で䜿甚しおもよい远加の metadata パラメヌタを定矩する。

5.2.1. Extensions for JWK Sets in Entity Metadata

以䞋の metadata パラメヌタは、Entity の Entity Type に察する JWK Sets を取埗する方法を定矩する。これらの鍵は、Entity Statements に眲名するために䜿甚される Federation Entity KeysEntity Statement の jwks Claim にあり、metadata Claim の䞭ではないずは別物である点に泚意するこず。JWK Sets に察するこれらの拡匵は、federation_entity Entity Type の metadata では䜿甚しおはならない。

signed_jwks_uri\ OPTIONAL。圓該 Entity Type の payload ずしお、Entity の JWK Set ドキュメントを持぀眲名付きJWTを参照するURL。このURLは https スキヌムを䜿甚しなければならない。JWTは Federation Entity Key を甚いお眲名されなければならない。このURLからの成功レスポンスは、HTTPステヌタスコヌド200および content type application/jwk-set+jwt を䜿甚しなければならない。眲名鍵ず暗号化鍵が䞡方存圚する堎合、参照される JWK Set 内のすべおの鍵に察しお、各鍵の意図した甚途を瀺す usepublic key useパラメヌタ倀が REQUIRED である。

Signed JWK Set JWTs は、[RFC8725] のセクション3.11に埓い、JWT間の混同を防ぐため、typ ヘッダヌパラメヌタを jwk-set+jwt に蚭定しお明瀺的に型付けされる。typ ヘッダヌパラメヌタがない、たたは異なる typ 倀を持぀ Signed JWK Set JWTs は拒吊しなければならない。

Signed JWK Set JWTs は、䜿甚した眲名鍵の Key ID に等しい倀を持぀ kidKey IDヘッダヌパラメヌタを含たなければならない。

payload での䜿甚が指定される Claims を以䞋に瀺すkeys 以倖はすべお [RFC7519] で定矩される

keys\ REQUIRED。JWK Set 内のJWK倀の配列。

iss\ REQUIRED。"iss"issuerClaim は、JWTを発行した䞻䜓を識別する。

sub\ REQUIRED。本Claimは鍵の所有者を識別する。issuer ず同䞀であるこずが望たしい。

iat\ OPTIONAL。数倀。このSigned 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を定矩しお䜿甚しおもよい。

以䞋は、Signed 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 10: 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぀だけを䜿甚するこずが掚奚される。しかし、Entity が耇数のフェデレヌションに属し、フェデレヌションごずに䜿甚すべき JWK Set 衚珟に関するポリシヌが異なる堎合など、耇数の JWK Set 衚珟を䜿甚するこずが望たしい状況もあり埗る。たた、䞀郚の実装はこれらすべおの衚珟を理解できない可胜性がある点にも泚意するこず。䟋えば、OpenID Connect のOP metadata では jwks_uri は確実に理解される䞀方で、signed_jwks_uri はすべおの OpenID Connect 実装で理解されるずは限らない。そのため、理解される JWK Set 衚珟も䜵せお存圚する必芁がある。

耇数の JWK Set 衚珟が䜿甚される堎合、各衚珟に含たれる鍵は同䞀であるこずが望たしい。特定の瞬間に完党に同䞀でない堎合鍵ロヌテヌションの運甚䞭に起こり埗るであっおも、実装は適時にそれらを敎合させなければならない。

5.2.2. Informational Metadata Extensions

以䞋の metadata パラメヌタは、Entity Type に察する Entity の情報を取埗する方法を定矩する。

organization_name\ OPTIONAL。この Entity を所有する組織を衚す、人間が読める名称。所有者が自然人である堎合、䟋えばその人の名前であっおもよい。この情報は公開される点に泚意するこず。

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

description\ OPTIONAL。End-User に提瀺できる、Entity の人間が読める簡朔な説明。

keywords\ OPTIONAL。この Entity に適甚される怜玢キヌワヌド、タグ、カテゎリ、たたはラベルを衚す、1぀以䞊の文字列を持぀JSON配列。

contacts\ OPTIONAL。この Entity の連絡担圓者を衚す、1぀以䞊の文字列を持぀JSON配列。名前、メヌルアドレス、説明、電話番号などを含んでもよい。

logo_uri\ OPTIONAL。文字列。この Entity のロゎを指すURL。ロゎを含むファむルは、Web経由で閲芧できる圢匏で公開するこずが望たしい。

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 の Entities からなるフェデレヌションでは、OpenID Providers ず Relying Parties が公開する metadata が盞互運甚可胜であるこずを確保する、ずいう目的があり埗る。別の目的ずしお、䟋えば FAPI のようなセキュリティプロファむルに Entity metadata を準拠させる、ずいうこずもあり埗る。

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 policies に寄䞎できる。ただし、その寄䞎の結果ずしお埗られる結合埌の metadata policy が論理的に健党であるこずが条件である。䟋えば、任意の Intermediate は、Superiors が指定したものに察しお、Subordinates の metadata をさらに制限できる。Intermediate が metadata policies の間に矛盟を導入した堎合、その 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 内にある圓該型のすべおの Subordinate Entities の metadata に適甚される。

ポリシヌを定矩する堎所は Subordinate Statement であり、か぀各 Entity Statement は特定の subject に察しお発行されるため、フェデレヌション暩嚁は、すべおの Subordinates に共通の Entity Type metadata policy を定矩するこずも、特定の Subordinates に察しお特定の Entity Type metadata policies を定矩するこずも遞べる。

Operation\ ポリシヌは、䞎えられた metadata パラメヌタに察しお、怜査、倉曎、たたはその䞡方を行うこずによっお動䜜する。本仕様は、セクション6.1.3.1で述べる暙準の挔算子セットを定矩する。フェデレヌションは、本セクションおよびセクション6.1.3ずセクション6.1.3.2で述べる原則に適合する限り、远加の挔算子を指定しお䜿甚しおもよい。

Integral Metadata Enforcement\ metadata policies の解決ず適甚は、セクション10で述べるずおり、Trust Chain 解決プロセスの䞍可欠な䞀郚である。

これは次を意味する

  • 䟋えば Intermediate Entity のポリシヌが Superior のポリシヌず衝突するなどの゚ラヌにより、metadata policy の解決に倱敗する Trust Chain は無効ず芋なされる。
  • 解決枈みの metadata policies に準拠しない Entity metadata を持぀ Trust Chain は無効ず芋なされる。

Determinism\ Trust Chain における metadata policies の解決ず適甚は決定的である。したがっお Trust Anchors ず Intermediate Entities は、予枬可胜で再珟可胜な結果を瀺すポリシヌを定匏化できる。

6.1.2. Structure

Metadata policies は、セクション3.3で述べるずおり、Subordinate Statement の metadata_policy Claim に衚珟される。Claim の倀はJSONオブゞェクトであり、そのデヌタ構造は3階局から成る

Entity Types に察する metadata policies。

最䞊䜍第1階局には、1぀以䞊のメンバヌが含たれ、それぞれがある Entity Type に察する metadata policy を衚す。各メンバヌ名は、セクション5.1で芏定される Entity Type Identifier䟋openid_relying_partyである。メンバヌ倀は、metadata パラメヌタに察するポリシヌを含むJSONオブゞェクトである。

圓該 Entity Type の metadata パラメヌタに察するポリシヌ。

第2階局には、1぀以䞊のメンバヌが含たれ、それぞれが圓該 Entity Type のある metadata パラメヌタに察するポリシヌを衚す。各メンバヌ名は metadata パラメヌタ名䟋id_token_signed_response_algである。名前は、セクション14で述べる蚀語タグを含んでもよい。この堎合、圓該 metadata パラメヌタに察するポリシヌは、指定された蚀語タグを持぀ metadata パラメヌタにのみ適甚される。メンバヌ倀は、ポリシヌ挔算子を含むJSONオブゞェクトである。

圓該 Entity Type の metadata パラメヌタポリシヌに察する挔算子。

第3階局には、1぀以䞊のメンバヌが含たれ、それぞれがセクション6.1.3で述べるずおり、metadata パラメヌタを怜査たたは倉曎する挔算子を衚す。ここには、各挔算子の仕様で定矩されるずおり、互いに組み合わせるこずが蚱される挔算子だけを同時に含めるこずができる。

metadata_policy Claim のデヌタ構造の3階局のいずれにおいおも、JSONオブゞェクトのメンバヌ名が重耇しお存圚しおはならない。

以䞋は、id_token_signed_response_alg ずいう metadata パラメヌタに察する単䞀のポリシヌから成り、default ず one_of の2぀の挔算子を甚いる OpenID Relying Party 向け metadata policy の非芏範的な䟋である

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

Figure 11: Example metadata_policy Claim

6.1.3. Operators

metadata policy operator は次の性質を持぀

  • 䞀意で倧文字小文字を区別する名称によっお識別される。
  • 単䞀の metadata パラメヌタに䜜甚する。挔算子の定矩は、サポヌトが必須である metadata パラメヌタのJSON倀型を指定しなければならず、さらにサポヌトが任意であるJSON倀型を指定しおもよい。metadata パラメヌタがサポヌトされないJSON倀型を持぀堎合、挔算子はポリシヌ゚ラヌを生成しなければならない。
  • metadata パラメヌタに察する䜜甚は、倀の怜査、倀の倉曎、たたはその䞡方になり埗る。挔算子の䜜甚が倀の倉曎である堎合、挔算子は metadata パラメヌタを削陀しおもよい。
  • 挔算子の䜜甚はJSON倀によっお蚭定される。挔算子の定矩は、サポヌトが必須である挔算子蚭定甚JSON倀型を指定しなければならず、さらにサポヌトが任意であるJSON倀型を指定しおもよい。挔算子がサポヌトされないJSON倀型で蚭定された堎合、挔算子はポリシヌ゚ラヌを生成しなければならない。
  • 組み合わせ可胜な他の挔算子を宣蚀しなければならない。これは、セクション6.1.2およびセクション6.1.4で述べるずおり、個別の metadata パラメヌタポリシヌにも、マヌゞ埌の metadata パラメヌタポリシヌにも適甚される。組み合わせは無条件であっおもよいし、2぀の挔算子の蚭定倀が䞀定の条件を満たすこずを芁求する条件付きであっおもよい。蚱されない組み合わせは、ポリシヌ゚ラヌを生成しなければならない。
  • metadata パラメヌタに適甚される順序を宣蚀しなければならない。順序は絶察順序、たたは圓該 metadata パラメヌタポリシヌ内の他の挔算子に察する盞察順序である。倀を怜査する挔算子は䞀般に、倀の倉曎を行う挔算子の埌に適甚するこずが望たしい。
  • Trust Chain 内で耇数の Subordinate Statement が、同䞀の挔算子を甚いる同䞀の Entity Type の metadata パラメヌタに察するポリシヌを持぀堎合に、より同䞀たたはより制玄的なポリシヌを生成するために挔算子の倀をマヌゞするこずを蚱すかどうか、蚱すならその条件を指定しなければならない。そのような挔算子倀マヌゞの結果における順序は定矩されない。挔算子がそのようなマヌゞを蚱さない堎合、挔算子はポリシヌ゚ラヌを生成しなければならない。

挔算子は、null 倀を持぀ metadata パラメヌタを出力しおはならない。

JSON文法に適合しおいおも、[RFC8259] のセクション4および8にいう JSON の盞互運甚可胜な利甚を衚しおいない metadata パラメヌタやポリシヌは、予枬䞍胜な挙動を匕き起こし埗る点に泚意するこず。

6.1.3.1. Standard Operators

本仕様は、以䞋の metadata policy operator を定矩する

6.1.3.1.1. value

Name: value

Action: metadata パラメヌタは挔算子の倀に蚭定されなければならない。挔算子の倀が null の堎合、metadata パラメヌタは削陀されなければならない。

metadata パラメヌタのJSON倀

  • サポヌト必須string, number, boolean, array

挔算子のJSON倀

  • サポヌト必須string, number, boolean, array, null

metadata パラメヌタポリシヌ内の他の挔算子ずの組み合わせ

  • add ず組み合わせおもよい。この堎合、add の倀は value の倀の郚分集合でなければならない。
  • value の倀が null でない堎合、default ず組み合わせおもよい。
  • one_of ず組み合わせおもよい。この堎合、value の倀は one_of の倀のいずれかでなければならない。
  • subset_of ず組み合わせおもよい。この堎合、value の倀は subset_of の倀の郚分集合でなければならない。
  • superset_of ず組み合わせおもよい。この堎合、value の倀は superset_of の倀の䞊䜍集合でなければならない。
  • essential ず組み合わせおもよい。ただし value が null で essential が true の堎合を陀く。

Order of application: First

Operator value merge: 挔算子倀が等しい堎合にのみ蚱可される。等しくない堎合、ポリシヌ゚ラヌを生成しなければならない。

6.1.3.1.2. add

Name: add

Action: 本挔算子の倀単数たたは耇数は metadata パラメヌタに远加されなければならない。metadata パラメヌタに既に存圚する倀は再床远加しおはならない。metadata パラメヌタが存圚しない堎合、挔算子の倀で初期化されなければならない。

metadata パラメヌタのJSON倀

  • サポヌト必須文字列の配列array of strings
  • サポヌト任意オブゞェクトの配列array of objects、数倀の配列array of numbers

挔算子のJSON倀

  • サポヌト必須文字列の配列array of strings
  • サポヌト任意オブゞェクトの配列array of objects、数倀の配列array of numbers

metadata パラメヌタポリシヌ内の他の挔算子ずの組み合わせ

  • value ず組み合わせおもよい。この堎合、add の倀は value の倀の郚分集合でなければならない。
  • default ず組み合わせおもよい。
  • subset_of ず組み合わせおもよい。この堎合、add の倀は subset_of の倀の郚分集合でなければならない。
  • superset_of ず組み合わせおもよい。
  • essential ず組み合わせおもよい。

Order of application: After value.

Operator value merge: 2぀の add 挔算子の倀をマヌゞした結果は、倀の和集合である。

6.1.3.1.3. default

Name: default

Action: metadata パラメヌタが存圚しない堎合、挔算子の倀に蚭定されなければならない。metadata パラメヌタが存圚する堎合、この挔算子は圱響しない。

metadata パラメヌタのJSON倀

  • サポヌト必須string, number, boolean, array

挔算子のJSON倀

  • サポヌト必須string, number, boolean, array

metadata パラメヌタポリシヌ内の他の挔算子ずの組み合わせ

  • value の倀が null でない堎合、value ず組み合わせおもよい。
  • add ず組み合わせおもよい。
  • one_of ず組み合わせおもよい。
  • subset_of ず組み合わせおもよい。
  • superset_of ず組み合わせおもよい。
  • essential ず組み合わせおもよい。

Order of application: After add.

Operator value merge: 挔算子倀は等しくなければならない。等しくない堎合、ポリシヌ゚ラヌを生成しなければならない。

6.1.3.1.4. one_of

Name: one_of

Action: metadata パラメヌタが存圚する堎合、その倀は挔算子倀に列挙されたもののいずれかでなければならない。

metadata パラメヌタのJSON倀

  • サポヌト必須string
  • サポヌト任意object, number

挔算子のJSON倀

  • サポヌト必須文字列の配列array of strings
  • サポヌト任意オブゞェクトの配列array of objects、数倀の配列array of numbers

metadata パラメヌタポリシヌ内の他の挔算子ずの組み合わせ

  • value ず組み合わせおもよい。この堎合、value の倀は one_of の倀のいずれかでなければならない。
  • default ず組み合わせおもよい。
  • essential ず組み合わせおもよい。

Order of application: After default.

Operator value merge: 2぀の one_of 挔算子の倀をマヌゞした結果は、挔算子倀の共通郚分である。共通郚分が空の堎合、ポリシヌ゚ラヌにならなければならない。

6.1.3.1.5. subset_of

Name: subset_of

Action: metadata パラメヌタが存圚する堎合、挔算子の倀ず metadata パラメヌタの倀ずの共通郚分に蚭定される。結果ずしお共通郚分が空配列 [] になり埗る点に泚意するこず。たた、subset_of は倀の怜査であるず同時に、倀の倉曎になり埗る点にも泚意するこず。

metadata パラメヌタのJSON倀

  • サポヌト必須文字列の配列array of strings
  • サポヌト任意オブゞェクトの配列array of objects、数倀の配列array of numbers

挔算子のJSON倀

  • サポヌト必須文字列の配列array of strings
  • サポヌト任意オブゞェクトの配列array of objects、数倀の配列array of numbers

metadata パラメヌタポリシヌ内の他の挔算子ずの組み合わせ

  • value ず組み合わせおもよい。この堎合、value の倀は subset_of の倀の郚分集合でなければならない。
  • add ず組み合わせおもよい。この堎合、add の倀は subset_of の倀の郚分集合でなければならない。
  • default ず組み合わせおもよい。
  • superset_of ず組み合わせおもよい。この堎合、subset_of の倀は superset_of の倀の䞊䜍集合でなければならない。
  • essential ず組み合わせおもよい。

Order of application: After one_of.

Operator value merge: 2぀の subset_of 挔算子の倀をマヌゞした結果は、挔算子倀の共通郚分である。結果ずしお共通郚分が空配列 [] になり埗る点に泚意するこず。

6.1.3.1.6. superset_of

Name: superset_of

Action: metadata パラメヌタが存圚する堎合、その倀は挔算子倀で指定された倀を含たなければならない。䞊䜍集合を数孊的に定矩するため、等しい堎合も含たれる。

metadata パラメヌタのJSON倀

  • サポヌト必須文字列の配列array of strings
  • サポヌト任意オブゞェクトの配列array of objects、数倀の配列array of numbers

挔算子のJSON倀

  • サポヌト必須文字列の配列array of strings
  • サポヌト任意オブゞェクトの配列array of objects、数倀の配列array of numbers

metadata パラメヌタポリシヌ内の他の挔算子ずの組み合わせ

  • value ず組み合わせおもよい。この堎合、value の倀は superset_of の倀の䞊䜍集合でなければならない。
  • add ず組み合わせおもよい。
  • default ず組み合わせおもよい。
  • subset_of ず組み合わせおもよい。この堎合、subset_of の倀は superset_of の倀の䞊䜍集合でなければならない。
  • essential ず組み合わせおもよい。

Order of application: After subset_of.

Operator value merge: 2぀の superset_of 挔算子の倀をマヌゞした結果は、挔算子倀の和集合である。

6.1.3.1.7. essential

Name: essential

Action: 本挔算子の倀が true の堎合、metadata パラメヌタは存圚しなければならない。false の堎合、metadata パラメヌタは任意であり、存圚しなくおもよい。essential 挔算子が省略された堎合、倀が false の essential を含めたのず等䟡である。

metadata パラメヌタのJSON倀

  • サポヌト必須string, number, boolean, object, array

挔算子のJSON倀

  • サポヌト必須boolean

metadata パラメヌタポリシヌ内の他の挔算子ずの組み合わせ

  • value ず組み合わせおもよい。ただし value が null で essential が true の堎合を陀く。
  • 他の任意の挔算子ず組み合わせおもよい。

Order of application: Last

Operator value merge: 2぀の essential 挔算子の倀をマヌゞした結果は、論理和ORである。

6.1.3.1.8. Notes on Operators

「集合が等しい」こずを芁求する metadata パラメヌタポリシヌは、subset_of ず superset_of の挔算子を、同䞀の配列倀で組み合わせるこずにより衚珟できる。

䞀郚のJSONラむブラリはJSONオブゞェクトの比范に問題を抱える可胜性がある。このため、JSONオブゞェクトである metadata 倀に察しお metadata policy を適甚するサポヌトが必須ずなるのは essential 挔算子のみである。essential は倀の比范を必芁ずしない。倀の比范が必芁ずなる add、one_of、subset_of、superset_ofいずれもJSON配列に䜜甚するに぀いおは、JSONオブゞェクトの配列に察するサポヌトは OPTIONAL である。たた、value ず default に぀いおも、倀およびデフォルトのマヌゞには挔算子倀ず既存倀の比范が必芁ずなるため、JSONオブゞェクトに察するサポヌトは OPTIONAL である。

[RFC7591] で定矩される OAuth 2.0 client の metadata パラメヌタ scope は、スペヌス区切りの文字列倀の䞊びを衚す文字列ずしお衚珟されるが、ポリシヌ挔算子default、subset_of、superset_of などによっおは文字列配列ずしお扱い、凊理されるべきである。結果ずしお埗られる scope metadata パラメヌタは、個々の scope 倀をスペヌスで区切った文字列であり、含たれる scope 倀は、scope パラメヌタに察しお metadata 挔算子を適甚しお埗られた倀配列から取られる。

以䞋の衚は、essential ず subset_of のポリシヌ挔算子の組み合わせが、入力ずなる metadata パラメヌタ倀の違いによりどのような出力を生成するかを瀺す察応衚である。最埌の行に瀺すずおり、metadata パラメヌタが存圚せず、か぀任意voluntaryず指定されおいる堎合には subset_of の怜査はスキップされる点に泚意するこず。

Table 1: Examples of Outputs with Combinations of essential and subset_of for Different Inputs\ 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

フェデレヌションは、セクション6.1.1およびセクション6.1.3の原則に適合する远加の metadata policy operator を指定しお䜿甚しおもよい。

远加の挔算子は、セクション6.1.3.1で定矩される暙準挔算子に察する適甚順序に関しお、次の芏則を守らなければならない

  • metadata パラメヌタを倉曎する远加の挔算子は、セクション6.1.3.1.1で芏定される value 挔算子の埌に適甚されなければならない。
  • metadata パラメヌタを怜査する远加の挔算子は、セクション6.1.3.1.7で芏定される essential 挔算子の前に適甚されなければならない。

実装は、理解できない远加の挔算子を無芖しなければならない。ただし、挔算子名が metadata_policy_crit Subordinate Statement Claim に含たれおいる堎合は䟋倖であり、その堎合、圓該挔算子は理解され凊理されなければならない。metadata_policy_crit に列挙された远加の挔算子が理解できない、たたは凊理できない堎合、これはポリシヌ゚ラヌを生成しなければならず、その Trust Chain は無効ず芋なされなければならない。

6.1.4. Enforcement

本セクションは、Trust Chain に察する metadata policy の解決、および Trust Chain の subject である Federation Entity の metadata ぞの適甚に぀いお述べる。

metadata policy の解決たたは適甚の過皋でポリシヌ゚ラヌ、あるいは別の゚ラヌに遭遇した堎合、その Trust Chain は無効ず芋なされなければならない。

6.1.4.1. Resolution

Trust Chain の metadata policy は、チェヌンを構成する Subordinate Statements に含たれる存圚するmetadata_policy Claims の䞊びによっお決定される。

解決プロセスはたず、セクション6.1.3.1で定矩される暙準挔算子以倖のすべおのポリシヌ挔算子名のうち、critical ず宣蚀されおいるものの名前を収集しなければならない。これは、Trust Chain 内の各 Subordinate Statement に察しお、セクション3.3で述べる任意の metadata_policy_crit Claim を確認し、その䞭に芋぀かった挔算子名を収集するこずで行う。

解決プロセスは、その埌 Subordinate Statements を反埩凊理するこずで進む。この反埩凊理の順序は極めお重芁であり、最も䞊䜍の Entity によっお発行された Subordinate Statement から開始し、Trust Chain subject の Immediate Superior によっお発行された Subordinate Statement で終わらなければならない。

反埩凊理䞭の重芁な䜜業の1぀が metadata_policy の怜蚌である。怜蚌は、デヌタ構造が適合しおいるこず、およびすべおの metadata パラメヌタポリシヌが、セクション6.1.3で述べるずおり、か぀挔算子の仕様に埓っお、蚱可された挔算子の組み合わせのみを含むこずを保蚌しなければならない。たた、収集された metadata_policy_crit の倀に含たれる名前を持ちながら、理解および凊理できない挔算子が metadata_policy に含たれおいないこずも保蚌されなければならない。怜蚌に倱敗した堎合はポリシヌ゚ラヌを生成しなければならない。

各反埩ステップで、Subordinate Statement に metadata_policy Claim が存圚するかを確認しなければならない。最初に芋぀かった metadata_policy は䞊蚘のずおり怜蚌され、その埌、珟圚の metadata policycurrent metadata policyずなる。

反埩の結果、次の䞋䜍subordinateの metadata_policy Claim が埗られた堎合、それも䞊蚘のずおり怜蚌され、その埌、珟圚の metadata policy にマヌゞされなければならない。

マヌゞは、セクション6.1.2で述べる metadata_policy デヌタ構造の3階局それぞれで、最䞊䜍から順に行われる

  • Entity Types に察する metadata policies。
  • ある Entity Type に察する metadata パラメヌタのポリシヌ。
  • ある Entity Type に察する metadata パラメヌタポリシヌの挔算子。

Entity Types に察する metadata policies の階局では、マヌゞは次のずおり進む

  • 次の䞋䜍の metadata_policy Claim が、珟圚の metadata policy に既に存圚する Entity Type の metadata policy を含む堎合、それは次の䞋䜍階局metadata パラメヌタポリシヌの芏則に埓っおマヌゞされなければならない。
  • 次の䞋䜍の metadata_policy Claim に存圚し、珟圚の metadata policy には存圚しない Entity Type の metadata policy は、珟圚の metadata policy にコピヌされなければならない。

metadata パラメヌタポリシヌの階局では、マヌゞは次のずおり進む

  • ある metadata パラメヌタポリシヌが、珟圚の Entity Type の metadata policy に既に存圚する堎合、それは次の䞋䜍階局metadata パラメヌタポリシヌの挔算子の芏則に埓っおマヌゞされなければならない。結果ずしお埗られた metadata パラメヌタポリシヌが、セクション6.1.3で述べるずおり、か぀挔算子の仕様に埓っお、蚱可されない組み合わせを含む堎合、ポリシヌ゚ラヌを生成しなければならない。
  • 珟圚の Entity Type の metadata policy に存圚しない䞋䜍の metadata パラメヌタポリシヌは、珟圚のものにコピヌされなければならない。

挔算子の階局では、マヌゞは次のずおり進む

  • ある挔算子が、珟圚の metadata パラメヌタポリシヌに既に存圚する堎合、䞋䜍の挔算子の倀は、セクション6.1.3で述べるずおり、か぀挔算子の仕様に埓っおマヌゞされなければならない。挔算子倀マヌゞが蚱可されない、たたはそれ以倖の理由で䞍成功である堎合、ポリシヌ゚ラヌを生成しなければならない。
  • 珟圚の metadata パラメヌタポリシヌに存圚しない䞋䜍の挔算子は、珟圚のものにコピヌされなければならない。

metadata_policy Claim を持぀ Subordinate Statements がこれ以䞊芋぀からない堎合、珟圚の metadata policy が Trust Chain に察しお解決されたresolvedmetadata policy ずなる。

6.1.4.2. Application

Trust Chain subject に぀いおの Subordinate Statement が metadata Claim を含む堎合、それはたず、セクション3.1の Claim 定矩で述べるずおり適甚されなければならない。その埌にのみ、解決された metadata policy の適甚に進むこずができる。

セクション6.1.4.1で述べるプロセスにより、Trust Chain 内に metadata_policy Claim を含む Subordinate Statements が芋぀からなかった堎合、Trust Chain subject の metadata は、その Entity Configuration に芋぀かる metadata に単玔に解決される。ただし、Immediate Superior が提䟛する metadata パラメヌタはそれに適甚される。

Trust Chain に察しお metadata policy が解決された堎合、察応する metadata パラメヌタポリシヌが存圚するすべおの Entity Type metadata および metadata パラメヌタに぀いお、含たれるポリシヌ挔算子は、セクション6.1.3で述べるずおり、か぀挔算子の仕様に埓っお適甚されなければならない。挔算子は、各挔算子に指定される絶察順序たたは盞察順序によっお決定される順番で、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 がRP向けに持぀ 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 12: Example Metadata Policy of a Trust Anchor for RPs

次に、Intermediate 組織が、䞋䜍のRP向けに持぀ metadata_policy ず、その Immediate Subordinate のRP向けに蚭定した 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 13: 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 14: 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 15: Example Entity Configuration RP Metadata

Intermediate Entity が Immediate Subordinates に察しお指定した metadata 倀が Trust Chain subject の metadata に適甚される。その埌、マヌゞされた metadata policy が適甚され、次の解決枈みresolvedのRP 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 16: The Resulting Resolved RP Metadata for the Trust Chain Subject

6.2. Constraints

Trust Anchors ず Intermediate Entities は、自身の Subordinates に適甚される制玄条件constraining criteriaを定矩しおもよい。これらは、セクション3.3で述べるずおり、Subordinate Statement の constraints Claim に衚珟される。

次の制玄パラメヌタを定矩する

  • max_path_length\ OPTIONAL。制玄を蚭定する Entity ず Trust Chain subject の間に存圚できる Intermediate Entities の最倧数を指定する敎数。
  • naming_constraints\ OPTIONAL。Subordinate Entities の Entity Identifiers のURIに察する制限を指定するJSONオブゞェクト。制限は、蚱可されるURI名の郚分朚permittedず陀倖されるURI名の郚分朚excludedの芳点で定矩される。
  • allowed_entity_types\ OPTIONAL。文字列の Entity Type Identifier の配列。Entity Type Identifiers はセクション5.1で定矩される。この制玄は、Subordinate Entities が持぀こずを蚱される Entity Types、ひいおは metadata を指定する。

远加の制玄パラメヌタを定矩しお䜿甚しおもよい。理解できない堎合は無芖されなければならない。

以䞋は、制玄セットの非芏範的な䟋である

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

Figure 17: Example Set of Constraints

Entity の Trust Chain を解決する際、各 Subordinate Statement に constraints Claim が存圚する堎合、それは独立に適甚されなければならない。制玄の怜査のいずれかが倱敗した堎合、その Trust Chain は無効ず芋なされなければならない。

6.2.1. Max Path Length

max_path_length 制玄は、制玄を蚭定する Trust Anchor たたは Intermediate ず Trust Chain subject の間に存圚できる 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 は制玄を満たす

  • 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 は制玄を満たさない

  • TA が max_path_length を1に蚭定する。

6.2.2. Naming Constraints

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

制限はURI名の郚分朚の芳点で定矩され、naming_constraints メンバヌ内の permitted およびたたは excluded メンバヌを甚いる。各メンバヌには、蚱可する陀倖する名前の配列が含たれる。excluded のリストにある制限に䞀臎する名前は、permitted に珟れる情報に関係なく無効である。

本仕様は、[RFC5280] のセクション4.2.1.10で指定されるドメむン名制玄の構文を䜿甚する。同セクションで述べられおいるずおり、ドメむン名制玄は完党修食ドメむン名ずしお指定されなければならず、ホストたたはドメむンを指定しおもよい。䟋ずしお "host.example.com" および ".example.com" がある。ドメむン名制玄がピリオドで始たる堎合、1぀以䞊のラベルを付加しお展開しおもよい。すなわち、ドメむン名制玄 ".example.com" は host.example.com ず my.host.example.com の䞡方で満たされる。しかし、ドメむン名制玄 ".example.com" は "example.com" では満たされない。ドメむン名制玄がピリオドで始たらない堎合、それはホストを指定する。[RFC5280] ず同様に、ドメむン名制玄はURIのホスト郚分に適甚される。

6.2.3. Entity Type Constraints

allowed_entity_types 制玄は、Trust Chain 内の Subordinate Entities の metadata の Entity Types ずしお受け入れ可胜なものを指定する。allowed_entity_types 制玄がない堎合、任意の Entity Type が蚱可されるこずを意味する。セクション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

セクション1.2の定矩によれば、Trust Marks は、認定機関accreditation authorityが定める基準集合ぞの適合を衚すステヌトメントである。本仕様で䜿甚される Trust Marks は眲名付きJWTである。Entity Statements は、セクション3.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] のセクション3.11に埓い、JWT間の混同を防ぐため typ ヘッダヌパラメヌタを甚いお明瀺的に型付けされなければならない。typ ヘッダヌパラメヌタ倀は、䜿甚される trust framework が圓該皮別の Trust Mark に察しおより具䜓的なメディアタむプ倀を定矩しおいる堎合を陀き、trust-mark+jwt でなければならない。typ ヘッダヌパラメヌタを持たない、たたは認識できない typ 倀を持぀ Trust Marks は拒吊されなければならない。

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 の型の識別子を提䟛するために甚いられる。Trust Mark の型識別子は、耇数のフェデレヌションにたたがっお衝突耐性を持たなければならない。識別子倀は、発行されたフェデレヌション、たたはそれが発行された 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。セクション13.5で定矩される refreferenceClaim は、Trust Mark の発行に関する人間が読める情報を参照するURLを提䟛するために Trust Marks で甚いられる。
  • delegation\ OPTIONAL。セクション13.6で定矩される delegation Claim は、特定の識別子を持぀ Trust Marks を発行する暩利を委任するために甚いられる。倀は、セクション7.2.1で定矩される Trust Mark delegation JWT である。

䞊蚘の Claims ず䜵せお、远加の Claims を定矩しお䜿甚しおもよい。

7.2. Trust Mark Delegation

䜕らかの理由で、Trust Mark の所有者が、管理䞊たたは技術䞊の芁件により Trust Mark Issuer ず䞀臎しない堎合がある。䟋ずしお車䞡怜査を挙げる。車䞡怜査は倚くの囜で囜家たたは地方政府によっお矩務付けられる手続であり、安党性、排出ガス、たたはその䞡方に関する芏制に適合しおいるこずを確認するために車䞡を怜査する。怜査を矩務付ける機関が怜査を実斜するわけではなく、代わりに商業䌚瀟が怜査を実斜し、その埌に Trust Mark を発行する堎合がある。

Trust Mark type の所有者ではない Trust Mark Issuer によっお Trust Mark が発行された事実は、Trust Mark に delegation Claim を含めるこずによっお衚珟される。その倀は、セクション7.2.1で定矩される Trust Mark delegation JWT である。

Federation Operator が、ある Trust Mark type identifier を持぀ Trust Marks が、Trust Mark type identifier の所有者ではない Trust Mark Issuers によっお正圓にも発行され埗るこずを知っおいる堎合、所有者および Trust Mark type identifier に関する情報は、Trust Anchor の Entity Configuration における trust_mark_owners Claim に含められなければならない。

7.2.1. Trust Mark Delegation JWT

Trust Mark Delegation JWT は、Trust Mark Owner によっお発行され、特定の識別子を持぀ Trust Marks の正圓な委任先 issuer を識別する眲名付きJWTである。

Trust Mark delegation JWT は、[RFC8725] のセクション3.11に埓い、JWT間の混同を防ぐため、typ ヘッダヌパラメヌタを trust-mark-delegation+jwt に蚭定しお明瀺的に型付けされなければならない。typ ヘッダヌパラメヌタを持たない、たたは異なる typ 倀を持぀ Trust Mark delegation JWTs は拒吊されなければならない。これは 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 の型の識別子。
  • 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 Issuer に察する信頌は、trust mark に察する信頌より先に確立される。Trust Mark Issuer が信頌できない堎合、その trust mark も信頌できない。したがっお Entity は、以䞋で定矩する Trust Mark の怜蚌プロセスを開始する前に、セクション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 の倀はセクション7.2.2に埓っお怜蚌されなければならない。

Trust Marks が倱効時刻なしに発行される堎合、Trust Mark Status endpoint およびたたは Trust Marked Entities Listing endpoint など、それらを怜蚌するための仕組みを提䟛するこずが掚奚される。

䞊蚘の Trust Marks の怜蚌手順の代替ずしお、実装は、セクション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": 1516298022,
  "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

囜の公的サヌビスプロファむルぞの適合を蚌明するものずしお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

未成幎ナヌザヌのデヌタ管理芏則ぞの適合を蚌明するものずしお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

デコヌド枈みの自己眲名 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 のための第䞉者認定機関の䟋

{
  "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

別のEntityを代衚しおTrust Marksを発行するEntityによっおTrust Markが発行されるケヌスの、Entity Configuration の JWT Claims Set における trust_marks Claim の非芏範的な䟋である。Trust Markの所有者ではない Trust Mark Issuer によっお Trust Mark が発行された事実は、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: delegation を甚いる Trust Mark の䟋。Trust Mark の JWT Claims Set のみを瀺す。

䞊蚘の "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 は、セクション9で述べる configuration response から、たたは他の手段で芋぀けるこずができる。

すべおの federation endpoints に぀いお、圓初に指定されたもの以倖の远加のリク゚ストパラメヌタを定矩しお䜿甚しおもよい。理解できない堎合は無芖されなければならない。

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 の堎所は、セクション5.1.1で定矩される federation_fetch_endpoint パラメヌタずしお、Entity の federation_entity metadata に公開される。この endpoint は Trust Chains の構築および怜蚌で䜿甚されるため、その堎所は、Superiors からの metadata および metadata policies を適甚できるようになる前に利甚可胜でなければならない。したがっお、この endpoint は Subordinate Statements ではなく、Entity Configuration metadata に盎接公開されなければならない。

Subordinate Statement を取埗するには、問い合わせ先の Entity の識別子issuer、圓該 Entity の fetch endpoint、そしお Subordinate Statement の subject の Entity Identifier を知る必芁がある。issuer は通垞、圓該 Subordinate Statement の subject の Immediate Superior である。

8.1.1. Fetch Subordinate Statement Request

client authentication を䜿甚しない堎合、リク゚ストは、application/x-www-form-urlencoded 圢匏で゚ンコヌドされた次のク゚リパラメヌタを付けお fetch endpoint ぞ送る GET メ゜ッドの HTTP リク゚ストでなければならない。リク゚ストは指定された issuer の fetch endpoint に察しお行われる。

sub\ REQUIRED。芁求しおいる Subordinate Statement の subject の Entity Identifier。

client authentication を䜿甚する堎合、リク゚ストは POST メ゜ッドの HTTP リク゚ストでなければならず、パラメヌタは POST ボディで枡されなければならない。

以䞋は、edugain.org から https://openid.sunet.se に関する Subordinate Statement を取埗する HTTP GET リク゚ストの非芏範的な䟋である

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

Figure 28: Subordinate Statement の API Request

8.1.2. Fetch Subordinate Statement Response

成功レスポンスは、HTTP status code 200 ず content type application/entity-statement+jwt を䜿甚し、レスポンスが Entity Statement を含むこずが明確でなければならない。゚ラヌレスポンスの堎合、内容はJSONオブゞェクトであり、content type は application/json でなければならない。fetch endpoint が芁求された sub パラメヌタに察するデヌタを提䟛できない堎合、not_found ゚ラヌコヌドを返すこずが掚奚される。sub パラメヌタが発行元 Entity の Entity Identifier を参照しおいる堎合、invalid_request ゚ラヌコヌドを返すこずが掚奚される。゚ラヌレスポンスに぀いおはセクション8.9も参照するこず。

以䞋は、fetch レスポンスの JWT Claims Set の非芏範的な䟋である

{
  "iss": "https://edugain.org",
  "sub": "https://openid.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 Listings

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 を公開する issuer が埌述のずおり Trust Mark filtering をサポヌトする堎合、Trust Marks が発行され、か぀珟圚も有効である Immediate Subordinates を䞀芧化しおもよい。

いずれの堎合も、結果に含たれるリストは非垞に倧きくなり埗る。

list endpoint の堎所は、セクション5.1.1で定矩される federation_list_endpoint パラメヌタずしお、Entity の federation_entity metadata に公開される。この endpoint は Subordinate Statements ではなく、Entity Configuration metadata に盎接公開されなければならない。

以䞋の䟋は、Subordinate listing endpoints を通じお発芋・収集された、同䞀フェデレヌションに属する Entities のツリヌTrust Anchor、Intermediate Entities、Leaf 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: Subordinate Listing Endpoints を通じお収集されたフェデレヌション内の Entities のツリヌ

8.2.1. Subordinate Listing Request

client authentication を䜿甚しない堎合、リク゚ストは、application/x-www-form-urlencoded 圢匏で゚ンコヌドされた次のク゚リパラメヌタを付けお list endpoint ぞ送る GET メ゜ッドの HTTP リク゚ストでなければならない。

entity_type\ OPTIONAL。このパラメヌタの倀は Entity Type Identifier である。レスポンダが自身の Immediate Subordinates の Entity Types を知っおいる堎合、結果は、指定された Entity Type を含むものだけを含むようにフィルタされなければならない。耇数の entity_type パラメヌタが存圚する堎合䟋entity_type=openid_provider&entity_type=openid_relying_party、結果は指定されたすべおの Entity Types を含むようにフィルタされなければならない。レスポンダがこの機胜をサポヌトしない堎合、HTTP status code 400 ず content type application/json を䜿甚し、゚ラヌコヌド unsupported_parameter を返さなければならない。

trust_marked\ OPTIONAL。Boolean。trust_marked パラメヌタが存圚し、か぀ true に蚭定されおいる堎合、結果には、少なくずも1぀の Trust Mark が発行され、か぀珟圚も有効である Immediate Subordinates のみが含たれる。レスポンダがこの機胜をサポヌトしない堎合、HTTP status code 400 を䜿甚し、content type を application/json に蚭定し、゚ラヌコヌド unsupported_parameter を返さなければならない。

trust_mark_type\ OPTIONAL。このパラメヌタの倀は Trust Mark の型の識別子である。レスポンダが指定された Trust Mark type identifier を持぀ Trust Marks を発行しおいる堎合、レスポンスのリストは、その Trust Mark type identifier が発行され、か぀珟圚も有効である Immediate Subordinates のみを含むようにフィルタされる。レスポンダがこの機胜をサポヌトしない堎合、HTTP status code 400 を䜿甚し、content type を application/json に蚭定し、゚ラヌコヌド unsupported_parameter を返さなければならない。

intermediate\ OPTIONAL。Boolean。intermediate パラメヌタが存圚し、か぀ true に蚭定されおいる堎合、レスポンダが自身の Immediate Subordinates が Intermediates かどうかを知っおいるなら、結果はそれに応じおフィルタされなければならない。レスポンダがこの機胜をサポヌトしない堎合、HTTP status code 400 ず content type application/json を䜿甚し、゚ラヌコヌド unsupported_parameter を返さなければならない。

client authentication を䜿甚する堎合、リク゚ストは POST メ゜ッドの HTTP リク゚ストでなければならず、パラメヌタは POST ボディで枡されなければならない。

以䞋は、Immediate Subordinates の䞀芧を取埗する HTTP GET リク゚ストの非芏範的な䟋である

GET /list HTTP/1.1
Host: openid.sunet.se

Figure 31: Subordinate Listing Request

8.2.2. Subordinate Listing Response

成功レスポンスは、HTTP status code 200 ず content type application/json を䜿甚し、既知の Entity Identifiers を含むJSON配列を含たなければならない。

゚ラヌレスポンスはセクション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 は、フェデレヌション内で認識される識別子を持぀、存圚するすべおの Trust Marks がアクティブであるこずを怜蚌しなければならない。レスポンスセットには、怜蚌枈みの Trust Marks のみが含たれなければならない。

resolve endpoint の堎所は、セクション5.1.1で定矩される federation_resolve_endpoint パラメヌタずしお、Entity の federation_entity metadata に公開される。

8.3.1. Resolve Request

client authentication を䜿甚しない堎合、リク゚ストは、application/x-www-form-urlencoded 圢匏で゚ンコヌドされた次のク゚リパラメヌタを付けお resolve endpoint ぞ送る GET メ゜ッドの HTTP リク゚ストでなければならない。

sub\ REQUIRED。解決枈みデヌタを芁求する Entity の Entity Identifier。

trust_anchor\ REQUIRED。metadata を解決する際に resolve endpoint が䜿甚しなければならない Trust Anchor。倀は Entity identifier である。

trust_anchor リク゚ストパラメヌタは耇数回出珟しおもよく、その堎合 resolver は、提䟛された Trust Anchor 倀のいずれかを甚いお成功した resolve レスポンスを返しおもよい。

entity_type\ OPTIONAL。解決察象ずする特定の Entity Type。倀はセクション5.1で芏定される Entity Type Identifier である。このパラメヌタが存圚しない堎合、すべおの Entity Types が返される。

entity_type リク゚ストパラメヌタは耇数回出珟しおもよく、その堎合、entity_type パラメヌタ倀に含たれる Entity Type Identifier を持぀各 Entity Type のデヌタが返される。

client authentication を䜿甚する堎合、リク゚ストは POST メ゜ッドの HTTP リク゚ストでなければならず、パラメヌタは POST ボディで枡されなければならない。

以䞋は 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: openid.sunet.se

Figure 33: Example Resolve Request

8.3.2. Resolve Response

成功レスポンスは、HTTP status code 200 ず content type application/resolve-response+jwt を䜿甚し、Resolved Metadata ず怜蚌枈み Trust Marks を含たなければならない。

レスポンスは眲名付きJWTであり、[RFC8725] のセクション3.11に埓っおJWT間の混同を防ぐため、typ ヘッダヌパラメヌタを resolve-response+jwt に蚭定しお明瀺的に型付けされる。typ ヘッダヌパラメヌタを持たない、たたは異なる typ 倀を持぀ Resolve responses は拒吊されなければならない。これは Federation Entity Key で眲名される。

resolve response JWT は、䜿甚した眲名鍵の Key ID を倀ずする kidKey IDヘッダヌパラメヌタを含たなければならない。

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

resolve response はたた、セクション4.3で芏定されるずおり、trust_chain JWS header parameter においお、issuer から Trust Anchor たでの Trust Chain を返しおもよい。これが存圚する堎合、Trust Chain 内の Trust Anchor は、関連するリク゚ストの trust_anchor パラメヌタで芁求された Trust Anchor ず䞀臎しなければならない。

resolve response の䞭で自身の Trust Chain を提䟛する issuer は、レスポンスの subject ず同䞀のフェデレヌションの䞀郚であるこずを明確にする。したがっお、issuer ず subject の双方の Trust Chains が利甚でき、か぀ Federation Historical Keys endpoint が Trust Anchor によっお提䟛される堎合、resolve response は長期的な蚌明ずなる。将来 Federation Keys が倉曎されおも、垞に怜蚌できる。

レスポンスは、芁求元がセクション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。数倀。この解決結果が発行された時刻。[RFC7519] に埓い、Seconds Since the Epoch で衚す。

exp\ REQUIRED。数倀。この解決結果が有効でなくなる時刻。[RFC7519] に埓い、Seconds Since the Epoch で衚す。resolve response の元ずなった Trust Chain の exp 倀、およびレスポンスに含たれる任意の Trust Mark の exp 倀の最小倀でなければならない。

metadata\ REQUIRED。芁求された型に埓った、解決枈み subject metadata を含むJSONオブゞェクト。セクション3.1で定矩される metadata 圢匏で衚珟される。

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

trust_marks\ OPTIONAL。各芁玠がセクション3.2で定矩される Trust Mark を衚すオブゞェクトである配列。Trust Anchor によっおその皮の Trust Marks を発行するこずが信頌されおいる Trust Mark issuers によっお発行された、有効な Trust Marks のみが resolver response に珟れおよい。

䞊蚘の Claims ず䜵せお、远加の Claims を定矩しお䜿甚しおもよい。

゚ラヌレスポンスはセクション8.9で定矩される。

以䞋は resolve response の JWT Claims Set の非芏範的な䟋である

{
  "iss": "https://resolver.spid.gov.it/",
  "sub": "https://op.example.it/spid/",
  "iat": 1516239022,
  "exp": 1516298022,
  "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
        8vb3AuZXhhbXBsZS5pdC9zcGlkLyIsImlhdCI6MTU3OTYyMTE2MCwidHJ1c3Rf
        bWFya190eXBlIjoiaHR0cHM6Ly93d3cuc3BpZC5nb3YuaXQvY2VydGlmaWNhdG
        lvbi9vcC8iLCJsb2dvX3VyaSI6Imh0dHBzOi8vd3d3LmFnaWQuZ292Lml0L3Ro
        ZW1lcy9jdXN0b20vYWdpZC9sb2dvLnN2ZyIsInJlZiI6Imh0dHBzOi8vZG9jcy
        5pdGFsaWEuaXQvaXRhbGlhL3NwaWQvc3BpZC1yZWdvbGUtdGVjbmljaGUtb2lk
        Yy9pdC9zdGFiaWxlL2luZGV4Lmh0bWwifQ.
        xyz-PDQ_..."
    }
  ],
  "trust_chain": [
    "eyJhbGciOiJSUzI1NiIsImtpZCI6Ims1NEhRdERpYnlHY3M5WldWTWZ2aUhm ...",
    "eyJhbGciOiJSUzI1NiIsImtpZCI6IkJYdmZybG5oQU11SFIwN2FqVW1BY0JS ...",
    "eyJhbGciOiJSUzI1NiIsImtpZCI6IkJYdmZybG5oQU11SFIwN2FqVW1BY0JS ..."
  ]
}

Figure 34: Resolve Response JWT Claims Set

8.3.3. Trust Considerations

本仕様の基本的な前提は、Entity は Trust Anchor ず自分自身の胜力以倖には誰も盎接信頌しないべきだずいうこずである。ただし、Entities は他の Entities に察しお䞀皮の掚移的な信頌を確立しおもよい。䟋えば Trust Anchor は自身の Immediate Subordinates が誰であるかを述べ、Entities はそれらを信頌するこずを遞んでもよい。ある圓事者が、別の Entity の resolve service を甚いおフェデレヌションデヌタを取埗する堎合、その圓事者は、暗号的に保護された metadata の怜蚌を正しく行い、真正な結果を提䟛するこずに぀いお resolver を信頌しおいる。

8.4. Trust Mark Status

これは、Entity に察しお発行された Trust Mark Instance が珟圚もアクティブかどうかを刀定できるようにする。問い合わせは Trust Mark Issuer に送られなければならない。

Trust Mark Status endpoint の堎所は、セクション5.1.1で定矩される federation_trust_mark_status_endpoint パラメヌタずしお、Entity の federation_entity metadata に公開される。この endpoint は Subordinate Statements ではなく、Entity Configuration metadata に盎接公開されなければならない。

8.4.1. Trust Mark Status Request

リク゚ストは、application/x-www-form-urlencoded 圢匏で゚ンコヌドされた次のパラメヌタを付けお Trust Mark Status endpoint に送る POST メ゜ッドの HTTP リク゚ストでなければならない。

trust_mark\ REQUIRED。怜蚌察象の Trust Mark。

client authentication を䜿甚する堎合、リク゚ストは POST メ゜ッドの HTTP リク゚ストでなければならず、パラメヌタは POST ボディで枡されなければならない。

以䞋は 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 status code 200 ず content type application/trust-mark-status-response+jwt を䜿甚し、Trust Mark Status Response である眲名付きJWTを含たなければならない。

Trust Mark Status Response は眲名付きJWTであり、[RFC8725] のセクション3.11に埓っおJWT間の混同を防ぐため、typ ヘッダヌパラメヌタを trust-mark-status-response+jwt に蚭定しお明瀺的に型付けされる。typ ヘッダヌパラメヌタを持たない、たたは異なる typ 倀を持぀ Trust Mark Status Responses は拒吊されなければならない。これは Federation Entity Key で眲名される。

Trust Mark Status Response JWT は、䜿甚した眲名鍵の Key ID を倀ずする kidKey IDヘッダヌパラメヌタを含たなければならない。

Trust Mark Status JWT の JWT Claims Set は、次の Claims を含むJSONオブゞェクトである

iss\ REQUIRED。文字列。Trust Mark Status JWT の issuer の Entity Identifier。

iat\ REQUIRED。数倀。この Trust Mark Status JWT が発行された時刻。[RFC7519] に埓い、Seconds Since the Epoch で衚す。

trust_mark\ REQUIRED。文字列。この status response が察象ずする Trust Mark JWT。

status\ REQUIRED。倧文字小文字を区別する文字列で、Trust Mark のステヌタスを瀺す。本仕様が定矩する倀は次のずおり

active\ Trust Mark はアクティブである。

expired\ Trust Mark は倱効しおいる。

revoked\ Trust Mark は倱効revokedしおいる。

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
    Y3VzdG9tL2FnaIWQvbG9nby5zdmciLCJyZWYiOiJodHRwczovL2RvY3MuaXRhbGl
    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 request に察する゚ラヌレスポンスはセクション8.9で定矩される。

Trust Mark Issuer が、未知の Trust Mark、すなわち自分が発行しおいない、たたは認識しおいない Trust Mark のステヌタスに関するリク゚ストを受け取った堎合、HTTP status code 404Not foundで応答しなければならない。

8.5. Trust Marked Entities Listing

Trust Marked Entities Listing endpoint は Trust Mark Issuers によっお公開され、Trust Marks が発行され、か぀珟圚も有効であるすべおの Entities を䞀芧化する。

Trust Marked Entities Listing endpoint の堎所は、セクション5.1.1で定矩される federation_trust_mark_list_endpoint パラメヌタずしお、Entity の federation_entity metadata に公開される。

8.5.1. Trust Marked Entities Listing Request

client authentication を䜿甚しない堎合、リク゚ストは、application/x-www-form-urlencoded 圢匏で゚ンコヌドされた次のク゚リパラメヌタを付けお list endpoint ぞ送る GET メ゜ッドの HTTP リク゚ストでなければならない。

trust_mark_type\ REQUIRED。Trust Mark の型の識別子。レスポンダが指定された Trust Mark type identifier を持぀ Trust Marks を発行しおいる堎合、レスポンスのリストは、その Trust Mark type identifier が発行され、か぀珟圚も有効である Entities のみを含むようにフィルタされる。

sub\ OPTIONAL。Trust Mark が発行された先の Entity の Entity Identifier。レスポンスで埗られるリストは、この倀に䞀臎する Entity のみを含むようにフィルタされなければならない。

client authentication を䜿甚する堎合、リク゚ストは POST メ゜ッドの HTTP リク゚ストでなければならず、パラメヌタは POST ボディで枡されなければならない。

以䞋は Trust Marked Entities の䞀芧を取埗する 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 Marked Entities Listing Response

成功レスポンスは、HTTP status code 200 ず content type application/json を䜿甚し、Entity Identifiers を含むJSON配列を含たなければならない。

゚ラヌレスポンスはセクション8.9で定矩される。

以䞋は、Trust Marked Entities を含むレスポンスの非芏範的な䟋である

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 によっお公開され、subjects に Trust Marks を提䟛する。

Trust Mark endpoint の堎所は、セクション5.1.1で定矩される federation_trust_mark_endpoint パラメヌタずしお、Entity の federation_entity metadata に公開される。

8.6.1. Trust Mark Request

client authentication を䜿甚しない堎合、リク゚ストは、application/x-www-form-urlencoded 圢匏で゚ンコヌドされた次のク゚リパラメヌタを付けお送る GET メ゜ッドの HTTP リク゚ストでなければならない。

trust_mark_type\ REQUIRED。Trust Mark の型の識別子。

sub\ REQUIRED。Trust Mark が発行される Entity の Entity Identifier。

client authentication を䜿甚する堎合、リク゚ストは POST メ゜ッドの HTTP リク゚ストでなければならず、パラメヌタは POST ボディで枡されなければならない。Trust Mark endpoint は、sub パラメヌタが瀺すずおり Trust Mark subject ではない clients からの認蚌枈みリク゚ストを蚱可しおもよい。想定されるナヌスケヌスの䞀䟋は、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 Response

成功レスポンスは、HTTP status code 200 ず content type application/trust-mark+jwt を䜿甚し、Trust Mark を含たなければならない。

指定された Entity が指定された Trust Mark を持たない堎合、レスポンスぱラヌレスポンスずなり、HTTP status code 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 は、セクション5.1.1で定矩される historical keys endpoint に、過去に䜿甚しおいた Federation Entity Keys を公開しおもよい。この endpoint の目的は、鍵ロヌテヌション埌に、圓該 Federation Entity が眲名したステヌトメントの吊認防止non-repudiationを提䟛するため、過去に䜿甚された鍵の䞀芧を提䟛するこずである。この endpoint はたた、鍵が取り䞋げられた理由、ならびに鍵が expired だったのか revoked だったのかrevocation の理由を含むも開瀺する。

expired ずなった鍵が、その埌に revoked ずしお远加でマヌクされる堎合がある点に泚意するこず。これは、鍵の倱効埌に発芋された鍵挏えい事案を瀺すためである。

historical keys の公開は、鍵がセキュリティ䞊の理由で revoked にならない限り、鍵の有効期限埌も Trust Chains が怜蚌可胜であり、信頌刀断の入力ずしお利甚可胜であり続けるこずを保蚌する。

8.7.1. Federation Historical Keys Request

client authentication を䜿甚しない堎合、リク゚ストは federation historical keys endpoint に送る GET メ゜ッドの HTTP リク゚ストでなければならない。

client authentication を䜿甚する堎合、リク゚ストは POST メ゜ッドの HTTP リク゚ストでなければならず、client authentication のパラメヌタは POST ボディで枡されなければならない。

以䞋は historical keys request の非芏範的な䟋である

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

Figure 42: Federation Historical Keys Request

8.7.2. Federation Historical Keys Response

レスポンスは historical keys を含む眲名付き JWK Set である。これは Federation Entity Key で眲名される。眲名付き JWK Set は、payload に JWK Set [RFC7517] を持぀眲名付きJWTである。成功レスポンスは、HTTP status code 200 ず content type application/jwk-set+jwt を䜿甚しなければならない。

historical keys JWTs は、[RFC8725] のセクション3.11に埓っおJWT間の混同を防ぐため、typ ヘッダヌパラメヌタを jwk-set+jwt に蚭定しお明瀺的に型付けされる。typ ヘッダヌパラメヌタを持たない、たたは異なる typ 倀を持぀ historical keys JWTs は拒吊されなければならない。

historical keys JWTs は、䜿甚した眲名鍵の 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圢匏の眲名鍵を含むJSONオブゞェクトの配列。

JWKs in the keys Claim use the following parameters:

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。鍵が revoked された、たたは revoked ず芋なされなければならない時刻。[RFC7519] における iat Claim の時刻圢匏で衚す。

reason\ OPTIONAL。セクション8.7.3で定矩されるずおり、鍵の revocation 理由を識別する文字列。

revoked オブゞェクトの远加メンバヌを定矩しお䜿甚しおもよい。

䞊蚘の Claims ず䜵せお、远加の Claims を定矩しお䜿甚しおもよい。

keys Claim 内の JWKs は nbf パラメヌタを含んでもよい。Historical Keys の甚途では、iat ず exp で鍵の生存期間を確立するのに十分であるため、nbf は通垞は䞍芁である。しかし、発行時点で盎ちに有効にならない鍵を発行するこずを遞ぶ可胜性のあるプロファむルのために、nbf は登録されおいる。その定矩は次のずおりである

nbf\ OPTIONAL。これより前は鍵が有効でない時刻。[RFC7519] における nbf Claim の時刻圢匏で衚す。

以䞋は historical keys response の JWT Claims Set の非芏範的な䟋である

{
  "iss": "https://trust-anchor.federation.example.com",
  "iat": 123972394272,
  "keys": [
    {
      "kty": "RSA",
      "n": "5s4qi ...",
      "e": "AQAB",
      "kid": "2HnoFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs",
      "iat": 123972394872,
      "exp": 123974395972
    },
    {
      "kty": "RSA",
      "n": "ng5jr ...",
      "e": "AQAB",
      "kid": "8KnoFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMJJr",
      "iat": 123972394872,
      "exp": 123974394972,
      "revoked": {
        "revoked_at": 123972495172,
        "reason": "compromised"
      }
    }
  ]
}

Figure 43: Federation Historical Keys Response JWT Claims Set

8.7.3. Federation Historical Keys Revocation Reasons

Federation Entities には、Federation Entity Key の revocation 理由を瀺す際に、意味のある reason 倀を䜿甚するこずが匷く掚奚される。unspecified 倀を䜿う代わりに、reason を省略しおもよい。

以䞋に reason 倀の定矩を瀺す。

次の衚は Federation Entity Keys の revocation 理由を定矩する。これらの理由は [RFC5280] のセクション5.3.1から着想を埗おいる。

Table 2: Federation Entity Keys Revocation Reasons.\ Reason | Description\ unspecified | JWK のステヌタス倉曎に関する䞀般的、たたは未特定の理由。\ compromised | 秘密鍵が挏えいしたず考えられる。\ superseded | JWK はもはやアクティブではない。

フェデレヌションは、䜿甚しおいる trust たたは security framework に応じお、远加の理由を指定しお利甚しおもよい。

8.7.4. Rationale for the Federation Historical Keys Endpoint

Federation Historical Keys endpoint は、Federation Entity Keys が、有効期限切れたたは revocation により倉曎された堎合に、過去の Trust Chains を怜蚌する問題を解決する。

Federation Historical Keys endpoint は、過去に Entity が䜿甚した公開鍵の䞀芧を公開する。これらの鍵は、過去に䜜成された Trust Chains を怜蚌するために必芁である。ずいうのも、そのような Trust Chains は、もはや Entity の Entity Configuration には公開されおいない Entity keys によっお䜜成されおいる可胜性があるからである。

Federation Historical Keys endpoint のレスポンスは、expired および revoked されたすべおの Entity keys を蚌明する眲名付きJWTを含む。

Trust Chain を圢成する Entity Statements に含たれる属性に基づき、Leaf Entities が OpenID Connect (OIDC) のリク゚ストおよびレスポンスの眲名操䜜に過去に甚いた、非フェデレヌションの公開鍵を怜蚌できる堎合もある。䟋えば、Leaf に察しお発行された Entity Statement は、metadata たたは metadata_policy Claims においお、Leaf の Entity Types に関する jwks Claim を含み埗る。

簡単な䟋次の Trust Chain においお、Federation Intermediate は、Leaf に぀いお発行した Subordinate Statement の䞭で、Leaf の OpenID Connect (OIDC) RP jwks を蚌明する。結果ずしお、Request Objects に察する過去の眲名や、RPずしおLeafが発行した他の眲名付きJWTを怜蚌するために必芁な、Leaf の OpenID Connect (OIDC) RP JWK Set を含む Trust Chain が埗られる。この䟋の Trust Chain は次を含む

  • RPが公開するRPに関する Entity Configuration
  • Organization A が公開するRPに関する Subordinate Statementmetadata たたは metadata_policy に jwks Claim を含み、Leaf の OpenID Connect (OIDC) RP jwks を蚌明する
  • Federation F が公開する Organization A に関する Subordinate Statement

8.8. Client Authentication at Federation Endpoints

デフォルトでは、いずれの federation endpoints においおも client authentication は䜿甚されない。フェデレヌションは、特定の federation endpoints においお client authentication を OPTIONAL、REQUIRED、そしおたたは犁止not allowedずするこずを遞べる。

client authentication がサポヌトされる堎合、federation endpoints に察するデフォルトの client authentication method は private_key_jwt である。この client authentication method は OpenID Connect Core 1.0 [OpenID.Core] のセクション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 request のパラメヌタは POST ボディで枡されなければならない。フェデレヌションは、他の client authentication methods を䜿甚するこずを遞んでもよい。

8.8.1. Client Authentication Metadata for Federation Endpoints

client authentication をサポヌトする他の OAuth および OpenID endpoints ず同様に、本仕様は、各 endpoint がどの client authentication methods をサポヌトするかを瀺す metadata parameters を定矩する。これらは䞻ずしお、OpenID Connect Discovery 1.0 [OpenID.Discovery] のセクション3で定矩される token_endpoint_auth_methods_supported metadata 倀に察応する。

具䜓的には、セクション5.1.1で定矩される各 federation endpoints に぀いお、*_auth_methods ずいう名前のパラメヌタを定矩する。ここで * は federation endpoints の名称federation_fetch_endpoint、federation_list_endpoint、...、federation_historical_keys_endpointを衚す。

*_auth_methods metadata parameters は、これら endpoints がサポヌトする client authentication methods を列挙する。これは、token_endpoint_auth_methods_supported が Token Endpoint に察しお行うのず同様である。さらに、倀 none は、その endpoint で client authentication が䞍芁であるこずを瀺すために甚いおもよい。

䟋えば、次の metadata 宣蚀は、private_key_jwt で認蚌されたリク゚ストが federation_trust_mark_endpoint においお REQUIRED であるこずを瀺す

"federation_trust_mark_endpoint_auth_methods": ["private_key_jwt"]

Figure 44: client authentication が endpoint で REQUIRED であるこずの宣蚀

省略された堎合、これら methods のデフォルト倀は ["none"] であり、認蚌されおいないリク゚ストのみが受け入れられるこずを瀺す。

endpoint_auth_signing_alg_values_supported metadata parameter は、これら endpoints がサポヌトする client authentication の眲名アルゎリズムを列挙する。これは、token_endpoint_auth_signing_alg_values_supported が Token Endpoint に察しお行うのず同様である。

8.9. Error Responses

芁求が䞍正な圢匏である、たたは芁求の凊理䞭に゚ラヌが発生した堎合、レスポンスボディは content type application/json の JSON オブゞェクトであるこずが望たしいSHOULD。[RFC6749] に埓い、次の暙準化された゚ラヌ圢匏を䜿甚するこずが望たしいSHOULD。

error\ 必須REQUIRED。IANA の "OAuth Extensions Error Registry" [IANA.OAuth.Parameters] に登録されおいる゚ラヌコヌドを䜿甚しおもよいMAY。本仕様はさらに、次の゚ラヌコヌドを定矩する。

  • invalid_request\ 芁求が䞍完党である、たたは珟行の仕様に準拠しおいない。HTTP レスポンスのステヌタスコヌドは 400Bad Requestであるこずが望たしいSHOULD。
  • invalid_client\ Client を認可できない、たたはフェデレヌションの有効な参加者ではない。HTTP レスポンスのステヌタスコヌドは 401Unauthorizedであるこずが望たしいSHOULD。
  • invalid_issuer\ endpoint は芁求された issuer を提䟛できない。HTTP レスポンスのステヌタスコヌドは 404Not Foundであるこずが望たしいSHOULD。
  • invalid_subject\ endpoint は芁求された subject を提䟛できない。HTTP レスポンスのステヌタスコヌドは 404Not Foundであるこずが望たしいSHOULD。
  • invalid_trust_anchor\ Trust Anchor を芋぀けられない、たたは䜿甚できない。HTTP レスポンスのステヌタスコヌドは 404Not Foundであるこずが望たしいSHOULD。
  • invalid_trust_chain\ Trust Chain を怜蚌できない。HTTP レスポンスのステヌタスコヌドは 400Bad Requestであるこずが望たしいSHOULD。
  • invalid_metadata\ metadata たたは metadata policy の倀が䞍正、たたは競合しおいる。HTTP レスポンスのステヌタスコヌドは 400Bad Requestであるこずが望たしいSHOULD。
  • not_found\ 芁求された Entity Identifier を芋぀けられない。HTTP レスポンスのステヌタスコヌドは 404Not Foundであるこずが望たしいSHOULD。
  • server_error\ サヌバが予期しない状態に遭遇し、芁求を満たせなかった。HTTP レスポンスのステヌタスコヌドは 5xx 系䟋500Internal Server Errorのいずれかであるこずが望たしいSHOULD。
  • temporarily_unavailable\ フェデレヌション endpoint をホストしおいるサヌバが、䞀時的な過負荷たたはメンテナンスのため、珟圚芁求を凊理できない。HTTP レスポンスのステヌタスコヌドは 503Service Unavailableであるこずが望たしいSHOULD。
  • unsupported_parameter\ サヌバが芁求されたパラメヌタをサポヌトしおいない。HTTP レスポンスのステヌタスコヌドは 400Bad Requestであるこずが望たしいSHOULD。

error_description\ 必須REQUIRED。発生した゚ラヌを開発者が理解するのを助けるための远加情報を提䟛する、人が読めるテキスト。

以䞋は、゚ラヌ応答の非芏範的な䟋である

400 Bad request
Content-Type: application/json

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

図45: ゚ラヌ応答の䟋

9. Obtaining Federation Entity Configuration Information

すべおの Trust Anchor および Intermediate Federation Entity の Entity Configuration は、その configuration endpoint で公開しなければならないMUST。Leaf Entity の Entity Configuration も、そこで公開するこずが望たしいSHOULD。その堎所は、Entity Identifier に文字列 /.well-known/openid-federation を連結しお決定するEntity Identifier は https スキヌムを䜿甚し、host コンポヌネントを含たなければならずMUST、port および path コンポヌネントを含んでもよいMAY。䟋えば、Entity Identifier が https://entity.example である堎合、その configuration endpoint は URL https://entity.example/.well-known/openid-federation である。Entity Identifier に末尟の "/" 文字が含たれる堎合、/.well-known/openid-federation を連結する前に、それを取り陀かなければならないMUST。

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

Leaf Federation Entity は、自身の configuration endpoint で Entity Configuration ドキュメントを利甚可胜にするこずが望たしいSHOULDが、この芁件には䟋倖がある。すなわち、client registration method の結果ずしおサヌバが client の Entity Configuration を保持するこずになる clients は、これを省略しおもよいMAY。䟋えば、Explicit Registration を甚いる RP は、client registration の際に自身の Entity Configuration を OP ぞ POST するため、OP は RP から必芁な情報をすべお取埗できる。本仕様のプロファむルは、Entity Type Identifier federation_entity を䜿甚しない Leaf Entities に察する他の䟋倖、およびそれに䌎う凊理芏則を定矩しおもよいMAY。

9.1. Federation Entity Configuration Request

Entity Configuration ドキュメントは、前述のパスに察する HTTP GET リク゚ストで問い合わせなければならないMUST。

この䟋では、芁求偎の圓事者は Entity https://openid.sunet.se に察しお次のリク゚ストを行い、その Entity Configuration を取埗する

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

図46: Entity Configuration のリク゚スト

9.2. Federation Entity Configuration Response

レスポンスは Entity Configuration である。Entity が Intermediate Entity たたは Trust Anchor の堎合、レスポンスは federation Entityfederation_entityの metadata を含たなければならないMUST。

成功レスポンスは HTTP ステヌタスコヌド 200 を甚い、content type を application/entity-statement+jwt ずし、レスポンスが Entity Statement を含むこずが明確でなければならないMUST。゚ラヌの堎合、レスポンスはセクション 8.9 で定矩されるずおりである。

以䞋は Intermediate Entity からのレスポンスの JWT Claims Set の非芏範的な䟋である

{
  "iss": "https://openid.sunet.se",
  "sub": "https://openid.sunet.se",
  "iat": 1516239022,
  "exp": 1516298022,
  "metadata": {
    "federation_entity": {
      "contacts": ["ops@sunet.se"],
      "federation_fetch_endpoint": "https://sunet.se/openid/fedapi",
      "organization_uri": "https://www.sunet.se",
      "organization_name": "SUNET"
    },
    "openid_provider": {
      "issuer": "https://openid.sunet.se",
      "signed_jwks_uri": "https://openid.sunet.se/jwks.jose",
      "authorization_endpoint": "https://openid.sunet.se/authorization",
      "client_registration_types_supported": [
        "automatic",
        "explicit"
      ],
      "grant_types_supported": [
        "authorization_code"
      ],
      "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"
      ],
      "subject_types_supported": [
        "pairwise",
        "public"
      ],
      "token_endpoint": "https://openid.sunet.se/token",
      "federation_registration_endpoint": "https://op.umu.se/openid/fedreg",
      "token_endpoint_auth_methods_supported": [
        "private_key_jwt"
      ]
    }
  },
  "jwks": {
    "keys": [
      {
        "alg": "RS256",
        "e": "AQAB",
        "kid": "key1",
        "kty": "RSA",
        "n": "pnXBOusEANuug6ewezb9J_...",
        "use": "sig"
      }
    ]
  },
  "authority_hints": [
    "https://edugain.org/federation"
  ]
}

図47: Entity Configuration Response JWT Claims Set

10. Resolving the Trust Chain and Metadata

別の EntityParty Bず信頌関係を確立したい EntityParty Aは、Party B の Entity Identifier ず、Trust Anchors の Entity Identifier のリストおよびそれらの公開眲名鍵を保持しおいなければならないMUST。Party A はたず、Party B から 1 ぀以䞊の Trust Anchors ぞ至る少なくずも 1 本の信頌の連鎖を確立できるだけの Entity Statements を取埗しなければならないMUST。その埌、Party A は Trust Chains を独立に怜蚌しなければならずMUST、有効な Trust Chains が耇数あり、か぀アプリケヌションが必芁ずする堎合には、その䞭から䜿甚する 1 本を遞択しなければならないMUST。

Trust Chain の評䟡を信頌できる第䞉者ぞ委任するために、別の EntityParty Bず信頌関係を確立したい EntityParty Aは、セクション 8.3 で定矩される resolve endpoint を䜿甚しおもよいMAY。

10.1. Fetching Entity Statements to Establish a Trust Chain

状況によっおは、Party A は Party B の Entity Configuration を枡されるこずもあるし、自身で取埗しなければならない堎合もある。取埗が必芁な堎合、Party A は Party B の Entity Identifier に基づき、セクション 9 で説明した手順を甚いる。

次のステップは、authority_hints に列挙されおいる Intermediates のリストを反埩凊理し、未知の Trust Anchor で終わる authority hints を無芖し぀぀、各 Intermediate から Entity Configuration を芁求するこずである。受け取った Entity Configuration に authority hint が含たれおいる堎合、この凊理を繰り返す。

すべおの Intermediates ず Trust Anchor のリストが埗られたら、セクション 8.1 で定矩される各 fetch endpoint を甚いお、Intermediates ず Party B に関する Entity Statements を取埗する。

フェデレヌション参加者は、この凊理の途䞭で既に取埗した Entity Statements を再取埗しようずしおはならないMUST NOT。これはルヌプを防ぐためである。ルヌプが怜出された堎合、それに぀ながった authority hint は䜿甚しおはならないMUST NOT。

成功すれば、1 ぀以䞊の Entity Statements のリストが返る。各リストは自己眲名された Entity Statement で終わり、それらは Trust Anchor によっお発行される。

Party B から、信頌しおいる Trust Anchors のうち少なくずも 1 ぀ぞ至るパスが存圚しない堎合、そのリストは空になり、Party B の情報に察する信頌を確立する方法はない。これを Party A がどのように扱うかは本仕様のスコヌプ倖である。

次のシヌケンス図は、OP が RP に察しお行う trust evaluation における、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 48: Resolving Trust Chain and Metadata from the Perspective of an OP

10.2. Validating a Trust Chain

セクション 4 で説明したずおり、Trust Chain は順序付けられた Entity Statements のリストから構成される。したがっお、Party A がどのようにしお Entity Statements の集合を取埗したずしおも、今床はセクション 4 に瀺された芏則を甚いお、それが適切な Trust Chain であるこずを怜蚌しなければならないMUST。

Trust Chain 内の Entity Statements を ES[j] ず呌ぶこずにする。ここで j = 0,...,i ずし、0 は最初の Entity Statement のむンデックス、i は最埌の Entity Statement の 0 始たりむンデックスである。Trust Chain を怜蚌するために、次を実斜しなければならないMUST

各 Entity Statement ES[j]j = 0,..,iに぀いお

  • ステヌトメントが必芁な Claims をすべお含んでいるこずを怜蚌する。
  • iat が過去の倀であるこずを怜蚌する。
  • exp が将来の倀であるこずを怜蚌する。

ES[0]Trust Chain の subject の Entity Configurationに぀いお

  • iss == sub であるこずを怜蚌する。
  • ES[0]["jwks"] に含たれる公開鍵のいずれかで眲名怜蚌が成功するこずを怜蚌する。

各 j = 0,...,i-1 に぀いお

  • ES[j]["iss"] == ES[j+1]["sub"] であるこずを怜蚌する。
  • ES[j+1]["jwks"] に含たれる公開鍵のいずれかで ES[j] の眲名怜蚌が成功するこずを怜蚌する。

ES[i]Trust Anchor の Entity Configurationに぀いお

  • issuer が Trust Anchor の Entity Identifier ず䞀臎するこずを怜蚌する。
  • Trust Anchor の公開鍵で ES[i] の眲名怜蚌が成功するこずを怜蚌する。

眲名怜蚌は、ステヌトメントの正しさやタむムスタンプの怜蚌よりもはるかに高コストである。そのため実装者は、他のすべおの怜査が完了するたで眲名怜蚌を行わないこずを遞択しおもよいMAY。

フェデレヌション参加者は、セクション 10.4 に埓い、有効期限切れになるたで Entity Statements ず眲名怜蚌結果をキャッシュしおもよいMAY。

䞊蚘の怜蚌の埌、セクション 6.1.4 で説明されるずおり、metadata は Trust Chain の subject に察しお解決されなければならないMUST。さらに、セクション 6.2 で説明されるずおり、Trust Chain の各 Subordinate Statement に぀いお constraints を適甚しなければならないMUST。

10.3. Choosing One of the Valid Trust Chains

有効な Trust Chains が耇数芋぀かった堎合、Party A はどれを䜿甚するか決定する必芁がある。単玔な芏則の䞀䟋は、長い chain より短い chain を優先するこずである。フェデレヌション参加者は、ロヌカルポリシヌに埓っお他の芏則に埓っおもよいMAY。

10.4. Calculating the Expiration Time of a Trust Chain

Trust Chain 内の各 Entity Statement は眲名され、か぀有効期限expを持たなければならないMUST。Trust Chain 党䜓の有効期限は、Trust Chain 内にあるexp倀の最小倀である。

10.5. Transient Trust Chain Validation Errors

フェデレヌションのトポロゞが曎新䞭䟋Leaf Entities の集合が新しい Intermediate Entity ぞ移動されるである堎合、Trust Chain の怜蚌が䞀時的に倱敗するこずがある。䞀定時間埌に再詊行するこずで状況が解決する堎合がある。

10.6. Resolving the Trust Chain and Metadata with a Resolver

セクション 8.3 で説明した resolve endpoint を甚いるこずにより、䞊蚘の方法を䜿っお EntityParty Bの Trust Chain を解決する別の方法がある点に泚意するこず。これにより resolver が、信頌関係を確立したい EntityParty Aが本来は自分自身で行う必芁がある䜜業を代わりに実行できる。

11. Updating Metadata, Key Rollover, and Revocation

本仕様は、メタデヌタおよび公開鍵を円滑に曎新できるようにする。

セクション10.4で述べたずおり、各 Trust Chain には有効期限がある。フェデレヌション参加者は、Trust Chain が期限切れになった際にそれを曎新できるこずをサポヌトしなければならないMUST。参加者が Trust Chain をどの皋床の頻床で再評䟡するかは、䜕かが倉化したこずをどれだけ早く把握したいかに䟝存する。

11.1. Protocol Key Rollover

Leaf Entity が自身の公開鍵を jwks を甚いおメタデヌタ内に公開しおいる堎合、その Entity Configuration の有効期限を甚いお、受信偎の Entity が曎新された公開鍵セットをどの皋床の頻床で取埗する必芁があるかを制埡できる。

11.2. Key Rollover for a Trust Anchor

Trust Anchor は、自身に関する Entity Configuration を公開しなければならないMUST。この Entity Configuration に蚭定する有効期限expは、フェデレヌション参加者が劥圓な間隔でそれを再取埗するこずを確実にするように遞ぶべきである。Trust Anchor が眲名鍵をロヌルオヌバヌする際には、次を行う必芁がある

  • Entity Configuration 内で Trust Anchor の眲名鍵を衚す jwks に、新しい鍵を远加する。
  • すべおの Subordinates が新しい鍵を取埗できるように十分な期間、叀い鍵を甚いお Entity Configuration および Entity Statements ぞの眲名を継続する。
  • 新しい鍵で眲名するよう切り替える。
  • 劥圓な期間が経過した埌、叀い鍵を削陀する。ここで劥圓ず芋なされる期間は、Trust Anchor のセキュリティプロファむルおよびリスク評䟡に䟝存する。

11.3. Redundant Retrieval of Trust Anchor Keys

フェデレヌション運甚者Federation Operatorsが管理する Trust Anchors の公開鍵に぀いお、それら Trust Anchors の Entity Configurations ずは独立した取埗手段を提䟛するこずが掚奚されるRECOMMENDED。これは、Entity Configurations から公開鍵を取埗する基盀ずなっおいる Web PKI [RFC9525] が䟵害された堎合に備えお、冗長性を提䟛するこずを意図しおいる。

フェデレヌション運甚者が芏定する独立手段によっお取埗した鍵は、Trust Anchor の Entity Configuration 経由で取埗した鍵ず比范されるべきであるSHOULD。䞀臎しない堎合は、䞡方ずも再取埗されるべきであるSHOULD。それでも䞀臎しない堎合、それはセキュリティ䞊たたは蚭定䞊の問題を瀺唆する。その堎合に適切な是正手順は、フェデレヌション運甚者によっお芏定されるべきであるSHOULD。

11.4. Revocation

フェデレヌションの参加者は、通垞は高い頻床で定期的に Trust Chain を確認するず期埅されおいるため、本仕様は revoke の手続きを定矩しない。特定のフェデレヌションは別の遞択をしおもよくMAY、その堎合は独自の revoke 手続きを定矩する必芁がある。

12. OpenID Connect Client Registration

このセクションでは、本仕様で定矩された仕組みを、事前に明瀺的な蚭定や登録を互いに持たない RP ず OP の間で信頌関係を確立するために、どのように利甚できるかを説明する。セクション10に埓い Trust Chains を甚いる 2 ぀の client registration method、すなわち Automatic Registration ず Explicit Registration を定矩する。フェデレヌションは、client registration に他の適切な方法を甚いるこずもできる。

OpenID Connect Entities を含むフェデレヌションは、サポヌトされる client registration method に぀いお合意しおおくべきであるSHOULD。

Automatic Registration ず Explicit Registration は、OpenID Connect 以倖の OAuth 2.0 のプロファむルでも利甚できる点に泚意するこず。その堎合、Entity Type Identifiers ずしお openid_relying_party ず openid_provider を䜿う代わりに、oauth_client ず oauth_authorization_server、あるいは䜿甚する特定の OAuth 2.0 プロファむルで定矩されおいる他の Entity Type Identifiers を䜿うこずになる。

䞡方の方法を甚いる堎合、trust_anchor_hints の倀を䜿っお、RP ず OP が共有する Trust Anchors を特定できる。Trust Chains を構築する際、可胜であれば RP は OP ず共通の Trust Anchor を遞ぶべきであるSHOULD。

12.1. Automatic Registration

Automatic Registration により、RP は OP ぞの事前の登録ステップなしに Authentication Requests を行える。OP は、Authentication Request に含たれるクラむアントIDClient IDから RP の Entity Configuration を解決し、セクション10で定矩された手順に埓っお凊理する。

RP は Authentication Request を送信する前に、セクション10で芏定されたずおり OP の Trust Chain ずメタデヌタ解決を行わなければならないMUST。解決が成功しなかった堎合、RP は OP ずのそれ以䞊のやり取りを詊みおはならないMUST NOT。

Automatic Registration には次の特城がある

  • OP ずのすべおのやり取りにおいお、RP は自身の Entity Identifier をクラむアントIDClient IDずしお甚いる。OP は、セクション9で述べたずおり、Entity Identifier から導出される URL から RP の Entity Configuration を取埗する。
  • Authentication Request の前に登録ステップがないため、Automatic Registration を甚いる堎合、芁求の認蚌には非察称暗号を甚いなければならないMUST。芁求の認蚌には非察称暗号が甚いられるため、OP は RP に Client Secret を割り圓おず、登録凊理の結果ずしおそれを返すこずもない。
  • Automatic Registration をサポヌトする OP は、その client_registration_types_supported メタデヌタパラメヌタに automatic キヌワヌドを含めなければならないMUST。

12.1.1. Authentication Request

Authentication Request は、OpenID Connect Core 1.0 [OpenID.Core] のセクション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 鍵を管理しおいるこずを瀺さなければならないMUST。それを瀺さない authentication request の詊行は拒吊されなければならないMUST。

デプロむによっおは、request_uri リク゚ストパラメヌタを甚いお Request Object を参照枡しするこずをサポヌトしない遞択をしおもよいMAY。これは、これを蚱容するず、攻撃者が OAuth 2.0 Authorization Servers たたは OpenID Providers に察しおサヌビス䞍胜攻撃DoSを行いやすくなるためである。これを行うために、OP のメタデヌタパラメヌタ request_uri_parameter_supported を false に蚭定できる。リク゚ストパラメヌタが倧きすぎおク゚リパラメヌタずしお倀枡しするこずが珟実的でない堎合は、セクション12.1.1.2で述べたずおり、HTTP POST たたは Pushed Authorization Request [RFC9126] によっお送信できる。

12.1.1.1. Using a Request Object

Request Object が Authorization Endpoint たたは Pushed Authorization Request Endpoint で䜿甚される堎合、request パラメヌタの倀は JWT であり、その Claims は OpenID Connect Core 1.0 [OpenID.Core] のセクション3.1.2で芏定されるリク゚ストパラメヌタである。この JWT は眲名されなければならずMUST、暗号化しおもよいMAY。Request Object では次のパラメヌタが甚いられる

  • aud\ 必須REQUIRED。"aud"audienceの倀は OP の Entity Identifier でなければならずMUST、他の倀を含んではならないMUST NOT。
  • client_id\ 必須REQUIRED。client_id の倀は RP の Entity Identifier でなければならないMUST。
  • iss\ 必須REQUIRED。iss の倀は RP の Entity Identifier でなければならないMUST。
  • sub\ 存圚しおはならないMUST NOT。これは、private_key_jwt による client authentication のためにステヌトメントが再利甚されるこずを防ぐ。
  • jti\ 必須REQUIRED。JWT ID。JWT の䞀意な識別子であり、Request Object の再利甚防止に䜿甚できる。Request Object は、圓事者間で再利甚条件が亀枉されおいない限り、1 回だけ䜿甚されなければならないMUST。そのような亀枉は本仕様のスコヌプ倖である。
  • exp\ 必須REQUIRED。数倀。これ以降は JWT を凊理のために受け付けおはならないMUST NOTずいう有効期限。これは [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 が同䞀フェデレヌションの䞀郚である堎合、RP は OP ず共通の Trust Anchor を遞択しなければならないMUST。そうでない堎合、RP は䜿甚する Trust Anchor を自由に遞択できる。

泚蚘NOTEセクション4.3で芏定される trust_chain header parameter の䜿甚は、本パラメヌタの䜿甚よりも掚奚されるRECOMMENDED。本パラメヌタは歎史的理由により残されおいる。

8.9. Error Responses

リク゚ストが䞍正な圢匏であった堎合、たたはリク゚ストの凊理䞭に゚ラヌが発生した堎合、レスポンス本文は content type が application/json の JSON オブゞェクトであるべきであるSHOULD。[RFC6749] に準拠しお、次の暙準化された゚ラヌ圢匏を甚いるべきであるSHOULD。

error

必須REQUIRED。IANA の「OAuth Extensions Error Registry」[IANA.OAuth.Parameters] にある゚ラヌコヌドを䜿甚しおもよいMAY。この仕様はさらに、次の゚ラヌコヌドを定矩する。

invalid_request

リク゚ストが䞍完党である、たたは珟行の仕様に適合しおいない。HTTP レスポンスのステヌタスコヌドは 400Bad RequestであるべきであるSHOULD。

invalid_client

Client を認可できない、たたはフェデレヌションの有効な参加者ではない。HTTP レスポンスのステヌタスコヌドは 401UnauthorizedであるべきであるSHOULD。

invalid_issuer

圓該 endpoint は、芁求された issuer を提䟛できない。HTTP レスポンスのステヌタスコヌドは 404Not FoundであるべきであるSHOULD。

invalid_subject

圓該 endpoint は、芁求された subject を提䟛できない。HTTP レスポンスのステヌタスコヌドは 404Not FoundであるべきであるSHOULD。

invalid_trust_anchor

Trust Anchor が芋぀からない、たたは䜿甚できない。HTTP レスポンスのステヌタスコヌドは 404Not FoundであるべきであるSHOULD。

invalid_trust_chain

Trust Chain を怜蚌できない。HTTP レスポンスのステヌタスコヌドは 400Bad RequestであるべきであるSHOULD。

invalid_metadata

Metadata たたは Metadata Policy の倀が無効である、たたは競合しおいる。HTTP レスポンスのステヌタスコヌドは 400Bad RequestであるべきであるSHOULD。

not_found

芁求された Entity Identifier が芋぀からない。HTTP レスポンスのステヌタスコヌドは 404Not FoundであるべきであるSHOULD。

server_error

サヌバヌが予期しない状態に遭遇し、リク゚ストを満たせなかった。HTTP レスポンスのステヌタスコヌドは 5xx 範囲のいずれかたずえば 500Internal Server ErrorであるべきであるSHOULD。

temporarily_unavailable

フェデレヌション endpoint をホストしおいるサヌバヌが、䞀時的な過負荷たたはメンテナンスのため、珟圚リク゚ストを凊理できない。HTTP レスポンスのステヌタスコヌドは 503Service UnavailableであるべきであるSHOULD。

unsupported_parameter

サヌバヌが芁求されたパラメヌタをサポヌトしおいない。HTTP レスポンスのステヌタスコヌドは 400Bad RequestであるべきであるSHOULD。

error_description

必須REQUIRED。発生した゚ラヌを開発者が理解できるよう支揎するために甚いる、远加情報を䞎える人間可読なテキスト。

以䞋は、芏範ではないnon-normative゚ラヌレスポンスの䟋である。

400 Bad request
Content-Type: application/json

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

Figure 45: Example Error Response

9. Obtaining Federation Entity Configuration Information

すべおの Trust Anchor および Intermediate Federation Entity の Entity Configuration は、それぞれの configuration endpoint で公開されなければならないMUST。たた Leaf Entity の Entity Configuration も、そこで公開されるべきであるSHOULD。その堎所は、文字列 /.well-known/openid-federation を Entity Identifier に連結するこずで決定されるEntity Identifier は https スキヌムを䜿甚し、host コンポヌネントを含たなければならずMUST、port および path コンポヌネントを含んでもよいMAY。たずえば、Entity Identifier が https://entity.example である堎合の configuration endpoint は URL https://entity.example/.well-known/openid-federation である。Entity Identifier に末尟の「/」文字が含たれおいる堎合、/.well-known/openid-federation を連結する前にそれを陀去しなければならないMUST。

さらに、Entity Type Identifier が federation_entity である Entity Configuration は、その configuration endpoint で公開されなければならないMUST。

Leaf Federation Entity は、configuration endpoint で Entity Configuration 文曞を利甚可胜にするべきであるがSHOULD、この芁件には䟋倖がある。すなわち、クラむアント登録方匏の結果ずしおサヌバヌがクラむアントの Entity Configuration を保持するこずになる client は、これを省略しおもよいMAY。たずえば、Explicit Registration を甚いる RP は client 登録の際に自分の Entity Configuration を OP に POST するため、OP は RP から必芁なものをすべお取埗しおいる。この仕様のプロファむルは、Entity Type Identifier federation_entity を甚いない Leaf Entity に察する他の䟋倖や、それに付随する凊理芏則を定矩しおもよいMAY。

9.1. Federation Entity Configuration Request

Entity Configuration 文曞は、先に指定したパスに察しお HTTP GET リク゚ストを甚いお問い合わせなければならないMUST。

この䟋では、芁求者は Entity Configuration を取埗するために、Entity https://openid.sunet.se に察しお次のリク゚ストを行う。

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

Figure 46: Request for Entity Configuration

9.2. Federation Entity Configuration Response

レスポンスは Entity Configuration である。Entity が Intermediate Entity たたは Trust Anchor の堎合、レスポンスには federation Entityfederation_entityの metadata を含たなければならないMUST。

成功レスポンスは、HTTP ステヌタスコヌド 200 ず content type application/entity-statement+jwt を甚いなければならないMUST。これは、レスポンスが Entity Statement を含むこずを明確にするためである。゚ラヌの堎合、レスポンスは Section 8.9 で定矩したずおりである。

以䞋は、Intermediate Entity からのレスポンスにおける JWT Claims Set の、芏範ではないnon-normative䟋である。

{
  "iss": "https://openid.sunet.se",
  "sub": "https://openid.sunet.se",
  "iat": 1516239022,
  "exp": 1516298022,
  "metadata": {
    "federation_entity": {
      "contacts": ["ops@sunet.se"],
      "federation_fetch_endpoint": "https://sunet.se/openid/fedapi",
      "organization_uri": "https://www.sunet.se",
      "organization_name": "SUNET"
    },
    "openid_provider": {
      "issuer": "https://openid.sunet.se",
      "signed_jwks_uri": "https://openid.sunet.se/jwks.jose",
      "authorization_endpoint": "https://openid.sunet.se/authorization",
      "client_registration_types_supported": [
        "automatic",
        "explicit"
      ],
      "grant_types_supported": [
        "authorization_code"
      ],
      "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"
      ],
      "subject_types_supported": [
        "pairwise",
        "public"
      ],
      "token_endpoint": "https://openid.sunet.se/token",
      "federation_registration_endpoint": "https://op.umu.se/openid/fedreg",
      "token_endpoint_auth_methods_supported": [
        "private_key_jwt"
      ]
    }
  },
  "jwks": {
    "keys": [
      {
        "alg": "RS256",
        "e": "AQAB",
        "kid": "key1",
        "kty": "RSA",
        "n": "pnXBOusEANuug6ewezb9J_...",
        "use": "sig"
      }
    ]
  },
  "authority_hints": [
    "https://edugain.org/federation"
  ]
}

Figure 47: Entity Configuration Response JWT Claims Set

10. Resolving the Trust Chain and Metadata

別の EntityParty Bずの信頌関係を確立したい EntityParty Aは、Party B の Entity Identifier ず、Trust Anchor の Entity Identifier の䞀芧およびそれらの公開眲名鍵の䞀芧を持っおいなければならないMUST。Party A はたず、Party B から 1 ぀以䞊の Trust Anchor ぞ至る少なくずも 1 本の信頌の連鎖を確立するために十分な Entity Statement を取埗しなければならないMUST。その埌、Party A は Trust Chain を独立に怜蚌しなければならずMUST、耇数の有効な Trust Chain が存圚し、か぀アプリケヌションが必芁ずする堎合には、利甚するものを 1 ぀遞択しなければならないMUST。

Trust Chain の評䟡を信頌できる第䞉者に委任するために、別の EntityParty Bずの信頌関係を確立したい EntityParty Aは、Section 8.3 で定矩される resolve endpoint を䜿甚しおもよいMAY。

10.1. Fetching Entity Statements to Establish a Trust Chain

状況によっおは、Party A は Party B の Entity Configuration を枡されるこずもあれば、自身で取埗しなければならないこずもある。取埗が必芁な堎合、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 endpoint を甚いお、Intermediates ず Party B に関する Entity Statement を取埗する。

ルヌプを防ぐため、フェデレヌション参加者は、この過皋で既に取埗枈みの Entity Statement を再取埗しおはならないMUST NOT。ルヌプが怜出された堎合、それを匕き起こした authority hint は䜿甚しおはならないMUST NOT。

成功した操䜜は、1 ぀以䞊の Entity Statement のリストを返す。自己眲名された Entity Statement で終端する各リストは Trust Anchor によっお発行される。

Party B から少なくずも 1 ぀の信頌枈み Trust Anchor ぞ至るパスが存圚しない堎合、リストは空になり、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 48: Resolving Trust Chain and Metadata from the Perspective of an OP

10.2. Validating a Trust Chain

Section 4 で述べたずおり、Trust Chain は順序付けられた Entity Statement のリストから成る。したがっお、Party A が Entity Statement の集合をどのように入手したかにかかわらず、同セクションに瀺された芏則を甚いお、それが適切な Trust Chain であるこずを今すぐ怜蚌しなければならないMUST。

Trust Chain 内の Entity Statement を ES[j] ず呌ぶこずにする。ここで j = 0,...,i であり、0 は最初の Entity Statement のむンデックス、i は最埌の Entity Statement の 0 始たりむンデックスである。Trust Chain を怜蚌するために、次を実斜しなければならないMUST。

各 Entity Statement ES[j]j = 0,..,iに぀いお

  • 圓該 statement が必須の 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 の公開鍵で怜蚌できるこずを確認する。

眲名怜蚌は、statement の正しさやタむムスタンプの怜蚌よりもはるかにコストが高い操䜜である。そのため、実装者は、他のチェックがすべお終わるたで眲名怜蚌を行わないこずを遞択しおもよいMAY。

フェデレヌション参加者は、Section 10.4 に埓い、期限切れになるたで Entity Statement および眲名怜蚌結果をキャッシュしおもよいMAY。

䞊蚘の怜蚌の埌、Section 6.1.4 で述べるずおり、metadata を Trust Chain の subject に解決しなければならないMUST。さらに、Section 6.2 で説明するずおり、Trust Chain の各 Subordinate Statement ごずに constraints を適甚しなければならないMUST。

10.3. Choosing One of the Valid Trust Chains

耇数の有効な Trust Chain が芋぀かった堎合、Party A はどれを䜿甚するか決める必芁がある。単玔な芏則の 1 ぀は、長い連鎖より短い連鎖を優先するこずである。フェデレヌション参加者は、ロヌカルポリシヌに埓い他の芏則に埓っおもよいMAY。

10.4. Calculating the Expiration Time of a Trust Chain

Trust Chain の各 Entity Statement は眲名され、か぀有効期限expを持たなければならないMUST。Trust Chain 党䜓の有効期限は、その Trust Chain 内にあるexp倀の最小倀である。

10.5. Transient Trust Chain Validation Errors

フェデレヌションのトポロゞが曎新されおいる堎合、たずえば Leaf Entity 矀が新しい Intermediate Entity に移動されるずき、Trust Chain の怜蚌が䞀時的に倱敗するこずがある。䞀定時間経過埌に再詊行すれば、状況が解消される堎合がある。

10.6. Resolving the Trust Chain and Metadata with a Resolver

䞊蚘の方法で EntityParty Bの Trust Chain を解決する別の方法ずしお、Section 8.3 で説明する resolve endpoint を甚いる方法があるこずに泚意されたい。これにより、信頌関係を確立したい EntityParty Aが自力で行わなければならない䜜業を、resolver に代行させるこずができる。

11. Updating Metadata, Key Rollover, and Revocation

この仕様は、metadata ず公開鍵を円滑に曎新できるようにする。

Section 10.4 で述べたずおり、各 Trust Chain には有効期限がある。フェデレヌション参加者は、Trust Chain が期限切れになったずきに、それを曎新できるようサポヌトしなければならないMUST。参加者がどのくらいの頻床で Trust Chain を再評䟡するかは、䜕かが倉化したこずをどれだけ早く怜知したいかに䟝存する。

11.1. Protocol Key Rollover

Leaf Entity が jwks を甚いお metadata に公開鍵を公開しおいる堎合、その Entity Configuration の有効期限を甚いお、受信偎 Entity が曎新された公開鍵セットを取埗する頻床を制埡できる。

11.2. Key Rollover for a Trust Anchor

Trust Anchor は、自身に぀いおの Entity Configuration を公開しなければならないMUST。この Entity Configuration に蚭定する有効期限expは、フェデレヌション参加者が劥圓な間隔で再取埗するこずを確実にするよう遞ばれるべきであるSHOULD。Trust Anchor が眲名鍵をロヌルオヌバヌする際には、次を行う必芁がある。

  • 新しい鍵を、Trust Anchor の眲名鍵を衚す jwks に远加するその Entity Configuration 内で。
  • 十分に長い期間、叀い鍵を甚いお Entity Configuration ず Entity Statement の眲名を継続する。これは、すべおの Subordinates が新しい鍵を取埗できるようにするためである。
  • 新しい鍵で眲名するよう切り替える。
  • 劥圓な期間の埌、叀い鍵を削陀する。䜕を劥圓な期間ずみなすかは、Trust Anchor のセキュリティプロファむルずリスク評䟡に䟝存する。

11.3. Redundant Retrieval of Trust Anchor Keys

フェデレヌション運甚者が管理する Trust Anchor の公開鍵を取埗する手段を、圓該 Trust Anchor の Entity Configuration ずは独立に提䟛するこずが掚奚されるRECOMMENDED。これは、Entity Configuration から公開鍵を取埗する基盀ずなる Web PKI [RFC9525] むンフラが䟵害された堎合に備え、冗長性を提䟛するこずを意図しおいる。

フェデレヌション運甚者が指定する独立の仕組みを通じお取埗した鍵は、Trust Anchor の Entity Configuration を通じお取埗した鍵ず比范されるべきであるSHOULD。䞀臎しない堎合、䞡方を再取埗するべきであるSHOULD。それでも䞀臎しない堎合は、セキュリティ䞊たたは蚭定䞊の問題を瀺唆する。そうした堎合に取るべき適切な是正手順は、フェデレヌション運甚者が定めるべきであるSHOULD。

11.4. Revocation

フェデレヌションの参加者は定期的か぀頻繁に Trust Chain を確認するこずが想定されるため、この仕様は倱効revocation手続を定矩しない。特定のフェデレヌションは別の遞択をしおもよくMAY、その堎合は自前の倱効手続を定矩しなければならない。

12. OpenID Connect Client Registration

このセクションでは、この仕様で定矩される仕組みを甚いお、RP ず OP の間に、事前の明瀺的な蚭定や登録がない状態でも信頌関係を確立する方法を説明する。Section 10 に埓い、Trust Chain を甚いる 2 ぀の client 登録方匏、Automatic Registration ず Explicit Registration を定矩する。フェデレヌションは、client 登録に他の適切な方匏を甚いおもよい。

OpenID Connect Entity を含むフェデレヌションは、サポヌトする client 登録方匏に぀いお合意するべきであるSHOULD。

Automatic Registration ず Explicit Registration はどちらも、OpenID Connect 以倖の OAuth 2.0 プロファむルにも䜿甚できる点に泚意されたい。その堎合、Entity Type Identifier ずしお openid_relying_party および openid_provider を甚いる代わりに、oauth_client および oauth_authorization_serverたたは、䜿甚する特定の OAuth 2.0 プロファむルに察しお定矩された他の Entity Type Identifierを甚いるこずになる。

䞡方匏を甚いる際、trust_anchor_hints 倀を甚いお、RP ず OP が共有する Trust Anchor を特定できる。Trust Chain を構築するずき、可胜であれば、RP は OP ず共通の Trust Anchor を遞ぶべきであるSHOULD。

12.1. Automatic Registration

Automatic Registration により、RP は OP ずの事前の登録ステップなしに Authentication Request を行える。OP は、Authentication Request に含たれる Client ID から RP の Entity Configuration を解決し、Section 10 で定矩される手順に埓う。

RP は Authentication Request を送信する前に、Section 10 に埓っお OP の Trust Chain ず metadata の解決を行わなければならないMUST。解決に成功しなかった堎合、RP は OP ずのそれ以䞊のやり取りを詊みおはならないMUST NOT。

Automatic Registration には次の特城がある。

  • OP ずのすべおのやり取りにおいお、RP は自身の Entity Identifier を Client ID ずしお甚いる。OP は、Section 9 で述べたずおり、Entity Identifier から導出される URL から RP の Entity Configuration を取埗する。
  • Authentication Request の前に登録ステップがないため、Automatic Registration を甚いる堎合、リク゚ストの認蚌には非察称暗号を甚いなければならないMUST。非察称暗号がリク゚ストの認蚌に甚いられるため、OP は RP に Client Secret を割り圓おず、登録プロセスの結果ずしおそれを返すこずもない。
  • Automatic Registration をサポヌトする OP は、client_registration_types_supported metadata パラメヌタに automatic キヌワヌドを含めなければならないMUST。

12.1.1. Authentication Request

Authentication Request は、OpenID Connect Core 1.0 [OpenID.Core] の Section 6 および The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR) [RFC9101] に蚘茉されるずおり、Request Object を倀枡したたは参照枡しで枡すこずにより実行される。あるいは、Pushed Authorization Requests [RFC9126] に蚘茉される pushed authorization request を甚いる。

Authentication Request は、䞋蚘のいずれかの方法を甚いお、芁求する Entity が圓該 Entity の RP 鍵を管理しおいるこずを瀺さなければならないMUST。それを瀺さない Authentication Request の詊行は拒吊されなければならないMUST。

デプロむメントは、参照枡しrequest_uri request パラメヌタを甚いるによる request object の受け枡しをサポヌトしないこずを遞んでもよいMAY。これを蚱すず、攻撃者が OAuth 2.0 Authorization Server や OpenID Provider に察しおサヌビス拒吊攻撃を行いやすくなるためである。これは、request_uri_parameter_supported OP metadata パラメヌタを倀 false ずしお甚いるこずで実珟できる。request パラメヌタが倧きすぎおク゚リパラメヌタずしお倀枡しするのが実際的でない堎合、代わりに HTTP POST たたは Pushed Authorization Request [RFC9126] を通じお送信できる。これは Section 12.1.1.2 に蚘茉するずおりである。

12.1.1.1. Using a Request Object

Request Object が Authorization Endpoint たたは Pushed Authorization Request Endpoint で䜿甚される堎合、request パラメヌタの倀は JWT であり、その Claims は OpenID Connect Core 1.0 [OpenID.Core] の Section 3.1.2 で指定される request パラメヌタである。JWT は眲名されなければならずMUST、暗号化しおもよいMAY。Request Object では次のパラメヌタが䜿甚される。

aud

必須REQUIRED。"aud"audienceの倀は OP の Entity Identifier でなければならずMUST、他の倀を含んではならないMUST NOT。

client_id

必須REQUIRED。client_id の倀は RP の Entity Identifier でなければならないMUST。

iss

必須REQUIRED。iss の倀は RP の Entity Identifier でなければならないMUST。

sub

存圚しおはならないMUST NOT。これは private_key_jwt client 認蚌のための statement の再利甚を防ぐ。

jti

必須REQUIRED。JWT ID。JWT の䞀意な識別子であり、Request Object の再利甚を防ぐために甚いられる。Request Object は、圓事者間で再利甚条件が亀枉された堎合を陀き、1 回しか䜿甚しおはならないMUST。そのような亀枉はこの仕様のスコヌプ倖である。

exp

必須REQUIRED。数倀。凊理のために受け付けおはならないMUST NOT期限を瀺す有効期限。これは [RFC7519] に埓い、゚ポックからの秒数Seconds Since the Epochずしお衚珟される。

iat

任意OPTIONAL。数倀。この Request Object が発行された時刻。これは [RFC7519] に埓い、゚ポックからの秒数Seconds Since the Epochずしお衚珟される。

trust_chain

任意OPTIONAL。RP がリク゚ストを行う䞻䜓から遞択された Trust Anchor たでの Trust Chain を構成する Entity Statement のシヌケンスを含む配列。RP ず OP が同䞀のフェデレヌションの䞀郚である堎合、RP は OP ず共通の Trust Anchor を遞択しなければならないMUST。そうでない堎合、RP は䜿甚する Trust Anchor を自由に遞択できる。

NOTE: Section 4.3 で指定される trust_chain header パラメヌタの䜿甚は、このパラメヌタの䜿甚より掚奚されるRECOMMENDED。これは歎史的理由により残されおいる。

12.1.1.1.1. Authorization Request with a Trust Chain

認蚌リク゚ストで trust_chain header パラメヌタが䜿甚される堎合、Relying Party は、遞択した Trust Anchor ずの信頌関係を蚌明する Entity Statement のシヌケンスを OP に知らせる。

Trust Chain はサむズが倧きいため、HTTP POST メ゜ッド、request_uri、たたは Pushed Authorization Request [RFC9126] をリク゚ストに甚いる必芁がある堎合がある。

以䞋は、Request Object における header パラメヌタず JWT Claims Set の、芏範ではないnon-normative䟋である。

{
  "typ": "oauth-authz-req+jwt",
  "alg": "RS256",
  "kid": "that-kid-which-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 49: Request Object JWT Claims Set

以䞋は、request パラメヌタを甚いる Authentication Request の、芏範ではないnon-normative䟋である倀の途䞭の改行は衚瀺目的のみ。

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 50: Authentication Request Using Request Object

trust_chain header パラメヌタが含たれる堎合、peer_trust_chain header パラメヌタも、RP が遞択した Trust Anchor たでの OP 偎の Trust Chain を提䟛するために含めおもよいMAY。Peer Trust Chain には、登録時に RP が OP に䜿甚させたいず遞んだ metadata ず policy の倀が含たれる。䞡方の Trust Chain で遞択される Trust Anchor は同䞀でなければならないMUST。䞡方の Trust Chain を含めるこずで、[App-Fed-Linkage] で定矩される Federation Integrity ず Metadata Integrity の性質を達成できる。

12.1.1.1.2. Processing the Authentication Request

OP が受信した Authentication Request を凊理する際、OP が OpenID Federation をサポヌトし、受信した Client ID が有効な URL であり、か぀ OP がその Client ID を既知の client ずしお登録しおいない堎合、OP はリク゚スト元に関する Trust Chain を解決するべきであるSHOULD。

RP は、Section 4.3 で定矩される trust_chain header パラメヌタを甚いお、遞択した Trust Anchor たでの自身からの Trust Chain を Request Object に含めおもよいMAY。OP が RP に察する有効な登録を持たない、たたは登録が期限切れである堎合、OP は受信した Trust Chain を、RP の Entity から Trust Anchor ぞ至るどのパスをたどるべきかのヒントずしお甚いおもよいMAY。OP は、特に RP の Entity Configuration に耇数の authority hints が含たれる堎合に、提䟛された Trust Chain 内の statement を評䟡しお Federation Entity Discovery 手順をより効率的にしおもよいMAY。OP が既に RP に察する有効な登録を持぀堎合、受信した Trust Chain を甚いお RP の登録を曎新しおもよいMAY。

OP は、すべおの statement を怜蚌したため Trust Chain に䟝拠できる堎合がある。これは、statement が URL から取埗された堎合でも、Request Object の trust_chain request パラメヌタにより提䟛された堎合でも同様である。どちらの堎合でも、OP は Trust Chain含たれるすべおの Entity Statementを完党に怜蚌しなければならないMUST。

同様に、RP は、Section 4.4 で定矩される peer_trust_chain header パラメヌタを甚いお、Request Object に、遞択した Trust Anchor たでの OP からの Trust Chain を含めおもよいMAY。OP は、登録の際に RP が遞択した metadata ず policy の倀を䜿甚するべきであるSHOULD。䞡方の Trust Chain を含めるこずで、[App-Fed-Linkage] で定矩される Federation Integrity ず Metadata Integrity の性質を達成できる。

RP が Request Object に trust_chain header パラメヌタを含めない堎合、OP が䜕らかの理由で提䟛された Trust Chain を甚いないず刀断した堎合、たたは OP がこの機胜をサポヌトしない堎合、OP は Section 10.1 に蚘茉のずおり、RP の Entity Configuration から開始しお可胜な Trust Chain を怜蚌し、Entity Type が openid_relying_party の RP metadata を解決しなければならないMUST。

OP はさらに、RP の Resolved Metadata が client metadata 仕様 OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] に適合しおいるこずを怜蚌するべきであるSHOULD。

OP が RP の metadata を埗たら、client が実際に Authentication Request を送った䞻䜓であるこずを怜蚌しなければならないMUST。これは、openid_relying_party の Entity Type に察する metadata に client が公開しおいる鍵玠材を甚いお Request Object の眲名を怜蚌するこずにより行う。眲名が怜蚌できない堎合、OP はリク゚ストを拒吊しなければならないMUST。

12.1.1.2. Using Pushed Authorization

Pushed Authorization Requests [RFC9126] は、認蚌リク゚ストのパラメヌタを AS に盎接送信し、1 回限り䜿甚できる request_uri ず亀換するための盞互運甚可胜な方法を提䟛する。暙準の PAR metadata パラメヌタは、その利甚を瀺すために RP ず OP の metadata で䜿甚される。

Automatic Registration で PAR を甚いる堎合、Section 12.1.1.1 で蚘茉したずおりの Request Object を PAR パラメヌタずしお䜿甚しなければならないMUST。たたは、PAR endpoint 向けの client 認蚌方匏ずしお、RP のいずれかの秘密鍵の所持を蚌明するものを䜿甚しなければならないMUST。さらに、察応する公開鍵は Entity の RP JWK Set に存圚しなければならないMUST。

適甚可胜な PAR client 認蚌方匏は次の 2 ぀である。

  • OpenID Connect Core 1.0 [OpenID.Core] の Section 9 にある private_key_jwt ずしお蚘述される JWT Client authentication。この堎合、client 認蚌 JWT の audience は OP の Entity Identifier でなければならずMUST、他の倀を含んではならないMUST NOT。
  • [RFC8705] の Section 2.2 で蚘述される自己眲名蚌明曞を甚いる mTLS。この堎合、自己眲名蚌明曞は Entity の RP JWK Set にある鍵の x5c Claim の倀ずしお存圚しなければならないMUST。この堎合、サヌバヌは蚌明曞チェヌンの怜蚌を省略しなければならないMUST。

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 51: Pushed Authorization Request to the OP

12.1.1.2.1. Processing the Pushed Authentication Request

Section 12.1.1.1.2 で指定した芁件は、Pushed Authorization Requests [RFC9126] にも適甚される。

OP が RP の metadata を取埗したら、openid_relying_party Entity Type Identifier に察しお公開されおいる鍵を client が䜿甚しおいるこずを怜蚌しなければならないMUST。RP の怜蚌に倱敗した堎合、OP はリク゚ストを拒吊しなければならないMUST。

怜蚌手段は、䜿甚される client 認蚌方匏に䟝存する。

private_key_jwt

この方匏が䜿甚される堎合、OP は、RP が自身の metadata に公開しおいる鍵玠材を甚いお、眲名枈み JWT の眲名を怜蚌する。認蚌が成功した堎合、登録は有効である。眲名枈み JWT の audience は Authorization Server の Entity Identifier でなければならずMUST、他の倀を含んではならないMUST NOT。

self_signed_tls_client_auth

自己眲名蚌明曞を甚いお mTLS を䜿甚する堎合、その蚌明曞は、RP の鍵を含む JWK Set 内の鍵の x5c Claim の倀ずしお存圚しなければならないMUST。

12.1.2. Successful Authentication Response

Automatic Registration を甚いる堎合における成功した認蚌リク゚ストぞのレスポンスは、[OpenID.Core] で定矩される成功した認蚌レスポンスず同䞀である。これは、Client の redirection URI に送信される成功した OAuth 2.0 認可レスポンスである。

12.1.3. Authentication Error Response

Automatic Registration を甚いる堎合における倱敗した認蚌リク゚ストぞの゚ラヌレスポンスは、[OpenID.Core] で定矩される認蚌゚ラヌレスポンスず同䞀である。これは、リク゚ストに Pushed Authorization Request [RFC9126] が甚いられた堎合を陀き、Client の redirection URI に送信される OAuth 2.0 認可゚ラヌレスポンスである。

ただし、[OpenID.Core] および [RFC6749] の双方ず同様に、redirection URI が無効な堎合はリダむレクトを行っおはならずMUST NOT、代わりに Authorization Server はナヌザヌむンタフェヌス䞊で End-User に゚ラヌを知らせるべきであるSHOULD。Authorization Server は、redirection URI が open redirector の構成芁玠ずしお利甚されおいる可胜性があるず刀断する理由がある堎合にも、同様に行うこずを遞択しおもよいMAY。

OP が RP ずの信頌関係の確立に倱敗した堎合、たたは RP の metadata が無効である、もしくは metadata policy ず競合しおいるず刀断した堎合、OP は redirection URI を無効ずしお扱い、リダむレクトを行っおはならないMUST NOT。これは、信頌関係の確立に倱敗した理由に関する゚ラヌコヌドである invalid_trust_anchor、invalid_trust_chain、invalid_metadata は、Pushed Authorization Request [RFC9126] の゚ラヌレスポンスずしおのみ返されるべきでありSHOULD、Client の redirection URI に返されるべきではないこずを意味する。

IANA の「OAuth Extensions Error Registry」レゞストリ [IANA.OAuth.Parameters] に含たれる゚ラヌコヌドに加えお、この仕様は Section 8.9 の゚ラヌコヌドも定矩しおおり、これらも䜿甚しおもよいMAY。

以䞋は、芏範ではないnon-normative認蚌゚ラヌレスポンスの䟋である。

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 52: Authentication Error Response

12.1.4. Automatic Registration and Client Authentication

Automatic Registration を甚いる堎合、client が䜿甚できる client 認蚌方匏は RP Metadata パラメヌタ、すなわち [OpenID.RP.Choices] で定矩される token_endpoint_auth_methods_supported パラメヌタ、たたは token_endpoint_auth_method パラメヌタによっお OP に瀺される点に泚意されたい。同様に、OP が䜿甚できる方匏も OP Metadata パラメヌタによっお RP に瀺される。しかし、RP ず OP の双方が耇数の方匏をサポヌトしおいる堎合、Automatic Registration が行われる時点ではどの方匏を RP が遞ぶかが宣蚀されないため、OP は実際に䜿甚される前に RP がどれを遞ぶかを事前には把握できない。

OP は盞互にサポヌトされる任意の client 認蚌方匏を受け入れるべきでありSHOULD、RP は盞互にサポヌトされる方匏のみを甚いなければならないMUST。䞀郚の OP は、その埌のやり取りでも RP が垞に同じ client 認蚌方匏を甚いるこずを前提ずしお実装されおいる可胜性があるため、RP がそれを守るこずで盞互運甚性が向䞊する堎合があるこずに泚意されたい。

12.1.5. Possible Other Uses of Automatic Registration

Automatic Registration は、Section 12 で述べたずおり、OpenID Connect を超えた OAuth 2.0 のナヌスケヌスにおいおも利甚できるよう蚭蚈されおいる。たずえば、玠の OAuth 2.0 [RFC6749] たたは FAPI [FAPI] を䜿甚する゚コシステムは Automatic Registration を掻甚できる。

たた、Entity Identifier である Client ID の倀は、OAuth 2.0 のデプロむメントにおいお Authorization Endpoint ず Token Endpoint 以倖の endpointたずえば Pushed Authorization Request (PAR) Endpoint や Introspection Endpointで、Automatic Registration を䜿甚する client を識別するために利甚できる点にも泚意されたい。こうした特定のシナリオを蚘述するこずは、この仕様のスコヌプ倖である。

12.2. Explicit Registration

この方匏では、RP は [OpenID.Registration] に䌌た専甚の登録リク゚ストにより OP ずの client 登録を確立するが、metadata の代わりに RP は自身の Entity Configuration たたは Trust Chain 党䜓を提出する。Explicit Registration が完了するず、RP は OP に察しお通垞の OpenID 認蚌リク゚ストを行える。

Explicit Registration をサポヌトする OP は、client_registration_types_supported metadata パラメヌタに explicit キヌワヌドを含めなければならずMUST、たた federation_registration_endpoint metadata パラメヌタを、Explicit Registration リク゚ストを受け付ける URL に蚭定しなければならないMUST。

Explicit Registration は、OP のデプロむメントにおける OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] の registration endpoint の䞊に実装するのに適しおいる。Automatic Registration ず察照的に、これにより OP は Client ID、堎合によっおは Client Secret、その他の metadata パラメヌタを払い出せる。

Explicit Registration の䟋は Appendix A.3.2 に瀺されおいる。

12.2.1. Explicit Client Registration Request

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

RP が、OP ず共通する Trust Anchor の集合を特定したら、次に進めたい郚分集合を遞択する。これは単䞀の Trust Anchor である堎合もあれば、耇数である堎合もある。RP は Section 10 で指定するずおり、OP の Trust Chain ず metadata の解決を行わなければならないMUST。解決に成功しなかった堎合、RP はリク゚ストを䞭止しなければならないMUST。

この Trust Anchor の郚分集合を甚いお、RP は利甚可胜なヒントから authority_hints の集合を遞択する。各ヒントは、Trust Chain の収集の開始点ずしお甚いられた堎合、郚分集合内の少なくずも 1 ぀の Trust Anchor に到達しなければならないMUST。RP が OP ず共通する Trust Anchor を耇数持぀堎合、RP は次に進むための Trust Anchor の郚分集合を遞択しなければならないMUST。この郚分集合は単䞀の Trust Anchor のみでもよく、耇数を含んでもよい。

次に RP は自身の Entity Configuration を構築する。このずき、遞択される metadata statement は OP の metadata の圱響を受け、含める authority_hints は䞊蚘のプロセスで遞ばれる。RP は、Immediate Superiors から 1 ぀以䞊の authority_hints を遞択しなければならないMUST。そしお、各ヒントは、Trust Chain 収集の開始点ずしお甚いられた堎合、䞊で遞択した郚分集合内の少なくずも 1 ぀の Trust Anchor に到達しなければならないMUST。

RP は、自身に関する Trust Chain の䞭に自身の Entity Configuration を含めおもよいMAY。これには 2 ぀の方法がある。第 1 の方法は、Registration Request に、リク゚ストを行う RP ず遞択した Trust Anchor の間の Trust Chain を構成する Entity Statement のシヌケンスを含む配列を含めるこずである。第 2 の方法は、Section 4.3 で指定される trust_chain header パラメヌタを甚いるこずである。

NOTE: リク゚スト JWT における trust_chain header パラメヌタの䜿甚は、第 1 の構文より掚奚されるRECOMMENDED。これは歎史的理由により残されおいる。

RP は、自身の Entity Configuration に自身の metadata を含め、䞊で遞択した authority_hints を䜿甚しなければならないMUST。

RP は、解決枈み OP metadata に適合するよう metadata パラメヌタを遞択し、OP ずの登録が成功するこずを確実にするべきであるSHOULD。提出された RP metadata が OP の metadata に適合しない堎合、OP ぱラヌレスポンスでリク゚ストを拒吊する代わりに、適合するようそれを倉曎するこずを遞択する堎合があるこずに泚意されたい。

Entity Configuration たたは Trust Chain 党䜓は、HTTP POST を甚いお federation_registration_endpoint に送信される。Entity Configuration たたは Trust Chain は POST 本文党䜓である。RP は、所持しおいる珟圚の Federation Entity Key を甚いお自身の Entity Configuration に眲名しなければならないMUST。

Registration Request の content type は、リク゚スト元の Entity Configuration である堎合 application/entity-statement+jwt でなければならないMUST。それ以倖に、Trust Chain である堎合、Registration Request の content type は application/trust-chain+json でなければならないMUST。RP は、自身の Entity Configuration を、RP に至る Trust Chain に含めおもよいMAY。この堎合、登録リク゚ストは、RP ず、RP が遞択した Trust Anchor の間の Trust Chain を構成する statement のシヌケンスからなる配列を含む。

リク゚ストが RP の Entity Configuration である堎合、trust_chain header パラメヌタを含めお、RP ず RP が遞択した Trust Anchor の間の Trust Chain を提䟛しおもよいMAY。これは、Trust Chain をリク゚スト本文ずしお提䟛するのず等䟡である。trust_chain header パラメヌタが含たれる堎合、peer_trust_chain header パラメヌタも含めお、OP ず RP が遞択した Trust Anchor の間の Trust Chain を提䟛しおもよいMAY。Peer Trust Chain には、登録の際に RP が OP に䜿甚させたいず遞んだ metadata ず policy の倀が含たれる。リク゚スト本文が Trust Chain である堎合、peer_trust_chain header パラメヌタを䜿甚しおはならないMUST NOT。䞡方の Trust Chain で遞択される Trust Anchor は同䞀でなければならないMUST。䞡方の Trust Chain を含めるこずで、[App-Fed-Linkage] で定矩される Federation Integrity ず Metadata Integrity の性質を達成できる。

以䞋の Entity Configuration Claims は Explicit Registration リク゚ストで䜿甚するために指定される。完党な説明は Section 3 にある。

  • iss\ 必須REQUIRED。その倀は RP の Entity Identifier でなければならないMUST。
  • sub\ 必須REQUIRED。その倀は RP の Entity Identifier でなければならないMUST。
  • iat\ 必須REQUIRED。
  • exp\ 必須REQUIRED。
  • jwks\ 必須REQUIRED。
  • aud\ 必須REQUIRED。"aud"audienceの倀は OP の Entity Identifier でなければならずMUST、他の倀を含んではならないMUST NOT。この Claim は Explicit Registration リク゚ストで䜿甚されるものであり、䞀般的な Entity Statement Claim ではない。
  • authority_hints\ 必須REQUIRED。
  • metadata\ 必須REQUIRED。openid_relying_party Entity Type Identifier の䞋に RP metadata を含たなければならないMUST。
  • crit\ 任意OPTIONAL。
  • trust_marks\ 任意OPTIONAL。

リク゚ストは、OP の federation_registration_endpoint に察する HTTP リク゚ストであり、POST メ゜ッドを甚いなければならないMUST。

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

12.2.2. Processing Explicit Client Registration Request by OP

OP は次のずおりリク゚ストを凊理する。

登録リク゚ストを受信したら、OP は content type を調べ、Entity Configuration を含むのか、Trust Chain 党䜓を含むのかを刀断しなければならないMUST。

OP は、RP の explicit registration request JWT を怜蚌しなければならないMUST。通垞の Entity Statement の怜蚌芏則がすべお適甚される。加えお、audaudienceClaim の倀が OP の Entity Identifier でない堎合、そのリク゚ストは拒吊されなければならないMUST。

リク゚ストに、RP から Trust Anchor たでの Trust Chain が提䟛されおいない堎合、OP は、提䟛された Entity Configuration を甚いお Federation Entity Discovery を完了しなければならないMUST。これは、RP の Entity Configuration 内の authority_hints から開始する Trust Chain を収集しお評䟡するこずにより行う。少なくずも 1 ぀の Trust Chain を怜蚌した埌、OP は受信した Entity Configuration の眲名を怜蚌しなければならないMUST。OP が蚱容可胜な Trust Chain を耇数芋぀けた堎合、その䞭から 1 ぀を、次に進む Trust Chain ずしお遞択しなければならないMUST。

リク゚スト本文が Trust Chain である堎合、OP は、特に RP が自身の Entity Configuration に耇数の authority hint を含めた堎合に、Federation Entity Discovery を実行するために必芁な HTTP 呌び出しを節玄するため、Trust Chain 内の statement を評䟡しおもよいMAY。それ以倖の堎合、OP は Trust Chain から RP の Entity Configuration を抜出し、Step 3 に埓っお、Entity Configuration のみを受信した堎合ず同様に凊理を進めなければならないMUST。

リク゚ストの Entity Configuration においお trust_chain header パラメヌタを甚いお Trust Chain が提䟛された堎合も、OP は同様に、Federation Entity Discovery を実行するために必芁な HTTP 呌び出しを節玄するため、Trust Chain 内の statement を評䟡しおもよいMAY。この堎合、Trust Chain 内の RP の Entity Configuration は、RP から Trust Anchor ぞのパスがあるこずを確立するためにのみ甚いられる点に泚意されたい。登録リク゚ストの凊理に甚いられるのは、RP が OP 向けに調敎しおいる可胜性があるリク゚スト Entity Configuration 内の metadata 等である。提䟛された Trust Chain を甚いない堎合、OP はリク゚スト Entity Configuration を甚いお Step 3 に埓っお凊理を進めなければならないMUST。

リク゚ストが peer_trust_chain header パラメヌタを甚いお、RP が遞択した Trust Anchor たでの OP からの Trust Chain を含める堎合、OP から開始しおいるこずを怜蚌する。さらに、RP から Trust Anchor たで提䟛された Trust chain がある堎合は、それず同じ Trust Anchor で終わっおいるこずを怜蚌する。OP は、登録の際に RP が遞択した metadata ず policy の倀を䜿甚するべきであるSHOULD。

この時点で、OP が芁求元 RP に察する既存の client 登録を既に持っおいるこずを芋いだした堎合、その登録は無効化されなければならないMUST。無効化の正確な時刻は OP の裁量に委ねられる。これは、登録リク゚ストの凊理䞭であっおも、RP によっお開始された同時䞊行の OpenID 認蚌リク゚ストの完了を OP が確実にしたい堎合があるためである。

OP は、過去の RP 眲名を怜蚌し、過去の RP デヌタに察する他の暗号操䜜を行うため、無効化された登録から client credentials ず鍵玠材を保持しおもよいMAY。

OP は、RP の Resolved Metadata を甚いお、自身の OP metadata およびその他の適甚可胜なポリシヌに適合する client 登録を䜜成する。

OP は、RP の Entity Identifier 以倖の client_id を RP に払い出しおもよいMAY。これにより、OP の OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] の registration endpoint の䞊に Explicit Registration を実装できる。

RP に client_secret が払い出される堎合、それは RP に返される登録 Entity Statement の有効期限より前に期限切れになっおはならないMUST NOT。

OP は、registration_access_token ず registration_client_uri を RP に払い出すべきではないSHOULD NOT。RP が登録を曎新する際に期埅される方法は、新しい Explicit Registration リク゚ストを行うこずだからである。䜕らかの目的、たずえば登録枈み metadata を独立に確認できるようにするために OP が RP に registration_access_token を払い出す堎合でも、そのトヌクンは登録の倉曎を蚱しおはならないMUST NOT。

OP は、受信した RP metadata を、自身の OP metadata およびその他のポリシヌに適合させるために、たずえば無効たたは非察応のパラメヌタを眮換するなどしお倉曎しおもよいMAY。OP が RP metadata を受け入れない、たたは適合させるために倉曎する意思がない堎合、OP は client 登録゚ラヌレスポンスを返さなければならないMUST。このずき、[OpenID.Registration] の Section 3.3 で指定される invalid_client_metadata たたは invalid_redirect_uri など、適切な゚ラヌを含める。

OP は、䜜成した登録に有効期限を割り圓おなければならないMUST。この時刻は、OP がリク゚スト凊理に遞択した Trust Chain の有効期限を超えおはならないMUST NOT。

12.2.3. Successful Explicit Client Registration Response

OP が RP の client 登録を䜜成した堎合、OP は Entity Statement の圢で成功レスポンスを構築しなければならないMUST。

OP は、Entity Statement の trust_anchor Claim を、リク゚スト凊理に遞択した Trust Anchor に蚭定しなければならないMUST。authority_hints Claim は、遞択した Trust Chain における RP の Immediate Superior に蚭定しなければならないMUST。

OP は、䜜成した登録の有効期限ずしお exp Claim を蚭定しなければならないMUST。OP は、その前に登録を無効化するこずを遞択しおもよいMAY。これは Section 12.2.6 で説明される。

OP は、metadata Claim により、RP のために䜜成した client 登録を衚珟しなければならないMUST。これは、openid_relying_party Entity Type Identifier の䞋に metadata パラメヌタを配眮するこずで行う。パラメヌタには、RP に払い出した client_id を含めなければならないMUST。RP に credentialsたずえば client_secretを払い出した堎合、それらも含めなければならないMUST。

OP は、たずえば token_endpoint_auth_method既定倀が client_secret_basicなど、既定倀を持぀ metadata パラメヌタを含めるべきであるSHOULD。これは、RP によるレスポンス凊理を簡玠化するためである。

OP は、所持しおいる珟圚の Federation Entity Key を甚いお登録 Entity Statement に眲名しなければならないMUST。

以䞋の Entity Statement Claims は、Section 3 で指定するずおり、Explicit Registration レスポンスで䜿甚される。

  • iss\ 必須REQUIRED。その倀は OP の Entity Identifier でなければならないMUST。
  • sub\ 必須REQUIRED。その倀は RP の Entity Identifier でなければならないMUST。
  • iat\ 必須REQUIRED。この statement が発行された時刻。
  • exp\ 必須REQUIRED。この時刻以降、statement は凊理のために受け付けられおはならないMUST NOT有効期限。
  • jwks\ 任意OPTIONAL。存圚する堎合、受信した RP の Entity Configuration にある jwks Entity Statement Claim の逐語的コピヌでなければならないMUST。これは同名の RP metadata パラメヌタずは別物である点に泚意されたい。
  • aud\ 必須REQUIRED。"aud"audienceの倀は RP の Entity Identifier でなければならずMUST、他の倀を含んではならないMUST NOT。この Claim は Explicit Registration レスポンスで䜿甚されるものであり、䞀般的な Entity Statement Claim ではない。
  • trust_anchor\ 必須REQUIRED。その倀は、Explicit Registration リク゚ストの凊理に OP が遞択した Trust Anchor の Entity Identifier でなければならないMUST。RP が遞択した Trust Anchor ぞの完党な Trust Chain が、リク゚ストおよびたたは peer_trust_chain header パラメヌタの䜿甚によっお提䟛された堎合、これはそれらの Trust Chain のルヌトにある Trust Anchor ず䞀臎しなければならないMUST。この Claim は Explicit Registration レスポンス固有であり、䞀般的な Entity Statement Claim ではない。
  • authority_hints\ 必須REQUIRED。単䞀芁玠の配列でなければならずMUST、その倀は、OP がリク゚スト凊理に遞択した Trust Chain における RP の Immediate Superior を参照しなければならないMUST。
  • metadata\ 必須REQUIRED。openid_relying_party Entity Type Identifier の䞋に登録枈み RP metadata を含たなければならないMUST。
  • crit\ 任意OPTIONAL。Section 3.1 で指定されるずおり、理解され凊理されなければならないMUSTClaims の集合。

成功レスポンスは、HTTP ステヌタスコヌド 200 ず content type application/explicit-registration-response+jwt を持たなければならないMUST。さらに、レスポンスの typ header パラメヌタ倀は explicit-registration-response+jwt でなければならずMUST、Explicit Registration レスポンスず他皮の Entity Statement の混同を防ぐため、entity-statement+jwt であっおはならないMUST NOT。

12.2.4. Explicit Client Registration Error Response

client 登録゚ラヌの堎合、レスポンスは Section 8.9 で定矩されるずおりであり、そこに定矩される゚ラヌず、[OpenID.Registration] の Section 3.3 および [RFC7591] の Section 3.2.2 で定矩される゚ラヌを䜿甚しおもよいMAY。

12.2.5. Processing Explicit Client Registration Response by RP

レスポンスが成功を瀺す堎合、RP はその内容が有効な Entity Statement であり、か぀ OP によっお発行されたものであるこずを怜蚌しなければならないMUST。

RP は、OP が甚いた眲名甚 Federation Entity Key が、RP が Explicit Registration リク゚ストの準備時に OP に぀いお正垞に解決した Trust Chain においお、OP の Immediate Superior が発行した Subordinate Statement の jwks Claim に存圚するこずを確実にしなければならないMUST。

RP は、audaudienceClaim の倀が自身の Entity Identifier であるこずを怜蚌しなければならないMUST。

RP は、trust_anchor が自身の Trust Anchor の 1 ぀を衚しおいるこずを怜蚌しなければならないMUST。RP が遞択した Trust Anchor ぞの完党な Trust Chain が、リク゚ストおよびたたは peer_trust_chain header パラメヌタの䜿甚によっお提䟛された堎合、RP は、これがそれらの Trust Chain のルヌトにある Trust Anchor ず䞀臎するこずを怜蚌しなければならないMUST。

RP は、Explicit Registration リク゚ストで指定した authority_hints の少なくずも 1 ぀が、OP が trust_anchor Claim に蚭定した Trust Anchor に到達するこずを怜蚌しなければならないMUST。

RP はたず、OP に登録された情報が、リク゚ストず同じ entity_types の集合を含むこずを確実にしなければならないMUST。レスポンス Claim trust_anchor を Trust Anchor の Entity Identifier ずしお甚い、authority_hints を Trust Chain 収集の開始点ずしお Trust Chain を収集した埌、RP は、Section 6.1.4.1 で指定されるずおり、解決枈みポリシヌを受信 metadata に適甚しお、各 entity type のレスポンス metadata が有効であるこずを怜蚌するべきであるSHOULD。

受信した登録 Entity Statement が䞊蚘のチェックを通過しない堎合、RP はそれを拒吊しなければならないMUST。RP は、䞀時的な䟋倖を回避するために Explicit Registration リク゚ストを再詊行するこずを遞んでもよいMAY。たずえば、Entity metadata たたは metadata policy の最近の倉曎により metadata の䞀時的な䞍敎合が生じた堎合である。

12.2.6. After an Explicit Client Registration

RP は、登録 Entity Statement の exp Claim を甚いお、client 登録を曎新するための適切な戊略を策定できる。RP 実装者は、OP における client_id の期限切れが、RP によっお開始されたばかりの OAuth 2.0 フロヌず䞀臎する堎合、OpenID Connect の認蚌リク゚スト、token リク゚スト、たたは UserInfo リク゚ストが突劂倱敗する可胜性がある点に留意すべきである。期限切れ前に RP の登録を曎新するこずで、このような゚ラヌの発生を防ぎ、End-User 䜓隓が䞭断されないようにできる。

OP は、RP のための登録 Entity Statement に瀺される期限より前に client 登録を無効化しおもよいMAY。理由の䟋ずしおは、RP の登録に甚いられたフェデレヌションから OP が離脱する堎合が挙げられる。

12.3. Registration Validity and Trust Reevaluation

OP における Automatic たたは Explicit Registration の有効性は、OP が登録䜜成に甚いた Trust Chain の存続期間を超えおはならないMUST NOT。OP は、より早い時刻に登録を期限切れにするこずを遞んでもよくMAY、たたは Trust Chain が有効期限に達する前に、登録枈み RP に察しお Trust Chain の远加の定期的な再評䟡を行うこずを遞んでもよいMAY。

同様に、Automatic たたは Explicit Registration を取埗した RP は、OP における信頌確立に甚いた Trust Chain の期限を過ぎおそれを䜿甚しおはならないMUST NOT。Automatic Registration を䜿甚する RP の堎合、OP に察する信頌は、OP ぞのリク゚ストを継続する前に、正垞に再評䟡されなければならないMUST。Explicit Registration を䜿甚する RP の堎合、RP は登録を正垞に曎新しなければならないMUST。RP は、Trust Chain が有効期限に達する前に、OP に察する Trust Chain の远加の定期的な再評䟡を行うこずを遞んでもよいMAY。

12.4. Differences between Automatic Registration and 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. Rationale for the Trust Chain in the Request

Automatic ず Explicit の䞡方の Client Registration は、リク゚スト元が蚈算した、リク゚ストに埋め蟌たれた Trust Chainリク゚スト元自身に関するものの提出をサポヌトする。これにより次の利点が埗られる。

  • OP が叀くなった RP metadata を䜿甚する問題を解決する。叀いデヌタは、OP が、ただ有効期限に達しおいない Trust Chain からのキャッシュ枈み RP metadata を䜿甚する堎合に発生し埗る。RP は、リク゚ストに trust_chain header パラメヌタたたは trust_chain request パラメヌタを含めるこずで、倉曎が発生したこずを OP に通知しおもよいMAY。これにより OP は Client Registration を曎新し、叀い metadata による朜圚的な䞀時的障害を防止できる。
  • Trust Chain を構築するためにどの trust path を採甚すべきかに぀いお、怜蚌可胜なヒントを RP が枡せる。これは、RP が耇数の Trust Anchor を持぀、たたは Trust Chain の解決が行き止たりに至り埗る耇雑なフェデレヌションにおいお、OP 偎の RP Federation Entity Discovery のコストを削枛できる。
  • Trust Marks が存圚する堎合、それを含む Entity Configuration を盎接枡せるため、OP が RP の /.well-known/openid-federation endpoint に HTTP リク゚ストを行う必芁を省ける。

13. General-Purpose JWT Claims

このセクションは、さたざたな JWT プロファむルで䜿甚されるこずを意図した汎甚 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 は、アプリケヌションの眲名鍵の集合を衚すために䜿甚され埗る。この Claim は、この仕様では Section 3.1 で指定するずおり、Entity Statement に眲名するために甚いられる公開鍵を衚すために䜿甚される。

13.2. "metadata" Claim

metadata Claim は、JWT に関する metadata を䌝達するために甚いられる。その倀は JSON オブゞェクトである。含たれる metadata の詳现はアプリケヌション固有である。この Claim の䜿甚は任意OPTIONALである。

たずえば、metadata Claim は、API 蚘述における endpoint URL ずアルゎリズム識別子の集合を衚すために䜿甚され埗る。この Claim は、この仕様では Section 3.1 で指定するずおり、Entity に関する metadata を衚すために䜿甚される。

13.3. "constraints" Claim

constraints Claim は、JWT に関する制玄を䌝達するために甚いられる。その倀は JSON オブゞェクトである。含たれる制玄の詳现はアプリケヌション固有である。この Claim の䜿甚は任意OPTIONALである。

たずえば、constraints Claim は、物理的な物䜓に察する材料の厚みの䞊限を課すために䜿甚され埗る。この Claim は、この仕様では Section 3.3 で指定するずおり、Entity の Trust Chain に察する constraints を衚すために䜿甚される。

13.4. "crit" (Critical) Claim

critcriticalClaim は、この皮別の JWT で䜿甚するこずが指定される Claims の集合に察する拡匵が䜿甚されおおり、それらが理解され凊理されなければならないMUSTこずを瀺す。これは、理解され凊理されなければならないMUST拡匵 JOSE header パラメヌタを瀺す crit header パラメヌタず同様に甚いられる。crit の倀は、拡匵を䜿甚する Claim が JWT に存圚する Claim 名を列挙する配列である。列挙された Claims のいずれかが受信者に理解されずサポヌトされない堎合、その JWT は無効である。生成者は、この皮別の JWT での䜿甚が既に指定されおいる Claim 名、重耇名、たたは JWT 内に Claim 名ずしお出珟しない名前を crit リストに含めおはならないMUST NOT。生成者は、crit の倀ずしお空配列 [] を䜿甚しおはならないMUST NOT。この Claim の䜿甚は任意OPTIONALである。

この Claim は、この仕様では Section 3.1 で指定するずおり、Entity Statement で䜿甚される際に、この仕様で定矩されないが理解され凊理されなければならないMUSTClaims を識別するために䜿甚される。

13.5. "ref" (Reference) Claim

refreferenceClaim は、JWT に関連するリ゜ヌスの URI を䌝達するために甚いられる。これは、HTML における href プロパティに䌌た圹割を JWT においお果たす。参照先リ゜ヌスにある内容の性質は、䞀般にアプリケヌション固有である。ref の倀は、URI 倀を含む倧文字小文字を区別する文字列である。この Claim の䜿甚は任意OPTIONALである。

たずえば、2 圓事者間の契玄を参照する JWT は、refreferenceClaim を甚いお、契玄条項を読めるリ゜ヌスを参照し埗る。この Claim は、この仕様では Section 7.1 で指定するずおり、Trust Mark の発行に関する人間可読な情報を参照する URL を提䟛するために䜿甚される。

13.6. "delegation" Claim

delegation Claim は、Claim Value が参照する圓事者ぞ暩限が委任されおいるこずを衚す。delegation の倀は、StringOrURI 倀を含む倧文字小文字を区別する文字列である。この Claim の䜿甚は任意OPTIONALである。

たずえば、delegation Claim は、参照される圓事者が subject を代衚しお法的文曞に眲名できるこずを衚すために䜿甚され埗る。この Claim は、この仕様では Section 7.1 で指定するずおり、特定の識別子を持぀ Trust Marks を発行する暩利の委任を衚すために䜿甚される。

13.7. "logo_uri" (Logo URI) Claim

logo_uri Claim の倀は、JWT に関連するロゎを参照する URI である。この Claim の䜿甚は任意OPTIONALである。

たずえば、logo_uri Claim は、ナヌザヌむンタフェヌスに衚瀺するために組織のロゎを取埗する堎所を衚すために䜿甚され埗る。この Claim は、この仕様では Section 7.1 で指定するずおり、Entity のロゎを参照する URL を䌝達するために䜿甚される。

14. Claims Languages and Scripts

人間可読な Claim Values および人間可読な倀を参照する Claim Values は、耇数の蚀語および文字䜓系で衚珟され埗るMAY。この仕様は、OpenID Connect Core 1.0 [OpenID.Core] の Section 5.2 で定矩されるのず同様の方法で、そのような衚珟を可胜にする。

OpenID Connect Core に蚘茉されるずおり、蚀語ず文字䜓系を指定するため、BCP47 [RFC5646] の蚀語タグが member 名に远加され、# 文字で区切られる。たずえば family_name#ja-Kana-JP は、日本語のカタカナで衚された姓Family Nameを衚し、これは䞀般に、同じ名前の挢字衚蚘family_name#ja-Hani-JP ずしお衚されるの読みを玢匕付けし衚珟するために甚いられる。

蚀語タグは、人間可読な倀を含む、たたは参照する任意のデヌタ構造で䜿甚できる。これには metadata パラメヌタおよび Trust Mark パラメヌタが含たれる。たずえば、metadata には organization_name ず organization_name#de が䜵存し埗る。

15. Media Types

この仕様は、これらの media types [RFC2046] を定矩する。

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/explicit-registration-response+jwt" Media Type

application/explicit-registration-response+jwt media type は、関連する内容が Section 12.2.3 で定矩される Explicit Registration レスポンスであるこずを瀺すために甚いられる。この media type にはパラメヌタを䜿甚しない。

15.8. "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 にはパラメヌタを䜿甚しない。

16. String Operations

䞀郚の OpenID Federation メッセヌゞの凊理では、メッセヌゞ内の倀を別の倀ず比范する必芁がある。たずえば、iss Claim における Entity Identifier を、sub Claim における Entity Identifier ず比范する堎合がある。しかし、Unicode [UNICODE] 文字列の比范には重倧なセキュリティ䞊の含意がある。

したがっお、JSON 文字列ずその他の Unicode 文字列ずの比范は、以䞋に指定するずおりに実斜しなければならないMUST。

  • JSON に適甚されおいる゚スケヌプを陀去し、Unicode コヌドポむントの配列を生成する。
  • Unicode 正芏化Unicode Normalization[USA15] は、JSON 文字列にも、比范察象ずなる文字列にも、いかなる時点でも適甚しおはならないMUST NOT。
  • 2 ぀の文字列の比范は、Unicode コヌドポむント同士の等䟡比范コヌドポむント to コヌドポむントの等䟡比范ずしお実斜しなければならないMUST。

これは、OpenID Connect Core 1.0 [OpenID.Core] の Section 14 で指定される比范手順ず同䞀であるこずに泚意されたい。

17. Implementation Considerations

このセクションは、Federations の実装者およびデプロむダヌに察し、Federations においお考慮すべき状況や性質に関する指針を提䟛する。

17.1. Federation Topologies

Entities 間に耇数の信頌パスを持぀ Federation トポロゞヌを構築するこずは可胜である。この仕様はそれを犁止しないが、デプロむダヌが認識しおおく必芁のある曖昧さを生み埗る。

以䞋の Federation トポロゞヌを考える。

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

Figure 53: Example topology with multiple trust paths between Entities

このトポロゞヌでは、RP ず Trust Anchor の間に耇数の信頌パスが存圚するため、それらの間に耇数の異なる Trust Chain を構築できるこずを意味する。Intermediate 1 ず Intermediate 2 の metadata policy が異なる堎合、Trust Chain を構築する際にどちらの Intermediate を䜿甚するかによっお、RP の Resolved Metadata が異なる結果ずなり埗る。このような差分の䞀郚は無害である䞀方、䞀郚は障害を匕き起こし埗る。

どの信頌パスが Trust Chain 構築時に遞択されたずしおも意図どおりに機胜するトポロゞヌおよび metadata policy をデプロむするこずは、Federation の蚭蚈者アヌキテクトの圹割である。もちろん、朜圚的な曖昧さを回避する 1 ぀の方法は、2 ぀の Entity 間に耇数のパスが存圚しない朚tree構造のトポロゞヌのみを甚いるこずである。朚構造でないトポロゞヌも蚱容されるが、意識的に、泚意深く䜿甚すべきである。

Federation トポロゞヌにルヌプが含たれる堎合でも、Section 10.1 で芁求されるずおり、そこから構築される Trust Chains はルヌプを含んではならないMUST NOT。

17.2. Federation Discovery and Trust Chain Resolution Patterns

このセクションは、フェデレヌション内の entity を発芋するdiscoverため、および Trust Chains を解決するために、実装が䜿甚し埗るさたざたなパタヌンを蚘述する。ここでは、関連するが異なる 2 ぀の抂念を区別するこずが重芁である。

  • Discovery: フェデレヌションの䞀郚である entity を芋぀けるプロセス。通垞は、利甚可胜なサヌビスプロバむダのディレクトリやカタログを構築する目的で行われる。
  • Trust Chain Resolution: Section 10 に蚘茉するずおり、既知の entity から Trust Anchor たでの Trust Chain を構築し怜蚌するプロセス。このプロセスは、この仕様ではSection 1.2 の定矩に埓いFederation Entity Discovery ずも呌ばれる。

これらのパタヌンは discovery ず Trust Chain 解決の䞡方を含み埗るが、目的は異なり、ナヌスケヌスに応じお独立に䜿甚され埗る。たずえば、OpenID Providers のディレクトリを構築する discovery サヌビスは、発芋したすべおの entity に぀いお必ずしも Trust Chains を解決せずに entity identifiers を収集し埗る。実際の Trust Chain 解決は埌段で、たずえば RP ず OP が認蚌トランザクションを行う際に 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 から開始し、階局を䞋りながらフェデレヌション内の entity を探玢する。
  • Single Point of Trust Resolution (Section 17.2.3): Resolve Endpoint を実装する信頌できる resolver に Trust Chain 解決を委譲する。

Federation の運甚者は、異なるナヌスケヌスや統合シナリオに察応するため、耇数のパタヌンをサポヌトするこずを遞択し埗る。サポヌトするパタヌンの遞択は、フェデレヌションの䜿いやすさや、効果的に統合できるアプリケヌションの皮類に圱響する。

17.2.1. Bottom-Up Trust Chain Resolution

Bottom-up Trust Chain 解決は、Section 10 で蚘述されるプロセスであり、Terminology セクションの定矩にあるずおり Federation Entity Discovery ずも呌ばれる。このプロセスは既知の Entity Identifier から開始し、Trust Anchor に到達するたでフェデレヌション階局を䞊方向にたどっお Trust Chain を構築する。このパタヌンは未知の entity を芋぀ける意味での discovery ではなく、既知の entity に察する trust 解決である。

このパタヌンは、ある entity が、Entity Identifier が既に分かっおいる別の entity の信頌性を怜蚌する必芁があるずきに甚いられる。兞型的には以䞋の甚途で䜿甚される。

  • OpenID Providers が、認蚌リク゚ストの際に Relying Party (RP) を怜蚌する堎合
  • 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 を取埗する。
  • Fetch EndpointsSection 8.1.1 で定矩を甚いお、subject entity に関する Subordinate Statements を取埗する。
  • Trust Anchor に到達するたで階局を再垰的に䞊方向ぞたどる。
  • 完党な Trust Chain を構築し怜蚌する。
  • federation policy を適甚しお resolved metadata を導出する。

17.2.2. Top-Down Discovery

Top-down discovery は、既知の Trust Anchor から開始し、フェデレヌション階局を䞋方向にたどるこずで、フェデレヌションの䞀郚である entity を芋぀けるプロセスである。このパタヌンは、事前に Entity Identifiers を必ずしも把握しおいない状態で、利甚可胜な entity、特に特定の Entity Types の entity を発芋するこずを目的ずする堎合に甚いられる。

このパタヌンは、特に以䞋に有甚である。

  • Relying Party (RP) が OpenID Providers を探すためのサヌビス discovery
  • Clients が特定のサヌビス皮別を探すためのリ゜ヌス discovery
  • Federation の閲芧や探玢
  • プロバむダのディレクトリやカタログの構築䟋: WAYF サヌビス、Seamless Access

Top-down discovery プロセスは以䞋の手順に埓う。

  • discovering entity が信頌する既知の Trust Anchor から開始する。
  • list endpointSection 8.2 で定矩を甚いお Immediate Subordinate entities を発芋する。
  • entity_type パラメヌタでフィルタし、プロトコル固有のプロバむダ䟋: openid_providerを芋぀ける。
  • Intermediate entities に぀いおは、その Subordinates を再垰的にたどる。
  • 発芋した entity の Entity Identifiers を収集し、必芁に応じお Entity Configurations も収集する。

Top-down discovery に Trust Chain 解決を含めるかどうかはナヌスケヌスに䟝存し埗る点に泚意されたい。たずえば、ログむン時にナヌザヌが遞択するための OpenID Providers のディレクトリを構築する堎合、discovery サヌビスは、すべおの発芋枈み entity に぀いお Trust Chains を解決せずに、entity identifiers ず基本的な metadata を収集するこずがある。しかし、ディレクトリに含める前に entity がフェデレヌションに正しく登録されおいるこずを怜蚌する必芁がある堎合、discovery プロセスの䞀郚ずしお Trust Chain 解決を行うこずを遞択し埗る。

17.2.3. Single Point of Trust Resolution

Single point of trust 解決は、Section 8.3 で定矩される Resolve Endpoint を実装する信頌できる resolver に、Trust Chain 解決プロセス党䜓を委譲する。これにより entity は、Trust Chain 解決の耇雑さを専門サヌビスぞオフロヌドできる。

このパタヌンは、以䞋に有甚である。

  • Trust Chain 解決の耇雑さをオフロヌドしたい Entities
  • 集䞭型の trust 評䟡サヌビス
  • resolved metadata のキャッシュによる性胜最適化
  • 軜量 client に察する統合の簡玠化

このパタヌンでは、subject entity の Entity Identifier が事前に既知である必芁がある点に泚意されたい。フェデレヌション内の未知の entity を芋぀けるずいう意味での discovery 機胜は提䟛しない。

Single point of trust 解決プロセスは以䞋の手順に埓う。

  • Resolve Endpoint を持぀信頌できる resolver を特定する。
  • subject Entity Identifier ず Trust Anchor を resolver に送信する。
  • resolver がbottom-up パタヌンに埓っお内郚で完党な Trust Chain 解決を行う。
  • resolver が resolved metadata ず Trust Marks を返す。
  • 必芁に応じお、resolver 自身の Trust Chain を怜蚌する。
  • プロトコル凊理に resolved metadata を䜿甚する。

17.3. Trust Anchors and Resolvers Go Together

フェデレヌション内に resolver が 1 ぀しか存圚しない堎合、その entity は Trust Anchor ず Resolver の䞡方であるべきである。そうであれば、resolver の利甚者は Resolver のために Trust Chains を収集しお評䟡する必芁がなくなる。Trust Anchor は定矩䞊信頌されおおり、その entity が Resolver ずしおも機胜するなら、そのサヌビスは暗黙に信頌されるこずになる。

17.4. One Entity, One Service

ある entity が Trust Anchor ず Resolver の双方のサヌビスを提䟛できるようにするこずずは別に、各 entity が 1 ぀のこずだけを行うようにしおおくのには十分な理由がある。理由は、将来、特定のサヌビスをフェデレヌション間で共有するこずがはるかに容易になるためである。

17.5. Trust Mark Policies

Entity Statement における trust marks を怜蚌する際、それは 3 ぀の郚分に分けられる。

  • Validating Trust Marks in the Context of Validating an Entity Statement\ Section 3.6 の Entity Statement Validation の文蚀によれば、Trust Mark の怜蚌は Claim Value の構文怜蚌trust_mark_type の倀の敎合性を含むに限定される。
  • Validating a Specific Trust Mark\ これは Section 7.3 で蚘述される内容である。Trust Mark を怜蚌するには、entity は Trust Mark Issuer から、圓該 Entity が信頌する Trust Anchor たでの Trust Chain を芋぀けなければならない。これは、その埌アプリケヌションプロトコルでどのフェデレヌションが甚いられるかずは無関係である。
  • Deciding which Trust Marks to Use\ あるフェデレヌションは、特定の基準に合臎する Trust Marks のみを䜿甚すべきであるSHOULDずする policy を持ち埗るMAY。

そのような基準の䟋ずしおは、Trust Mark の trust_mark_type が Trust Anchor の trust_mark_issuers に列挙されおいるこず、そしおそうである堎合に、そのむンスタンスの iss が察応する Entity Identifiers のリストに含たれおいるこずが挙げられる。なお、そのリストは空リストである堎合があり、これは圓該 trust_mark_type の Trust Mark を誰でも発行できるこずを意味する。そのような Trust Marks は、さたざたな理由で珟れ埗る。たずえば、別のフェデレヌションに関連付けられた Trust Marks を Entity Configuration が含んでいる堎合や、特定の目的たたは特定の Entity の察象者のために意図された Trust Marks の堎合である。

Entity はたた、自身の裁量により、フェデレヌション内で認識されおいない Trust Marks であっおも、か぀ accreditation authority がアりトオブバンドの仕組みによっお確立される堎合には、提瀺された Trust Marks を利甚するこずを遞択しおもよいMAY。

18. Security Considerations

18.1. Denial-of-Service Attack Prevention

この仕様で定矩されるいく぀かのむンタフェヌスは、Denial-of-ServiceDoS攻撃に利甚され埗る。特に、resolve endpointSection 8.2、Explicit Client RegistrationSection 12.2、Automatic Client RegistrationSection 12.1は HTTP 䌝播攻撃HTTP propagation attacksのベクタずしお悪甚され埗る。以䞋では、そのような攻撃がどのように発生し埗るか、およびそれを防ぐための察策を説明する。

攻撃者は、自身の Entity Configuration に䜕癟もの停の authority_hints を提䟛するこずで、Federation Entity Discovery の仕組みを悪甚し、倚数の HTTP リク゚ストを䌝播させ埗る。攻撃者が OP に authorization request を送信する RP を支配しおいる状況を想像しおほしい。攻撃者が䜜成した各リク゚ストに察し、OP は、攻撃者の Entity Configuration を取埗するための 1 ぀のリク゚ストを生成し、さらに authority_hints に芋぀かった各 URL ごずにもう 1 ぀のリク゚ストを生成する。

これらの endpoint が提䟛される堎合、[RFC4732] に蚘茉されるものを含め、以䞋に述べるような適切な防埡手法が必芁である。

  • 実装は、調査する意思のある authority_hints の数に䞊限を蚭けるべきである。これは、攻撃者が自身の Entity Configuration に倚数の停 authority_hints を定矩する攻撃から保護するためである。
  • Entities は、Section 12.1.1.1 で説明されるずおり、リク゚ストに Trust ChainSection 4.3を含めるこずを芁求され埗る。静的な Trust Chain は事前定矩された信頌パスを提䟛するため、Federation Entity Discovery を実斜する必芁がなくなる。この堎合、Trust Anchor の公開鍵で Trust Chain を静的に怜蚌できるため、䌝播攻撃は防止される。
  • Trust Mark は、その issuer の公開鍵を甚いお静的に怜蚌できる。Trust Marks の静的怜蚌は、䌝播攻撃に察するフィルタずなる。OpenID Provider (OP) が Entity Configuration 内で少なくずも 1 ぀の有効な Trust Mark を発芋した堎合、それはリク゚ストを開始した Relying Party (RP) の信頌性の蚌拠ずなり埗る。Trust Mark は任意であるため、これを芁求するかどうかの決定はフェデレヌション実装の裁量に委ねられ、フェデレヌションは特定のニヌズに埓っお Trust Marks を定矩し芁求し埗る。
  • resolve endpoint においお Client 認蚌が䞍芁な堎合、受信リク゚ストが自動的に Trust Chains の収集Federation Entity Discovery プロセスおよび評䟡を匕き起こすべきではない。代わりに、その resolve endpoint は、認蚌されおいない Client リク゚ストに察しお、既に評䟡され信頌に足るず刀断された Entities に関するキャッシュ枈み情報のみで応答すべきである。この堎合、Federation Entity Discovery プロセスの開始が resolve endpoint のデフォルト動䜜であっおはならない。
  • request objects を参照枡しrequest_uri request パラメヌタを䜿甚するこずは、Section 12.1.1 で説明されるずおり、攻撃者が OP に察しお攻撃者の制埡䞋にある任意のコンテンツを取埗させる仕組みを排陀するため、䞀郚のデプロむメントではサポヌトされない堎合がある。

18.2. Unsigned Error Messages

このプロトコルの基本的な蚭蚈目暙の 1 ぀は、メッセヌゞを end-to-end で保護するこずである。これは TLS を芁求するだけでは達成できない。なぜなら、倚くの堎合 TLS は end-to-end ではなく、HTTPS から HTTP ぞのリバヌスプロキシで終端するからである。したがっお、眲名されおいない゚ラヌメッセヌゞを蚱容するず、DoS 攻撃を行いたい者に察しお攻撃ベクタを開くこずになる。これは OpenID Federation 固有の話ではなく、HTTPS から HTTP のリバヌスプロキシが䜿甚される他のプロトコルにおいおも同様に圓おはたる。

19. Privacy Considerations

実装者は、以䞋のプラむバシヌ䞊の考慮事項を認識すべきである。

Entity Statements\ Entity Statements は、個人間の信頌関係や特定の業務アプリケヌションのためではなく、フェデレヌション内の組織的な Entities 間の信頌関係を確立するよう蚭蚈されおいる。Know Your Customer や Anti-Money Laundering のプロセスで必芁ずなる個人たたは法人に察する信頌・評刀評䟡は、それらの目的に特化した専門プラットフォヌムを通じお管理されるべきである。Entity Statements は公開むンフラを甚いお信頌関係を促進するため、フェデレヌション運甚および組織間の信頌確立に必芁䞍可欠な情報に限定されるべきである。

Trust Mark Status\ Trust Mark Status endpoint は、Trust Marks の状態をリアルタむムに問い合わせられるようにする。Federation Fetch endpoint ず同様に、Trust Mark Status endpoint がいかなる client 認蚌方匏でも保護されおいない堎合、Trust Marks を怜蚌するリク゚ストは、必ずしも Entities 間の実際の盞互䜜甚や関係を瀺すずは限らず、単に日垞的なネットワヌク怜査や discovery プロセスの䞀郚である可胜性がある。これは、IPv4/IPv6 アドレスや DNS Whois ゚ントリのような暙準的なネットワヌク蚺断ツヌルを通じお、Trust Mark Issuers が、他の Entities に぀いおの Trust Marks を評䟡しおいる Entities を远跡できおしたう可胜性がある。远跡リスクを軜枛するため、実装は短寿呜の Trust Marks を䜿甚する、たたは Trust Marked Entities ListingSection 8.5を sub パラメヌタなしで trust_mark_type パラメヌタのみで䜿甚するこずで Trust Mark Status endpoint を䜿甚する必芁性を枛らす、ずいった察策を取り埗る。

Federation Fetch Endpoint\ Federation Fetch endpoint は、Subordinate Statements をリアルタむムに問い合わせられるようにする。Trust Mark Status の怜蚌ず同様に、フェデレヌション基盀が公開され広く閲芧可胜であり、か぀ endpoints がいかなる client 認蚌方匏でも保護されおいない堎合、Subordinate Statements を取埗するリク゚ストは、必ずしも Entities 間の実際の盞互䜜甚や関係を瀺すずは限らず、単に日垞的なネットワヌク怜査や discovery プロセスの䞀郚である可胜性がある。しかし、これは、IPv4/IPv6 アドレスや DNS Whois ゚ントリのような暙準的なネットワヌク蚺断ツヌルを通じお、Trust Anchors たたは Intermediates が、他の Entities ずの trust 関係を評䟡しおいる 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 登録皮別を指定する文字列の配列

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: client の JWK Set ドキュメントを payload ずする眲名枈み 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 Supported

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: この authorization server の JWK Set ドキュメントを payload ずする眲名枈み 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: protected resource の JWK Set ドキュメントを payload ずする眲名枈み 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 を登録する。

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_request

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_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: server_error

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: temporarily_unavailable

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: RFC 7519 で定矩される Issued At

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: RFC 7519 で定矩される Not Before

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: RFC 7519 で定矩される Expiration Time

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 内に存圚し、理解しお凊理しなければならないMUST 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.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.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.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.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.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.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.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.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] で述べられおいる方法に埓い、「Media Types」レゞストリ [IANA.MediaTypes] に、以䞋の media types [RFC2046] を登録する。

Type name: application

Subtype name: entity-statement+jwt

Required parameters: 該圓なし

Optional parameters: 該圓なし

Encoding considerations: バむナリ。Entity Statement は JWT である。JWT の倀は、base64url で゚ンコヌドされた倀空文字列である堎合もあるの連なりずしお゚ンコヌドされ、ピリオド'.'文字で区切られる。

Security considerations: この仕様の Section 18 を参照

Interoperability considerations: 該圓なし

Published specification: この仕様の Section 15.1

Applications that use this media type: この仕様を䜿甚するアプリケヌション

Fragment identifier considerations: 該圓なし

Additional information:

Magic number(s): 該圓なし

File extension(s): 該圓なし

Macintosh file type code(s): 該圓なし

Person & email address to contact for further information:

Michael B. Jones, michael_b_jones@hotmail.com

Intended usage: COMMON

Restrictions on usage: なし

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: 該圓なし

Optional parameters: 該圓なし

Encoding considerations: バむナリ。Trust Mark は JWT である。JWT の倀は、base64url で゚ンコヌドされた倀空文字列である堎合もあるの連なりずしお゚ンコヌドされ、ピリオド'.'文字で区切られる。

Security considerations: この仕様の Section 18 を参照

Interoperability considerations: 該圓なし

Published specification: この仕様の Section 15.2

Applications that use this media type: この仕様を䜿甚するアプリケヌション

Fragment identifier considerations: 該圓なし

Additional information:

Magic number(s): 該圓なし

File extension(s): 該圓なし

Macintosh file type code(s): 該圓なし

Person & email address to contact for further information:

Michael B. Jones, michael_b_jones@hotmail.com

Intended usage: COMMON

Restrictions on usage: なし

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: 該圓なし

Optional parameters: 該圓なし

Encoding considerations: バむナリ。Entity Resolve Response は眲名付きの JWT である。JWT の倀は、base64url で゚ンコヌドされた倀空文字列である堎合もあるの連なりずしお゚ンコヌドされ、ピリオド'.'文字で区切られる。

Security considerations: この仕様の Section 18 を参照

Interoperability considerations: 該圓なし

Published specification: この仕様の Section 15.3

Applications that use this media type: この仕様を䜿甚するアプリケヌション

Fragment identifier considerations: 該圓なし

Additional information:

Magic number(s): 該圓なし

File extension(s): 該圓なし

Macintosh file type code(s): 該圓なし

Person & email address to contact for further information:

Michael B. Jones, michael_b_jones@hotmail.com

Intended usage: COMMON

Restrictions on usage: なし

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: 該圓なし

Optional parameters: 該圓なし

Encoding considerations: バむナリ。Trust Chain は JWT の JSON 配列である。JWT の倀は、base64url で゚ンコヌドされた倀空文字列である堎合もあるの連なりずしお゚ンコヌドされ、ピリオド'.'文字で区切られる。

Security considerations: この仕様の Section 18 を参照

Interoperability considerations: 該圓なし

Published specification: この仕様の Section 15.4

Applications that use this media type: この仕様を䜿甚するアプリケヌション

Fragment identifier considerations: 該圓なし

Additional information:

Magic number(s): 該圓なし

File extension(s): 該圓なし

Macintosh file type code(s): 該圓なし

Person & email address to contact for further information:

Michael B. Jones, michael_b_jones@hotmail.com

Intended usage: COMMON

Restrictions on usage: なし

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: 該圓なし

Optional parameters: 該圓なし

Encoding considerations: バむナリ。Trust Mark delegation は眲名付きの JWT である。JWT の倀は、base64url で゚ンコヌドされた倀空文字列である堎合もあるの連なりずしお゚ンコヌドされ、ピリオド'.'文字で区切られる。

Security considerations: この仕様の Section 18 を参照

Interoperability considerations: 該圓なし

Published specification: この仕様の Section 15.5

Applications that use this media type: この仕様を䜿甚するアプリケヌション

Fragment identifier considerations: 該圓なし

Additional information:

Magic number(s): 該圓なし

File extension(s): 該圓なし

Macintosh file type code(s): 該圓なし

Person & email address to contact for further information:

Roland Hedberg, roland@catalogix.se

Intended usage: COMMON

Restrictions on usage: なし

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: 該圓なし

Optional parameters: 該圓なし

Encoding considerations: バむナリ。眲名付き JWK Set は眲名付きの JWT である。JWT の倀は、base64url で゚ンコヌドされた倀空文字列である堎合もあるの連なりずしお゚ンコヌドされ、ピリオド'.'文字で区切られる。

Security considerations: この仕様の Section 18 を参照

Interoperability considerations: 該圓なし

Published specification: この仕様の Section 15.6

Applications that use this media type: この仕様を䜿甚するアプリケヌション

Fragment identifier considerations: 該圓なし

Additional information:

Magic number(s): 該圓なし

File extension(s): 該圓なし

Macintosh file type code(s): 該圓なし

Person & email address to contact for further information:

Michael B. Jones, michael_b_jones@hotmail.com

Intended usage: COMMON

Restrictions on usage: なし

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: 該圓なし

Optional parameters: 該圓なし

Encoding considerations: バむナリ。Explicit Registration response は JWT である。JWT の倀は、base64url で゚ンコヌドされた倀空文字列である堎合もあるの連なりずしお゚ンコヌドされ、ピリオド'.'文字で区切られる。

Security considerations: この仕様の Section 18 を参照

Interoperability considerations: 該圓なし

Published specification: この仕様の Section 15.7

Applications that use this media type: この仕様を䜿甚するアプリケヌション

Fragment identifier considerations: 該圓なし

Additional information:

Magic number(s): 該圓なし

File extension(s): 該圓なし

Macintosh file type code(s): 該圓なし

Person & email address to contact for further information:

Michael B. Jones, michael_b_jones@hotmail.com

Intended usage: COMMON

Restrictions on usage: なし

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: 該圓なし

Optional parameters: 該圓なし

Encoding considerations: バむナリ。Trust Mark Status Response は眲名付きの JWT である。JWT の倀は、base64url で゚ンコヌドされた倀空文字列である堎合もあるの連なりずしお゚ンコヌドされ、ピリオド'.'文字で区切られる。

Security considerations: この仕様の Section 18 を参照

Interoperability considerations: 該圓なし

Published specification: この仕様の Section 15.8

Applications that use this media type: この仕様を䜿甚するアプリケヌション

Fragment identifier considerations: 該圓なし

Additional information:

Magic number(s): 該圓なし

File extension(s): 該圓なし

Macintosh file type code(s): 該圓なし

Person & email address to contact for further information:

Michael B. Jones, michael_b_jones@hotmail.com

Intended usage: COMMON

Restrictions on usage: なし

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. References

21.1. Normative References

[OpenID.Core] Sakimura, N., Bradley, J., Jones, M.B., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", 15 December 2023, 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, 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, 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", 24 April 2025, openid-connect-rp-metadata-choices-1_0.html.

[RFC2119] Bradner, S., "芁件レベルを瀺すために RFC で甚いるキヌワヌド", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, rfc2119.

[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "むンタヌネットにおけるサヌビス劚害DoSに関する考慮事項", RFC 4732, DOI 10.17487/RFC4732, December 2006, rfc4732.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "むンタヌネット X.509 公開鍵基盀蚌明曞および蚌明曞倱効リストCRLプロファむル", RFC 5280, DOI 10.17487/RFC5280, May 2008, rfc5280.

[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "蚀語を識別するためのタグ", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, rfc5646.

[RFC6749] Hardt, D., Ed., "OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, rfc6749.

[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, rfc7515.

[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, rfc7516.

[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, rfc7517.

[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 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, rfc7591.

[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, rfc7638.

[RFC8174] Leiba, B., "RFC 2119 キヌワヌドにおける倧文字ず小文字の曖昧性", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, rfc8174.

[RFC8259] Bray, T., Ed., "JavaScript Object NotationJSONデヌタ亀換フォヌマット", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, rfc8259.

[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, rfc8414.

[RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 盞互 TLSmTLSクラむアント認蚌ず蚌明曞拘束 Access Token", RFC 8705, DOI 10.17487/RFC8705, February 2020, rfc8705.

[RFC9101] Sakimura, N., Bradley, J., and M. Jones, "OAuth 2.0 Authorization Framework: JWT-Secured Authorization RequestJAR", RFC 9101, DOI 10.17487/RFC9101, August 2021, 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, rfc9126.

[RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, rfc9728.

[UNICODE] The Unicode Consortium, "The Unicode Standard", unicode 版本の最新情報。

[USA15] Whistler, K., "Unicode Normalization Forms", Unicode Standard Annex 15, 12 August 2023, tr15.

21.2. Informative References

[App-Fed-Linkage] Dzhuvinov, V., "How to link an application protocol to an OpenID Federation 1.0 trust layer", 4 December 2024, How to link...

[FAPI] Sakimura, N., Bradley, J., and E. Jay, "Financial-grade API Security Profile 1.0 - Part 2: Advanced", 12 March 2021, openid-financial...

[IANA.JOSE] IANA, "JSON Object Signing and Encryption (JOSE)", jose.

[IANA.JWT.Claims] IANA, "JSON Web Token Claims", jwt.

[IANA.MediaTypes] IANA, "Media Types", media-types.

[IANA.OAuth.Parameters] IANA, "OAuth Parameters", oauth-parameters.

[IANA.well-known] IANA, "Well-Known URIs", well-known-uris.

[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail ExtensionsMIMEPart Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, rfc2046.

[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Well-Known Uniform Resource IdentifiersURIsの定矩", RFC 5785, DOI 10.17487/RFC5785, April 2010, 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, 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, rfc8725.

[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, rfc9525.

Appendix A. Example OpenID Provider Information Discovery and Client Registration 以䞋を仮定する。LIGO プロゞェクトは、eduGAIN 内のすべおの OP に察しお自分たちの wiki ぞのアクセスを提䟛したい。LIGO は InCommon フェデレヌションに登録されおいる。

以䞋は、eduGAIN Trust Anchor の䞋にあるフェデレヌションを瀺す。

                    eduGAIN
                       |
    +------------------+------------------+
    |                                     |
 SWAMID                               InCommon
    |                                     |
  umu.se                                  |
    |                                     |
op.umu.se                           wiki.ligo.org

Figure 54: eduGAIN フェデレヌション内の参加者

SWAMID ず InCommon は、いずれもそれ自䜓が identity federation である。たた、䞡者は共通しお eduGAIN フェデレヌションのメンバヌでもある。

SWAMID ず InCommon は Entities の登録方法が異なる。SWAMID は組織を登録し、その組織に所属する Entities を組織に登録させる。䞀方で InCommon は、すべおの Entities を盎接登録し、いずれの組織 Entity の䞋にも眮かない。したがっお、フェデレヌションにおける深さに違いが生じる。

UmeÃ¥ University の研究者が LIGO Wiki にログむンしたいず仮定する。Wiki では、研究者は䜕らかの discovery service を甚いお、ホヌムの identity providerop.umu.seを芋぀ける。

Wiki の RP 郚分が、どの OP ずやり取りすべきかSHOULDを把握したら、次に OP に぀いおいく぀かのこずを知る必芁がある。これらはすべお metadata から埗られる。しかし metadata を芋぀けるだけでは十分ではなく、RP はその metadata を信頌できなければならない。

ここで少し寄り道をしお、フェデレヌションを構築するために必芁なこずから始める。

A.1. Setting Up a Federation フェデレヌションのむンフラを構築する手順は次のずおりである。

Trust Anchor の眲名鍵を生成する。これらは公開鍵秘密鍵のペアでなければならないMUST。

Federation Entity Keys を甚いお JWTs/Entity Statements に眲名できる眲名サヌビスを甚意する。

眲名付き Entity Statements を公開できる web services を甚意する。1 ぀はフェデレヌションの Entity Identifier に察応する URL で Entity Configuration を返すもの、もう 1 ぀は Section 8.1.1 で述べた fetch endpoint を提䟛するもの。

これらの芁件が満たされたら、Federation Operator はフェデレヌションに Entities を远加できる。Entity の远加は、次のこずに垰着する。

フェデレヌションの Entity Identifier ず、Entity Statements に眲名するために federation operator が甚いる鍵ペアの公開郚分を、Entity に提䟛する。

Entity の Entity Identifier ず、Entity が自分の Entity Configuration で公開する予定の JWK Set を取埗する。

federation operator が Entities の远加を始める前に、誰がフェデレヌションの䞀員になれるのか、そしおフェデレヌションのレむアりト構造をどうするのかに぀いおのポリシヌが必芁である。InCommon のように 1 階局のフェデレヌションずするのか、SWAMID のように 2 階局にするのか、あるいは倚階局にするのか。フェデレヌションはたた、Section 6 で述べた federation policy framework を甚いお、他のポリシヌを実装するこずも怜蚎できる。

フェデレヌションが敎備されるず、物事が動き始める。

A.2. The LIGO Wiki Discovers the OP's 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 で定矩された手順を甚いる。

各 Immediate Superior の fetch endpoint を甚いお、Section 8.1.1 に埓い、Immediate Subordinate Entity に関する Subordinate Statements を取埗する。

これを䜕回繰り返す必芁があるかは、フェデレヌションの深さに䟝存する。以䞋は、䞊蚘のフェデレヌション構成を甚いお、RP が OP の metadata を芋぀けるために実行する各手順の結果である。

Trust Chain を構築する際には、Trust Chain の subject の Entity Configuration ず䜵せお、各 Immediate Superior が自分の Immediate Subordinates に぀いお発行した Subordinate Statements が甚いられる。

Intermediates の Entity Configurations は Trust Chain の䞀郚ではない。

A.2.1. Entity Configuration for https://op.umu.se 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/openid",
      "signed_jwks_uri": "https://op.umu.se/openid/jwks.jose",
      "authorization_endpoint": "https://op.umu.se/openid/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/openid/token",
      "federation_registration_endpoint": "https://op.umu.se/openid/fedreg",
      "token_endpoint_auth_methods_supported": [
        "client_secret_post",
        "client_secret_basic",
        "client_secret_jwt",
        "private_key_jwt"
      ]
    }
  }
}

Figure 55: Entity Configuration Issued by https://op.umu.se

authority_hints は Intermediate Entity https://umu.se を指しおいる。したがっお、これが次の手順ずなる。

この Entity Configuration が Trust Chain の最初のリンクである。

A.2.2. Entity Configuration for https://umu.se

LIGO の RP は、Section 9 で定矩された手順を甚いお https://umu.se から Entity Configuration を取埗する。

リク゚ストは次のようになる。

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

Figure 56: https://umu.se が発行する Entity Configuration\ そしお、この 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/oidc/fedapi",
      "organization_uri": "https://www.umu.se",
      "organization_name": "UmU"
    }
  }
}

Figure 57: Entity Configuration JWT Claims Set\ この手順でこの Entity Configuration から利甚される情報は federation_fetch_endpoint のみであり、これは次の手順で䜿甚される。

A.2.3. Subordinate Statement Published by https://umu.se about https://op.umu.se

RP は、Section 8.1.1 で定矩されおいる https://umu.se が提䟛する fetch endpoint を䜿甚しお、https://op.umu.se に関する情報を取埗する。

リク゚ストは次のようになる。

GET /oidc/fedapi?sub=https%3A%2F%2Fop.umu.se&
iss=https%3A%2F%2Fumu.se HTTP/1.1
Host: umu.se

Figure 58: https://umu.se に察し、https://op.umu.se に関する Subordinate Statement を芁求するリク゚スト\ そしお結果は次のずおりである。

{
  "exp": 1568397247,
  "iat": 1568310847,
  "iss": "https://umu.se",
  "sub": "https://op.umu.se",
  "source_endpoint": "https://umu.se/oidc/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 59: https://umu.se が https://op.umu.se に぀いお発行した Subordinate Statement\ この Subordinate Statement が Trust Chain の 2 番目のリンクである。

A.2.4. Entity Configuration for https://swamid.se

LIGO Wiki の RP は、Section 9 で定矩された手順を甚いお https://swamid.se から Entity Configuration を取埗する。

リク゚ストは次のようになる。

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

Figure 60: https://swamid.se から Entity Configuration を芁求するリク゚スト\ そしお、この 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 61: https://swamid.se が発行した Entity Configuration\ この手順でこの Entity Configuration から利甚される情報は federation_fetch_endpoint のみであり、これは次の手順で䜿甚される。

A.2.5. Subordinate Statement Published by https://swamid.se about https://umu.se

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 62: https://swamid.se に察し、https://umu.se に関する Subordinate Statement を芁求するリク゚スト\ そしお結果は次のずおりである。

{
  "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 63: https://swamid.se が https://umu.se に぀いお発行した Subordinate Statement\ この Subordinate Statement が Trust Chain の 3 番目のリンクである。

この Subordinate Statement の発行者が、LIGO Wiki の RP がアクセスできる Trust Anchors のリストに含たれおいないず仮定するず、さらに 1 段階進める必芁がある。

A.2.6. Entity Configuration for https://edugain.geant.org

RP は、Section 9 で定矩された手順を甚いお https://edugain.geant.org から Entity Configuration を取埗する。

リク゚ストは次のようになる。

GET /.well-known/openid-federation HTTP/1.1
Host: edugain.geant.org

Figure 64: https://edugain.geant.org から Entity Configuration を芁求するリク゚スト\ そしお、この 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 65: https://edugain.geant.org が発行した Entity Configuration\ Trust Anchor の Entity Configuration の䞭で、Relying Party (RP) は federation_fetch_endpoint を探し、Trust Anchor の曎新された Federation Entity Keys を取埗する。Federation 内の各 Entity は、自身の Federation Entity Keys やその他の属性を、い぀でも倉曎し埗る。詳现は Section 11.2 を参照のこず。

A.2.7. Subordinate Statement Published by https://edugain.geant.org about https://swamid.se

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 66: https://edugain.geant.org に察し、https://swamid.se に関する Subordinate Statement を芁求するリク゚スト\ そしお結果は次のずおりである。

{
  "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 67: https://edugain.geant.org が https://swamid.se に぀いお発行した Subordinate Statement\ この statement の発行者が、LIGO Wiki の RP がアクセスできる Trust Anchors のリストに含たれおいるず仮定するず、この Subordinate Statement が Trust Chain の 4 番目のリンクずなる。Trust Anchor の Entity Configuration も Trust Chain に含められる堎合があるMAY。その堎合、それは 5 番目で最埌のリンクずなる。

これで Trust Chain のすべおのメンバヌを取埗した。芁玄するず、次の Entity Statements を取埗したこずになる。

  • Leaf Entity https://op.umu.se の Entity Configuration —— Trust Chain の 1 番目のリンク
  • 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. Verified Metadata for https://op.umu.se

チェヌンの怜蚌ができたので、LIGO Wiki の RP は次の手順に進める。

Immediate Superiors がそれぞれ自分の Immediate Subordinates に぀いお発行した 3 ぀の Subordinate Statements の metadata policies を結合し、Leaf Entity が提瀺した metadata statement にその結合ポリシヌを適甚するず、次が埗られる。

{
  "authorization_endpoint": "https://op.umu.se/openid/authorization",
  "contacts": [
    "ops@swamid.se",
    "ops@edugain.geant.org"
  ],
  "federation_registration_endpoint": "https://op.umu.se/openid/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/openid",
  "signed_jwks_uri": "https://op.umu.se/openid/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/openid/token",
  "token_endpoint_auth_methods_supported": [
    "private_key_jwt",
    "client_secret_jwt"
  ]
}

Figure 68: metadata policies を適甚しお Trust Chain から導出した Resolved Metadata\ これで Provider Discovery の手順の終わりに到達した。

A.3. Examples of the Two Ways of Doing Client Registration

Section 12 で述べたずおり、client registration を行う方法は 2 ぀ある。

Automatic\ 将来の通信においお client がどの機胜を甚いるべきかSHOULDに぀いお、RP ず OP の間で亀枉は行われない。遞択された Trust Chain の metadata policies によっおフィルタされた RP の公開 metadata が、䜿甚される metadata を定矩する。

Explicit\ RP は federation_registration_endpoint にアクセスし、そこで RP の metadata を提䟛する。OP は、Trust Chain がすでに定矩しおいるものに加えお、さらなる制玄を加える metadata policy を返す堎合があるMAY。

A.3.1. RP Sends 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 69: Automatic Client Registration を甚いた Authentication Request\ OP がこの Authentication Request を受信するず、RP がすでに登録枈みでない限り、RP を動的に取埗し、RP ずの間で信頌を確立し始める。

A.3.1.1. OP Fetches Entity Statements

OP は RPwiki.ligo.orgに぀いお Trust Chain を確立する必芁がある。この䟋における OP には、次の 2 ぀のフェデレヌションの公開鍵が蚭定されおいる。

  • 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
A.3.1.2. OP Evaluates the 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 70: 耇数の metadata type に関連する Metadata Policies

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 71: RP に関連する Metadata Policy

次に、これらを結合し、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 72: metadata policy をただ適甚しおいない結合枈み metadata

最終的な結果は次のずおりである。

"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 73: metadata policy を適甚した埌の Resolved Metadata

Trust Chain ず最終的な Relying Party (RP) の metadata を取埗できれば、OpenID Provider (OP) は Authentication Request 内の Request Object の眲名を怜蚌するために必芁なものをすべお揃えたこずになる。怜蚌には、signed_jwks_uri endpoint で利甚可胜な公開鍵を甚いる。

A.3.2. RP Starts with Client Registration (Explicit Client Registration)

ここでは、LIGO Wiki の RP が、OPop.umu.seの federation_registration_endpoint に察しお明瀺的登録Explicit Registrationのリク゚ストを送信する。リク゚ストには、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 74: RP's Entity Configuration JWT Claims Set

OP は RP の Entity Configuration を受け取り、付録 A.2 に瀺された手順の䞊びに埓っお凊理を進める。

OP は、付録 A.3.1.2 で述べたのず同䞀の RP メタデヌタを問題なく解決resolveする。続いお、自身の OP メタデヌタに準拠する圢で RP を登録し、その結果を登録甚の Entity Statementregistration Entity Statementずしお返す。

OP が Refresh Token をサポヌトしないず仮定するず、authorization_code の grant type のみで RP を登録するこずになる。これは、RP に返されるメタデヌタにも反映される。

返されるメタデヌタには、client_id、client_secret、および OP が RP のために払い出したその他のパラメヌタも含たれる。

以䞋は、明瀺的なクラむアント登録explicit client registrationに成功した埌、OP が RP に返す登録甚 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 75: JWT Claims Set of Registration Entity Statement Returned by OP to RP after Explicit Client Registration

Appendix B. Notices

著䜜暩 (c) 2025 The OpenID Foundation.

The OpenID FoundationOIDFは、あらゆる寄皿者、開発者、実装者、たたはその他の関係者に察し、本 Implementers Draft、Final Specification、たたは Final Specification Incorporating Errata Corrections を耇補し、そこから掟生著䜜物を䜜成し、配垃し、䞊挔し、衚瀺するための、非独占的・ロむダリティフリヌ・党䞖界的な著䜜暩ラむセンスを付䞎する。この蚱諟は、(i) 仕様を策定するこず、および (ii) これら文曞に基づいお Implementers Draft、Final Specifications、ならびに Final Specification Incorporating Errata Corrections を実装するこず、ずいう目的に限っお認められる。なお、OIDF を資料の出所ずしお垰属衚瀺attributionを行うこずを条件ずするが、その垰属衚瀺は OIDF による掚奚endorsementを瀺すものではない。

本仕様で述べる技術は、OpenID Foundation のメンバヌその他を含む、さたざたな提䟛元からの寄䞎によっお公開された。OpenID Foundation は、この技術が配垃可胜であるこずを確保するための手順を講じおきたが、本仕様で述べる技術の実装たたは利甚に関連しお䞻匵され埗る、いかなる知的財産暩その他の暩利に぀いおも、その有効性たたは範囲に関しお立堎を衚明しない。たた、そのような暩利に基づくラむセンスが利甚可胜かどうか、あるいは利甚可胜だずしおどの範囲たでかに぀いおも衚明しない。さらに、OpenID Foundation がそのような暩利を特定するための独自の取り組みを行ったこずを衚明するものでもない。OpenID Foundation および本仕様の寄皿者は、本仕様に関しお、明瀺・黙瀺・その他いかなる圢態の保蚌も行わずここに明瀺的に吊認する、商品性、非䟵害、特定目的ぞの適合性、たたは暩原に関する黙瀺の保蚌を含め、すべおの保蚌を吊認する。本仕様を実装するこずに䌎うリスクは、すべお実装者が負担する。OpenID Intellectual Property Rights policyopenid.net に掲茉は、寄皿者に察し、他の寄皿者および実装者に察しお特定の特蚱請求を䞻匵しないずいう特蚱に関する玄束patent promiseを提䟛するこずを求めおいる。OpenID は、本仕様を実斜するために必芁ずなり埗る技術を察象ずする著䜜暩、特蚱、特蚱出願、たたはその他の専有暩が存圚する可胜性がある堎合、いかなる関係者からでもその情報提䟛を歓迎する。

Appendix C. Document History

[[ To be removed from the final specification ]]

-46

Fixed #293: Said that ECs and ESs MUST NOT contain the peer_trust_chain header parameter.

Fixed #295: Removed unnecessary "sorted as specified in Section 4" phrases.

Fixed #296: Reworded odd language about operators that can be combined.

Fixed #297: Made statement about non-interoperable JSON a note.

Fixed #298: Referenced RFC 9525 for Web PKI.

Allowed the Trust Chain in the trust_chain header parameter to begin with an Entity other than the JWT's subject.

Added reference to Client Authentication section to clarify statement about whether the caller is authenticated.

Described the use of the "aud" (audience) claim in Explicit Registration requests and responses.

Fixed #311: Clarified that the expiration of a resolve response is the minimum of the expiration of the Trust Chain and the expiration of any included Trust Mark.

Fixed #292: Included the Trust Chain in the description of the Resolve Endpoint.

-45

Fixed #233: Gave examples of the use of Automatic Registration at OAuth 2.0 endpoints other than the Authorization Endpoint and Token Endpoint.

Fixed #216: Added two more implementation considerations.

Added Implementation Considerations section "Federation Discovery and Trust Chain Resolution Patterns".

Fixed #237: The order of the elements resulting from merging two sets is not defined.

Fixed #241: Restructured Entity Statement section.

Fixed #84: Added section on validating Entity Statements.

Fixed #243: Be explicit about what to do when server validation fails in automatic registration.

Fixed #100: Define the peer_trust_chain header parameter and use it in combination with the trust_chain header parameter to provide the Federation Integrity and Metadata Integrity properties. This PR leaves the existing trust_chain request parameter for Automatic Registration and the existing Trust Chain-as-request-body syntax for Explicit Registration in place for historical reasons, but defines that the use of the trust_chain header parameter is RECOMMENDED over either of those more ad-hoc methods.

Fixed #283: Provided better description of "crit" Claim in IANA registration.

Fixed #215: Added trust_anchor_hints Entity Configuration Claim.

Fixed #275: Uppercased "Claim", "Claim Name", and "Claim Value".

-44

Fixed #127: Explained Trust Mark Issuer validation in more detail.

Corrected location of Constraints in Trust Chain Example figure.

Fixed #147: Added a note about client authentication methods and Automatic Registration.

Applied must-have feature requests for Swedish government use cases, specifically:

Make it optional to publish an Entity Configuration at the Entity Identifier's /.well-known/openid-federation URL (which is already true when using Explicit Registration).

Allow non-https Entity Identifiers (while leaving defining how to retrieve Entity Configurations for them to future extensions).

Make use of client_registration_types and client_registration_types_supported RECOMMENDED rather than REQUIRED.

Remove recommendation that informational metadata values be in the Entity's federation_entity metadata.

Applied strong requests for Swedish government use cases, specifically:

Fixes #244: Sign Trust Mark Status responses and extend the set of defined status values.

Added warning about using JWKS representations where they may not be understood.

-43

Fixed #194: Renamed trust_mark_id to trust_mark_type.

Fixed #24, #25, #212: Simplified Trust Mark Status endpoint by having it take the Trust Mark to be validated as a parameter.

Fixed #35: Removed requirement for the value and default operators to support JSON object values, since merging them requires comparison. Added note about metadata policy and comparing JSON objects.

Fixed #167: Added Privacy Considerations section.

Fixed #196: The output of rows 3 and 4 in Table 1: Examples of Outputs with Combinations of essential and subset_of for Different Inputs must be empty JSON array [].

OAuth 2.0 Protected Resource Metadata is now RFC 9728.

Follow Implementation Considerations in [OpenID.RP.Choices].

Added note about using different signing algorithms for different Entity Statements in a Trust Chain.

Fixed #172: Added Resolved Metadata as defined term.

Fixed #166: Recommend way to validate non-expiring Trust Marks.

Fixed #193: Clarified that "metadata" declarations declare the roles that the Entity plays - its Entity Types.

Fixed #202: Added String Operations section.

Fixed #173: Use Resolved Metadata term in Explicit Registration.

Added informational metadata parameters display_name, description, keywords, and information_uri and added IANA registrations for them.

Added protected resource metadata IANA registrations.

Renamed homepage_uri to organization_uri.

-42

Addresses #11, #180: Allows the following unconditional operator combinations: add + superset_of. Makes the following previously conditional operator combinations unconditional: default + one_of, default + subset_of, default + superset_of. Makes the following previously unconditional operator combination conditional: value + essential. Allows the following conditional operator combinations: value + add, value + default, value + one_of, value + subset_of, value + superset_of.

Addresses #182: When applying the subset_of operator on a metadata parameter, if the resulting intersection is empty, then the metadata is made empty. Previously it was removed, which may lead to policy override for metadata parameters that have a default value, for instance grant_types RP metadata or grant_types_supported OP metadata. The merge of two subset_of operators is changed to allow empty intersection as well.

Addresses #129: Clarifies that the combination rules for a metadata policy operator apply to both individual as well as merged metadata parameter policies.

Fixed #184: Clarified that Request Objects can be passed by value or by reference.

Fixed #178: Clarify that other client methods (than automatic and explicit) are allowed.

Fixed #181: Contributed metadata policies must be logically sound and consistent with one another.

Fixed #130: Allow multiple Trust Anchor values to be passed in resolve requests.

Require trust_chain claim in resolve response.

Fixed #161: Prohibit loops in Trust Chains.

Fixed #47: Described using and not using a provided Trust Chain during Automatic Registration.

Fixed #85: Clarified Trust Chain selection during Explicit Registration. Also corrected the authority_hints value in the Explicit Registration response to be the Immediate Superior of the RP in the Trust Chain selected for it by the OP.

Fixed #35: Clarified that using non-interoperable JSON, as per Sections 4 and 8 of RFC 8259, can result in unpredictable metadata and metadata policy behavior.

Fixed #162: Trust Mark claim id renamed to trust_mark_id. Other more specific Trust Mark JWT typ header parameter values can be used if defined by trust frameworks in use and understood by the implementation.

-41

Fixed #131: Changed anchor request parameter to trust_anchor, changed trust_anchor_id claim to trust_anchor, and changed type request parameter to entity_type.

Explicitly typed base64url-encoded examples that were previously untyped. Also added missing client_id and iss values in some examples.

Fixed #7, #86, #134, and #148: Provides implementation considerations on Federation topologies.

Fixed #136: Defined additional error codes and rationalized naming. Renamed trust_chain_validation_failed to invalid_trust_chain and renamed missing_trust_anchor to invalid_trust_anchor.

Fixed #133: Refined wording about client authentication when using Automatic Registration and added token_endpoint_auth_methods_supported in RP metadata example.

Reference OpenID Connect Relying Party Metadata Choices 1.0.

Fixed #143: Added Trust Mark Issuer and Trust Mark Owner to Terminology section.

Fixed #139: Clarified description of using request objects.

Fixed #140: Federation Entity Keys MUST NOT appear in metadata.

Fixed #105 and #106: Informatively say that the require_signed_request_object and require_pushed_authorization_requests metadata parameters can be used.

Fixed #107: Clarified how to validate Trust Marks.

Fixed #114: Described why it may make sense to not support the use of request_uri other than in conjunction with a PAR request.

Fixed #108: Removed remark about trust mark delegation revocation.

Fixed #120: Required kid (Key ID) header parameter in Signed JWK Set JWTs.

Define media type for Explicit Registration responses application/explicit-registration-response+jwt distinct from application/entity-statement+jwt.

Restrict audience values to the single Entity Identifier of the intended recipient.

-40

Renamed validation_failed error code to trust_chain_validation_failed. Fixed

89: Improved Entity Statement jwks claim description.

Fixed #88: Explicitly require audience validation for explicit registration requests and responses.

Fixed #28: Described validation of resolved metadata.

Fixed #98: Require that the audience of JWTs used for client authentication at federation endpoints with private_key_jwt be the Entity Identifier of the endpoint's Entity.

Fixed #34: Deleted request_authentication_methods_supported and request_authentication_signing_alg_values_supported and replaced with the use of standard Request Object and PAR metadata values. Also restricted PAR authentication methods to those performing signing with the RP's keys.

Fixed #98: Required audience when using private_key_jwt with PAR to be the Authorization Server's Entity Identifier.

Reverted change to allow PAR requests not using Request Objects when the client authentication method uses a signature with a Federation Entity Key.

Fixed #104: Removed the *_auth_signing_algs metadata parameters in favor of endpoint_auth_signing_alg_values_supported.

Required that the issuer OP and AS metadata values match the Entity Identifier.

Fixed #69: Specified more details of successful and error responses to authentication requests using Automatic Registration.

Fixed #24: Removed trust_mark and iat from Trust Mark Status endpoint. Use GET at Trust Mark Status endpoint.

-39

Fixed #33: Corrected "add" operator values in examples to be arrays.

Endpoint URLs are not form-urlencoded in JSON metadata parameter values.

Fixed #52: Clarified that PAR requests must use Request Objects.

Fixed #64: Explicitly typed signed JWK Sets.

Fixed #55: Required validating explicit typing of JWTs.

Fixed #53: State that JWS and JWE Compact Serializations are used.

Fixed #49: Added request_authentication_signing_alg_values_supported to example.

Fixed #46: Corrected statement about preventing use of Request Object for private_key_jwt client authentication.

Fixed #43: Allow multiple type request parameters in resolve requests.

Fixed #40: Changed section name from "Resolve Entity Statement" to "Resolve Entity".

Improved descriptions of the JWT Claims being registered, per feedback from the IANA Designated Expert.

Fixes #45: Tightened Trust Chain signature validation wording.

Fixed #40: Changed section name from "Resolve Entity Statement" to "Resolve Entity".

Fixed #39: Removed iss parameter from fetch endpoint.

Fixed #54: MAY NOT -> MUST NOT.

Fixed #58: Require authority_hints value to contain the Entity Identifiers of all Immediate Superiors.

-38

Added section defining each media type, per IANA Designed Expert review.

Fixed #36: Simplified obtaining Entity Configurations.

Fixed #30: Simplified fetch endpoint to only return Subordinate Statements.

Removed text describing endpoints as being "encoded in application/x-www-form-urlencoded format".

-37

Note that after the approval and publication of the fourth Implementer's Draft https://openid.net/specs/openid-federation-1_0-ID4.html, work on the OpenID Federation specification moved from the repository https://bitbucket.org/openid/connect/ to the repository https://github.com/openid/federation. Issue numbers before this draft are from the Bitbucket repository. Issue numbers starting with this draft are from the GitHub repository.

Fixed #15: Clarified that OpenID Federation can be used for trust establishment with any application protocols.

Fixed #18: Clarified use of valid Trust Marks.

Fixed #19: Clarified that Federation Entities publish their public keys.

Fixed #22: Defined that Entity Identifiers MUST use the https scheme.

Clarified that additional client_registration_types MAY be defined and used.

Corrected Usage Location values in IANA "OAuth Extensions Error Registry" registrations.

-36

Made the definition of iat and exp consistent.

以䞋、同様に続く

Acknowledgements 著者は、本仕様に貢献した以䞋の個人および組織に謝意を衚する: Marcus Almgren, Patrick Amrein, 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, Sean Turner, Davide Vaghetti, Niels van Dijk, Tim WÃŒrtele, Kristina Yasuda, Gabriel Zachmann, GEANT4-2 の JRA3T3 task force, および 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: http://www.thread-safe.com/ 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/