Diff: rfc9932.original

	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 the
	context of Federations (MATF) framework, developed to complement	context of Federations (MATF) framework, developed to complement

	multilateral SAML federations within the education sector. These	multilateral Security Assertion Markup Language (SAML) federations
	federations often rely on just-in-time provisioning, where user	within the education sector. These federations often rely on just-
	accounts are created at first login based on information from the	in-time provisioning, where user accounts are created at first login
	SAML assertion. However, educators need to be able to manage	based on information from the SAML assertion. However, educators
	resources and classes before students access the service. MATF	need to be able to manage resources and classes before students
	bridges this gap by using secure machine-to-machine communication,	access the service. MATF bridges this gap by using secure machine-
	enabling pre-provisioning of user information using a trust model and	to-machine communication, enabling pre-provisioning of user
	metadata structure inspired by SAML federations.	information using a 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 and service-to-service
	interactions, and is not intended for browser-based authentication.	interactions, and is not intended for browser-based authentication.
	Because its applicability in a browser environment has not been	Because its applicability in a browser environment has not been
	studied, using MATF within browsers is not recommended. Doing so may	studied, using MATF within browsers is not recommended. Doing so may
	introduce risks that differ from those typically addressed by	introduce risks that differ from those typically addressed by
	standard browser security models.	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 7, line 15 ¶	skipping to change at line 304 ¶
	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.


	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.

	skipping to change at page 12, line 26 ¶	skipping to change at line 550 ¶
	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 traditional certificate revocation
	mechanisms and shifts the trust relationship to the specific, updated	mechanisms and shifts the trust relationship to the specific, updated
	public key identified by its pin.	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 41 ¶	skipping to change at line 658 ¶

	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 federation members entities.

	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	The client then uses the selected server claims base_uri, pins and if
	needed issuers to establish a connection.	needed issuers to establish a connection.

	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 the
	communication mechanism isn't HTTP-based. In the event of a	communication mechanism isn't HTTP based. In the event of a
	metadata publication outage, members can rely on cached metadata	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.4. 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.


	skipping to change at page 17, line 33 ¶	skipping to change at line 794 ¶
	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, PEM-
	encoded. Certificate verification relies on public key pinning,	encoded. Certificate verification relies on public key pinning,
	with the list of allowed issuers used only when a certificate	with the list of allowed issuers used only when a certificate
	chain validation mechanism is unavoidable. For self-signed	chain validation mechanism is unavoidable. For self-signed
	certificates, the certificate itself acts as its own issuer and	certificates, the certificate itself acts as its own issuer and
	MUST be listed as such in the metadata.	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 an issuer certificate, PEM-
		encoded.

	- 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

	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 FO ensures the federation
	runs smoothly and serves their needs. Moa's success highlights the	runs smoothly and serves their needs. Moa's success highlights the
	importance of collaboration, with members and the FO working together	importance of collaboration, with members and the FO working together
	to maintain trust, security, and interoperability in the education	to maintain trust, security, and interoperability in the education

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


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

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

	[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web	[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
	Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May	Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
	2015, <https://www.rfc-editor.org/info/rfc7515>.	2015, <https://www.rfc-editor.org/info/rfc7515>.

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

	skipping to change at page 28, line 50 ¶	skipping to change at line 1307 ¶
	<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>.

	[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	[EGIL] Sambruk, "EGIL – smidig hantering av skolans digitala
	accounts efficiently", 2022,	användarkonton" [EGIL – manage your school's digital user
	<https://sambruk.se/egil-dnp/>.	accounts efficiently], <https://sambruk.se/egil-dnp/>.


	[Moa] The Swedish Internet Foundation, "Machine and Organization	[Moa] Internetstiftelsens Federationer [The Swedish Internet
	Authentication", 2022,	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 2023,
	<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,	[eIDAS] European Commission, "eIDAS: electronic Identification,

	Authentication and trust Services", 2014,	Authentication and trust Services",
	<https://eidas.ec.europa.eu/>.	<https://eidas.ec.europa.eu/>.


	[eduGAIN] GEANT Association, "eduGAIN: Interfederation service	[eduGAIN] eduGAIN, "eduGAIN: Interfederation service connecting
	connecting research and education identity federations	research and education identity federations worldwide",
	worldwide", 2023, <https://edugain.org>.	<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. 65 change blocks.
	186 lines changed or deleted	203 lines changed or added
This html diff was produced by rfcdiff 1.48.