rfc9932v1.txt		rfc9932.txt
	skipping to change at line 110 ¶		skipping to change at line 110 ¶
	10. IANA Considerations		10. IANA Considerations
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	11.2. Informative References		11.2. Informative References
	Appendix A. JSON Schema for MATF Metadata		Appendix A. JSON Schema for MATF Metadata
	Acknowledgements		Acknowledgements
	Authors' Addresses		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 Security Assertion Markup Language (SAML) federations		Security Assertion Markup Language (SAML) federations within the
	within the education sector. These federations often rely on just-		education sector. These federations often rely on just-in-time
	in-time provisioning, where user accounts are created at first login		provisioning, where user accounts are created at first login based on
	based on information from the SAML assertion. However, educators		information from the SAML assertion. However, educators need to be
	need to be able to manage resources and classes before students		able to manage resources and classes before students access the
	access the service. MATF bridges this gap by using secure machine-		service. MATF bridges this gap by using secure machine-to-machine
	to-machine communication, enabling pre-provisioning of user		communication, enabling pre-provisioning of user information using a
	information using a trust model and metadata structure inspired by		trust model and metadata structure inspired by SAML federations.
	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/>.
	skipping to change at line 288 ¶		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.
	skipping to change at line 463 ¶		skipping to change at line 463 ¶
	* 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 line 543 ¶		skipping to change at line 543 ¶
	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 preconfigured 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.
	skipping to change at line 628 ¶		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. A server MAY also		certificate using the client's published pins. A server MAY also
	check 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.
	skipping to change at line 721 ¶		skipping to change at line 721 ¶
	- Syntax: Must adhere to Semantic Versioning (see		- 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; this is 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.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.
	- Example: 3600		- Example: 3600
	skipping to change at line 785 ¶		skipping to change at line 785 ¶
	- 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 an issuer certificate, PEM-		- Syntax: Each object contains a PEM-encoded issuer certificate.
	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 line 898 ¶		skipping to change at line 898 ¶
	}]		}]
	* tags (OPTIONAL)		* tags (OPTIONAL)
	A list of strings that describe the endpoint's capabilities.		A list of strings that describe the endpoint's capabilities.
	- Data Type: Array of Strings		- Data Type: Array of Strings
	- Syntax: Strings describing endpoint capabilities.		- Syntax: Strings describing endpoint capabilities.
	- Pattern: ^[a-z0-9]{1,64}$		- Pattern: "^[a-z0-9]{1,64}$"
	- Example: ["scim", "xyzzy"]		- Example: ["scim", "xyzzy"]
	Tags are fundamental for discovery within a federation, aiding		Tags are fundamental for discovery within a federation, aiding
	both servers and clients in identifying appropriate connections.		both servers and clients in identifying appropriate connections.
	- Server Tags: Tags associated with servers are used by clients		- Server Tags: Tags associated with servers are used by clients
	to discover servers offering the services they require.		to discover servers offering the services they require.
	Clients can search for servers based on tags that indicate		Clients can search for servers based on tags that indicate
	supported protocols or the type of data they handle, enabling		supported protocols or the type of data they handle, enabling
	skipping to change at line 942 ¶		skipping to change at line 942 ¶
	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 line 1159 ¶		skipping to change at line 1159 ¶
	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 line 1275 ¶		skipping to change at line 1275 ¶
	11. References		11. References
	11.1. Normative 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 line 1303 ¶		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>.
	11.2. Informative References		11.2. Informative References
			[eduGAIN] eduGAIN, "eduGAIN: Interfederation service connecting
			research and education identity federations worldwide",
			<https://edugain.org>.
	[EGIL] Sambruk, "EGIL – smidig hantering av skolans digitala		[EGIL] Sambruk, "EGIL – smidig hantering av skolans digitala
	användarkonton" [EGIL – manage your school's digital user		användarkonton" [EGIL – manage your school's digital user
	accounts efficiently], <https://sambruk.se/egil-dnp/>.		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		[Moa] Internetstiftelsens Federationer [The Swedish Internet
	Foundation], "Machine and Organization Authentication", 6		Foundation], "Machine and Organization Authentication", 6
	October 2025,		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]
	Skolverket [Swedish National Agency for Education], "API		Skolverket [Swedish National Agency for Education], "API
	för autentisering" [Authentication API for User		för autentisering" [Authentication API for User
	Management], commit f8c2e93, 4 September 2023,		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",
	<https://eidas.ec.europa.eu/>.
	[eduGAIN] eduGAIN, "eduGAIN: Interfederation service connecting
	research and education identity federations worldwide",
	<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 ===============
	{		{
End of changes. 21 change blocks.
	63 lines changed or deleted		63 lines changed or added
This html diff was produced by rfcdiff 1.48.