Independent Submission S. Halén
Request for Comments: 9932 The Swedish Internet Foundation
Category: Informational J. Schlyter
ISSN: 2070-1721 Kirei AB
April 2026
This Informational Independent Submission to the RFC Series describes a means to use TLS 1.3 to perform machine-to-machine mutual authentication within federations. This memo is not a standard. It does not modify the TLS protocol in any way, nor does it require changes to common TLS libraries. TLS is specified and standardized by the IETF's TLS Working Group.
RFC シリーズへのこの独立した情報提供では、TLS 1.3 を使用してフェデレーション内でマシン間の相互認証を実行する手段について説明します。このメモは標準ではありません。TLS プロトコルは一切変更されず、一般的な TLS ライブラリへの変更も必要ありません。TLS は、IETF の TLS Working Group によって指定および標準化されています。
The framework enables interoperable trust management for federated machine-to-machine communication. It introduces a centrally managed trust anchor and a controlled metadata publication process, ensuring that only authorized members are identifiable within the federation. These mechanisms support unambiguous entity identification and reduce the risk of impersonation, promoting secure and policy-aligned interaction across organizational boundaries.
このフレームワークにより、フェデレーションされたマシン間通信の相互運用可能な信頼管理が可能になります。これにより、一元管理されるトラスト アンカーと制御されたメタデータ公開プロセスが導入され、フェデレーション内で承認されたメンバーのみが識別可能になります。これらのメカニズムは、明確なエンティティの識別をサポートし、なりすましのリスクを軽減し、組織の境界を越えた安全でポリシーに沿った対話を促進します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他の RFC ストリームとは独立した、RFC シリーズへの貢献です。RFC 編集者は独自の裁量でこの文書を公開することを選択しており、実装または展開におけるこの文書の価値については何も述べていません。RFC 編集者によって出版が承認された文書は、どのレベルのインターネット標準の候補でもありません。see Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9932.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9932 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。
1. Introduction
1.1. Reserved Words
1.2. Terminology
2. Diverse Design Patterns
3. Trust Model
3.1. Role of the Federation Operator
3.2. Federation Members' Responsibilities
3.3. Chain of Trust
3.4. Member Vetting
3.5. Metadata Authenticity
4. Metadata Repository
4.1. Metadata Submission
4.2. Maintaining Up-to-Date Metadata
5. Authentication
5.1. Public Key Pinning
5.1.1. Benefits of Public Key Pinning
5.2. Pin Discovery and Preloading
5.3. Verification of Received Certificates
5.4. Failure to Validate
5.5. Certificate Rotation
5.6. Implementation Guidelines
6. Federation Metadata
6.1. Federation Metadata Claims
6.1.1. Entities
6.2. Metadata Schema
6.3. Example Metadata
6.4. Metadata Signing
6.5. Example Signature Protected Header
7. Example Usage Scenarios
7.1. Client Behavior
7.2. Server Behavior
7.3. SPKI Generation
7.4. Curl and Public Key Pinning
8. Deployments of the MATF Framework
8.1. Skolfederation Moa
8.2. Swedish National Agency for Education
8.3. Sambruk's EGIL
9. Security Considerations
9.1. Security Risks and Trust Management
9.2. TLS
9.3. Federation Metadata Updates
9.4. Verifying the Federation Metadata Signature
9.5. Time Synchronization
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Appendix A. JSON Schema for MATF Metadata
Acknowledgements
Authors' Addresses
This document describes the Mutually Authenticating TLS in Federations (MATF) framework, developed to complement multilateral Security Assertion Markup Language (SAML) federations within the education sector. These federations often rely on just-in-time provisioning, where user accounts are created at first login based on information from the SAML assertion. However, educators need to be able to manage resources and classes before students access the service. MATF bridges this gap by using secure machine-to-machine communication, enabling pre-provisioning of user information with a trust model and metadata structure inspired by SAML federations.
このドキュメントでは、教育分野内の多国間セキュリティ アサーション マークアップ言語 (SAML) フェデレーションを補完するために開発された、フェデレーションにおける相互認証 TLS (MATF) フレームワークについて説明します。これらのフェデレーションは多くの場合、SAML アサーションからの情報に基づいて最初のログイン時にユーザー アカウントが作成される、ジャストインタイム プロビジョニングに依存します。ただし、学生がサービスにアクセスする前に、教育者がリソースとクラスを管理できる必要があります。MATF は、安全なマシン間通信を使用してこのギャップを埋め、SAML フェデレーションからインスピレーションを得た信頼モデルとメタデータ構造によるユーザー情報の事前プロビジョニングを可能にします。
MATF is designed specifically for secure authentication in machine-to-machine contexts, such as RESTful APIs (where "RESTful" refers to the Representational State Transfer (REST) architecture) and service-to-service interactions, and is not intended for browser-based authentication. Because its applicability in a browser environment has not been studied, using MATF within browsers is not recommended. Doing so may introduce risks that differ from those typically addressed by standard browser security models.
MATF は、RESTful API (「RESTful」とは Representational State Transfer (REST) アーキテクチャを指します) やサービス間の対話など、マシン間のコンテキストでの安全な認証専用に設計されており、ブラウザー ベースの認証を目的としていません。ブラウザ環境での MATF の適用性は研究されていないため、ブラウザ内で MATF を使用することはお勧めできません。これを行うと、標準のブラウザー セキュリティ モデルで通常対処されるリスクとは異なるリスクが発生する可能性があります。
This work is not a product of the IETF, does not represent a standard, and has not achieved community consensus. It aims to address specific federation challenges and provide a framework for secure communication.
この成果は IETF の成果物ではなく、標準を表すものではなく、コミュニティのコンセンサスも得られていません。これは、フェデレーションの特定の課題に対処し、安全な通信のためのフレームワークを提供することを目的としています。
TLS is specified by the IETF TLS Working Group. TLS 1.3 is defined in [RFC8446]. Additional information about the TLS Working Group is available at <https://datatracker.ietf.org/wg/tls/about/>.
TLS は、IETF TLS Working Group によって指定されています。TLS 1.3は[RFC8446]で定義されています。TLS ワーキング グループに関する追加情報は、<https://datatracker.ietf.org/wg/tls/about/> で入手できます。
This document is an Informational RFC, which means it offers information and guidance but does not specify mandatory standards. Therefore, the keywords used throughout this document are for informational purposes only and do not imply any specific requirements.
この文書は情報 RFC です。つまり、情報とガイダンスを提供しますが、必須の標準は指定しません。したがって、このドキュメント全体で使用されているキーワードは情報提供のみを目的としており、特定の要件を意味するものではありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Federation:
フェデレーション：
A trusted network of entities that adhere to common security policies and standards, using MATF for secure communication.
安全な通信に MATF を使用する、共通のセキュリティ ポリシーと標準に準拠するエンティティの信頼されたネットワーク。
Federation Member:
連盟メンバー:
An entity that has been approved to join the federation and can leverage MATF for secure communication with other members.
フェデレーションへの参加が承認されており、MATF を利用して他のメンバーと安全に通信できるエンティティ。
Federation Operator:
フェデレーション オペレーター:
The entity responsible for the overall operation and management of the federation, including managing the federation metadata, enforcing security policies, and onboarding new members.
フェデレーションのメタデータの管理、セキュリティ ポリシーの適用、新しいメンバーのオンボーディングなど、フェデレーションの全体的な運用と管理を担当するエンティティ。
Federation Metadata:
フェデレーションメタデータ:
A cryptographically signed document containing information about all entities within the federation.
フェデレーション内のすべてのエンティティに関する情報を含む、暗号化された署名付き文書。
Metadata Repository:
メタデータ リポジトリ:
A centralized repository storing information about all entities within the federation.
フェデレーション内のすべてのエンティティに関する情報を保存する集中リポジトリ。
Member Metadata:
メンバーのメタデータ:
Information about entities associated with a specific member within the federation.
フェデレーション内の特定のメンバーに関連付けられたエンティティに関する情報。
Member Vetting:
メンバー審査:
The process of verifying and approving applicants to join the federation, ensuring they meet security and trustworthiness requirements.
フェデレーションへの参加申請者を検証および承認し、申請者がセキュリティと信頼性の要件を満たしていることを確認するプロセス。
Trust Anchor:
トラストアンカー:
The federation's root of trust is established by the public key used to verify federation metadata signatures, which allows participants to confidently rely on the information it contains.
フェデレーションの信頼のルートは、フェデレーション メタデータ署名の検証に使用される公開キーによって確立され、参加者はそれに含まれる情報を自信を持って信頼できます。
MATF is designed to be flexible and adaptable to the varying needs of different federations. Federations can differ significantly in terms of size, scope, and security requirements, which makes it challenging to prescribe a one-size-fits-all trust framework and security measures.
MATF は、さまざまな連盟のさまざまなニーズに柔軟に適応できるように設計されています。フェデレーションは、規模、範囲、セキュリティ要件の点で大きく異なる場合があるため、画一的な信頼フレームワークとセキュリティ対策を規定することが困難になります。
For instance, in the European Union, Regulation (EU) No 910/2014 (the electronic identification, authentication, and trust services (eIDAS) Regulation) [eIDAS] establishes a regulatory framework for electronic identification and trust services for electronic transactions in the internal market. The eIDAS Regulation provides a basis for cross-border recognition of notified electronic identification schemes and for regulated trust services.
たとえば、欧州連合では、規則 (EU) No 910/2014 (電子識別、認証、および信頼サービス (eIDAS) 規則) [eIDAS] により、域内市場での電子取引のための電子識別および信頼サービスに関する規制の枠組みが確立されています。eIDAS 規制は、通知された電子識別スキームの国境を越えた認識と、規制された信託サービスの基礎を提供します。
Similarly, national federations, such as those found in education or healthcare sectors, often have their own specific trust frameworks and security measures tailored to their unique needs. These federations may leverage existing national identification systems or other trusted credentials to establish member identities and ensure secure interactions.
同様に、教育や医療分野などの各国の連盟は、多くの場合、独自のニーズに合わせた独自の信頼フレームワークやセキュリティ対策を講じています。これらの連盟は、既存の国民識別システムまたはその他の信頼できる資格情報を利用して、メンバーの ID を確立し、安全なやり取りを確保する場合があります。
Organizations may also set up their own federations, tailored to the specific security requirements and trust models relevant to their context. For example, a private business federation might establish its own vetting processes and trust framework based on the nature of its business and the sensitivity of the data being exchanged.
組織は、コンテキストに関連する特定のセキュリティ要件と信頼モデルに合わせて、独自のフェデレーションをセットアップすることもできます。たとえば、民間ビジネス連合は、ビジネスの性質と交換されるデータの機密性に基づいて、独自の審査プロセスと信頼フレームワークを確立する場合があります。
By allowing federations the flexibility to tailor their trust frameworks and security measures, MATF can support a wide range of use cases. This flexibility is crucial for accommodating the diverse requirements and challenges faced by different federations, ensuring a secure and adaptable system for establishing trust and facilitating secure communication.
フェデレーションが信頼フレームワークとセキュリティ対策を柔軟に調整できるようにすることで、MATF は幅広いユースケースをサポートできます。この柔軟性は、さまざまなフェデレーションが直面する多様な要件や課題に対応し、信頼を確立し安全な通信を促進するための安全で適応性のあるシステムを確保するために非常に重要です。
The MATF framework operates on a trust model that is central to its design and functionality. This section outlines the key components of this trust model and its implications for federation members and the federation operator.
MATF フレームワークは、その設計と機能の中心となる信頼モデルに基づいて動作します。このセクションでは、この信頼モデルの主要なコンポーネントと、フェデレーション メンバーおよびフェデレーション オペレーターに対するその影響について概説します。
The federation operator plays a critical role in the MATF framework. This entity is responsible for:
フェデレーション オペレーターは、MATF フレームワークにおいて重要な役割を果たします。このエンティティは次の責任を負います。
* Managing the central trust anchor, which is used to establish trust across different domains within the federation.
* 中央のトラスト アンカーの管理。フェデレーション内のさまざまなドメイン間で信頼を確立するために使用されます。
* Vetting federation members to ensure they meet the required standards and policies.
* 連盟メンバーを審査して、必要な基準とポリシーを満たしていることを確認します。
* Maintaining and securing the federation metadata, which includes public key pins [RFC7469], issuer certificates, and other essential information.
* 公開鍵ピン [RFC7469]、発行者証明書、その他の重要な情報を含むフェデレーション メタデータの維持と保護。
Additionally, the federation operator SHOULD develop their own threat models to proactively identify potential risks and threats. This process involves examining the operating environment, evaluating both internal and external threats, and understanding how vulnerabilities can be exploited. The goal of the threat model is to enable the federation operator to establish mitigation strategies that address the identified risks.
さらに、フェデレーション オペレーターは、潜在的なリスクと脅威を積極的に特定するために、独自の脅威モデルを開発する必要があります (SHOULD)。このプロセスには、動作環境の調査、内部および外部の両方の脅威の評価、および脆弱性が悪用される方法の理解が含まれます。The goal of the threat model is to enable the federation operator to establish mitigation strategies that address the identified risks.
The security and stability of the federation rely on the integrity and competence of the federation operator. Members must be able to fully trust this central authority, as its role is essential to maintaining the federation's reliability and security.
フェデレーションのセキュリティと安定性は、フェデレーション オペレーターの誠実さと能力に依存しています。この中央機関の役割は連盟の信頼性とセキュリティを維持するために不可欠であるため、メンバーはこの中央機関を完全に信頼できなければなりません。
Federation members share the responsibility of maintaining trust and security within the federation.
フェデレーションのメンバーは、フェデレーション内の信頼とセキュリティを維持する責任を共有します。
Their responsibilities include:
彼らの責任には以下が含まれます:
* Adhering to the federation's security policies and procedures.
* 連盟のセキュリティ ポリシーと手順を遵守します。
* Ensuring the accuracy and timeliness of their metadata submissions.
* メタデータの提出の正確性と適時性を確保します。
* Cooperating with the federation operator's vetting and security measures.
* 連盟運営者の審査およびセキュリティ対策に協力します。
By fulfilling these responsibilities, federation members help sustain the trust framework that enables secure and reliable communication within the federation.
これらの責任を果たすことで、フェデレーション メンバーは、フェデレーション内での安全で信頼性の高い通信を可能にする信頼フレームワークの維持に役立ちます。
Federation members submit member metadata to the federation. As part of federation operations, the federation MUST ensure the authenticity and integrity of submitted member metadata and the authenticity of the submitting member.
フェデレーション メンバーは、フェデレーションにメンバー メタデータを送信します。フェデレーション操作の一環として、フェデレーションは、送信されたメンバーのメタデータの信頼性と完全性、および送信メンバーの信頼性を保証しなければなりません (MUST)。
Each federation operates within a trust framework that encompasses its own security policies and procedures. This framework is designed to ensure the integrity, authenticity, and confidentiality of communications within the federation. Key components of this framework include:
各フェデレーションは、独自のセキュリティ ポリシーと手順を包含する信頼フレームワーク内で動作します。このフレームワークは、フェデレーション内の通信の完全性、信頼性、機密性を保証するように設計されています。このフレームワークの主要なコンポーネントは次のとおりです。
* Public key pinning [RFC7469] and preloading to thwart on-path attacks by rejecting peers whose public key in the presented certificate does not match a pin published in the federation metadata.
* 公開鍵ピン留め [RFC7469] とプリロードにより、提示された証明書内の公開鍵がフェデレーション メタデータで公開されているピンと一致しないピアを拒否することで、オンパス攻撃を阻止します。
* Regular updates and verification of federation metadata to prevent the use of outdated or compromised information.
* フェデレーション メタデータを定期的に更新して検証し、古い情報や侵害された情報の使用を防ぎます。
The federation operator aggregates, signs, and publishes the federation metadata, which combines all members' member metadata along with additional federation-specific information. By placing trust in the federation and its associated federation metadata signature verification key, federation members trust the information contained within the federation metadata.
フェデレーション オペレーターは、フェデレーション メタデータを集約、署名、公開します。フェデレーション メタデータは、すべてのメンバーのメンバー メタデータとフェデレーション固有の追加情報を組み合わせたものです。フェデレーションおよびそれに関連付けられたフェデレーション メタデータ署名検証キーを信頼することにより、フェデレーション メンバーはフェデレーション メタデータに含まれる情報を信頼します。
The trust anchor for the federation is established through the federation metadata signature verification key, a critical component requiring secure distribution and verification. To achieve this, the signature verification key material is distributed using a JSON Web Key (JWK) Set [RFC7517], providing a flexible framework for exposing multiple public keys, including the current signature verification key and keys for rollover. This structured approach ensures members can readily access the necessary keys for verification purposes.
フェデレーションのトラスト アンカーは、安全な配布と検証を必要とする重要なコンポーネントであるフェデレーション メタデータ署名検証キーを通じて確立されます。これを実現するために、署名検証キー素材は JSON Web Key (JWK) Set [RFC7517] を使用して配布され、現在の署名検証キーとロールオーバー用のキーを含む複数の公開キーを公開するための柔軟なフレームワークを提供します。この構造化されたアプローチにより、メンバーは検証目的で必要なキーに簡単にアクセスできるようになります。
An additional layer of security is introduced through thumbprint verification [RFC7638], where federation members can independently verify the key's authenticity. This involves comparing the calculated cryptographic thumbprint of the key with a trusted value, ensuring its integrity. Importantly, this verification process can be conducted through channels separate from the JWK Set itself, enhancing security by eliminating reliance on a single distribution mechanism.
追加のセキュリティ層は拇印検証 [RFC7638] によって導入され、フェデレーション メンバーはキーの信頼性を独立して検証できます。これには、計算されたキーの暗号化拇印を信頼できる値と比較し、その整合性を確保することが含まれます。重要なのは、この検証プロセスは JWK セット自体とは別のチャネルを通じて実行でき、単一の配布メカニズムへの依存を排除することでセキュリティを強化できることです。
This trust framework is essential for enabling seamless and secure interoperability across different trust domains within the federation.
この信頼フレームワークは、フェデレーション内のさまざまな信頼ドメイン間でシームレスで安全な相互運用性を実現するために不可欠です。
To ensure the security and integrity of the MATF framework, a member vetting process is essential. Detailed vetting processes are beyond the scope of this document but can be guided by established frameworks such as eIDAS and eduGAIN.
MATF フレームワークのセキュリティと整合性を確保するには、メンバーの審査プロセスが不可欠です。詳細な審査プロセスはこの文書の範囲を超えていますが、eIDAS や eduGAIN などの確立されたフレームワークによってガイドできます。
The following are non-normative references to established frameworks:
以下は、確立されたフレームワークへの非規範的な参照です。
* eIDAS: The eIDAS regulation can provide guidance for member vetting and identity assurance practices.
* eIDAS: eIDAS 規制は、会員の審査と身元保証の実践に関するガイダンスを提供できます。
* eduGAIN: eduGAIN is an interfederation service connecting identity federations worldwide, primarily within the research and education sector. eduGAIN documentation on participation requirements and federation practices can inform member vetting processes [eduGAIN].
* eduGAIN: eduGAIN は、主に研究および教育部門内の世界中のアイデンティティ フェデレーションを接続する相互フェデレーション サービスです。参加要件と連合の実践に関する eduGAIN 文書は、メンバーの審査プロセスに情報を提供できます [eduGAIN]。
Ensuring the authenticity of metadata is necessary for maintaining the security and trustworthiness of the MATF framework. This document specifies mechanisms for protecting and verifying the authenticity of federation metadata, including JWS signing. Operational procedures for authenticating member metadata submissions are outside the scope of this document and are defined by the federation operator or applicable regulatory bodies.
メタデータの信頼性を確保することは、MATF フレームワークのセキュリティと信頼性を維持するために必要です。この文書は、JWS 署名を含むフェデレーション メタデータの信頼性を保護および検証するためのメカニズムを指定します。メンバーのメタデータ送信を認証するための操作手順は、この文書の範囲外であり、フェデレーション オペレーターまたは該当する規制機関によって定義されます。
The MATF metadata repository acts as a central vault, securely storing all information about all participating federation members and their respective entities. This information, known as federation metadata, is presented as a JSON Web Signature (JWS) [RFC7515] to ensure its authenticity and integrity.
MATF メタデータ リポジトリは、中央保管庫として機能し、参加しているすべてのフェデレーション メンバーとそれぞれのエンティティに関するすべての情報を安全に保存します。フェデレーション メタデータとして知られるこの情報は、その信頼性と完全性を保証するために JSON Web Signature (JWS) [RFC7515] として提示されます。
The metadata repository is subject to stringent security measures to safeguard the integrity of the stored information. This MAY involve:
メタデータ リポジトリには、保存された情報の整合性を保護するための厳格なセキュリティ対策が適用されます。これには以下が含まれる場合があります:
* Member management: The federation operator can centrally enforce security policies and vet new members before they are added to the repository.
* メンバー管理: フェデレーション オペレーターは、セキュリティ ポリシーを一元的に適用し、リポジトリに追加される前に新しいメンバーを精査できます。
* Access controls: Access to repository management functions and member metadata submission endpoints SHOULD be restricted to authorized federation members.
* アクセス制御: リポジトリ管理機能とメンバーのメタデータ送信エンドポイントへのアクセスは、承認されたフェデレーション メンバーに制限されるべきです。
* Regular backups: Robust backup procedures ensure data recovery in case of unforeseen circumstances.
* 定期的なバックアップ: 堅牢なバックアップ手順により、不測の事態が発生した場合でもデータを確実に回復します。
Before member metadata is added to the federation's repository, the submitted metadata MUST undergo a validation process. This process verifies the accuracy, completeness, and validity of the information provided by a member. Metadata that does not pass validation MUST be rejected. The validation process MUST include, at a minimum, the following checks:
メンバーのメタデータがフェデレーションのリポジトリに追加される前に、送信されたメタデータは検証プロセスを受けなければなりません。このプロセスでは、会員から提供された情報の正確性、完全性、有効性が検証されます。検証に合格しないメタデータは拒否されなければなりません (MUST)。検証プロセスには、少なくとも次のチェックが含まれなければなりません。
* Format validation: The submitted metadata is checked to ensure that it conforms to the schema and format specifications defined in Section 6.2 and Appendix A.
* 形式の検証: 送信されたメタデータがチェックされ、セクション 6.2 および付録 A で定義されているスキーマおよび形式の仕様に準拠していることが確認されます。
* Unique entity identifier: The submitted metadata is checked to ensure that the entity_id value, as defined in Section 6.1.1, is not already registered by another member.
* 固有のエンティティ識別子: 送信されたメタデータは、セクション 6.1.1 で定義されているentity_id 値が別のメンバーによってまだ登録されていないことを確認するためにチェックされます。
* Unique public key pin digests: The submitted metadata is checked to ensure that pins entries, as defined in Section 6.1.1.1, do not introduce a digest value that is already registered to a different entity_id. While reuse of the same digest value within the same entity_id is permitted, uniqueness across different entities is REQUIRED to prevent identity collisions and to support the resolution of a unique entity_id from a derived pin, as specified in Section 5.2.
* 固有の公開キー PIN ダイジェスト: 送信されたメタデータがチェックされ、セクション 6.1.1.1 で定義されているとおり、PIN エントリに、別のentity_id にすでに登録されているダイジェスト値が導入されていないことが確認されます。同じentity_id内で同じダイジェスト値を再利用することは許可されていますが、セクション5.2で規定されているように、IDの衝突を防止し、派生ピンからの一意のentity_idの解決をサポートするために、異なるエンティティ間での一意性が必要です。
* Issuer certificate checks: The issuer certificates in issuers, as defined in Section 6.1.1, are checked to ensure that they are syntactically valid, not expired, and use algorithms that meet the federation's security requirements.
* 発行者証明書のチェック: セクション 6.1.1 で定義されている発行者の発行者証明書は、構文的に有効であること、有効期限が切れていないこと、およびフェデレーションのセキュリティ要件を満たすアルゴリズムを使用していることを確認するためにチェックされます。
* Tag validation: Tags, as defined in Section 6.1.1.1, are checked to ensure that they conform to the defined tag syntax. If the federation defines an approved set of tag values, submitted tags are checked to ensure that they are members of that set.
* タグの検証: セクション 6.1.1.1 で定義されているタグは、定義されたタグ構文に準拠していることを確認するためにチェックされます。フェデレーションが承認されたタグ値のセットを定義している場合、送信されたタグはチェックされ、そのセットのメンバーであることが確認されます。
The metadata repository provides a controlled location for storing member metadata and for producing federation metadata for distribution to federation members.
メタデータ リポジトリは、メンバーのメタデータを保存し、フェデレーション メンバーに配布するためのフェデレーション メタデータを生成するための、制御された場所を提供します。
It is up to the federation, through its governance and operational processes, to determine which channels are provided to members for submitting their metadata to the metadata repository. Members typically have the option to upload the metadata directly to the repository, provided such functionality exists, or to send it to the federation operator through a designated secure channel. If an insecure channel is used, additional measures MUST be taken to verify the authenticity and integrity of the metadata. Such measures may include verifying the checksum of the metadata through another channel. The choice of submission channel may depend on factors such as the federation's guidelines and the preferences of the member.
メタデータをメタデータ リポジトリに送信するためにメンバーにどのチャネルを提供するかを決定するのは、フェデレーションのガバナンスおよび運用プロセスを通じて決定されます。通常、メンバーには、そのような機能が存在する場合にメタデータをリポジトリに直接アップロードするか、指定された安全なチャネルを通じてフェデレーション オペレーターに送信するかを選択できます。安全でないチャネルが使用される場合は、メタデータの信頼性と完全性を検証するために追加の措置を講じなければなりません。このような措置には、別のチャネルを通じてメタデータのチェックサムを検証することが含まれる場合があります。提出チャンネルの選択は、連盟のガイドラインやメンバーの好みなどの要因に依存する場合があります。
In a MATF federation, accurate and current metadata is essential for ensuring secure and reliable communication between members. This necessitates maintaining up-to-date metadata accessible by all members.
MATF フェデレーションでは、メンバー間の安全で信頼性の高い通信を確保するために、正確かつ最新のメタデータが不可欠です。そのため、すべてのメンバーがアクセスできる最新のメタデータを維持する必要があります。
* Federation metadata: The federation operator publishes a JWS containing an aggregate of all entity metadata. This JWS serves as the source of truth for information about all members within the federation. Outdated information in the JWS can lead to issues such as failed connections, discovery challenges, and potential security risks.
* フェデレーション メタデータ: フェデレーション オペレーターは、すべてのエンティティ メタデータの集約を含む JWS を公開します。この JWS は、連盟内のすべてのメンバーに関する信頼できる情報源として機能します。JWS 内の情報が古いと、接続の失敗、検出の問題、潜在的なセキュリティ リスクなどの問題が発生する可能性があります。
* Local metadata: Each member maintains a local metadata store containing information about other members within the federation. This information is retrieved from the federation's publicly accessible JWS. Outdated data in the local store can hinder a member's ability to discover and connect with other relevant entities.
* ローカル メタデータ: 各メンバーは、フェデレーション内の他のメンバーに関する情報を含むローカル メタデータ ストアを維持します。この情報は、フェデレーションの公的にアクセス可能な JWS から取得されます。Outdated data in the local store can hinder a member's ability to discover and connect with other relevant entities.
The following outlines the procedures for keeping metadata up to date:
以下に、メタデータを最新の状態に保つ手順の概要を示します。
* Federation Operator Role: The federation operator plays a crucial role in maintaining data integrity within the federation. Their responsibilities include:
* フェデレーション オペレーターの役割: フェデレーション オペレーターは、フェデレーション内のデータの整合性を維持する上で重要な役割を果たします。彼らの責任には次のものが含まれます。
- Defining rules for metadata management that MUST include, at a minimum, expiration and cache time management.
- 少なくとも有効期限とキャッシュ時間の管理を含めなければならないメタデータ管理のルールを定義します。
- Implementing mechanisms to update the published federation metadata, ensuring it adheres to the expiration time (exp as defined in Section 6.1) and cache TTL (cache_ttl as defined in Section 6.1) specifications.
- 公開されたフェデレーション メタデータを更新するためのメカニズムを実装し、有効期限 (セクション 6.1 で定義されている exp) およびキャッシュ TTL (セクション 6.1 で定義されている cache_ttl) 仕様に準拠していることを確認します。
* Member Responsibility: Members must follow the federation's metadata management rules and refresh their local metadata store according to the defined expiration and cache regulations.
* メンバーの責任: メンバーは、フェデレーションのメタデータ管理ルールに従い、定義された有効期限とキャッシュの規制に従ってローカル メタデータ ストアを更新する必要があります。
By adhering to these responsibilities, the federation ensures that information remains valid for the defined timeframe and that caching mechanisms utilize up-to-date data effectively.
これらの責任を遵守することで、フェデレーションは、定義された期間にわたって情報が有効であり、キャッシュ メカニズムが最新のデータを効果的に利用することを保証します。
All communication established within the federation uses TLS 1.3 [RFC8446] with mutual authentication. This mechanism ensures the authenticity of both communicating parties, establishing a robust foundation for secure data exchange.
フェデレーション内で確立されるすべての通信は、相互認証を伴う TLS 1.3 [RFC8446] を使用します。このメカニズムにより、通信する双方の信頼性が保証され、安全なデータ交換のための堅牢な基盤が確立されます。
MATF implements public key pinning based on [RFC7469]. Public key pinning associates one or more public key pins with each federation endpoint. These pins are published in the federation metadata. During a connection, clients and servers extract the public key from the presented certificate and verify that it matches the preconfigured public key pins retrieved from the federation metadata.
MATF は、[RFC7469] に基づいて公開鍵の固定を実装します。公開キーのピン留めは、1 つ以上の公開キーのピンを各フェデレーション エンドポイントに関連付けます。これらのピンはフェデレーション メタデータで公開されます。接続中に、クライアントとサーバーは、提示された証明書から公開キーを抽出し、それがフェデレーション メタデータから取得した事前構成された公開キー PIN と一致することを確認します。
The decision to utilize public key pinning in the MATF framework was driven by several critical factors aimed at enhancing security and ensuring trust.
MATF フレームワークで公開キーの固定を利用するという決定は、セキュリティの強化と信頼の確保を目的としたいくつかの重要な要因によって決定されました。
In interfederation environments, where multiple federations need to trust each other, public key pinning remains effective. Members can validate entities in other federations using pins published through shared metadata, ensuring trust across boundaries. Unlike private certificate chains, which can become complex and difficult to manage across multiple federations, public key pinning provides a straightforward mechanism for establishing trust. MATF interfederation addresses this challenge by aggregating metadata from all participating federations into a unified metadata repository. This shared metadata enables secure communication between entities in different federations, ensuring consistent key validation and robust cross-federation trust and security.
複数のフェデレーションが相互に信頼する必要があるフェデレーション環境では、公開キーのピン留めは引き続き有効です。メンバーは、共有メタデータを通じて公開されたピンを使用して他のフェデレーションのエンティティを検証し、境界を越えた信頼を確保できます。複雑になり、複数のフェデレーション間での管理が困難になる可能性があるプライベート証明書チェーンとは異なり、公開キーのピン留めは、信頼を確立するための簡単なメカニズムを提供します。MATF インターフェデレーションは、参加しているすべてのフェデレーションからのメタデータを統合メタデータ リポジトリに集約することで、この課題に対処します。この共有メタデータにより、異なるフェデレーション内のエンティティ間の安全な通信が可能になり、一貫したキー検証とフェデレーション間の堅牢な信頼とセキュリティが確保されます。
Public key pinning provides a robust defense mechanism by directly binding a peer to a specific public key. This ensures that only the designated key is trusted, preventing attackers from exploiting fraudulent certificates. By eliminating reliance on external trust intermediaries, this approach significantly enhances resilience against potential threats.
公開キーの固定は、ピアを特定の公開キーに直接バインドすることにより、堅牢な防御メカニズムを提供します。これにより、指定されたキーのみが信頼されるようになり、攻撃者による不正な証明書の悪用が防止されます。このアプローチは、外部の信頼仲介者への依存を排除することで、潜在的な脅威に対する回復力を大幅に強化します。
The use of self-signed certificates within the federation leverages public key pinning to establish trust. By bypassing external Certificate Authorities (CAs), servers and clients rely on the federation's mechanisms to validate trust. Public key pinning ensures that only the specific self-signed public keys, identified by key pins in the metadata, are trusted.
フェデレーション内で自己署名証明書を使用すると、公開キーの固定を活用して信頼を確立します。外部の認証局 (CA) をバイパスすることにより、サーバーとクライアントはフェデレーションのメカニズムに依存して信頼を検証します。公開キーのピン留めにより、メタデータ内のキー ピンによって識別される特定の自己署名公開キーのみが信頼されることが保証されます。
In deployments that rely on certificate chains and certificate revocation mechanisms, revocation can be complex and slow. This complexity arises because a certificate that can no longer be trusted, and potentially other certificates within the chain, may need to be revoked and reissued. Public key pinning mitigates this complexity by allowing clients to base trust decisions on pinned public keys rather than on certificate chains.
証明書チェーンと証明書失効メカニズムに依存する展開では、失効が複雑で時間がかかる可能性があります。この複雑さは、信頼できなくなった証明書、およびチェーン内の他の証明書を取り消して再発行する必要がある可能性があるために発生します。公開キーの固定は、クライアントが証明書チェーンではなく固定された公開キーに基づいて信頼の決定を行えるようにすることで、この複雑さを軽減します。
If a public key can no longer be trusted within a MATF federation, the associated pin is removed. Updated metadata is published. The updated metadata includes a new pin corresponding to the public key in the replacement certificate. This approach reduces reliance on certificate revocation mechanisms and shifts the trust relationship to the specific, updated public key identified by its pin.
MATF フェデレーション内で公開キーが信頼できなくなった場合、関連付けられた PIN は削除されます。更新されたメタデータが公開されます。更新されたメタデータには、置換証明書の公開キーに対応する新しい PIN が含まれています。このアプローチにより、証明書失効メカニズムへの依存が軽減され、信頼関係が PIN によって識別される特定の更新された公開キーに移行されます。
Peers in the federation obtain public key pins from the federation metadata. These pins serve as preconfigured trust parameters used for validation, as specified in Section 5.3.
フェデレーション内のピアは、フェデレーション メタデータから公開キー PIN を取得します。これらのピンは、セクション 5.3 で指定されているように、検証に使用される事前設定された信頼パラメーターとして機能します。
The federation MUST define discovery rules. These rules describe how peers use federation metadata claims such as organization and tags to identify relevant endpoints and their pins.
フェデレーションは検出ルールを定義しなければなりません。これらのルールは、ピアが組織やタグなどのフェデレーション メタデータ クレームを使用して、関連するエンドポイントとそのピンを識別する方法を説明します。
Before initiating or accepting a connection, a peer MUST preload the pins for the selected or authorized endpoints from its local metadata store. Maintenance of the local metadata store, including refresh behavior and expiry handling, is specified in Section 4.2.
接続を開始または受け入れる前に、ピアは選択または承認されたエンドポイントのピンをローカル メタデータ ストアからプリロードしなければなりません (MUST)。更新動作や有効期限の処理を含むローカル メタデータ ストアのメンテナンスについては、セクション 4.2 で規定されています。
To support peer identification, the preloaded state MUST enable mapping from a derived pin to the corresponding entity_id. This may be achieved by maintaining a local index that maps each preloaded pin value to its associated entity_id.
ピアの識別をサポートするには、プリロード状態で派生ピンから対応するentity_idへのマッピングを有効にしなければなりません(MUST)。これは、プリロードされた各ピン値をその関連するentity_idにマップするローカルインデックスを維持することによって実現できます。
A server MAY preload only the pins for clients that satisfy the server's connection policy (for example, based on organization or tags). Pin validation enforces the resulting policy as specified in Section 5.3.
サーバーは、サーバーの接続ポリシー (たとえば、組織やタグに基づく) を満たすクライアントのピンのみをプリロードしてもよい(MAY)。PIN 検証では、セクション 5.3 で指定されているポリシーが適用されます。
Upon connection establishment, both endpoints MUST verify that the public key in the presented peer certificate matches a pin published in the federation metadata. This validation MAY be performed by the TLS stack or by application logic.
接続の確立時に、両方のエンドポイントは、提示されたピア証明書の公開キーがフェデレーション メタデータで公開されている PIN と一致することを確認しなければなりません (MUST)。この検証は、TLS スタックまたはアプリケーション ロジックによって実行されてもよい (MAY)。
In architectures where an intermediary terminates the TLS session, pin validation MUST be performed by either the intermediary or the application. If the application performs pin validation, the intermediary MUST forward the peer certificate or a derived pin to the application. The application MUST be able to determine the peer entity_id from the forwarded information and the federation metadata. This resolution relies on the client pin digest uniqueness property specified in Section 6.1.1.1.
仲介者が TLS セッションを終了するアーキテクチャでは、PIN 検証は仲介者またはアプリケーションのいずれかによって実行されなければなりません (MUST)。アプリケーションが PIN 検証を実行する場合、仲介者はピア証明書または派生した PIN をアプリケーションに転送しなければなりません (MUST)。アプリケーションは、転送された情報とフェデレーションメタデータからピアのentity_idを決定できなければなりません(MUST)。この解決は、セクション 6.1.1.1 で指定されているクライアント PIN ダイジェストの一意性プロパティに依存します。
If the intermediary performs pin validation, it MUST propagate the peer certificate, the derived pin, or the entity_id to the application to enable authorization.
仲介者がピン検証を実行する場合、認可を有効にするために、ピア証明書、派生ピン、またはentity_idをアプリケーションに伝播しなければなりません(MUST)。
The channel between the intermediary and the application MUST be integrity protected and MUST provide endpoint authentication.
仲介者とアプリケーション間のチャネルは完全性が保護されなければならず、エンドポイント認証を提供しなければなりません。
Any conveyed certificate, pin, or identity used for this purpose MUST be derived directly from the TLS session. Implementations MUST NOT accept these values from peer-supplied application data.
この目的で使用される伝達される証明書、PIN、または ID は、TLS セッションから直接派生する必要があります。実装は、ピアが提供するアプリケーション データからこれらの値を受け入れてはなりません (MUST NOT)。
If the implementation permits disabling default CA-based certificate chain validation, it SHOULD do so while still enforcing pin validation. If chain validation is required, the trust anchors used for certificate chain validation MUST be selected from the issuers listed in the federation metadata.
実装がデフォルトの CA ベースの証明書チェーン検証の無効化を許可する場合、PIN 検証を強制しながらそうする必要があります (SHOULD)。チェーンの検証が必要な場合、証明書チェーンの検証に使用されるトラスト アンカーは、フェデレーション メタデータにリストされている発行者から選択する必要があります。
If no matching pin is found for a peer, the connection MUST be handled according to Section 5.4.
ピアに一致するピンが見つからない場合、接続はセクション 5.4 に従って処理されなければなりません。
A received certificate that fails validation MUST result in the immediate termination of the connection. This includes scenarios where the derived pin does not match any preloaded pin or where the peer identity cannot be resolved. This strict enforcement ensures that only authorized and secure communication channels are established within the federation.
受信した証明書が検証に失敗した場合は、接続を即時に終了しなければなりません (MUST)。これには、派生ピンがプリロードされたピンと一致しないシナリオ、またはピア ID を解決できないシナリオが含まれます。この厳格な実施により、承認された安全な通信チャネルのみがフェデレーション内で確立されることが保証されます。
To replace a certificate, whether due to expiration or other reasons, the following procedure MUST be followed:
証明書を置き換えるには、有効期限またはその他の理由にかかわらず、次の手順に従う必要があります。
1. Submitting updated metadata: When a certificate is scheduled for rotation, the federation member submits updated metadata that adds the pin for the new public key alongside the already published pins. The federation operator republishes the signed federation metadata aggregate, making the new pin available to all federation members.
1. 更新されたメタデータの送信: 証明書のローテーションがスケジュールされている場合、フェデレーション メンバーは、既に公開されているピンに加えて新しい公開キーのピンを追加する更新されたメタデータを送信します。フェデレーション オペレーターは、署名されたフェデレーション メタデータ集合体を再公開し、すべてのフェデレーション メンバーが新しいピンを利用できるようにします。
2. Propagation period: Federation members MUST refresh their local metadata stores as specified in Section 4.2. The rotating member MUST allow sufficient time for peers to refresh and preload the new pin before switching to the new certificate.
2. 伝播期間: フェデレーション メンバーは、セクション 4.2 で指定されているようにローカル メタデータ ストアを更新しなければなりません (MUST)。ローテーションメンバーは、新しい証明書に切り替える前に、ピアが新しいピンを更新してプリロードするのに十分な時間を確保しなければなりません (MUST)。
3. Switching to the new certificate: After the propagation period has elapsed, the rotating member updates its TLS stack to present the new certificate. This allows peers that have preloaded the new pin to validate the rotated certificate.
3. 新しい証明書への切り替え: 伝播期間が経過すると、ローテーション メンバーが TLS スタックを更新して新しい証明書を提示します。これにより、新しいピンをプリロードしたピアが、ローテーションされた証明書を検証できるようになります。
4. Removing the old pin: Following a successful transition, the rotating member MUST submit updated metadata excluding the old pin. The federation operator republishes the aggregate, ensuring that only current public keys remain trusted within the federation.
4. 古いピンの削除: 移行が成功した後、ローテーションメンバーは古いピンを除いて更新されたメタデータを送信しなければなりません(MUST)。フェデレーション オペレーターは集約を再公開し、現在の公開キーのみがフェデレーション内で信頼されるようにします。
The placement of pin validation depends on the deployment architecture. For clients, validation is typically performed by the component initiating the TLS connection. For servers using an intermediary, the communication channel between the intermediary and the application MUST be integrity protected to prevent tampering with forwarded peer identity material.
ピン検証の配置は、展開アーキテクチャによって異なります。クライアントの場合、検証は通常、TLS 接続を開始するコンポーネントによって実行されます。仲介者を使用するサーバーの場合、転送されたピア ID マテリアルの改ざんを防ぐために、仲介者とアプリケーション間の通信チャネルの整合性が保護されなければなりません (MUST)。
When an intermediary propagates peer identity material (for example, the peer certificate, a derived pin, or the entity_id) using HTTP header fields, those header fields are the mechanism used to fulfill the requirements specified in Section 5.3. For each header field name used for this purpose, the intermediary MUST remove any instance of that header field received from the peer and then set the header field value itself. This ensures that the application only processes identity material derived directly from the TLS session, enabling the application to match the peer to the federation metadata and apply authorization policy based on federation metadata claims. Header fields that are not used to convey identity material are unaffected by this requirement. The communication channel between the intermediary and the application MUST provide integrity protection and endpoint authentication to prevent tampering with forwarded peer identity material.
仲介者が HTTP ヘッダー フィールドを使用してピア ID マテリアル (ピア証明書、派生ピン、entity_id など) を伝播する場合、これらのヘッダー フィールドは、セクション 5.3 で指定された要件を満たすために使用されるメカニズムです。この目的で使用されるヘッダーフィールド名ごとに、仲介者はピアから受信したヘッダーフィールドのインスタンスをすべて削除し、ヘッダーフィールド値自体を設定しなければなりません(MUST)。これにより、アプリケーションは TLS セッションから直接派生した ID マテリアルのみを処理することが保証され、アプリケーションがピアをフェデレーション メタデータと照合し、フェデレーション メタデータのクレームに基づいて認可ポリシーを適用できるようになります。ID マテリアルの伝達に使用されないヘッダー フィールドは、この要件の影響を受けません。仲介者とアプリケーション間の通信チャネルは、転送されたピア ID マテリアルの改ざんを防ぐために、完全性保護とエンドポイント認証を提供しなければなりません (MUST)。
Implementations SHOULD, when possible, rely on libraries with built-in support for pinning. libcurl, for example, supports pinning via the CURLOPT_PINNEDPUBLICKEY option. In Python, the cryptography library can extract public keys, and application code can compare the derived pin to a configured value. Go provides crypto/tls and crypto/x509 for certificate inspection and public key extraction. In Java, java.security.cert.X509Certificate enables public key extraction, while java.net.http.HttpClient allows pinning enforcement using a custom SSLContext and TrustManager. The choice of library is left to the discretion of each implementation.
実装は、可能であれば、固定のサポートが組み込まれたライブラリに依存するべきです(SHOULD)。たとえば、libcurl は、CURLOPT_PINNEDPUBLICKEY オプションによる固定をサポートします。Python では、暗号ライブラリは公開キーを抽出でき、アプリケーション コードは派生した PIN を構成された値と比較できます。Go は、証明書検査と公開キー抽出のために crypto/tls および crypto/x509 を提供します。Java では、java.security.cert.X509Certificate によって公開キーの抽出が可能になり、java.net.http.HttpClient によってカスタム SSLContext および TrustManager を使用したピン留めの強制が可能になります。ライブラリの選択は、各実装の裁量に任されています。
Federation metadata is published as a JSON Web Signature (JWS) [RFC7515]. The payload contains statements about entities of federation members.
フェデレーション メタデータは、JSON Web Signature (JWS) [RFC7515] として公開されます。ペイロードには、フェデレーション メンバーのエンティティに関するステートメントが含まれています。
Metadata is used for authentication and service discovery. A client selects a server based on metadata claims such as organization and tags. To establish a connection, the client uses the base_uri, pins, and, if needed, issuers of the selected server.
メタデータは認証とサービス検出に使用されます。クライアントは、組織やタグなどのメタデータ要求に基づいてサーバーを選択します。接続を確立するために、クライアントは、base_uri、pin、および必要に応じて、選択したサーバーの発行者を使用します。
This section defines the set of claims that can be included in metadata.
このセクションでは、メタデータに含めることができるクレームのセットを定義します。
* iat (REQUIRED)
* iat (必須)
Identifies the time at which the federation metadata was issued.
フェデレーション メタデータが発行された時刻を識別します。
- Data Type: Integer
- データ型: 整数
- Syntax: NumericDate as defined in [RFC7519], Section 4.1.6.
- 構文: [RFC7519]、セクション 4.1.6 で定義されている NumericDate。
- Example: 1755514949
- 例: 1755514949
* exp (REQUIRED)
* 経験値 (必須)
Identifies the expiration time on or after which the federation metadata is no longer valid. Once the exp time has passed, the metadata MUST be rejected regardless of cache state.
フェデレーション メタデータが有効でなくなるまでの有効期限を示します。exp 時間が経過すると、キャッシュの状態に関係なく、メタデータは拒否されなければなりません (MUST)。
- Data Type: Integer
- データ型: 整数
- Syntax: NumericDate as defined in [RFC7519], Section 4.1.4.
- 構文: [RFC7519]、セクション 4.1.4 で定義されている NumericDate。
- Example: 1756119888
- 例: 1756119888
* iss (REQUIRED)
* (必須)
A URI uniquely identifying the issuing federation. This value differentiates federations, prevents ambiguity, and ensures that entities are recognized within their intended context. Verification of the iss claim enables recipients to determine the origin of the information and to establish trust with entities within the identified federation.
発行元のフェデレーションを一意に識別する URI。この値はフェデレーションを区別し、曖昧さを防ぎ、エンティティが意図されたコンテキスト内で確実に認識されるようにします。iss クレームの検証により、受信者は情報の出所を特定し、特定されたフェデレーション内のエンティティとの信頼を確立することができます。
- Data Type: String
- データ型: 文字列
- Syntax: StringOrURI as defined in [RFC7519], Section 4.1.1. In MATF, this value MUST be a URI.
- 構文: [RFC7519]、セクション 4.1.1 で定義されている StringOrURI。MATF では、この値は URI でなければなりません。
- Example: "https://federation.example.org"
- 例: 「https://federation.example.org」
* version (REQUIRED)
* バージョン (必須)
Indicates the schema version of the federation metadata. This ensures compatibility between members of the federation by defining a clear versioning mechanism for interpreting metadata.
フェデレーション メタデータのスキーマ バージョンを示します。これにより、メタデータを解釈するための明確なバージョン管理メカニズムが定義されるため、フェデレーションのメンバー間の互換性が確保されます。
- Data Type: String
- データ型: 文字列
- Syntax: The value MUST follow Semantic Versioning (see <https://semver.org>).
- 構文: 値はセマンティック バージョニングに従わなければなりません (<https://semver.org> を参照)。
- Example: "1.0.0"
- 例：「1.0.0」
* cache_ttl (OPTIONAL)
* キャッシュ_ttl (オプション)
Specifies the duration in seconds for caching downloaded federation metadata, allowing for independent caching outside of specific HTTP configurations. This is particularly useful when the communication mechanism is not based on HTTP. In the event of a metadata publication outage, members can rely on cached metadata until it expires, as indicated by the exp claim in the JWS payload, defined in Section 6.1. Once expired, metadata MUST no longer be trusted. If omitted, a mechanism to refresh metadata MUST still exist to ensure the metadata remains valid.
ダウンロードされたフェデレーション メタデータをキャッシュする期間を秒単位で指定します。これにより、特定の HTTP 構成の外部で独立したキャッシュが可能になります。これは、通信メカニズムが HTTP に基づいていない場合に特に便利です。メタデータの公開が停止した場合、セクション 6.1 で定義されている JWS ペイロードの exp クレームで示されているように、メンバーは期限が切れるまでキャッシュされたメタデータに依存できます。有効期限が切れると、メタデータは信頼できなくなります。省略した場合でも、メタデータが有効なままであることを保証するために、メタデータを更新するメカニズムが存在しなければなりません (MUST)。
- Data Type: Integer
- データ型: 整数
- Syntax: Integer representing the duration in seconds.
- 構文: 期間を秒単位で表す整数。
- Example: 3600
- 例: 3600
* entities (REQUIRED)
* エンティティ (必須)
Contains the list of entities within the federation.
フェデレーション内のエンティティのリストが含まれます。
- Data Type: Array of Objects
- データ型: オブジェクトの配列
- Syntax: Each object MUST conform to the entity definition, as specified in Section 6.1.1.
- 構文: 各オブジェクトは、セクション 6.1.1 で指定されているエンティティ定義に準拠しなければなりません (MUST)。
Metadata contains a list of entities that may be used for communication within the federation. Each entity describes one or more endpoints owned by a member. An entity has the following properties:
メタデータには、フェデレーション内の通信に使用できるエンティティのリストが含まれています。各エンティティは、メンバーが所有する 1 つ以上のエンドポイントを記述します。エンティティには次のプロパティがあります。
* entity_id (REQUIRED)
* エンティティ ID (必須)
A URI that uniquely identifies the entity. This identifier MUST NOT collide with any other entity_id within the federation or within any other federation that the entity interacts with.
エンティティを一意に識別する URI。この識別子は、フェデレーション内、またはエンティティが対話する他のフェデレーション内の他のentity_idと衝突してはなりません(MUST NOT)。
- Data Type: String
- データ型: 文字列
- Syntax: URI as defined in [RFC3986].
- 構文: [RFC3986] で定義されている URI。
- Example: "https://example.com"
- 例: 「https://example.com」
* organization (OPTIONAL)
* 組織 (オプション)
A name identifying the organization that the entity's metadata represents. The federation operator MUST ensure that a mechanism is in place to verify that the organization claim corresponds to the rightful owner of the information exchanged between nodes. This is crucial for the trust model, ensuring certainty about the identities of the involved parties. The federation operator SHOULD choose an approach that best suits the specific needs and trust model of the federation.
エンティティのメタデータが表す組織を識別する名前。フェデレーションオペレータは、組織の主張がノード間で交換される情報の正当な所有者に対応することを検証するメカニズムが整備されていることを確認しなければなりません(MUST)。これは信頼モデルにとって重要であり、関係者の身元に関する確実性を確保します。フェデレーション オペレータは、フェデレーションの特定のニーズと信頼モデルに最も適したアプローチを選択する必要があります (SHOULD)。
- Data Type: String
- データ型: 文字列
- Syntax: A name identifying the organization represented by the entity.
- 構文: エンティティによって表される組織を識別する名前。
- Example: "Example Org"
- 例: 「組織例」
* issuers (REQUIRED)
* 発行者 (必須)
A list of certificate issuers allowed to issue certificates for the entity's endpoints. For each issuer, the issuer's root CA certificate MUST be included in the x509certificate property and be encoded using the Privacy-Enhanced Mail (PEM) format. Certificate verification relies on public key pinning, with the list of allowed issuers used only when a certificate chain validation mechanism is unavoidable. For self-signed certificates, the certificate itself acts as its own issuer and MUST be listed as such in the metadata.
エンティティのエンドポイントの証明書を発行できる証明書発行者のリスト。各発行者について、発行者のルート CA 証明書を x509certificate プロパティに含め、プライバシー強化メール (PEM) 形式を使用してエンコードする必要があります。証明書の検証は公開キーの固定に依存しており、証明書チェーンの検証メカニズムが避けられない場合にのみ、許可された発行者のリストが使用されます。自己署名証明書の場合、証明書自体が独自の発行者として機能し、そのようにメタデータにリストされなければなりません。
- Data Type: Array of Objects
- データ型: オブジェクトの配列
- Syntax: Each object contains an issuer certificate encoded as PEM, as specified in [RFC7468]. The Base64 content MUST be wrapped so that each line consists of exactly 64 characters, except for the final line. In JSON text, line breaks in the PEM value are represented using the "\n" escape sequence.
- 構文: 各オブジェクトには、[RFC7468] で指定されているように、PEM としてエンコードされた発行者証明書が含まれています。Base64 コンテンツは、最終行を除き、各行がちょうど 64 文字で構成されるように折り返されなければなりません (MUST)。JSON テキストでは、PEM 値の改行は「\n」エスケープ シーケンスを使用して表されます。
- Example: Issuer truncated for readability.
- 例: 読みやすくするために発行者は切り詰められています。
"issuers": [{
"x509certificate": "-----BEGIN CERTIFICATE-----\nMIIDDD"
}]
* servers (OPTIONAL)
* サーバー (オプション)
Contains the list of servers within the entity.
エンティティ内のサーバーのリストが含まれます。
- Data Type: Array of Objects
- データ型: オブジェクトの配列
- Syntax: Each object MUST conform to the server definition, as specified in Section 6.1.1.1.
- 構文: 各オブジェクトは、セクション 6.1.1.1 で指定されているサーバー定義に準拠しなければなりません (MUST)。
* clients (OPTIONAL)
* クライアント (オプション)
Contains the list of clients within the entity.
エンティティ内のクライアントのリストが含まれます。
- Data Type: Array of Objects
- データ型: オブジェクトの配列
- Syntax: Each object MUST conform to the client definition, as specified in Section 6.1.1.1.
- 構文: 各オブジェクトは、セクション 6.1.1.1 で指定されているクライアント定義に準拠しなければなりません (MUST)。
The entity's servers and clients are listed below.
エンティティのサーバーとクライアントは以下にリストされています。
* description (OPTIONAL)
* 説明 (オプション)
A human-readable text describing the server or client.
サーバーまたはクライアントを説明する人間が読めるテキスト。
- Data Type: String
- データ型: 文字列
- Syntax: Free-form text describing the server or client.
- 構文: サーバーまたはクライアントを説明する自由形式のテキスト。
- Example: "SCIM Server 1"
- 例: 「SCIM サーバー 1」
* base_uri (REQUIRED for servers, OPTIONAL for clients)
* Base_uri (サーバーの場合は必須、クライアントの場合はオプション)
The base URL of the server. This claim is REQUIRED for server endpoints. The value MUST be an absolute URI as defined in Section 4.3 of [RFC3986]. The value serves as the base URI for resolving relative references to server resources, as described in Section 5 of [RFC3986].
サーバーのベース URL。この要求はサーバー エンドポイントに必須です。値は、[RFC3986] のセクション 4.3 で定義されている絶対 URI でなければなりません (MUST)。この値は、[RFC3986] のセクション 5 で説明されているように、サーバー リソースへの相対参照を解決するためのベース URI として機能します。
- Data Type: String
- データ型: 文字列
- Syntax: An absolute URI as defined in Section 4.3 of [RFC3986] that is used as a URL.
- 構文: URL として使用される、[RFC3986] のセクション 4.3 で定義されている絶対 URI。
- Example: "https://scim.example.com/"
- 例: 「https://scim.example.com/」
* pins (REQUIRED)
* ピン (必須)
A list of objects representing public key pins [RFC7469].
公開鍵ピンを表すオブジェクトのリスト [RFC7469]。
- Data Type: Array of Objects
- データ型: オブジェクトの配列
- Syntax: A list of objects, where each object represents a single public key pin with the following properties:
- 構文: オブジェクトのリスト。各オブジェクトは次のプロパティを持つ単一の公開キー PIN を表します。
o alg (REQUIRED)
o alg (必須)
The name of the cryptographic hash algorithm. Currently, the RECOMMENDED value is 'sha256'. As more secure algorithms are developed over time, federations should be ready to adopt these newer options for enhanced security.
暗号化ハッシュ アルゴリズムの名前。現在、推奨値は「sha256」です。時間の経過とともにより安全なアルゴリズムが開発されるため、連合はセキュリティを強化するためにこれらの新しいオプションを採用する準備ができている必要があります。
+ Data Type: String
+ データ型: 文字列
+ Syntax: The name of the algorithm.
+ 構文: アルゴリズムの名前。
+ Example: "sha256"
+ 例：「sha256」
o digest (REQUIRED)
o ダイジェスト (必須)
The public key of the end-entity certificate, converted to a Subject Public Key Information (SPKI) fingerprint, as specified in Section 2.4 of [RFC7469]. For clients, the digest value MUST be unique across entities in the federation metadata to enable unambiguous identification of the peer. Within the same entity, the same digest value MAY be assigned to multiple clients.
[RFC7469] のセクション 2.4 で指定されているように、サブジェクト公開鍵情報 (SPKI) フィンガープリントに変換された、エンドエンティティ証明書の公開鍵。クライアントの場合、ピアの明確な識別を可能にするために、ダイジェスト値はフェデレーション メタデータ内のエンティティ全体で一意である必要があります。同じエンティティ内で、同じダイジェスト値を複数のクライアントに割り当てることができます。
+ Data Type: String
+ データ型: 文字列
+ Syntax: SPKI fingerprint.
+ 構文: SPKI フィンガープリント。
+ Example: "+hcmCjJEtLq4BRPhrILyhgn98Lhy6DaWdpmsBAgOLCQ="
+ 例: "+hcmCjJEtLq4BRPhrILyhgn98Lhy6DaWdpmsBAgOLCQ="
- Example:
- 例：
"pins": [{
"alg": "sha256",
"digest": "+hcmCjJEtLq4BRPhrILyhgn98Lhy6DaWdpmsBAgOLCQ="
}]
* tags (OPTIONAL)
* タグ (オプション)
A list of strings that describe the endpoint's capabilities.
エンドポイントの機能を説明する文字列のリスト。
- Data Type: Array of Strings
- データ型: 文字列の配列
- Syntax: Strings describing endpoint capabilities.
- 構文: エンドポイントの機能を説明する文字列。
- Pattern: ^[a-z0-9]{1,64}$
- パターン: ^[a-z0-9]{1,64}$
- Example: ["scim", "xyzzy"]
- 例: ["scim"、"xyzzy"]
Tags are fundamental for discovery within a federation, aiding both servers and clients in identifying appropriate connections.
タグはフェデレーション内の検出の基礎であり、サーバーとクライアントの両方が適切な接続を識別するのに役立ちます。
- Server Tags: Tags associated with servers are used by clients to discover servers offering the services they require. Clients can search for servers based on tags that indicate supported protocols or the type of data they handle, enabling discovery of compatible servers.
- サーバー タグ: サーバーに関連付けられたタグは、クライアントが必要なサービスを提供するサーバーを検出するために使用されます。クライアントは、サポートされているプロトコルや処理するデータの種類を示すタグに基づいてサーバーを検索できるため、互換性のあるサーバーを見つけることができます。
- Client Tags: Tags associated with clients are used by servers to identify clients with specific characteristics or capabilities. For instance, a server might only accept connections from clients that support particular protocols. By filtering incoming requests based on these tags, servers can identify suitable clients.
- クライアント タグ: クライアントに関連付けられたタグは、特定の特性または機能を持つクライアントを識別するためにサーバーによって使用されます。たとえば、サーバーは、特定のプロトコルをサポートするクライアントからの接続のみを受け入れる場合があります。これらのタグに基づいて受信リクエストをフィルタリングすることにより、サーバーは適切なクライアントを識別できます。
Federation-Specific Considerations: While tags are tied to individual federations and serve distinct purposes within each, several key considerations are crucial to ensure clarity and promote consistent tag usage:
フェデレーション固有の考慮事項: タグは個々のフェデレーションに関連付けられており、それぞれのフェデレーション内で異なる目的を果たしますが、明確性を確保し、一貫したタグの使用を促進するには、いくつかの重要な考慮事項が重要です。
- Well-Defined Scope: Each federation MUST establish a clear scope for its tags, detailing their intended use, allowed tag values, associated meanings, and any relevant restrictions. Maintaining a well-defined and readily accessible registry of approved tags is essential for the federation.
- 明確に定義された範囲: 各フェデレーションは、タグの使用目的、許可されるタグ値、関連する意味、および関連する制限を詳細に記載して、タグの明確な範囲を確立しなければなりません。明確に定義され、すぐにアクセスできる承認済みタグのレジストリを維持することは、連盟にとって不可欠です。
- Validation Mechanisms: Implementing validation mechanisms for tags is highly recommended. This can involve a dedicated operation or service verifying tag validity and compliance with the federation's regulations. Such validation ensures consistency within the federation by preventing the use of unauthorized or irrelevant tags.
- 検証メカニズム: タグの検証メカニズムを実装することを強くお勧めします。これには、タグの有効性と連盟の規制への準拠を検証する専用の操作またはサービスが含まれる場合があります。このような検証により、無許可のタグや無関係なタグの使用が防止され、フェデレーション内の一貫性が保証されます。
The MATF metadata schema is defined in Appendix A. This schema specifies the format for describing entities involved in MATF and their associated information.
MATF メタデータ スキーマは、付録 A で定義されています。このスキーマは、MATF に関与するエンティティとその関連情報を記述するための形式を指定します。
Note: The schema in Appendix A is folded due to line length limitations as specified in [RFC8792].
注: 付録 A のスキーマは、[RFC8792] で指定されている行の長さの制限により折りたたまれています。
The following is a non-normative example of a metadata statement. Line breaks in the issuers claim example are for readability only.
以下は、メタデータ ステートメントの非規範的な例です。発行者の主張の例内の改行は、読みやすくするためだけのものです。
{
"iat": 1755514949,
"exp": 1756119888,
"iss": "https://federation.example.org",
"version": "1.0.0",
"cache_ttl": 3600,
"entities": [{
"entity_id": "https://example.com",
"organization": "Example Org",
"issuers": [{
"x509certificate": "-----BEGIN CERTIFICATE-----\nMIIDDDCCAf
SgAwIBAgIJAIOsfJBStJQhMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV\nBAM
MEHNjaW0uZXhhbXBsZS5jb20wHhcNMTcwNDA2MDc1MzE3WhcNMTcwNTA2MD
c1\nMzE3WjAbMRkwFwYDVQQDDBBzY2ltLmV4YW1wbGUuY29tMIIBIjANBgk
qhkiG9w0B\nAQEFAAOCAQ8AMIIBCgKCAQEAyr+3dXTC8YXoi0LDJTH0lTfv
8omQivWFOr3+/PBE\n6hmpLSNXK/EZJBD6ZT4Q+tY8dPhyhzT5RFZCVlrDs
e/kY00F4yoflKiqx9WSuCrq\nZFr1AUtIfGR/LvRUvDFtuHo1MzFttiK8Wr
wskMYZrw1zLHTIVwBkfMw1qr2XzxFK\njt0CcDmFxNdY5Q8kuBojH9+xt5s
ZbrJ9AVH/OI8JamSqDjk9ODyGg+GrEZFClP/B\nxa4Fsl04En/9GfaJnCU1
NpU0cqvWbVUlLOy8DaQMN14HIdkTdmegEsg2LR/XrJkt\nho16diAXrgS25
3xbkdD3T5d6lHiZCL6UxkBh4ZHRcoftSwIDAQABo1MwUTAdBgNV\nHQ4EFg
QUs1dXuhGhGc2UNb7ikn3t6cBuU34wHwYDVR0jBBgwFoAUs1dXuhGhGc2U\
nNb7ikn3t6cBuU34wDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQsFAA
OCAQEA\nrR9wxPhUa2XfQ0agAC0oC8TFf8wbTYb0ElP5Ej834xMMW/wWTSA
N8/3WqOWNQJ23\nf0vEeYQwfvbD2fjLvYTyM2tSPOWrtQpKuvulIrxV7Zz8
A61NIjblE3rfea1eC8my\nTkDOlMKV+wlXXgUxirride+6ubOWRGf92fgze
DGJWkmm/a9tj0L/3e0xIXeujxC7\nMIt3p99teHjvnZQ7FiIBlvGc1o8FD1
FKmFYd74s7RxrAusBEAAmBo3xyB89cFU0d\nKB2fkH2lkqiqkyOtjrlHPoy
6ws6g1S6U/Jx9n0NEeEqCfzXnh9jEpxisSO+fBZER\npCwj2LMNPQxZBqBF
oxbFPw==\n-----END CERTIFICATE-----"
}],
"servers": [{
"description": "SCIM Server 1",
"base_uri": "https://scim.example.com/",
"pins": [{
"alg": "sha256",
"digest": "+hcmCjJEtLq4BRPhrILyhgn98Lhy6DaWdpmsBAgOLCQ="
}],
"tags": [
"scim"
]
}],
"clients": [{
"description": "SCIM Client 1",
"pins": [{
"alg": "sha256",
"digest": "+hcmCjJEtLq4BRPhrILyhgn98Lhy6DaWdpmsBAgOLCQ="
}]
}]
}]
}
Federation metadata is signed using JWS and published using JWS JSON Serialization according to the general JWS JSON Serialization syntax defined in [RFC7515]. Federation metadata signatures are RECOMMENDED to be created using the algorithm ECDSA using P-256 and SHA-256 ("ES256") as defined in [RFC7518]. However, to accommodate evolving cryptographic standards, alternative algorithms MAY be used, provided they meet the security requirements of the federation.
フェデレーション メタデータは、JWS を使用して署名され、[RFC7515] で定義されている一般的な JWS JSON シリアル化構文に従って、JWS JSON シリアル化を使用して公開されます。フェデレーションメタデータ署名は、[RFC7518] で定義されている P-256 および SHA-256 (「ES256」) を使用するアルゴリズム ECDSA を使用して作成することが推奨されます(RECOMMENDED)。ただし、進化する暗号標準に対応するために、フェデレーションのセキュリティ要件を満たしている限り、代替アルゴリズムを使用してもよい(MAY)。
Federations may need to transition to post-quantum cryptographic algorithms for federation metadata signatures and for endpoint certificate public key types. MATF can accommodate such transitions through key rollover and by updating published pins as new key types are deployed.
フェデレーションでは、フェデレーション メタデータの署名およびエンドポイント証明書の公開キー タイプについて、ポスト量子暗号アルゴリズムへの移行が必要になる場合があります。MATF は、キー ロールオーバーを通じて、また新しいキー タイプがデプロイされるときに公開ピンを更新することによって、このような移行に対応できます。
The following JWS Protected Header parameters are REQUIRED:
次の JWS 保護ヘッダー パラメーターが必須です。
* alg (Algorithm)
* alg (アルゴリズム)
Identifies the algorithm used to generate the JWS signature [RFC7515], Section 4.1.1.
JWS 署名の生成に使用されるアルゴリズム [RFC7515]、セクション 4.1.1 を特定します。
* kid (Key Identifier)
* kid (キー識別子)
Identifies the key in the issuer's key set that was used to generate the JWS signature [RFC7515], Section 4.1.4.
JWS 署名 [RFC7515]、セクション 4.1.4 の生成に使用された発行者の鍵セット内の鍵を識別します。
The following is a non-normative example of a signature protected header.
以下は、署名で保護されたヘッダーの非規範的な例です。
{
"alg": "ES256",
"kid": "c2fb760e-f4b6-4f7e-b17a-7115d2826d51"
}
The examples in this section are not normative and illustrate the procedures described in Sections 5.2 and 5.3.
このセクションの例は規範的なものではなく、セクション 5.2 および 5.3 で説明されている手順を説明するものです。
The following example describes a scenario within the federation "Skolfederation" where MATF is deployed. Both clients and servers are registered members of the federation. In this scenario, clients manage cross-domain user accounts using SS 12000:2018, which is a System for Cross-domain Identity Management (SCIM) extension.
次の例では、MATF が展開されるフェデレーション「Skolfederation」内のシナリオについて説明します。クライアントとサーバーは両方ともフェデレーションの登録メンバーです。このシナリオでは、クライアントは、クロスドメイン ID 管理 (SCIM) 拡張機能のシステムである SS 12000:2018 を使用してクロスドメイン ユーザー アカウントを管理します。
+------------------------------------------------------+
| |
| Federation Metadata |
| |
+-----+-------------------------------+----------------+
| |
(A) (A)
| |
v v
+-----------+ +--------------------------------+
| Local MD | | Local MD |
+-----+-----+ +------+---------------------+---+
| | |
(B) (C) (F)
| | |
v v v
+-----------+ +--------------+ +-------+
| | | | | |
| Client +---(D)-->+ Intermediary +---(E)-->+ App |
| | | | | |
+-----------+ +--------------+ +-------+
A. Clients and servers retrieve federation metadata and update their local metadata stores as described in Section 4.2.
A. クライアントとサーバーは、セクション 4.2 で説明されているように、フェデレーション メタデータを取得し、ローカル メタデータ ストアを更新します。
B. The client selects a server endpoint based on metadata claims and preloads the pins published for that endpoint.
B. クライアントはメタデータ クレームに基づいてサーバー エンドポイントを選択し、そのエンドポイントに対して公開されたピンをプリロードします。
C. If certificate chain validation is performed, the TLS client or intermediary configures its trust store using the issuers listed in the federation metadata for the selected entity.
C. 証明書チェーンの検証が実行される場合、TLS クライアントまたは仲介者は、選択されたエンティティのフェデレーション メタデータにリストされている発行者を使用してトラスト ストアを構成します。
D. The client initiates a TLS connection to the selected base_uri and presents its client certificate.
D. クライアントは、選択されたbase_uriへのTLS接続を開始し、クライアント証明書を提示します。
E. If an intermediary terminates the TLS session, it forwards identity material derived from the TLS session to the application as described in Sections 5.3 and 5.6.
E. 仲介者が TLS セッションを終了する場合、セクション 5.3 および 5.6 で説明されているように、TLS セッションから派生した ID マテリアルをアプリケーションに転送します。
F. The application maps the derived pin to a matching metadata entry and uses the associated entity_id for identification and authorization.
F. アプリケーションは、派生した PIN を一致するメタデータ エントリにマッピングし、関連付けられたentity_id を識別と認可に使用します。
A certificate is issued for the client. The client's certificate issuer and public key pins are published in the federation metadata.
クライアントに対して証明書が発行されます。クライアントの証明書発行者と公開キー PIN は、フェデレーション メタデータで公開されます。
When a client initiates a connection to a remote server (identified by the server's entity_id), the following steps are performed:
クライアントがリモート サーバー (サーバーのentity_id によって識別される) への接続を開始すると、次の手順が実行されます。
1. The client selects a server endpoint from the identified entity's servers list whose tags match the required service capabilities.
1. クライアントは、タグが必要なサービス機能と一致する、識別されたエンティティのサーバー リストからサーバー エンドポイントを選択します。
2. The client preloads the selected endpoint's pins from its local metadata store. If certificate chain validation is performed, the client also loads the issuers listed for the entity.
2. クライアントは、選択したエンドポイントのピンをローカル メタデータ ストアからプリロードします。証明書チェーンの検証が実行される場合、クライアントはエンティティに対してリストされた発行者もロードします。
3. The client initiates a TLS connection to the selected endpoint using the base_uri and presents its client certificate.
3. クライアントは、base_uri を使用して選択されたエンドポイントへの TLS 接続を開始し、クライアント証明書を提示します。
4. The client performs pin validation for the server certificate as described in Section 5.3. This validation may be performed by the TLS stack during the handshake or by application logic after the connection is established, but it completes before any application data is exchanged.
4. クライアントは、セクション 5.3 で説明されているように、サーバー証明書の PIN 検証を実行します。この検証は、ハンドシェイク中に TLS スタックによって実行されるか、接続が確立された後にアプリケーション ロジックによって実行されますが、アプリケーション データが交換される前に完了します。
5. If validation succeeds, the client proceeds with application transactions.
5. 検証が成功すると、クライアントはアプリケーションのトランザクションを続行します。
To accept inbound connections from a client, the server uses federation metadata to perform pin validation of the public key in the presented client certificate. The federation metadata publishes client public key pins, and for deployments that perform certificate chain validation, the allowed issuers.
クライアントからの受信接続を受け入れるために、サーバーはフェデレーション メタデータを使用して、提示されたクライアント証明書内の公開キーの PIN 検証を実行します。フェデレーション メタデータは、クライアントの公開キー PIN を公開し、証明書チェーンの検証を実行する展開の場合は、許可された発行者を公開します。
When the server receives a TLS connection attempt from a remote client, the following steps are performed:
サーバーがリモート クライアントから TLS 接続試行を受信すると、次の手順が実行されます。
1. The server is configured to request or require a client certificate. If certificate chain validation is performed, the trust store is populated using the issuers published in the federation metadata. Otherwise, the server requests a client certificate without issuer validation (for example, optional_no_ca).
1. サーバーは、クライアント証明書を要求または要求するように構成されています。証明書チェーンの検証が実行される場合、フェデレーション メタデータで公開された発行者を使用してトラスト ストアにデータが設定されます。それ以外の場合、サーバーは発行者の検証なしでクライアント証明書を要求します (たとえば、optional_no_ca)。
2. The server can prefilter the federation metadata to identify the set of clients it is willing to communicate with and preload only the pins for those clients, as described in Section 5.2.
2. セクション 5.2 で説明されているように、サーバーはフェデレーション メタデータを事前にフィルタリングして、通信するクライアントのセットを識別し、それらのクライアントのピンのみを事前にロードできます。
3. After the TLS handshake completes, the server derives the client's pin from the presented certificate and matches it against the preloaded pins. When a match is found, the server determines the client's entity_id from the corresponding metadata entry.
3. TLS ハンドシェイクが完了すると、サーバーは提示された証明書からクライアントの PIN を取得し、それをプリロードされた PIN と照合します。一致するものが見つかると、サーバーは対応するメタデータ エントリからクライアントのentity_idを決定します。
4. If pin validation succeeds, the server proceeds with application transactions. If pin validation fails, the server terminates the connection.
4. PIN の検証が成功すると、サーバーはアプリケーションのトランザクションを続行します。PIN の検証が失敗した場合、サーバーは接続を終了します。
The following is an example of how to use OpenSSL to generate a SPKI fingerprint from a PEM-encoded certificate.
以下は、OpenSSL を使用して PEM エンコードされた証明書から SPKI フィンガープリントを生成する方法の例です。
openssl x509 -in <certificate.pem> -pubkey -noout | \
openssl pkey -pubin -outform der | \
openssl dgst -sha256 -binary | \
openssl enc -base64
The following is an example of public key pinning with curl.
以下は、curl を使用した公開キーの固定の例です。
curl --cert client.pem --key client.key \
--pinnedpubkey \
'sha256//0Ok2aNfcrCNDMhC2uXIdxBFOvMfEVtzlNVUT5pur0Dk=' \
https://host.example.com
The MATF framework has proven its practical value and robustness through successful deployments in several environments.
MATF フレームワークは、いくつかの環境での導入の成功を通じて、その実用的な価値と堅牢性を証明しています。
Skolfederation Moa [Moa] is a federation designed to secure communication between digital educational resources and schools. MATF was developed to meet Moa's needs and enables secure data exchange for schools, municipalities, educational platforms, and services across Sweden.
Skolfederation Moa [Moa] は、デジタル教育リソースと学校の間の通信を安全にするために設計された連合です。MATF は Moa のニーズを満たすために開発され、スウェーデン全土の学校、自治体、教育プラットフォーム、サービスでの安全なデータ交換を可能にします。
The community plays a crucial role in this type of federation. Members are active participants, and the federation operator ensures the federation runs smoothly and serves their needs. Moa's success highlights the importance of collaboration, with members and the federation operator working together to maintain trust, security, and interoperability in the education sector.
このタイプの連合では、コミュニティが重要な役割を果たします。メンバーは積極的な参加者であり、フェデレーションの運営者はフェデレーションがスムーズに運営され、メンバーのニーズに応えられるようにします。Moa の成功は、教育分野における信頼、セキュリティ、相互運用性を維持するためにメンバーと連盟運営者が協力するというコラボレーションの重要性を浮き彫りにしています。
The deployment of MATF in the Swedish education sector has provided several key insights. Maintaining an accurate registry of metadata ownership with reliable contact information is essential for troubleshooting and ensuring accountability. The deployment also demonstrated the importance of setting reasonable expiration times for metadata. Too short an expiration can hinder the ability to implement contingency plans for publishing new metadata during outages.
スウェーデンの教育分野における MATF の導入により、いくつかの重要な洞察が得られました。トラブルシューティングと説明責任の確保には、メタデータ所有権の正確なレジストリと信頼できる連絡先情報を維持することが不可欠です。この導入では、メタデータの有効期限を適切に設定することの重要性も実証しました。有効期限が短すぎると、停止中に新しいメタデータを公開するための緊急時対応計画の実装が妨げられる可能性があります。
Metadata validation is necessary to maintain a stable federation. While manual validation may be sufficient in the early stages of a federation, it becomes unmanageable as the federation scales. Without an automated validation process, incorrect metadata uploaded by members is likely to go undetected, leading to publication of incorrect metadata.
メタデータの検証は、安定したフェデレーションを維持するために必要です。フェデレーションの初期段階では手動による検証で十分かもしれませんが、フェデレーションが拡大するにつれて管理できなくなります。自動検証プロセスがなければ、メンバーによってアップロードされた誤ったメタデータが検出されない可能性があり、誤ったメタデータが公開される可能性があります。
The federation metadata signing private key is required to publish signed federation metadata. In fallback scenarios, federation metadata may be retrieved from an alternate location, but publishing updated federation metadata requires access to the signing private key. Therefore, secure and redundant management of the signing private key is necessary to support fallback mechanisms and reliable publication. Recipients MUST validate the JWS signature using the federation signature verification key before using federation metadata, regardless of where it is obtained.
署名されたフェデレーション メタデータを公開するには、フェデレーション メタデータ署名秘密キーが必要です。フォールバック シナリオでは、フェデレーション メタデータを別の場所から取得できますが、更新されたフェデレーション メタデータを公開するには、署名用秘密キーにアクセスする必要があります。したがって、フォールバック メカニズムと信頼性の高い公開をサポートするには、署名秘密キーの安全かつ冗長な管理が必要です。受信者は、取得場所に関係なく、フェデレーション メタデータを使用する前に、フェデレーション署名検証キーを使用して JWS 署名を検証しなければなりません (MUST)。
The Swedish National Agency for Education [SkolverketMATF] leverages MATF within its digital national test platform to establish a robust authentication mechanism. The platform utilizes an API for client verification prior to secure data transfer to the agency's test service, ensuring the integrity and confidentiality of educational data.
スウェーデン国立教育庁 [SkolverketMATF] は、デジタル国家試験プラットフォーム内で MATF を活用して、堅牢な認証メカニズムを確立しています。このプラットフォームは、政府機関のテスト サービスに安全にデータを転送する前にクライアントの検証に API を利用し、教育データの完全性と機密性を確保します。
Sambruk's EGIL [EGIL], a platform providing digital services to municipalities, has successfully integrated the MATF framework. This deployment demonstrates the framework's adaptability to support a wide range of digital service infrastructures.
サンブルクの EGIL [EGIL] は、地方自治体にデジタル サービスを提供するプラットフォームであり、MATF フレームワークの統合に成功しました。この展開は、幅広いデジタル サービス インフラストラクチャをサポートするフレームワークの適応性を示しています。
These deployments highlight the effectiveness of the MATF framework in enhancing security and interoperability within the educational sector.
これらの展開は、教育分野におけるセキュリティと相互運用性の強化における MATF フレームワークの有効性を浮き彫りにしています。
The security risks associated with the MATF framework are confined to each individual federation. Both the federation operator and federation members share the responsibility of maintaining trust and security. Proper handling of metadata and thorough vetting of members are crucial to sustaining this trust.
MATF フレームワークに関連するセキュリティ リスクは、個々のフェデレーションに限定されます。フェデレーション オペレーターとフェデレーション メンバーは両方とも、信頼とセキュリティを維持する責任を共有します。この信頼を維持するには、メタデータの適切な処理とメンバーの徹底的な検査が不可欠です。
Deployments that terminate a session at an intermediary and convey identity material to an application introduce a critical trust boundary. If the intermediary is compromised or fails to properly sanitize inbound headers, an attacker could spoof a peer's entity_id. Therefore, intermediaries that convey identity material to an application MUST comply with the requirements in Section 5.6.
仲介者でセッションを終了し、アイデンティティ情報をアプリケーションに伝達する展開では、重要な信頼境界が導入されます。仲介者が危険にさらされているか、受信ヘッダーを適切にサニタイズできない場合、攻撃者がピアのentity_idを偽装する可能性があります。したがって、アイデンティティ素材をアプリケーションに伝達する仲介者は、セクション 5.6 の要件に従わなければなりません (MUST)。
Implementations SHOULD avoid logging conveyed certificates, pins, or identity values unless required for diagnostics to prevent the accidental exposure of session-specific identity material.
実装では、セッション固有の ID マテリアルが偶発的に公開されることを防ぐために、診断で必要な場合を除き、伝達された証明書、PIN、または ID 値のログを避ける必要があります (SHOULD)。
The security considerations for TLS 1.3 are detailed in Section 10 and Appendices C, D, and E of [RFC8446].
TLS 1.3 のセキュリティに関する考慮事項は、[RFC8446] のセクション 10 および付録 C、D、および E で詳しく説明されています。
Regularly updating the local copy of federation metadata is essential for accessing the latest information about active entities, current public key pins [RFC7469], and valid issuer certificates. The use of outdated metadata may expose systems to security risks, such as interaction with revoked entities or acceptance of manipulated data.
フェデレーション メタデータのローカル コピーを定期的に更新することは、アクティブなエンティティ、現在の公開キー PIN [RFC7469]、および有効な発行者証明書に関する最新情報にアクセスするために不可欠です。古いメタデータを使用すると、取り消されたエンティティとのやり取りや操作されたデータの受け入れなど、システムがセキュリティ リスクにさらされる可能性があります。
Ensuring data integrity and security within the MATF framework relies on verifying the signature of downloaded federation metadata. This verification confirms the origin of the metadata by validating the JWS signature using the federation signature verification key trusted by the recipient. It also confirms that the signed content has not been altered by unauthorized parties. By verifying the signature, trust is maintained in the integrity of the information used for validation, including member public key pins and issuer certificates. To achieve a robust implementation, it is important to consider the security aspects outlined in [RFC7515], which describes security considerations related to algorithm selection, key compromise, and signature integrity.
MATF フレームワーク内でデータの整合性とセキュリティを確保するには、ダウンロードされたフェデレーション メタデータの署名を検証する必要があります。この検証では、受信者が信頼するフェデレーション署名検証キーを使用して JWS 署名を検証することにより、メタデータの出所を確認します。また、署名されたコンテンツが無許可の当事者によって変更されていないことも確認されます。署名を検証することにより、メンバーの公開キー PIN や発行者の証明書など、検証に使用される情報の整合性に対する信頼が維持されます。堅牢な実装を実現するには、[RFC7515] で概説されているセキュリティの側面を考慮することが重要です。RFC7515 では、アルゴリズムの選択、鍵の侵害、署名の完全性に関するセキュリティの考慮事項が説明されています。
Maintaining synchronized clocks across all federation members is critical for the security of the MATF framework. Inaccurate timestamps can compromise the validity of digital signatures and certificates, hinder reliable log analysis, and potentially expose the system to time-based attacks. Therefore, all federation members MUST employ methods to ensure their system clocks are synchronized with a reliable time source.
すべてのフェデレーション メンバー間で同期クロックを維持することは、MATF フレームワークのセキュリティにとって重要です。タイムスタンプが不正確だと、デジタル署名と証明書の有効性が損なわれ、信頼性の高いログ分析が妨げられ、システムが時間ベースの攻撃にさらされる可能性があります。したがって、すべてのフェデレーション メンバーは、システム クロックが信頼できる時刻源と確実に同期する方法を採用しなければなりません。
This document has no IANA actions.
この文書には IANA のアクションはありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
April 2015, <https://www.rfc-editor.org/info/rfc7468>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
2015, <https://www.rfc-editor.org/info/rfc7469>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
2015, <https://www.rfc-editor.org/info/rfc7638>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[eduGAIN] eduGAIN, "eduGAIN: Interfederation service connecting
research and education identity federations worldwide",
<https://edugain.org>.
[EGIL] Sambruk, "EGIL - smidig hantering av skolans digitala
användarkonton" [EGIL - manage your school's digital user
accounts efficiently], <https://sambruk.se/egil-dnp/>.
[eIDAS] European Union, "Consolidated text: Regulation (EU) No
910/2014 of the European Parliament and of the Council of
23 July 2014 on electronic identification and trust
services for electronic transactions in the internal
market and repealing Directive 1999/93/EC", 18 October
2024, <https://eur-lex.europa.eu/eli/reg/2014/910>.
[Moa] Internetstiftelsens Federationer [The Swedish Internet
Foundation], "Machine and Organization Authentication", 6
October 2025,
<https://wiki.federationer.internetstiftelsen.se/x/
LYA5AQ>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[SkolverketMATF]
Skolverket [Swedish National Agency for Education], "API
för autentisering" [Authentication API for User
Management], commit f8c2e93, 4 September 2025,
<https://github.com/skolverket/dnp-
usermanagement/blob/main/authentication-api/README.md>.
The following JSON Schema defines the structure of MATF metadata. It conforms to draft 2020-12 of the JSON Schema standard.
次の JSON スキーマは、MATF メタデータの構造を定義します。JSON スキーマ標準のドラフト 2020-12 に準拠しています。
Version: 1.0.0
バージョン: 1.0.0
=============== NOTE: '\\' line wrapping per RFC 8792 ===============
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://mtlsfed.se/schema/matf-metadata-schema.json",
"title": "JSON Schema for Mutually Authenticating TLS in the con\
\text of Federations",
"description": "Version: 1.0.0",
"type": "object",
"additionalProperties": true,
"required": [
"iat",
"exp",
"iss",
"version",
"entities"
],
"properties": {
"iat": {
"title": "Issued at",
"description": "Time at which the metadata was issued (U\
\NIX timestamp)",
"type": "integer",
"minimum": 0,
"examples": [
1755514949
]
},
"exp": {
"title": "Expiration time",
"description": "Time at which the metadata expires (UNIX\
\ timestamp)",
"type": "integer",
"minimum": 0,
"examples": [
1756119888
]
},
"iss": {
"title": "The federation issuing the metadata",
"description": "A URI that uniquely identifies the feder\
\ation that issued the metadata",
"type": "string",
"format": "uri",
"minLength": 1,
"examples": [
"https://example.com/federation"
]
},
"version": {
"title": "Metadata schema version",
"description": "Schema version follows semantic versioni\
\ng (https://semver.org)",
"type": "string",
"pattern": "^\\d+\\.\\d+\\.\\d+$",
"examples": [
"1.0.0"
]
},
"cache_ttl": {
"title": "Metadata cache TTL",
"description": "How long in seconds to cache metadata. T\
\he effective maximum is bounded by the exp claim.",
"type": "integer",
"minimum": 0,
"examples": [
3600
]
},
"entities": {
"type": "array",
"minItems": 1,
"items": {
"$ref": "#/$defs/entity"
}
}
},
"$defs": {
"entity": {
"type": "object",
"additionalProperties": true,
"required": [
"entity_id",
"issuers"
],
"properties": {
"entity_id": {
"title": "Entity identifier",
"description": "Globally unique identifier for t\
\he entity.",
"type": "string",
"format": "uri",
"examples": [
"https://example.com"
]
},
"organization": {
"title": "Name of entity organization",
"description": "Name identifying the organizatio\
\n that the entity's metadata represents.",
"type": "string",
"examples": [
"Example Org"
]
},
"issuers": {
"title": "Entity certificate issuers",
"description": "A list of certificate issuers th\
\at are allowed to issue certificates for the entity's endpoints. Fo\
\r each issuer, the issuer's root CA certificate is included in the \
\x509certificate property (PEM-encoded).",
"type": "array",
"minItems": 1,
"items": {
"$ref": "#/$defs/cert_issuers"
}
},
"servers": {
"type": "array",
"items": {
"$ref": "#/$defs/endpoint"
}
},
"clients": {
"type": "array",
"items": {
"$ref": "#/$defs/endpoint"
}
}
}
},
"endpoint": {
"type": "object",
"additionalProperties": true,
"required": [
"pins"
],
"properties": {
"description": {
"title": "Endpoint description",
"type": "string",
"examples": [
"SCIM Server 1"
]
},
"tags": {
"title": "Endpoint tags",
"description": "A list of strings that describe \
\the endpoint's capabilities.",
"type": "array",
"items": {
"type": "string",
"pattern": "^[a-z0-9]{1,64}$",
"examples": [
"xyzzy"
]
}
},
"base_uri": {
"title": "Endpoint base URI",
"type": "string",
"format": "uri",
"examples": [
"https://scim.example.com"
]
},
"pins": {
"title": "Certificate pin set",
"type": "array",
"minItems": 1,
"items": {
"$ref": "#/$defs/pin_directive"
}
}
}
},
"cert_issuers": {
"title": "Certificate issuers",
"type": "object",
"additionalProperties": false,
"required": [
"x509certificate"
],
"properties": {
"x509certificate": {
"title": "X.509 Certificate (PEM)",
"type": "string",
"pattern": "^-----BEGIN CERTIFICATE-----(?:\\r?\\
\\n)(?:[A-Za-z0-9+/=]{64}\\r?\\n)*(?:[A-Za-z0-9+/=]{1,64}\\r?\\n)---\
\--END CERTIFICATE-----(?:\\r?\\n)?$"
}
}
},
"pin_directive": {
"title": "RFC 7469 pin directive",
"type": "object",
"additionalProperties": false,
"required": [
"alg",
"digest"
],
"properties": {
"alg": {
"title": "Directive name",
"type": "string",
"enum": [
"sha256"
],
"examples": [
"sha256"
]
},
"digest": {
"title": "Directive value (Base64)",
"type": "string",
"pattern": "^[A-Za-z0-9+/]{43}=$",
"examples": [
"HiMkrb4phPSP+OvGqmZd6sGvy7AUn4k3XEe8OMBrzt8\
\="
]
}
}
}
}
}
This project was funded through the NGI0 PET Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet programme, under the aegis of DG Communications Networks, Content and Technology under grant agreement No 825310.
このプロジェクトは、助成契約番号 825310 に基づいて DG Communications Networks、Content and Technology の後援を受け、欧州委員会の次世代インターネット プログラムからの資金援助を受けて NLnet によって設立された基金である NGI0 PET 基金を通じて資金提供されました。
The authors thank the following people for the detailed review and suggestions:
著者らは、詳細なレビューと提案をしてくれた次の方々に感謝します。
* Rasmus Larsson
* ラスムス・ラーソン
* Mats Dufberg
* マッツ・デュフバーグ
* Joe Siltberg
* ジョー・シルトバーグ
* Stefan Norberg
* ステファン・ノーバーグ
* Petter Blomberg
* ペッター・ブロンバーグ
The authors would also like to thank participants in the EGIL working group for their comments on this specification.
著者らはまた、この仕様に関してコメントを寄せてくださった EGIL ワーキング グループの参加者にも感謝したいと思います。
Stefan Halén
The Swedish Internet Foundation
Email: stefan.halen@internetstiftelsen.se
Jakob Schlyter
Kirei AB
Email: jakob@kirei.se