rfc9932.original		rfc9932.txt
	Network Working Group S. Halen		Independent Submission S. Halén
	Internet-Draft The Swedish Internet Foundation		Request for Comments: 9932 The Swedish Internet Foundation
	Intended status: Informational J. Schlyter		Category: Informational J. Schlyter
	Expires: 28 February 2026 Kirei AB		ISSN: 2070-1721 Kirei AB
	27 August 2025		February 2026
	Mutually Authenticating TLS in the context of Federations		Mutually Authenticating TLS in the Context of Federations
	draft-halen-fedae-03
	Abstract		Abstract
	This informational independent submission to the RFC series describes		This Informational Independent Submission to the RFC Series describes
	a means to use TLS 1.3 to perform machine-to-machine mutual		a means to use TLS 1.3 to perform machine-to-machine mutual
	authentication within federations. This memo is not a standard. It		authentication within federations. This memo is not a standard. It
	does not modify the TLS protocol in any way, nor does it require		does not modify the TLS protocol in any way, nor does it require
	changes to common TLS libraries. TLS is specified and standardized		changes to common TLS libraries. TLS is specified and standardized
	by the IETF's TLS working group.		by the IETF's TLS Working Group.
	The framework enables interoperable trust management for federated		The framework enables interoperable trust management for federated
	machine-to-machine communication. It introduces a centrally managed		machine-to-machine communication. It introduces a centrally managed
	trust anchor and a controlled metadata publication process, ensuring		trust anchor and a controlled metadata publication process, ensuring
	that only authorized members are identifiable within the federation.		that only authorized members are identifiable within the federation.
	These mechanisms support unambiguous entity identification and reduce		These mechanisms support unambiguous entity identification and reduce
	the risk of impersonation, promoting secure and policy-aligned		the risk of impersonation, promoting secure and policy-aligned
	interaction across organizational boundaries.		interaction across organizational boundaries.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This document is not an Internet Standards Track specification; it is
	provisions of BCP 78 and BCP 79.		published for informational purposes.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This is a contribution to the RFC Series, independently of any other
	and may be updated, replaced, or obsoleted by other documents at any		RFC stream. The RFC Editor has chosen to publish this document at
	time. It is inappropriate to use Internet-Drafts as reference		its discretion and makes no statement about its value for
	material or to cite them other than as "work in progress."		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.
	This Internet-Draft will expire on 28 February 2026.		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.
	Copyright Notice		Copyright Notice
	Copyright (c) 2025 IETF Trust and the persons identified as the		Copyright (c) 2026 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction
	1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . 3		1.1. Reserved Words
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Terminology
	2. Diverse Design Patterns . . . . . . . . . . . . . . . . . . . 4		2. Diverse Design Patterns
	3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Trust Model
	3.1. Role of the Federation Operator . . . . . . . . . . . . . 5		3.1. Role of the Federation Operator
	3.2. Federation Members' Responsibilities . . . . . . . . . . 6		3.2. Federation Members' Responsibilities
	3.3. Chain of Trust . . . . . . . . . . . . . . . . . . . . . 6		3.3. Chain of Trust
	3.4. Member Vetting . . . . . . . . . . . . . . . . . . . . . 7		3.4. Member Vetting
	3.5. Metadata Authenticity . . . . . . . . . . . . . . . . . . 8		3.5. Metadata Authenticity
	4. Metadata Repository . . . . . . . . . . . . . . . . . . . . . 8		4. Metadata Repository
	4.1. Metadata Submission . . . . . . . . . . . . . . . . . . . 9		4.1. Metadata Submission
	4.2. Maintaining Up-to-Date Metadata . . . . . . . . . . . . . 9		4.2. Maintaining Up-to-Date Metadata
	5. Authentication . . . . . . . . . . . . . . . . . . . . . . . 10		5. Authentication
	5.1. Public Key Pinning . . . . . . . . . . . . . . . . . . . 11		5.1. Public Key Pinning
	5.1.1. Benefits of Public Key Pinning . . . . . . . . . . . 11		5.1.1. Benefits of Public Key Pinning
	5.2. Pin Discovery and Preloading . . . . . . . . . . . . . . 12		5.2. Pin Discovery and Preloading
	5.3. Verification of Received Certificates . . . . . . . . . . 12		5.3. Verification of Received Certificates
	5.4. Failure to Validate . . . . . . . . . . . . . . . . . . . 13		5.4. Failure to Validate
	5.5. Certificate Rotation: . . . . . . . . . . . . . . . . . . 13		5.5. Certificate Rotation
	5.6. Implementation Guidelines . . . . . . . . . . . . . . . . 13		5.6. Implementation Guidelines
	6. Federation Metadata . . . . . . . . . . . . . . . . . . . . . 14		6. Federation Metadata
	6.1. Federation Metadata Claims . . . . . . . . . . . . . . . 14		6.1. Federation Metadata Claims
	6.1.1. Entities . . . . . . . . . . . . . . . . . . . . . . 16		6.1.1. Entities
	6.2. Metadata Schema . . . . . . . . . . . . . . . . . . . . . 20		6.2. Metadata Schema
	6.3. Example Metadata . . . . . . . . . . . . . . . . . . . . 20		6.3. Example Metadata
	6.4. Metadata Signing . . . . . . . . . . . . . . . . . . . . 22		6.4. Metadata Signing
	6.5. Example Signature Protected Header . . . . . . . . . . . 22		6.5. Example Signature Protected Header
	7. Example Usage Scenarios . . . . . . . . . . . . . . . . . . . 22		7. Example Usage Scenarios
	7.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 23		7.1. Client
	7.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 24		7.2. Server
	7.3. SPKI Generation . . . . . . . . . . . . . . . . . . . . . 24		7.3. SPKI Generation
	7.4. Curl and Public Key Pinning . . . . . . . . . . . . . . . 25		7.4. Curl and Public Key Pinning
	8. Deployments of the MATF Framework . . . . . . . . . . . . . . 25		8. Deployments of the MATF Framework
	8.1. Skolfederation Moa . . . . . . . . . . . . . . . . . . . 25		8.1. Skolfederation Moa
	8.2. Swedish National Agency for Education . . . . . . . . . . 26		8.2. Swedish National Agency for Education
	8.3. Sambruk's EGIL . . . . . . . . . . . . . . . . . . . . . 26		8.3. Sambruk's EGIL
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 26		9. Security Considerations
	9.1. Security Risks and Trust Management . . . . . . . . . . . 26		9.1. Security Risks and Trust Management
	9.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 26		9.2. TLS
	9.3. Federation Metadata Updates . . . . . . . . . . . . . . . 27		9.3. Federation Metadata Updates
	9.4. Verifying the Federation Metadata Signature . . . . . . . 27		9.4. Verifying the Federation Metadata Signature
	9.5. Time Synchronization . . . . . . . . . . . . . . . . . . 27		9.5. Time Synchronization
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27		10. IANA Considerations
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		11. References
	12. Normative References . . . . . . . . . . . . . . . . . . . . 28		11.1. Normative References
	13. Informative References . . . . . . . . . . . . . . . . . . . 28		11.2. Informative References
	Appendix A. JSON Schema for MATF Metadata . . . . . . . . . . . 29		Appendix A. JSON Schema for MATF Metadata
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34		Acknowledgements
			Authors' Addresses
	1. Introduction		1. Introduction
	This document describes the Mutually Authenticating TLS in the		This document describes the Mutually Authenticating TLS in
	context of Federations (MATF) framework, developed to complement		Federations (MATF) framework, developed to complement multilateral
	multilateral SAML federations within the education sector. These		Security Assertion Markup Language (SAML) federations within the
	federations often rely on just-in-time provisioning, where user		education sector. These federations often rely on just-in-time
	accounts are created at first login based on information from the		provisioning, where user accounts are created at first login based on
	SAML assertion. However, educators need to be able to manage		information from the SAML assertion. However, educators need to be
	resources and classes before students access the service. MATF		able to manage resources and classes before students access the
	bridges this gap by using secure machine-to-machine communication,		service. MATF bridges this gap by using secure machine-to-machine
	enabling pre-provisioning of user information using a trust model and		communication, enabling pre-provisioning of user information using a
	metadata structure inspired by SAML federations.		trust model and metadata structure inspired by SAML federations.
	MATF is designed specifically for secure authentication in machine-		MATF is designed specifically for secure authentication in machine-
	to-machine contexts, such as RESTful APIs and service-to-service		to-machine contexts, such as RESTful APIs (where "RESTful" refers to
	interactions, and is not intended for browser-based authentication.		the Representational State Transfer (REST) architecture) and service-
	Because its applicability in a browser environment has not been		to-service interactions, and is not intended for browser-based
	studied, using MATF within browsers is not recommended. Doing so may		authentication. Because its applicability in a browser environment
	introduce risks that differ from those typically addressed by		has not been studied, using MATF within browsers is not recommended.
	standard browser security models.		Doing so may introduce risks that differ from those typically
			addressed by standard browser security models.
	This work is not a product of the IETF, does not represent a		This work is not a product of the IETF, does not represent a
	standard, and has not achieved community consensus. It aims to		standard, and has not achieved community consensus. It aims to
	address specific federation challenges and provide a framework for		address specific federation challenges and provide a framework for
	secure communication.		secure communication.
	TLS is specified by the IETF TLS Working Group. TLS 1.3 is defined		TLS is specified by the IETF TLS Working Group. TLS 1.3 is defined
	in [RFC8446]. Additional information about the TLS Working Group is		in [RFC8446]. Additional information about the TLS Working Group is
	available at https://datatracker.ietf.org/wg/tls/about/		available at <https://datatracker.ietf.org/wg/tls/about/>.
	(https://datatracker.ietf.org/wg/tls/about/).
	1.1. Reserved Words		1.1. Reserved Words
	This document is an Informational RFC, which means it offers		This document is an Informational RFC, which means it offers
	information and guidance but does not specify mandatory standards.		information and guidance but does not specify mandatory standards.
	Therefore, the keywords used throughout this document are for		Therefore, the keywords used throughout this document are for
	informational purposes only and do not imply any specific		informational purposes only and do not imply any specific
	requirements.		requirements.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119].		"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.
	1.2. Terminology		1.2. Terminology
	* Federation: A trusted network of entities that adhere to common		Federation: A trusted network of entities that adhere to common
	security policies and standards, using MATF for secure		security policies and standards, using MATF for secure
	communication.		communication.
	* Federation Member: An entity that has been approved to join the		Federation Member: An entity that has been approved to join the
	federation and can leverage MATF for secure communication with		federation and can leverage MATF for secure communication with
	other members.		other members.
	* Federation Operator: The entity responsible for the overall		Federation Operator: The entity responsible for the overall
	operation and management of the federation, including managing the		operation and management of the federation, including managing the
	federation metadata, enforcing security policies, and onboarding		federation metadata, enforcing security policies, and onboarding
	new members.		new members.
	* Federation Metadata: A cryptographically signed document		Federation Metadata: A cryptographically signed document containing
	containing information about all entities within the federation.		information about all entities within the federation.
	* Metadata Repository: A centralized repository storing information		Metadata Repository: A centralized repository storing information
	about all entities within the federation.		about all entities within the federation.
	* Member Metadata: Information about entities associated with a		Member Metadata: Information about entities associated with a
	specific member within the federation.		specific member within the federation.
	* Member Vetting: The process of verifying and approving applicants		Member Vetting: The process of verifying and approving applicants to
	to join the federation, ensuring they meet security and		join the federation, ensuring they meet security and
	trustworthiness requirements.		trustworthiness requirements.
	* Trust Anchor: The federation's root of trust is established by the		Trust Anchor: The federation's root of trust is established by the
	federation metadata signing key, which verifies the federation		federation metadata signing key, which verifies the federation
	metadata and allows participants to confidently rely on the		metadata and allows participants to confidently rely on the
	information it contains.		information it contains.
	2. Diverse Design Patterns		2. Diverse Design Patterns
	MATF is designed to be flexible and adaptable to the varying needs of		MATF is designed to be flexible and adaptable to the varying needs of
	different federations. Federations can differ significantly in terms		different federations. Federations can differ significantly in terms
	of size, scope, and security requirements, which makes it challenging		of size, scope, and security requirements, which makes it challenging
	to prescribe a one-size-fits-all trust framework and security		to prescribe a one-size-fits-all trust framework and security
	measures.		measures.
	For instance, in the European Union, the eIDAS (electronic		For instance, in the European Union, the electronic Identification,
	Identification, Authentication, and trust Services) regulation		Authentication, and trust Services (eIDAS) regulation establishes a
	establishes a framework for electronic identification and trust		framework for electronic identification and trust services for
	services for electronic transactions within the EU. This regulation		electronic transactions within the EU. This regulation provides a
	provides a comprehensive set of standards for secure electronic		comprehensive set of standards for secure electronic interactions
	interactions across member states. National federations within EU		across member states. National federations within EU member states
	member states adhere to these standards, ensuring interoperability		adhere to these standards, ensuring interoperability and mutual
	and mutual recognition of electronic IDs across different countries.		recognition of electronic IDs across different countries.
	Similarly, national federations, such as those found in education or		Similarly, national federations, such as those found in education or
	healthcare sectors, often have their own specific trust frameworks		healthcare sectors, often have their own specific trust frameworks
	and security measures tailored to their unique needs. These		and security measures tailored to their unique needs. These
	federations may leverage existing national identification systems or		federations may leverage existing national identification systems or
	other trusted credentials to establish member identities and ensure		other trusted credentials to establish member identities and ensure
	secure interactions.		secure interactions.
	Organizations may also set up their own federations, tailored to the		Organizations may also set up their own federations, tailored to the
	specific security requirements and trust models relevant to their		specific security requirements and trust models relevant to their
	skipping to change at page 6, line 21 ¶		skipping to change at line 261 ¶
	the identified risks.		the identified risks.
	The security and stability of the federation rely on the integrity		The security and stability of the federation rely on the integrity
	and competence of the federation operator. Members must be able to		and competence of the federation operator. Members must be able to
	fully trust this central authority, as its role is essential to		fully trust this central authority, as its role is essential to
	maintaining the federation's reliability and security.		maintaining the federation's reliability and security.
	3.2. Federation Members' Responsibilities		3.2. Federation Members' Responsibilities
	Federation members share the responsibility of maintaining trust and		Federation members share the responsibility of maintaining trust and
	security within the federation. Their responsibilities include:		security within the federation.
			Their responsibilities include:
	* Adhering to the federation's security policies and procedures.		* Adhering to the federation's security policies and procedures.
	* Ensuring the accuracy and timeliness of their metadata		* Ensuring the accuracy and timeliness of their metadata
	submissions.		submissions.
	* Cooperating with the federation operator's vetting and security		* Cooperating with the federation operator's vetting and security
	measures.		measures.
	By fulfilling these responsibilities, federation members help sustain		By fulfilling these responsibilities, federation members help sustain
	skipping to change at page 6, line 46 ¶		skipping to change at line 288 ¶
	ensured by the federation.		ensured by the federation.
	3.3. Chain of Trust		3.3. Chain of Trust
	Each federation operates within a trust framework that encompasses		Each federation operates within a trust framework that encompasses
	its own security policies and procedures. This framework is designed		its own security policies and procedures. This framework is designed
	to ensure the integrity, authenticity, and confidentiality of		to ensure the integrity, authenticity, and confidentiality of
	communications within the federation. Key components of this		communications within the federation. Key components of this
	framework include:		framework include:
	* Public key pinning [RFC7469] and preloading to thwart man-in-the-		* Public key pinning [RFC7469] and preloading to thwart on-path
	middle attacks by ensuring validated certificates.		attacks by ensuring validated certificates.
	* Regular updates and verification of federation metadata to prevent		* Regular updates and verification of federation metadata to prevent
	the use of outdated or compromised information.		the use of outdated or compromised information.
	The federation operator aggregates, signs, and publishes the		The federation operator aggregates, signs, and publishes the
	federation metadata, which combines all members' member metadata		federation metadata, which combines all members' member metadata
	along with additional federation-specific information. By placing		along with additional federation-specific information. By placing
	trust in the federation and its associated signing key, federation		trust in the federation and its associated signing key, federation
	members trust the information contained within the federation		members trust the information contained within the federation
	metadata.		metadata.
	The trust anchor for the federation is established through the		The trust anchor for the federation is established through the
	federation's signing key, a critical component requiring secure		federation's signing key, a critical component requiring secure
	distribution and verification. To achieve this, the federation's		distribution and verification. To achieve this, the federation's
	signing key is distributed using a JSON Web Key Set (JWKS) [RFC7517],		signing key is distributed using a JSON Web Key (JWK) Set [RFC7517],
	providing a flexible framework for exposing multiple keys, including		providing a flexible framework for exposing multiple keys, including
	the signing key and keys for rollover. This structured approach		the signing key and keys for rollover. This structured approach
	ensures members can readily access the necessary keys for		ensures members can readily access the necessary keys for
	verification purposes.		verification purposes.
	An additional layer of security is introduced through thumbprint		An additional layer of security is introduced through thumbprint
	verification [RFC7638], where federation members can independently		verification [RFC7638], where federation members can independently
	verify the key's authenticity. This involves comparing the		verify the key's authenticity. This involves comparing the
	calculated cryptographic thumbprint of the key with a trusted value,		calculated cryptographic thumbprint of the key with a trusted value,
	ensuring its integrity. Importantly, this verification process can		ensuring its integrity. Importantly, this verification process can
	be conducted through channels separate from the JWKS itself,		be conducted through channels separate from the JWK Set itself,
	enhancing security by eliminating reliance on a single distribution		enhancing security by eliminating reliance on a single distribution
	mechanism.		mechanism.
	This trust framework is essential for enabling seamless and secure		This trust framework is essential for enabling seamless and secure
	interoperability across different trust domains within the		interoperability across different trust domains within the
	federation.		federation.
	3.4. Member Vetting		3.4. Member Vetting
	To ensure the security and integrity of the MATF framework, a member		To ensure the security and integrity of the MATF framework, a member
	skipping to change at page 8, line 21 ¶		skipping to change at line 359 ¶
	security and trustworthiness of the MATF framework. The specific		security and trustworthiness of the MATF framework. The specific
	mechanisms for ensuring metadata authenticity are beyond the scope of		mechanisms for ensuring metadata authenticity are beyond the scope of
	this document and must be defined by the federation or regulatory		this document and must be defined by the federation or regulatory
	bodies.		bodies.
	4. Metadata Repository		4. Metadata Repository
	The MATF metadata repository acts as a central vault, securely		The MATF metadata repository acts as a central vault, securely
	storing all information about all participating federation members		storing all information about all participating federation members
	and their respective entities. This information, known as federation		and their respective entities. This information, known as federation
	metadata, is presented as a JWS [RFC7515]to ensure its authenticity		metadata, is presented as a JSON Web Signature (JWS) [RFC7515] to
	and integrity.		ensure its authenticity and integrity.
	The metadata repository is subject to stringent security measures to		The metadata repository is subject to stringent security measures to
	safeguard the integrity of the stored information. This MAY involve:		safeguard the integrity of the stored information. This MAY involve:
	* Member Management: The federation operator can centrally enforce		* Member Management: The federation operator can centrally enforce
	security policies and vet new members before they are added to the		security policies and vet new members before they are added to the
	repository.		repository.
	* Access Controls: Only authorized members within the federation		* Access Controls: Only authorized members within the federation
	should have access to the repository.		should have access to the repository.
	skipping to change at page 9, line 15 ¶		skipping to change at line 399 ¶
	* Unique Public Key Pins: Public key pins [RFC7469] are used to		* Unique Public Key Pins: Public key pins [RFC7469] are used to
	identify client entities within the federation metadata during the		identify client entities within the federation metadata during the
	connection validation process. When a server validates a client's		connection validation process. When a server validates a client's
	TLS connection, it extracts the pin from the client's TLS		TLS connection, it extracts the pin from the client's TLS
	certificate and matches it against entries in the federation		certificate and matches it against entries in the federation
	metadata. The requirements for pin uniqueness and usage are		metadata. The requirements for pin uniqueness and usage are
	detailed in Section 6.1.1.1.		detailed in Section 6.1.1.1.
	* Certificate Verification: The issuer certificates listed in the		* Certificate Verification: The issuer certificates listed in the
	metadata are validated to ensure that the algorithms used in the		metadata are validated to ensure that the algorithms used in the
	certificates are well-known and secure, and that the certificates		certificates are well known and secure, and that the certificates
	are currently valid and have not expired		are currently valid and have not expired.
	* Tag Validation: Ensures that tags, as defined in Section 6.1.1.1		* Tag Validation: Ensures that tags (as defined in Section 6.1.1.1)
	in the metadata adhere to the defined tag structure, verifying		in the metadata adhere to the defined tag structure, verifying
	both mandatory and optional tags. This process is crucial for		both mandatory and optional tags. This process is crucial for
	maintaining consistency and preventing unauthorized tags within a		maintaining consistency and preventing unauthorized tags within a
	federation.		federation.
	The MATF metadata repository serves as the vital foundation for		The MATF metadata repository serves as the vital foundation for
	establishing trust and enabling secure communication within a MATF		establishing trust and enabling secure communication within a MATF
	environment. By providing a central, secure, and controlled		environment. By providing a central, secure, and controlled
	repository for critical information, the metadata repository empowers		repository for critical information, the metadata repository empowers
	members to confidently discover other trusted entities, and establish		members to confidently discover other trusted entities, and establish
	skipping to change at page 10, line 19 ¶		skipping to change at line 450 ¶
	issues like failed connections, discovery challenges, and		issues like failed connections, discovery challenges, and
	potential security risks.		potential security risks.
	* Local Metadata: Each member maintains a local metadata store		* Local Metadata: Each member maintains a local metadata store
	containing information about other members within the federation.		containing information about other members within the federation.
	This information is retrieved from the federation's publicly		This information is retrieved from the federation's publicly
	accessible JWS. Outdated data in the local store can hinder a		accessible JWS. Outdated data in the local store can hinder a
	member's ability to discover and connect with other relevant		member's ability to discover and connect with other relevant
	entities.		entities.
	The following outlines the procedures for keeping metadata up-to-		The following outlines the procedures for keeping metadata up to
	date:		date:
	* Federation Operator Role: The federation operator plays a crucial		* Federation Operator Role: The federation operator plays a crucial
	role in maintaining data integrity within the federation. Their		role in maintaining data integrity within the federation. Their
	responsibilities include:		responsibilities include:
	- Defining regulations for metadata management that MUST include,		- Defining regulations for metadata management that MUST include,
	at a minimum but not limited to, expiration and cache time		at a minimum but not limited to, expiration and cache time
	management.		management.
	- Implementing mechanisms to update the published federation		- Implementing mechanisms to update the published federation
	metadata, ensuring it adheres to the expiration time (exp as		metadata, ensuring it adheres to the expiration time (exp as
	defined in Section 6.4) and cache TTL (cache_ttl as defined in		defined in Section 6.1) and cache TTL (cache_ttl as defined in
	Section 6.1) specifications.		Section 6.1) specifications.
	* Member Responsibility: Members must follow the federation's		* Member Responsibility: Members must follow the federation's
	metadata management regulations and refresh their local metadata		metadata management regulations and refresh their local metadata
	store according to the defined expiration and cache regulations.		store according to the defined expiration and cache regulations.
	By adhering to these responsibilities, the Federation ensures that		By adhering to these responsibilities, the Federation ensures that
	information remains valid for the defined timeframe and that caching		information remains valid for the defined timeframe and that caching
	mechanisms utilize up-to-date data effectively.		mechanisms utilize up-to-date data effectively.
	skipping to change at page 11, line 11 ¶		skipping to change at line 487 ¶
	TLS authentication, as defined in [RFC8446]. This mechanism ensures		TLS authentication, as defined in [RFC8446]. This mechanism ensures
	the authenticity of both communicating parties, establishing a robust		the authenticity of both communicating parties, establishing a robust
	foundation for secure data exchange.		foundation for secure data exchange.
	5.1. Public Key Pinning		5.1. Public Key Pinning
	MATF implements public key pinning as specified in [RFC7469]. Public		MATF implements public key pinning as specified in [RFC7469]. Public
	key pinning associates one or more unique public keys with each		key pinning associates one or more unique public keys with each
	endpoint within the federation, stored in the federation metadata.		endpoint within the federation, stored in the federation metadata.
	During a connection, clients and servers extract the public key from		During a connection, clients and servers extract the public key from
	the received certificate and validate it against the pre-configured		the received certificate and validate it against the preconfigured
	public key pins retrieved from the federation metadata.		public key pins retrieved from the federation metadata.
	5.1.1. Benefits of Public Key Pinning		5.1.1. Benefits of Public Key Pinning
	The decision to utilize public key pinning in the MATF framework was		The decision to utilize public key pinning in the MATF framework was
	driven by several critical factors aimed at enhancing security and		driven by several critical factors aimed at enhancing security and
	ensuring trust:		ensuring trust.
	5.1.1.1. Interfederation Trust		5.1.1.1. Interfederation Trust
	In interfederation environments, where multiple federations need to		In interfederation environments, where multiple federations need to
	trust each other, public key pinning remains effective. Each		trust each other, public key pinning remains effective. Each
	federation can pin the public keys of entities in other federations,		federation can pin the public keys of entities in other federations,
	ensuring trust across boundaries. Unlike private certificate chains,		ensuring trust across boundaries. Unlike private certificate chains,
	which can become complex and difficult to manage across multiple		which can become complex and difficult to manage across multiple
	federations, public key pinning provides a straightforward mechanism		federations, public key pinning provides a straightforward mechanism
	for establishing trust. MATF interfederation addresses this		for establishing trust. MATF interfederation addresses this
	skipping to change at page 11, line 47 ¶		skipping to change at line 523 ¶
	Public key pinning provides a robust defense mechanism by directly		Public key pinning provides a robust defense mechanism by directly
	binding a peer to a specific public key. This ensures that only the		binding a peer to a specific public key. This ensures that only the
	designated key is trusted, preventing attackers from exploiting		designated key is trusted, preventing attackers from exploiting
	fraudulent certificates. By eliminating reliance on external trust		fraudulent certificates. By eliminating reliance on external trust
	intermediaries, this approach significantly enhances resilience		intermediaries, this approach significantly enhances resilience
	against potential threats.		against potential threats.
	5.1.1.3. Use of Self-Signed Certificates		5.1.1.3. Use of Self-Signed Certificates
	The use of self-signed certificates within the federation leverages		The use of self-signed certificates within the federation leverages
	public key pinning to establish trust. By bypassing external CAs,		public key pinning to establish trust. By bypassing external
	servers and clients rely on the federation's mechanisms to validate		Certificate Authorities (CAs), servers and clients rely on the
	trust. Public key pinning ensures that only the specific self-signed		federation's mechanisms to validate trust. Public key pinning
	public keys, identified by key pins in the metadata, are trusted.		ensures that only the specific self-signed public keys, identified by
			key pins in the metadata, are trusted.
	5.1.1.4. Revocation		5.1.1.4. Revocation
	If any certificate in a certificate chain is compromised, the		If any certificate in a certificate chain is compromised, the
	revocation process can be complex and slow. This complexity arises		revocation process can be complex and slow. This complexity arises
	because not only the compromised certificate but potentially multiple		because not only the compromised certificate but potentially multiple
	certificates within the chain might need to be revoked and reissued.		certificates within the chain might need to be revoked and reissued.
	Public key pinning mitigates this complexity by allowing clients to		Public key pinning mitigates this complexity by allowing clients to
	explicitly trust a specific public key, thereby reducing dependency		explicitly trust a specific public key, thereby reducing dependency
	on the entire certificate chain's integrity.		on the entire certificate chain's integrity.
	If a leaf certificate is compromised within a MATF federation, the		If a leaf certificate is compromised within a MATF federation, the
	revocation process involves removing the pin associated with the		revocation process involves removing the pin associated with the
	compromised certificate and publishing updated metadata that includes		compromised certificate and publishing updated metadata that includes
	a new pin corresponding to the replacement certificate. This		a new pin corresponding to the replacement certificate. This
	approach eliminates reliance on traditional certificate revocation		approach eliminates reliance on standard PKI-based certificate
	mechanisms and shifts the trust relationship to the specific, updated		revocation mechanisms and shifts the trust relationship to the
	public key identified by its pin.		specific, updated public key identified by its pin.
	5.2. Pin Discovery and Preloading		5.2. Pin Discovery and Preloading
	Peers in the federation retrieve these unique public key pins,		Peers in the federation retrieve these unique public key pins,
	serving as pre-configured trust parameters, from the federation		serving as preconfigured trust parameters, from the federation
	metadata. The federation MUST facilitate the discovery process,		metadata. The federation MUST facilitate the discovery process,
	allowing peers to identify the relevant pins for each endpoint.		allowing peers to identify the relevant pins for each endpoint.
	Information such as organization, tags, and descriptions within the		Information such as organization, tags, and descriptions within the
	federation metadata supports this discovery.		federation metadata supports this discovery.
	Before initiating any connection, clients and servers MUST preload		Before initiating any connection, clients and servers MUST preload
	the designated pins from the federation metadata. This aligns with		the designated pins from the federation metadata. This aligns with
	the principle described in Section 2.7 of [RFC7469], which introduces		the principle described in Section 2.7 of [RFC7469], which introduces
	optional sources for pinning information, with the federation		optional sources for pinning information, with the federation
	metadata serving as one such source. Preloading pins restricts		metadata serving as one such source. Preloading pins restricts
	skipping to change at page 13, line 15 ¶		skipping to change at line 588 ¶
	application itself, assuming the peer certificate is appropriately		application itself, assuming the peer certificate is appropriately
	transferred (e.g., via an HTTP header).		transferred (e.g., via an HTTP header).
	5.4. Failure to Validate		5.4. Failure to Validate
	A received certificate that fails validation MUST result in the		A received certificate that fails validation MUST result in the
	immediate termination of the connection. This strict enforcement		immediate termination of the connection. This strict enforcement
	ensures that only authorized and secure communication channels are		ensures that only authorized and secure communication channels are
	established within the federation.		established within the federation.
	5.5. Certificate Rotation:		5.5. Certificate Rotation
	To replace a certificate, whether due to expiration or other reasons,		To replace a certificate, whether due to expiration or other reasons,
	the following procedure must be followed:		the following procedure must be followed:
	1. Publishing New Metadata: When a certificate needs to be changed,		1. Publishing New Metadata: When a certificate needs to be changed,
	federation members publish new metadata containing the pin		federation members publish new metadata containing the pin
	(SHA256 thumbprint) of the new public key. This ensures that the		(SHA256 thumbprint) of the new public key. This ensures that the
	new pin is available to all federation members.		new pin is available to all federation members.
	2. Propagation Period: Allow time for the updated metadata to		2. Propagation Period: Allow time for the updated metadata to
	skipping to change at page 14, line 11 ¶		skipping to change at line 628 ¶
	application handling the TLS session, either by enforcing direct		application handling the TLS session, either by enforcing direct
	pinning or by extracting and validating the public key against the		pinning or by extracting and validating the public key against the
	published pins.		published pins.
	For servers, validation depends on deployment. If the application		For servers, validation depends on deployment. If the application
	terminates the TLS session, it performs direct pinning or extracts		terminates the TLS session, it performs direct pinning or extracts
	and validates the public key. If a reverse proxy terminates the TLS		and validates the public key. If a reverse proxy terminates the TLS
	session, it can enforce direct pinning or forward the certificate to		session, it can enforce direct pinning or forward the certificate to
	the application (e.g., via an HTTP header) for validation.		the application (e.g., via an HTTP header) for validation.
	Implementations SHOULD, when possible, rely on libraries with native		Implementations SHOULD, when possible, rely on libraries with built-
	support for pinning. Libcurl, for example, supports pinning via the		in support for pinning. Libcurl, for example, supports pinning via
	PINNEDPUBLICKEY option. In Python, the cryptography library can		the PINNEDPUBLICKEY option. In Python, the cryptography library can
	extract public keys, while the requests package together with urllib3		extract public keys, while the requests package together with urllib3
	can intercept certificates. Go provides crypto/tls and crypto/x509		can intercept certificates. Go provides crypto/tls and crypto/x509
	for certificate inspection and public key extraction. In Java,		for certificate inspection and public key extraction. In Java,
	java.security.cert.X509Certificate enables public key extraction,		java.security.cert.X509Certificate enables public key extraction,
	while java.net.http.HttpClient allows pinning enforcement using a		while java.net.http.HttpClient allows pinning enforcement using a
	custom SSLContext and TrustManager. The choice of library is left to		custom SSLContext and TrustManager. The choice of library is left to
	the discretion of each implementation.		the discretion of each implementation.
	If bypassing standard CA validation is possible, it SHOULD be done.		If bypassing standard CA validation is possible, it SHOULD be done.
	If not, the issuers listed in the federation metadata MUST be used as		If not, the issuers listed in the federation metadata MUST be used as
	the trust store to validate certificate issuers while still enforcing		the trust store to validate certificate issuers while still enforcing
	key pinning. Without issuer validation against issuers in metadata,		key pinning. Without issuer validation against issuers in metadata,
	self-signed certificates would not be accepted. These mechanisms		self-signed certificates would not be accepted. These mechanisms
	ensure compatibility with existing TLS infrastructure while		ensure compatibility with existing TLS infrastructure while
	maintaining strict security guarantees.		maintaining strict security guarantees.
	6. Federation Metadata		6. Federation Metadata
	Federation metadata is published as a JWS [RFC7515]. The payload		Federation metadata is published as a JWS [RFC7515]. The payload
	contains statements about federation members entities.		contains statements about entities of federation members.
	Metadata is used for authentication and service discovery. A client		Metadata is used for authentication and service discovery. A client
	selects a server based on metadata claims (e.g., organization, tags).		selects a server based on metadata claims (e.g., organization, tags).
	The client then uses the selected server claims base_uri, pins and if		To establish a connection, the client then uses the base_uri, pins,
	needed issuers to establish a connection.		and, if needed, issuers of the selected server claims.
	Upon receiving a connection, a server validates the received client		Upon receiving a connection, a server validates the received client
	certificate using the client's published pins. Server MAY also check		certificate using the client's published pins. A server MAY also
	other claims such as organization and tags to determine if the		check other claims such as organization and tags to determine if the
	connection is accepted or terminated.		connection is accepted or terminated.
	6.1. Federation Metadata Claims		6.1. Federation Metadata Claims
	This section defines the set of claims that can be included in		This section defines the set of claims that can be included in
	metadata.		metadata.
	* iat (REQUIRED)		* iat (REQUIRED)
	Identifies the time at which the federation metadata was issued.		Identifies the time at which the federation metadata was issued.
	- Data Type: Integer		- Data Type: Integer
	- Syntax: NumericDate as defined in [RFC7519], Section 4.1.6		- Syntax: NumericDate as defined in [RFC7519], Section 4.1.6.
	- Example: 1755514949		- Example: 1755514949
	* exp (REQUIRED)		* exp (REQUIRED)
	Identifies the expiration time on or after which the federation		Identifies the expiration time on or after which the federation
	metadata is no longer valid. Once the exp time has passed, the		metadata is no longer valid. Once the exp time has passed, the
	metadata MUST be rejected regardless of cache state.		metadata MUST be rejected regardless of cache state.
	- Data Type: Integer		- Data Type: Integer
	- Syntax: NumericDate as defined in [RFC7519], Section 4.1.4		- Syntax: NumericDate as defined in [RFC7519], Section 4.1.4.
	- Example: 1756119888		- Example: 1756119888
	* iss (REQUIRED)		* iss (REQUIRED)
	A URI uniquely identifying the issuing federation. This value		A URI uniquely identifying the issuing federation. This value
	differentiates federations, prevents ambiguity, and ensures that		differentiates federations, prevents ambiguity, and ensures that
	entities are recognized within their intended context.		entities are recognized within their intended context.
	Verification of the iss claim enables recipients to determine the		Verification of the iss claim enables recipients to determine the
	origin of the information and to establish trust with entities		origin of the information and to establish trust with entities
	within the identified federation.		within the identified federation.
	- Data Type: String		- Data Type: String
	- Syntax: URI, as defined in [RFC7519], Section 4.1.1		- Syntax: URI as defined in [RFC7519], Section 4.1.1.
	- Example: "https://federation.example.org"		- Example: "https://federation.example.org"
	* version (REQUIRED)		* version (REQUIRED)
	Indicates the schema version of the federation metadata. This		Indicates the schema version of the federation metadata. This
	ensures compatibility between members of the federation by		ensures compatibility between members of the federation by
	defining a clear versioning mechanism for interpreting metadata.		defining a clear versioning mechanism for interpreting metadata.
	- Data Type: String		- Data Type: String
	- Syntax: Must adhere to Semantic Versioning (https://semver.org		- Syntax: Must adhere to Semantic Versioning (see
	(https://semver.org)).		<https://semver.org>).
	- Example: "1.0.0"		- Example: "1.0.0"
	* cache_ttl (OPTIONAL)		* cache_ttl (OPTIONAL)
	Specifies the duration in seconds for caching downloaded		Specifies the duration in seconds for caching downloaded
	federation metadata, allowing for independent caching outside of		federation metadata, allowing for independent caching outside of
	specific HTTP configurations, particularly useful when the		specific HTTP configurations. This is particularly useful when
	communication mechanism isn't HTTP-based. In the event of a		the communication mechanism is not based on HTTP. In the event of
	metadata publication outage, members can rely on cached metadata		a metadata publication outage, members can rely on cached metadata
	until it expires, as indicated by the exp claim in the JWS		until it expires, as indicated by the exp claim in the JWS
	payload, defined in Section 6.4. Once expired, metadata MUST no		payload, defined in Section 6.1. Once expired, metadata MUST no
	longer be trusted. If omitted, a mechanism to refresh metadata		longer be trusted. If omitted, a mechanism to refresh metadata
	MUST still exist to ensure the metadata remains valid.		MUST still exist to ensure the metadata remains valid.
	- Data Type: Integer		- Data Type: Integer
	- Syntax: Integer representing the duration in seconds.		- Syntax: Integer representing the duration in seconds.
	- Example: 3600		- Example: 3600
	* entities (REQUIRED)		* entities (REQUIRED)
	skipping to change at page 17, line 4 ¶		skipping to change at line 764 ¶
	NOT collide with any other entity_id within the federation or		NOT collide with any other entity_id within the federation or
	within any other federation that the entity interacts with.		within any other federation that the entity interacts with.
	- Data Type: URI		- Data Type: URI
	- Syntax: A valid URI.		- Syntax: A valid URI.
	- Example: "https://example.com"		- Example: "https://example.com"
	* organization (OPTIONAL)		* organization (OPTIONAL)
	A name identifying the organization that the entity's metadata		A name identifying the organization that the entity's metadata
	represents. The federation operator MUST ensure a mechanism is in		represents. The federation operator MUST ensure a mechanism is in
	place to verify that the organization claim corresponds to the		place to verify that the organization claim corresponds to the
	rightful owner of the information exchanged between nodes. This		rightful owner of the information exchanged between nodes. This
	is crucial for the trust model, ensuring certainty about the		is crucial for the trust model, ensuring certainty about the
	identities of the involved parties. The federation operator		identities of the involved parties. The federation operator
	SHOULD choose an approach that best suits the specific needs and		SHOULD choose an approach that best suits the specific needs and
	trust model of the federation.		trust model of the federation.
	- Data Type: String		- Data Type: String
	- Syntax: A name identifying the organization represented by the		- Syntax: A name identifying the organization represented by the
	entity.		entity.
	- Example: "Example Org"		- Example: "Example Org"
	* issuers (REQUIRED)		* issuers (REQUIRED)
	A list of certificate issuers allowed to issue certificates for		A list of certificate issuers allowed to issue certificates for
	the entity's endpoints. For each issuer, the issuer's root CA		the entity's endpoints. For each issuer, the issuer's root CA
	certificate MUST be included in the x509certificate property, PEM-		certificate MUST be included in the x509certificate property and
	encoded. Certificate verification relies on public key pinning,		be encoded by Privacy-Enhanced Mail (PEM). Certificate
	with the list of allowed issuers used only when a certificate		verification relies on public key pinning, with the list of
	chain validation mechanism is unavoidable. For self-signed		allowed issuers used only when a certificate chain validation
	certificates, the certificate itself acts as its own issuer and		mechanism is unavoidable. For self-signed certificates, the
	MUST be listed as such in the metadata.		certificate itself acts as its own issuer and MUST be listed as
			such in the metadata.
	- Data Type: List of Objects		- Data Type: List of Objects
	- Syntax: Each object contains a issuer certificate, PEM-encoded.		- Syntax: Each object contains a PEM-encoded issuer certificate.
	- Example: Issuer truncated for readability.		- Example: Issuer truncated for readability.
	"issuers": [{		"issuers": [{
	"x509certificate": "-----BEGIN CERTIFICATE-----\nMIIDDD"		"x509certificate": "-----BEGIN CERTIFICATE-----\nMIIDDD"
	}]		}]
	* servers (OPTIONAL)		* servers (OPTIONAL)
	Contains the list of servers within the entity.		Contains the list of servers within the entity.
	skipping to change at page 18, line 4 ¶		skipping to change at line 813 ¶
	* servers (OPTIONAL)		* servers (OPTIONAL)
	Contains the list of servers within the entity.		Contains the list of servers within the entity.
	- Data Type: Array of Objects		- Data Type: Array of Objects
	- Syntax: Each object MUST conform to the server definition, as		- Syntax: Each object MUST conform to the server definition, as
	specified in Section 6.1.1.1.		specified in Section 6.1.1.1.
	* clients (OPTIONAL)		* clients (OPTIONAL)
	Contains the list of clients within the entity.		Contains the list of clients within the entity.
	- Data Type: Array of Objects		- Data Type: Array of Objects
	- Syntax: Each object MUST conform to the client definition, as		- Syntax: Each object MUST conform to the client definition, as
	specified in Section 6.1.1.1.		specified in Section 6.1.1.1.
	6.1.1.1. Servers / Clients		6.1.1.1. Servers / Clients
	A list of the entity's servers and clients.		The entity's servers and clients are listed below.
	* description (OPTIONAL)		* description (OPTIONAL)
	A human readable text describing the server or client.		A human-readable text describing the server or client.
	- Data Type: String		- Data Type: String
	- Syntax: Free-form text describing the server or client.		- Syntax: Free-form text describing the server or client.
	- Example: "SCIM Server 1"		- Example: "SCIM Server 1"
	* base_uri (OPTIONAL)		* base_uri (OPTIONAL)
	The base URL of the server, which is required for endpoints that		The base URL of the server, which is required for endpoints that
	describe server.		describe servers.
	- Data Type: URI		- Data Type: URI
	- Syntax: A valid URL.		- Syntax: A valid URL.
	- Example: "https://scim.example.com/"		- Example: "https://scim.example.com/"
	* pins (REQUIRED)		* pins (REQUIRED)
	A list of objects representing Public Key Pins [RFC7469].		A list of objects representing public key pins [RFC7469].
	- Data Type: Array of Objects		- Data Type: Array of Objects
	- Syntax: A list of objects, where each object represents a		- Syntax: A list of objects, where each object represents a
	single public key pin with the following properties:		single public key pin with the following properties:
	o alg (REQUIRED)		o alg (REQUIRED)
	The name of the cryptographic hash algorithm. Currently,		The name of the cryptographic hash algorithm. Currently,
	the RECOMMENDED value is 'sha256'. As more secure		the RECOMMENDED value is 'sha256'. As more secure
	skipping to change at page 20, line 12 ¶		skipping to change at line 918 ¶
	supported protocols or the type of data they handle, enabling		supported protocols or the type of data they handle, enabling
	discovery of compatible servers.		discovery of compatible servers.
	- Client Tags: Tags associated with clients are used by servers		- Client Tags: Tags associated with clients are used by servers
	to identify clients with specific characteristics or		to identify clients with specific characteristics or
	capabilities. For instance, a server might only accept		capabilities. For instance, a server might only accept
	connections from clients that support particular protocols. By		connections from clients that support particular protocols. By
	filtering incoming requests based on these tags, servers can		filtering incoming requests based on these tags, servers can
	identify suitable clients.		identify suitable clients.
	Federation-Specific Considerations		Federation-Specific Considerations: While tags are tied to
			individual federations and serve distinct purposes within each,
	While tags are tied to individual federations and serve distinct		several key considerations are crucial to ensure clarity and
	purposes within each, several key considerations are crucial to		promote consistent tag usage:
	ensure clarity and promote consistent tag usage:
	- Well-Defined Scope: Each federation MUST establish a clear		- Well-Defined Scope: Each federation MUST establish a clear
	scope for its tags, detailing their intended use, allowed tag		scope for its tags, detailing their intended use, allowed tag
	values, associated meanings, and any relevant restrictions.		values, associated meanings, and any relevant restrictions.
	Maintaining a well-defined and readily accessible registry of		Maintaining a well-defined and readily accessible registry of
	approved tags is essential for the federation.		approved tags is essential for the federation.
	- Validation Mechanisms: Implementing validation mechanisms for		- Validation Mechanisms: Implementing validation mechanisms for
	tags is highly recommended. This may involve a dedicated		tags is highly recommended. This may involve a dedicated
	operation or service verifying tag validity and compliance with		operation or service verifying tag validity and compliance with
	the federation's regulations. Such validation ensures		the federation's regulations. Such validation ensures
	consistency within the federation by preventing the use of		consistency within the federation by preventing the use of
	unauthorized or irrelevant tags.		unauthorized or irrelevant tags.
	6.2. Metadata Schema		6.2. Metadata Schema
	The MATF metadata schema is defined in Appendix A. This schema		The MATF metadata schema is defined in Appendix A. This schema
	specifies the format for describing entities involved in MATF and		specifies the format for describing entities involved in MATF and
	their associated information.		their associated information.
	Note: The schema in Appendix A is folded due to line length		| Note: The schema in Appendix A is folded due to line length
	limitations as specified in [RFC8792].		| limitations as specified in [RFC8792].
	6.3. Example Metadata		6.3. Example Metadata
	The following is a non-normative example of a metadata statement.		The following is a non-normative example of a metadata statement.
	Line breaks within the issuers' claim is for readability only.		Line breaks within the issuers' claim is for readability only.
	{		{
	"exp": 1755514949,		"iat": 1755514949,
	"iat": 1756119888,		"exp": 1756119888,
	"iss": "https://federation.example.org",		"iss": "https://federation.example.org",
	"version": "1.0.0",		"version": "1.0.0",
	"cache_ttl": 3600,		"cache_ttl": 3600,
	"entities": [{		"entities": [{
	"entity_id": "https://example.com",		"entity_id": "https://example.com",
	"organization": "Example Org",		"organization": "Example Org",
	"issuers": [{		"issuers": [{
	"x509certificate": "-----BEGIN CERTIFICATE-----\nMIIDDDCCAf		"x509certificate": "-----BEGIN CERTIFICATE-----\nMIIDDDCCAf
	SgAwIBAgIJAIOsfJBStJQhMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV\nBAM		SgAwIBAgIJAIOsfJBStJQhMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV\nBAM
	MEHNjaW0uZXhhbXBsZS5jb20wHhcNMTcwNDA2MDc1MzE3WhcNMTcwNTA2MD		MEHNjaW0uZXhhbXBsZS5jb20wHhcNMTcwNDA2MDc1MzE3WhcNMTcwNTA2MD
	skipping to change at page 22, line 8 ¶		skipping to change at line 1005 ¶
	"alg": "sha256",		"alg": "sha256",
	"digest": "+hcmCjJEtLq4BRPhrILyhgn98Lhy6DaWdpmsBAgOLCQ="		"digest": "+hcmCjJEtLq4BRPhrILyhgn98Lhy6DaWdpmsBAgOLCQ="
	}]		}]
	}]		}]
	}]		}]
	}		}
	6.4. Metadata Signing		6.4. Metadata Signing
	Federation metadata is signed using JWS and published using JWS JSON		Federation metadata is signed using JWS and published using JWS JSON
	Serialization according to the General JWS JSON Serialization Syntax		Serialization according to the general JWS JSON Serialization syntax
	defined in [RFC7515]. Federation metadata signatures are RECOMMENDED		defined in [RFC7515]. Federation metadata signatures are RECOMMENDED
	to be created using the algorithm _ECDSA using P-256 and SHA-256_		to be created using the algorithm _ECDSA using P-256 and SHA-256_
	("ES256") as defined in [RFC7518]. However, to accommodate evolving		("ES256") as defined in [RFC7518]. However, to accommodate evolving
	cryptographic standards, alternative algorithms MAY be used, provided		cryptographic standards, alternative algorithms MAY be used, provided
	they meet the security requirements of the federation.		they meet the security requirements of the federation.
	The following protected JWS header parameters are REQUIRED:		The following protected JWS header parameters are REQUIRED:
	* alg (Algorithm)		* alg (Algorithm)
	skipping to change at page 22, line 46 ¶		skipping to change at line 1043 ¶
	7. Example Usage Scenarios		7. Example Usage Scenarios
	The examples in this section are non-normative.		The examples in this section are non-normative.
	The following example describes a scenario within the federation		The following example describes a scenario within the federation
	"Skolfederation" where MATF is already established. Both clients and		"Skolfederation" where MATF is already established. Both clients and
	servers are registered members of the federation. In this scenario,		servers are registered members of the federation. In this scenario,
	clients aim to manage cross-domain user accounts within the service.		clients aim to manage cross-domain user accounts within the service.
	The standard used for account management is SS 12000:2018 (i.e., a		The standard used for account management is SS 12000:2018 (i.e., a
	SCIM extension).		System for Cross-domain Identity Management (SCIM) extension).
	+---------------------------------------------+		+---------------------------------------------+
	| |		| |
	| Federation Metadata |		| Federation Metadata |
	| |		| |
	+---+--------------------------+--------------+		+---+--------------------------+--------------+
	| |		| |
	(A) (A)		(A) (A)
	| |		| |
	v v		v v
	skipping to change at page 23, line 50 ¶		skipping to change at line 1090 ¶
	application.		application.
	F. The application converts the certificate to a public key pin and		F. The application converts the certificate to a public key pin and
	checks the federation metadata for a matching pin. The entity's		checks the federation metadata for a matching pin. The entity's
	entity_id should be used as an identifier.		entity_id should be used as an identifier.
	7.1. Client		7.1. Client
	A certificate is issued for the client and the issuer is published in		A certificate is issued for the client and the issuer is published in
	the federation metadata together with the client's certificate public		the federation metadata together with the client's certificate public
	key pins		key pins.
	When the client wants to connect to a remote server (identified by an		When the client wants to connect to a remote server (identified by an
	entity identifier) the following steps need to be taken:		entity identifier) the following steps need to be taken:
	1. Find possible server candidates by filtering the remote entity's		1. Find possible server candidates by filtering the remote entity's
	list of servers based on tags.		list of servers based on tags.
	2. Connect to the server URI. Include the entity's list of		2. Connect to the server URI. Include the entity's list of
	certificate issuers in the TLS clients list of trusted CAs, or		certificate issuers in the TLS clients list of trusted CAs, or
	trust the listed pins explicitly.		trust the listed pins explicitly.
	skipping to change at page 24, line 41 ¶		skipping to change at line 1129 ¶
	configure optional untrusted TLS client certificate		configure optional untrusted TLS client certificate
	authentication (e.g., optional_no_ca).		authentication (e.g., optional_no_ca).
	2. Once a connection has been accepted, validate the received client		2. Once a connection has been accepted, validate the received client
	certificate using the client's published pins.		certificate using the client's published pins.
	3. Commence transactions.		3. Commence transactions.
	7.3. SPKI Generation		7.3. SPKI Generation
	Example of how to use OpenSSL to generate a SPKI fingerprint from a		The following is an example of how to use OpenSSL to generate a SPKI
	PEM-encoded certificate.		fingerprint from a PEM-encoded certificate.
	openssl x509 -in <certificate.pem> -pubkey -noout | \		openssl x509 -in <certificate.pem> -pubkey -noout | \
	openssl pkey -pubin -outform der | \		openssl pkey -pubin -outform der | \
	openssl dgst -sha256 -binary | \		openssl dgst -sha256 -binary | \
	openssl enc -base64		openssl enc -base64
	7.4. Curl and Public Key Pinning		7.4. Curl and Public Key Pinning
	Example of public key pinning with curl. Line breaks are for		The following is an example of public key pinning with curl. Line
	readability only.		breaks are for readability only.
	curl --cert client.pem --key client.key --pinnedpubkey 'sha256//0Ok		curl --cert client.pem --key client.key --pinnedpubkey 'sha256//0Ok
	2aNfcrCNDMhC2uXIdxBFOvMfEVtzlNVUT5pur0Dk=' https://host.example.com		2aNfcrCNDMhC2uXIdxBFOvMfEVtzlNVUT5pur0Dk=' https://host.example.com
	8. Deployments of the MATF Framework		8. Deployments of the MATF Framework
	The MATF framework has proven its practical value and robustness		The MATF framework has proven its practical value and robustness
	through successful deployments in several environments.		through successful deployments in several environments.
	8.1. Skolfederation Moa		8.1. Skolfederation Moa
	Skolfederation Moa [Moa], is a federation designed to secure		Skolfederation Moa [Moa] is a federation designed to secure
	communication between digital educational resources and schools.		communication between digital educational resources and schools.
	MATF is developed to meet Moa's needs and enables secure data		MATF is developed to meet Moa's needs and enables secure data
	exchange for schools, municipalities, educational platforms, and		exchange for schools, municipalities, educational platforms, and
	services across Sweden.		services across Sweden.
	The community plays a crucial role in this type of federation.		The community plays a crucial role in this type of federation.
	Members are active participants, and the FO ensures the federation		Members are active participants, and the federation operator ensures
	runs smoothly and serves their needs. Moa's success highlights the		the federation runs smoothly and serves their needs. Moa's success
	importance of collaboration, with members and the FO working together		highlights the importance of collaboration, with members and the
	to maintain trust, security, and interoperability in the education		federation operator working together to maintain trust, security, and
	sector.		interoperability in the education sector.
	The deployment of MATF in the Swedish education sector has provided		The deployment of MATF in the Swedish education sector has provided
	several key insights. Maintaining an accurate registry of metadata		several key insights. Maintaining an accurate registry of metadata
	ownership with reliable contact information is essential for		ownership with reliable contact information is essential for
	troubleshooting and ensuring accountability. The deployment also		troubleshooting and ensuring accountability. The deployment also
	demonstrated the importance of setting reasonable expiration times		demonstrated the importance of setting reasonable expiration times
	for metadata. Too short an expiration can hinder the ability to		for metadata. Too short an expiration can hinder the ability to
	implement contingency plans for publishing new metadata during		implement contingency plans for publishing new metadata during
	outages.		outages.
	skipping to change at page 27, line 37 ¶		skipping to change at line 1262 ¶
	9.5. Time Synchronization		9.5. Time Synchronization
	Maintaining synchronized clocks across all federation members is		Maintaining synchronized clocks across all federation members is
	critical for the security of the MATF framework. Inaccurate		critical for the security of the MATF framework. Inaccurate
	timestamps can compromise the validity of digital signatures and		timestamps can compromise the validity of digital signatures and
	certificates, hinder reliable log analysis, and potentially expose		certificates, hinder reliable log analysis, and potentially expose
	the system to time-based attacks. Therefore, all federation members		the system to time-based attacks. Therefore, all federation members
	MUST employ methods to ensure their system clocks are synchronized		MUST employ methods to ensure their system clocks are synchronized
	with a reliable time source.		with a reliable time source.
	10. Acknowledgements		10. IANA Considerations
	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.
	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.
	11. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	12. Normative References		11. References
			11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning		[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
	Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April		Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
	2015, <https://www.rfc-editor.org/info/rfc7469>.		2015, <https://www.rfc-editor.org/info/rfc7469>.
	skipping to change at page 28, line 46 ¶		skipping to change at line 1299 ¶
	<https://www.rfc-editor.org/info/rfc7518>.		<https://www.rfc-editor.org/info/rfc7518>.
	[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,		(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
	<https://www.rfc-editor.org/info/rfc7519>.		<https://www.rfc-editor.org/info/rfc7519>.
	[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)		[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
	Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September		Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
	2015, <https://www.rfc-editor.org/info/rfc7638>.		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		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	13. Informative References		11.2. Informative References
	[EGIL] Sambruk, "EGIL - manage your school's digital user		[eduGAIN] eduGAIN, "eduGAIN: Interfederation service connecting
	accounts efficiently", 2022,		research and education identity federations worldwide",
	<https://sambruk.se/egil-dnp/>.		<https://edugain.org>.
	[Moa] The Swedish Internet Foundation, "Machine and Organization		[EGIL] Sambruk, "EGIL – smidig hantering av skolans digitala
	Authentication", 2022,		användarkonton" [EGIL – manage your school's digital user
			accounts efficiently], <https://sambruk.se/egil-dnp/>.
			[eIDAS] European Commission, "eIDAS: electronic Identification,
			Authentication and trust Services",
			<https://eidas.ec.europa.eu/>.
			[Moa] Internetstiftelsens Federationer [The Swedish Internet
			Foundation], "Machine and Organization Authentication", 6
			October 2025,
	<https://wiki.federationer.internetstiftelsen.se/x/		<https://wiki.federationer.internetstiftelsen.se/x/
	LYA5AQ>.		LYA5AQ>.
	[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,		[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
	"Handling Long Lines in Content of Internet-Drafts and		"Handling Long Lines in Content of Internet-Drafts and
	RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,		RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
	<https://www.rfc-editor.org/info/rfc8792>.		<https://www.rfc-editor.org/info/rfc8792>.
	[SkolverketMATF]		[SkolverketMATF]
	Swedish National Agency for Education, "Authentication API		Skolverket [Swedish National Agency for Education], "API
	for User Management", 2023,		för autentisering" [Authentication API for User
			Management], commit f8c2e93, 4 September 2025,
	<https://github.com/skolverket/dnp-		<https://github.com/skolverket/dnp-
	usermanagement/blob/main/authentication-api/README.md>.		usermanagement/blob/main/authentication-api/README.md>.
	[eIDAS] European Commission, "eIDAS: electronic Identification,
	Authentication and trust Services", 2014,
	<https://eidas.ec.europa.eu/>.
	[eduGAIN] GEANT Association, "eduGAIN: Interfederation service
	connecting research and education identity federations
	worldwide", 2023, <https://edugain.org>.
	Appendix A. JSON Schema for MATF Metadata		Appendix A. JSON Schema for MATF Metadata
	The following JSON Schema defines the structure of MATF metadata. It		The following JSON Schema defines the structure of MATF metadata. It
	conforms to draft 2020-12 of the JSON Schema standard.		conforms to draft 2020-12 of the JSON Schema standard.
	Version: 1.0.0		Version: 1.0.0
	=============== NOTE: '\\' line wrapping per RFC 8792 ===============		=============== NOTE: '\\' line wrapping per RFC 8792 ===============
	{		{
	skipping to change at page 34, line 25 ¶		skipping to change at line 1572 ¶
	"examples": [		"examples": [
	"HiMkrb4phPSP+OvGqmZd6sGvy7AUn4k3XEe8OMBrzt8\		"HiMkrb4phPSP+OvGqmZd6sGvy7AUn4k3XEe8OMBrzt8\
	\="		\="
	]		]
	}		}
	}		}
	}		}
	}		}
	}		}
			Acknowledgements
			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.
			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.
	Authors' Addresses		Authors' Addresses
	Stefan Halen		Stefan Halén
	The Swedish Internet Foundation		The Swedish Internet Foundation
	Email: stefan.halen@internetstiftelsen.se		Email: stefan.halen@internetstiftelsen.se
	Jakob Schlyter		Jakob Schlyter
	Kirei AB		Kirei AB
	Email: jakob@kirei.se		Email: jakob@kirei.se
End of changes. 77 change blocks.
	227 lines changed or deleted		245 lines changed or added
This html diff was produced by rfcdiff 1.48.