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 March 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 Behavior
7.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.2. Server Behavior
7.3. SPKI Generation . . . . . . . . . . . . . . . . . . . . . 24 7.3. SPKI Generation
7.4. Curl and Public Key Pinning . . . . . . . . . . . . . . . 25 7.4. Curl and Public Key Pinning
8. Deployments of the MATF Framework . . . . . . . . . . . . . . 25 8. Deployments of the MATF Framework
8.1. Skolfederation Moa . . . . . . . . . . . . . . . . . . . 25 8.1. Skolfederation Moa
8.2. Swedish National Agency for Education . . . . . . . . . . 26 8.2. Swedish National Agency for Education
8.3. Sambruk's EGIL . . . . . . . . . . . . . . . . . . . . . 26 8.3. Sambruk's EGIL
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations
9.1. Security Risks and Trust Management . . . . . . . . . . . 26 9.1. Security Risks and Trust Management
9.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.2. TLS
9.3. Federation Metadata Updates . . . . . . . . . . . . . . . 27 9.3. Federation Metadata Updates
9.4. Verifying the Federation Metadata Signature . . . . . . . 27 9.4. Verifying the Federation Metadata Signature
9.5. Time Synchronization . . . . . . . . . . . . . . . . . . 27 9.5. Time Synchronization
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. References
12. Normative References . . . . . . . . . . . . . . . . . . . . 28 11.1. Normative References
13. Informative References . . . . . . . . . . . . . . . . . . . 28 11.2. Informative References
Appendix A. JSON Schema for MATF Metadata . . . . . . . . . . . 29 Appendix A. JSON Schema for MATF Metadata
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Acknowledgements
Authors' Addresses
1. Introduction 1. Introduction
This document describes the Mutually Authenticating TLS in the This document describes the Mutually Authenticating TLS in
context of Federations (MATF) framework, developed to complement Federations (MATF) framework, developed to complement multilateral
multilateral SAML federations within the education sector. These Security Assertion Markup Language (SAML) federations within the
federations often rely on just-in-time provisioning, where user education sector. These federations often rely on just-in-time
accounts are created at first login based on information from the provisioning, where user accounts are created at first login based on
SAML assertion. However, educators need to be able to manage information from the SAML assertion. However, educators need to be
resources and classes before students access the service. MATF able to manage resources and classes before students access the
bridges this gap by using secure machine-to-machine communication, service. MATF bridges this gap by using secure machine-to-machine
enabling pre-provisioning of user information using a trust model and communication, enabling pre-provisioning of user information with a
metadata structure inspired by SAML federations. trust model and metadata structure inspired by SAML federations.
MATF is designed specifically for secure authentication in machine- MATF is designed specifically for secure authentication in machine-
to-machine contexts, such as RESTful APIs and service-to-service to-machine contexts, such as RESTful APIs (where "RESTful" refers to
interactions, and is not intended for browser-based authentication. the Representational State Transfer (REST) architecture) and service-
Because its applicability in a browser environment has not been to-service interactions, and is not intended for browser-based
studied, using MATF within browsers is not recommended. Doing so may authentication. Because its applicability in a browser environment
introduce risks that differ from those typically addressed by has not been studied, using MATF within browsers is not recommended.
standard browser security models. Doing so may introduce risks that differ from those typically
addressed by standard browser security models.
This work is not a product of the IETF, does not represent a This work is not a product of the IETF, does not represent a
standard, and has not achieved community consensus. It aims to standard, and has not achieved community consensus. It aims to
address specific federation challenges and provide a framework for address specific federation challenges and provide a framework for
secure communication. secure communication.
TLS is specified by the IETF TLS Working Group. TLS 1.3 is defined TLS is specified by the IETF TLS Working Group. TLS 1.3 is defined
in [RFC8446]. Additional information about the TLS Working Group is in [RFC8446]. Additional information about the TLS Working Group is
available at https://datatracker.ietf.org/wg/tls/about/ available at <https://datatracker.ietf.org/wg/tls/about/>.
(https://datatracker.ietf.org/wg/tls/about/).
1.1. Reserved Words 1.1. Reserved Words
This document is an Informational RFC, which means it offers This document is an Informational RFC, which means it offers
information and guidance but does not specify mandatory standards. information and guidance but does not specify mandatory standards.
Therefore, the keywords used throughout this document are for Therefore, the keywords used throughout this document are for
informational purposes only and do not imply any specific informational purposes only and do not imply any specific
requirements. requirements.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Terminology 1.2. Terminology
* Federation: A trusted network of entities that adhere to common Federation: A trusted network of entities that adhere to common
security policies and standards, using MATF for secure security policies and standards, using MATF for secure
communication. communication.
* Federation Member: An entity that has been approved to join the Federation Member: An entity that has been approved to join the
federation and can leverage MATF for secure communication with federation and can leverage MATF for secure communication with
other members. other members.
* Federation Operator: The entity responsible for the overall Federation Operator: The entity responsible for the overall
operation and management of the federation, including managing the operation and management of the federation, including managing the
federation metadata, enforcing security policies, and onboarding federation metadata, enforcing security policies, and onboarding
new members. new members.
* Federation Metadata: A cryptographically signed document Federation Metadata: A cryptographically signed document containing
containing information about all entities within the federation. information about all entities within the federation.
* Metadata Repository: A centralized repository storing information Metadata Repository: A centralized repository storing information
about all entities within the federation. about all entities within the federation.
* Member Metadata: Information about entities associated with a Member Metadata: Information about entities associated with a
specific member within the federation. specific member within the federation.
* Member Vetting: The process of verifying and approving applicants Member Vetting: The process of verifying and approving applicants to
to join the federation, ensuring they meet security and join the federation, ensuring they meet security and
trustworthiness requirements. trustworthiness requirements.
* Trust Anchor: The federation's root of trust is established by the Trust Anchor: The federation's root of trust is established by the
federation metadata signing key, which verifies the federation public key used to verify federation metadata signatures, which
metadata and allows participants to confidently rely on the allows participants to confidently rely on the information it
information it contains. 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, Regulation (EU) No 910/2014 (the
Identification, Authentication, and trust Services) regulation electronic identification, authentication, and trust services (eIDAS)
establishes a framework for electronic identification and trust Regulation) [eIDAS] establishes a regulatory framework for electronic
services for electronic transactions within the EU. This regulation identification and trust services for electronic transactions in the
provides a comprehensive set of standards for secure electronic internal market. The eIDAS Regulation provides a basis for cross-
interactions across member states. National federations within EU border recognition of notified electronic identification schemes and
member states adhere to these standards, ensuring interoperability for regulated trust services.
and mutual 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 260
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
the overall trust framework that enables secure and reliable the trust framework that enables secure and reliable communication
communication within the federation. Federation members submit within the federation.
member metadata to the federation. Both the authenticity of the
submitted member metadata and the submitting member need to be Federation members submit member metadata to the federation. As part
ensured by the federation. of federation operations, the federation MUST ensure the authenticity
and integrity of submitted member metadata and the authenticity of
the submitting member.
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 rejecting peers whose public key in the presented
certificate does not match a pin published in the federation
metadata.
* 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 federation metadata
members trust the information contained within the federation signature verification key, federation members trust the information
metadata. contained within the federation 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 metadata signature verification key, a critical component
distribution and verification. To achieve this, the federation's requiring secure distribution and verification. To achieve this, the
signing key is distributed using a JSON Web Key Set (JWKS) [RFC7517], signature verification key material is distributed using a JSON Web
providing a flexible framework for exposing multiple keys, including Key (JWK) Set [RFC7517], providing a flexible framework for exposing
the signing key and keys for rollover. This structured approach multiple public keys, including the current signature verification
ensures members can readily access the necessary keys for key and keys for rollover. This structured approach ensures members
verification purposes. can readily access the necessary keys for 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
vetting process is essential. Detailed vetting processes are beyond vetting process is essential. Detailed vetting processes are beyond
the scope of this document but can be guided by established the scope of this document but can be guided by established
frameworks such as eIDAS and eduGAIN. frameworks such as eIDAS and eduGAIN.
The following are non-normative references to established frameworks: The following are non-normative references to established frameworks:
* eIDAS: The eIDAS regulation establishes a framework for electronic * eIDAS: The eIDAS regulation can provide guidance for member
identification and trust services within the European Union. It vetting and identity assurance practices.
ensures secure and standardized electronic interactions across
member states, facilitating mutual recognition of electronic IDs.
Operators can refer to the eIDAS framework for guidance on robust
authentication and identity verification processes [eIDAS].
* eduGAIN: eduGAIN is an interfederation service connecting identity * eduGAIN: eduGAIN is an interfederation service connecting identity
federations worldwide, primarily within the research and education federations worldwide, primarily within the research and education
sectors. It ensures high standards of security and sector. eduGAIN documentation on participation requirements and
interoperability, allowing institutions to collaborate seamlessly. federation practices can inform member vetting processes
eduGAIN's processes for vetting, as described in [eduGAIN], can [eduGAIN].
serve as a useful reference.
3.5. Metadata Authenticity 3.5. Metadata Authenticity
Ensuring the authenticity of metadata is crucial for maintaining the Ensuring the authenticity of metadata is necessary for maintaining
security and trustworthiness of the MATF framework. The specific the security and trustworthiness of the MATF framework. This
mechanisms for ensuring metadata authenticity are beyond the scope of document specifies mechanisms for protecting and verifying the
this document and must be defined by the federation or regulatory authenticity of federation metadata, including JWS signing.
bodies. Operational procedures for authenticating member metadata submissions
are outside the scope of this document and are defined by the
federation operator or applicable regulatory bodies.
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: Access to repository management functions and
should have access to the repository. member metadata submission endpoints SHOULD be restricted to
authorized federation members.
* Regular Backups: Robust backup procedures ensure data recovery in * Regular backups: Robust backup procedures ensure data recovery in
case of unforeseen circumstances. case of unforeseen circumstances.
Before member metadata is added to the federation's repository, the Before member metadata is added to the federation's repository, the
submitted metadata MUST undergo a validation process. This process submitted metadata MUST undergo a validation process. This process
aims to verify the accuracy, completeness, and validity of the verifies the accuracy, completeness, and validity of the information
information provided by a member. The validation process MUST provided by a member. Metadata that does not pass validation MUST be
include, at a minimum but not limited to, the following checks: rejected. The validation process MUST include, at a minimum, the
following checks:
* Format Validation: The system checks if the submitted metadata * Format validation: The submitted metadata is checked to ensure
adheres to the defined schema and format specifications. that it conforms to the schema and format specifications defined
in Section 6.2 and Appendix A.
* Unique Entity ID: Checks are performed to ensure that the * Unique entity identifier: The submitted metadata is checked to
entity_id in the submitted metadata is not already registered by ensure that the entity_id value, as defined in Section 6.1.1, is
another member. Each entity within the federation must have a not already registered by another member.
unique identifier.
* Unique Public Key Pins: Public key pins [RFC7469] are used to * Unique public key pin digests: The submitted metadata is checked
identify client entities within the federation metadata during the to ensure that pins entries, as defined in Section 6.1.1.1, do not
connection validation process. When a server validates a client's introduce a digest value that is already registered to a different
TLS connection, it extracts the pin from the client's TLS entity_id. While reuse of the same digest value within the same
certificate and matches it against entries in the federation entity_id is permitted, uniqueness across different entities is
metadata. The requirements for pin uniqueness and usage are REQUIRED to prevent identity collisions and to support the
detailed in Section 6.1.1.1. resolution of a unique entity_id from a derived pin, as specified
in Section 5.2.
* Certificate Verification: The issuer certificates listed in the * Issuer certificate checks: The issuer certificates in issuers, as
metadata are validated to ensure that the algorithms used in the defined in Section 6.1.1, are checked to ensure that they are
certificates are well-known and secure, and that the certificates syntactically valid, not expired, and use algorithms that meet the
are currently valid and have not expired federation's security requirements.
* Tag Validation: Ensures that tags, as defined in Section 6.1.1.1 * Tag validation: Tags, as defined in Section 6.1.1.1, are checked
in the metadata adhere to the defined tag structure, verifying to ensure that they conform to the defined tag syntax. If the
both mandatory and optional tags. This process is crucial for federation defines an approved set of tag values, submitted tags
maintaining consistency and preventing unauthorized tags within a are checked to ensure that they are members of that set.
federation.
The MATF metadata repository serves as the vital foundation for The metadata repository provides a controlled location for storing
establishing trust and enabling secure communication within a MATF member metadata and for producing federation metadata for
environment. By providing a central, secure, and controlled distribution to federation members.
repository for critical information, the metadata repository empowers
members to confidently discover other trusted entities, and establish
secure connections for seamless interaction.
4.1. Metadata Submission 4.1. Metadata Submission
It is up to the federation to determine which channels should be It is up to the federation, through its governance and operational
provided to members for submitting their metadata to the metadata processes, to determine which channels are provided to members for
repository. Members typically have the option to either upload the submitting their metadata to the metadata repository. Members
metadata directly to the repository, provided such functionality typically have the option to upload the metadata directly to the
exists, or to send it to the federation operator through a designated repository, provided such functionality exists, or to send it to the
secure channel. If an insecure channel is used, additional measures federation operator through a designated secure channel. If an
MUST be taken to verify the authenticity and integrity of the insecure channel is used, additional measures MUST be taken to verify
metadata. Such measures may include verifying the checksum of the the authenticity and integrity of the metadata. Such measures may
metadata through another channel. The choice of submission channel include verifying the checksum of the metadata through another
may depend on factors such as the federation's guidelines and the channel. The choice of submission channel may depend on factors such
preferences of the member. as the federation's guidelines and the preferences of the member.
4.2. Maintaining Up-to-Date Metadata 4.2. Maintaining Up-to-Date Metadata
In a MATF federation, accurate and current metadata is essential for In a MATF federation, accurate and current metadata is essential for
ensuring secure and reliable communication between members. This ensuring secure and reliable communication between members. This
necessitates maintaining up-to-date metadata accessible by all necessitates maintaining up-to-date metadata accessible by all
members. members.
* Federation Metadata: The federation operator publishes a JWS * Federation metadata: The federation operator publishes a JWS
containing an aggregate of all entity metadata. This JWS serves containing an aggregate of all entity metadata. This JWS serves
as the source of truth for information about all members within as the source of truth for information about all members within
the federation. Outdated information in the JWS can lead to the federation. Outdated information in the JWS can lead to
issues like failed connections, discovery challenges, and issues such as 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 rules for metadata management that MUST include, at a
at a minimum but not limited to, expiration and cache time minimum, 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 rules and refresh their local metadata store
store according to the defined expiration and cache regulations. 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.
5. Authentication 5. Authentication
All communication established within the federation leverages mutual All communication established within the federation uses TLS 1.3
TLS authentication, as defined in [RFC8446]. This mechanism ensures [RFC8446] with mutual authentication. This mechanism ensures the
the authenticity of both communicating parties, establishing a robust 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 based on [RFC7469]. Public key
key pinning associates one or more unique public keys with each pinning associates one or more unique public keys with each
endpoint within the federation, stored in the federation metadata. federation endpoint, which are 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 presented certificate and verify that it matches the
public key pins retrieved from the federation metadata. preconfigured 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. Members can
federation can pin the public keys of entities in other federations, validate entities in other federations using pins published through
ensuring trust across boundaries. Unlike private certificate chains, shared metadata, ensuring trust across boundaries. Unlike private
which can become complex and difficult to manage across multiple certificate chains, which can become complex and difficult to manage
federations, public key pinning provides a straightforward mechanism across multiple federations, public key pinning provides a
for establishing trust. MATF interfederation addresses this straightforward mechanism for establishing trust. MATF
challenge by aggregating metadata from all participating federations interfederation addresses this challenge by aggregating metadata from
into a unified metadata repository. This shared metadata enables all participating federations into a unified metadata repository.
secure communication between entities in different federations, This shared metadata enables secure communication between entities in
ensuring consistent key validation and robust cross-federation trust different federations, ensuring consistent key validation and robust
and security. cross-federation trust and security.
5.1.1.2. Fortifying Security Against Threats 5.1.1.2. Fortifying Security Against Threats
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 In deployments that rely on certificate chains and certificate
revocation process can be complex and slow. This complexity arises revocation mechanisms, revocation can be complex and slow. This
because not only the compromised certificate but potentially multiple complexity arises because a certificate that can no longer be
certificates within the chain might need to be revoked and reissued. trusted, and potentially other certificates within the chain, may
Public key pinning mitigates this complexity by allowing clients to need to be revoked and reissued. Public key pinning mitigates this
explicitly trust a specific public key, thereby reducing dependency complexity by allowing clients to base trust decisions on pinned
on the entire certificate chain's integrity. public keys rather than on certificate chains.
If a leaf certificate is compromised within a MATF federation, the If a public key can no longer be trusted within a MATF federation,
revocation process involves removing the pin associated with the the associated pin is removed. Updated metadata is published. The
compromised certificate and publishing updated metadata that includes updated metadata includes a new pin corresponding to the public key
a new pin corresponding to the replacement certificate. This in the replacement certificate. This approach reduces reliance on
approach eliminates reliance on traditional certificate revocation certificate revocation mechanisms and shifts the trust relationship
mechanisms and shifts the trust relationship to the specific, updated 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 obtain public key pins from the federation
serving as pre-configured trust parameters, from the federation metadata. These pins serve as preconfigured trust parameters used
metadata. The federation MUST facilitate the discovery process, for validation, as specified in Section 5.3.
allowing peers to identify the relevant pins for each endpoint.
Information such as organization, tags, and descriptions within the
federation metadata supports this discovery.
Before initiating any connection, clients and servers MUST preload The federation MUST define discovery rules. These rules describe how
the designated pins from the federation metadata. This aligns with peers use federation metadata claims such as organization and tags to
the principle described in Section 2.7 of [RFC7469], which introduces identify relevant endpoints and their pins.
optional sources for pinning information, with the federation
metadata serving as one such source. Preloading pins restricts Before initiating or accepting a connection, a peer MUST preload the
connections to endpoints with matching public keys, mitigating the pins for the selected or authorized endpoints from its local metadata
risks posed by fraudulent certificates. store. Maintenance of the local metadata store, including refresh
behavior and expiry handling, is specified in Section 4.2.
To support peer identification, the preloaded state MUST enable
mapping from a derived pin to the corresponding entity_id. This may
be achieved by maintaining a local index that maps each preloaded pin
value to its associated entity_id.
A server MAY preload only the pins for clients that satisfy the
server's connection policy (for example, based on organization or
tags). Pin validation enforces the resulting policy as specified in
Section 5.3.
5.3. Verification of Received Certificates 5.3. Verification of Received Certificates
Upon connection establishment, both endpoints, client and server, Upon connection establishment, both endpoints MUST verify that the
must either leverage public key pinning or validate the received public key in the presented peer certificate matches a pin published
certificate against the published pins. Additionally, the federation in the federation metadata. This validation MAY be performed by the
metadata contains issuer information, which implementations MAY TLS stack or by application logic.
optionally use to verify certificate issuers. This step remains at
the discretion of each individual implementation.
In scenarios where a TLS session terminates independent of the In architectures where an intermediary terminates the TLS session,
application (e.g., via a reverse proxy), the termination point can pin validation MUST be performed by either the intermediary or the
utilize optional untrusted TLS client certificate authentication or application. If the application performs pin validation, the
validate the certificate issuer itself. Depending on the specific intermediary MUST forward the peer certificate or a derived pin to
implementation, pin validation can then be deferred to the the application. The application MUST be able to determine the peer
application itself, assuming the peer certificate is appropriately entity_id from the forwarded information and the federation metadata.
transferred (e.g., via an HTTP header). This resolution relies on the client pin digest uniqueness property
specified in Section 6.1.1.1.
If the intermediary performs pin validation, it MUST propagate the
peer certificate, the derived pin, or the entity_id to the
application to enable authorization.
The channel between the intermediary and the application MUST be
integrity protected and MUST provide endpoint authentication.
Any conveyed certificate, pin, or identity used for this purpose MUST
be derived directly from the TLS session. Implementations MUST NOT
accept these values from peer-supplied application data.
If the implementation permits disabling default CA-based certificate
chain validation, it SHOULD do so while still enforcing pin
validation. If chain validation is required, the trust anchors used
for certificate chain validation MUST be selected from the issuers
listed in the federation metadata.
If no matching pin is found for a peer, the connection MUST be
handled according to Section 5.4.
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 includes scenarios
ensures that only authorized and secure communication channels are where the derived pin does not match any preloaded pin or where the
peer identity cannot be resolved. This strict enforcement ensures
that only authorized and secure communication channels are
established within the federation. 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. Submitting updated metadata. When a certificate is scheduled for
federation members publish new metadata containing the pin rotation, the federation member submits updated metadata that
(SHA256 thumbprint) of the new public key. This ensures that the adds the pin for the new public key alongside the already
new pin is available to all federation members. published pins. The federation operator republishes the signed
federation metadata aggregate, making the new pin available to
all federation members.
2. Propagation Period: Allow time for the updated metadata to 2. Propagation period. Federation members MUST refresh their local
propagate throughout the federation before switching to the new metadata stores as specified in Section 4.2. The rotating member
certificate. This overlap period ensures that all nodes MUST allow sufficient time for peers to refresh and preload the
recognize the new pin and avoid connection issues. new pin before switching to the new certificate.
3. Switching to the New Certificate: After ensuring the new metadata 3. Switching to the new certificate. After the propagation period
has propagated, members switch to the new certificate in their has elapsed, the rotating member updates its TLS stack to present
TLS stack. the new certificate. This allows peers that have preloaded the
new pin to validate the rotated certificate.
4. Removing Old Pin: After successfully switching to the new 4. Removing the old pin. Following a successful transition, the
certificate, members must publish updated metadata that excludes rotating member MUST submit updated metadata excluding the old
the old pin. This final step ensures that only the current pin. The federation operator republishes the aggregate, ensuring
public keys are trusted. that only current public keys remain trusted within the
federation.
5.6. Implementation Guidelines 5.6. Implementation Guidelines
Public key validation MUST always be enforced, either through direct The placement of pin validation depends on the deployment
pinning or by deferring validation to the application. architecture. For clients, validation is typically performed by the
component initiating the TLS connection. For servers using an
For clients, public key validation typically occurs within the intermediary, the communication channel between the intermediary and
application handling the TLS session, either by enforcing direct the application MUST be integrity protected to prevent tampering with
pinning or by extracting and validating the public key against the forwarded peer identity material.
published pins.
For servers, validation depends on deployment. If the application
terminates the TLS session, it performs direct pinning or extracts
and validates the public key. If a reverse proxy terminates the TLS
session, it can enforce direct pinning or forward the certificate to
the application (e.g., via an HTTP header) for validation.
Implementations SHOULD, when possible, rely on libraries with native When an intermediary propagates peer identity material (for example,
support for pinning. Libcurl, for example, supports pinning via the the peer certificate, a derived pin, or the entity_id) using HTTP
PINNEDPUBLICKEY option. In Python, the cryptography library can header fields, those header fields are the mechanism used to fulfill
extract public keys, while the requests package together with urllib3 the requirements specified in Section 5.3. For each header field
can intercept certificates. Go provides crypto/tls and crypto/x509 name used for this purpose, the intermediary MUST remove any instance
for certificate inspection and public key extraction. In Java, of that header field received from the peer and then set the header
java.security.cert.X509Certificate enables public key extraction, field value itself. This ensures that the application only processes
while java.net.http.HttpClient allows pinning enforcement using a identity material derived directly from the TLS session, enabling the
custom SSLContext and TrustManager. The choice of library is left to application to match the peer to the federation metadata and apply
the discretion of each implementation. authorization policy based on federation metadata claims. Header
fields that are not used to convey identity material are unaffected
by this requirement. The communication channel between the
intermediary and the application MUST provide integrity protection
and endpoint authentication to prevent tampering with forwarded peer
identity material.
If bypassing standard CA validation is possible, it SHOULD be done. Implementations SHOULD, when possible, rely on libraries with built-
If not, the issuers listed in the federation metadata MUST be used as in support for pinning. libcurl, for example, supports pinning via
the trust store to validate certificate issuers while still enforcing the CURLOPT_PINNEDPUBLICKEY option. In Python, the cryptography
key pinning. Without issuer validation against issuers in metadata, library can extract public keys, and application code can compare the
self-signed certificates would not be accepted. These mechanisms derived pin to a configured value. Go provides crypto/tls and
ensure compatibility with existing TLS infrastructure while crypto/x509 for certificate inspection and public key extraction. In
maintaining strict security guarantees. Java, java.security.cert.X509Certificate enables public key
extraction, while java.net.http.HttpClient allows pinning enforcement
using a custom SSLContext and TrustManager. The choice of library is
left to the discretion of each implementation.
6. Federation Metadata 6. Federation Metadata
Federation metadata is published as a JWS [RFC7515]. The payload Federation metadata is published as a JSON Web Signature (JWS)
contains statements about federation members entities. [RFC7515]. The payload 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, such as organization and
The client then uses the selected server claims base_uri, pins and if tags. To establish a connection, the client uses the base_uri, pins,
needed issuers to establish a connection. and, if needed, issuers of the selected server.
Upon receiving a connection, a server validates the received client
certificate using the client's published pins. Server MAY also check
other claims such as organization and tags to determine if the
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: StringOrURI as defined in [RFC7519], Section 4.1.1. In
MATF, this value MUST be a URI.
- 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: The value MUST follow Semantic Versioning (see
(https://semver.org)). <https://semver.org>).
- Example: "1.0.0" - Example: "1.0.0"
* cache_ttl (OPTIONAL) * cache_ttl (OPTIONAL)
Specifies the duration in seconds for caching downloaded Specifies the duration in seconds for caching downloaded
federation metadata, allowing for independent caching outside of federation metadata, allowing for independent caching outside of
specific HTTP configurations, particularly useful when the specific HTTP configurations. This is particularly useful when
communication mechanism isn't HTTP-based. In the event of a the communication mechanism is not based on HTTP. In the event of
metadata publication outage, members can rely on cached metadata a metadata publication outage, members can rely on cached metadata
until it expires, as indicated by the exp claim in the JWS until it expires, as indicated by the exp claim in the JWS
payload, defined in Section 6.4. Once expired, metadata MUST no payload, defined in Section 6.1. Once expired, metadata MUST no
longer be trusted. If omitted, a mechanism to refresh metadata longer be trusted. If omitted, a mechanism to refresh metadata
MUST still exist to ensure the metadata remains valid. MUST still exist to ensure the metadata remains valid.
- Data Type: Integer - Data Type: Integer
- Syntax: Integer representing the duration in seconds. - Syntax: Integer representing the duration in seconds.
- Example: 3600 - Example: 3600
* entities (REQUIRED) * entities (REQUIRED)
skipping to change at page 16, line 42 skipping to change at line 785
communication within the federation. Each entity describes one or communication within the federation. Each entity describes one or
more endpoints owned by a member. An entity has the following more endpoints owned by a member. An entity has the following
properties: properties:
* entity_id (REQUIRED) * entity_id (REQUIRED)
A URI that uniquely identifies the entity. This identifier MUST A URI that uniquely identifies the entity. This identifier MUST
NOT collide with any other entity_id within the federation or NOT collide with any other entity_id within the federation or
within any other federation that the entity interacts with. within any other federation that the entity interacts with.
- Data Type: URI - Data Type: String
- Syntax: A valid URI. - Syntax: A URI as defined in [RFC3986].
- Example: "https://example.com" - Example: "https://example.com"
* organization (OPTIONAL) * organization (OPTIONAL)
A name identifying the organization that the entity's metadata A name identifying the organization that the entity's metadata
represents. The federation operator MUST ensure a mechanism is in represents. The federation operator MUST ensure that a mechanism
place to verify that the organization claim corresponds to the is in place to verify that the organization claim corresponds to
rightful owner of the information exchanged between nodes. This the rightful owner of the information exchanged between nodes.
is crucial for the trust model, ensuring certainty about the This is crucial for the trust model, ensuring certainty about the
identities of the involved parties. The federation operator identities of the involved parties. The federation operator
SHOULD choose an approach that best suits the specific needs and SHOULD choose an approach that best suits the specific needs and
trust model of the federation. trust model of the federation.
- Data Type: String - Data Type: String
- Syntax: A name identifying the organization represented by the - Syntax: A name identifying the organization represented by the
entity. entity.
- Example: "Example Org" - Example: "Example Org"
* issuers (REQUIRED) * issuers (REQUIRED)
A list of certificate issuers allowed to issue certificates for A list of certificate issuers allowed to issue certificates for
the entity's endpoints. For each issuer, the issuer's root CA the entity's endpoints. For each issuer, the issuer's root CA
certificate MUST be included in the x509certificate property, PEM- certificate MUST be included in the x509certificate property and
encoded. Certificate verification relies on public key pinning, be encoded using the Privacy-Enhanced Mail (PEM) format.
with the list of allowed issuers used only when a certificate Certificate verification relies on public key pinning, with the
chain validation mechanism is unavoidable. For self-signed list of allowed issuers used only when a certificate chain
validation mechanism is unavoidable. For self-signed
certificates, the certificate itself acts as its own issuer and 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: Array of Objects
- Syntax: Each object contains a issuer certificate, PEM-encoded. - Syntax: Each object contains an issuer certificate encoded as
PEM, as specified in [RFC7468]. The Base64 content MUST be
wrapped so that each line consists of exactly 64 characters,
except for the final line. In JSON text, line breaks in the
PEM value are represented using the "\n" escape sequence.
- 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 845
* 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 (REQUIRED for servers, OPTIONAL for clients)
The base URL of the server, which is required for endpoints that The base URL of the server. This claim is REQUIRED for server
describe server. endpoints. The value MUST be an absolute URI as defined in
Section 4.3 of [RFC3986]. The value serves as the base URI for
resolving relative references to server resources, as described in
Section 5 of [RFC3986].
- Data Type: URI - Data Type: String
- Syntax: A valid URL. - Syntax: An absolute URI as defined in Section 4.3 of [RFC3986]
that is used as a 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 19, line 13 skipping to change at line 906
ready to adopt these newer options for enhanced security. ready to adopt these newer options for enhanced security.
+ Data Type: String + Data Type: String
+ Syntax: The name of the algorithm. + Syntax: The name of the algorithm.
+ Example: "sha256" + Example: "sha256"
o digest (REQUIRED) o digest (REQUIRED)
The public key of the end-entity certificate converted to a The public key of the end-entity certificate, converted to a
Subject Public Key Information (SPKI) fingerprint, as Subject Public Key Information (SPKI) fingerprint, as
specified in Section 2.4 of [RFC7469]. For clients, the specified in Section 2.4 of [RFC7469]. For clients, the
digest MUST be globally unique for unambiguous digest value MUST be unique across entities in the
identification. However, within the same entity_id object, federation metadata to enable unambiguous identification of
the same digest MAY be assigned to multiple clients. the peer. Within the same entity, the same digest value MAY
be assigned to multiple clients.
+ Data Type: String + Data Type: String
+ Syntax: SPKI fingerprint. + Syntax: SPKI fingerprint.
+ Example: "+hcmCjJEtLq4BRPhrILyhgn98Lhy6DaWdpmsBAgOLCQ=" + Example: "+hcmCjJEtLq4BRPhrILyhgn98Lhy6DaWdpmsBAgOLCQ="
- Example: - Example:
"pins": [{ "pins": [{
skipping to change at page 20, line 12 skipping to change at line 955
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 can involve a dedicated
operation or service verifying tag validity and compliance with operation or service verifying tag validity and compliance with
the federation's regulations. Such validation ensures the federation's regulations. Such validation ensures
consistency within the federation by preventing the use of consistency within the federation by preventing the use of
unauthorized or irrelevant tags. unauthorized or irrelevant tags.
6.2. Metadata Schema 6.2. Metadata Schema
The MATF metadata schema is defined in Appendix A. This schema The MATF metadata schema is defined in Appendix A. This schema
specifies the format for describing entities involved in MATF and specifies the format for describing entities involved in MATF and
their associated information. their associated information.
Note: The schema in Appendix A is folded due to line length | Note: The schema in Appendix A is folded due to line length
limitations as specified in [RFC8792]. | limitations as specified in [RFC8792].
6.3. Example Metadata 6.3. Example Metadata
The following is a non-normative example of a metadata statement. The following is a non-normative example of a metadata statement.
Line breaks within the issuers' claim is for readability only. Line breaks in the example of the issuers claim are for readability
only.
{ {
"exp": 1755514949, "iat": 1755514949,
"iat": 1756119888, "exp": 1756119888,
"iss": "https://federation.example.org", "iss": "https://federation.example.org",
"version": "1.0.0", "version": "1.0.0",
"cache_ttl": 3600, "cache_ttl": 3600,
"entities": [{ "entities": [{
"entity_id": "https://example.com", "entity_id": "https://example.com",
"organization": "Example Org", "organization": "Example Org",
"issuers": [{ "issuers": [{
"x509certificate": "-----BEGIN CERTIFICATE-----\nMIIDDDCCAf "x509certificate": "-----BEGIN CERTIFICATE-----\nMIIDDDCCAf
SgAwIBAgIJAIOsfJBStJQhMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV\nBAM SgAwIBAgIJAIOsfJBStJQhMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV\nBAM
MEHNjaW0uZXhhbXBsZS5jb20wHhcNMTcwNDA2MDc1MzE3WhcNMTcwNTA2MD MEHNjaW0uZXhhbXBsZS5jb20wHhcNMTcwNDA2MDc1MzE3WhcNMTcwNTA2MD
skipping to change at page 22, line 8 skipping to change at line 1043
"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: Federations may need to transition to post-quantum (PQ) cryptographic
algorithms for federation metadata signatures and for endpoint
certificate public key types. MATF can accommodate such transitions
through key rollover and by updating published pins as new key types
are deployed.
The following JWS Protected Header parameters are REQUIRED:
* alg (Algorithm) * alg (Algorithm)
Identifies the algorithm used to generate the JWS signature Identifies the algorithm used to generate the JWS signature
[RFC7515], Section 4.1.1. [RFC7515], Section 4.1.1.
* kid (Key Identifier) * kid (Key Identifier)
Identifies the signing key in the key set used to sign the JWS Identifies the key in the issuer's key set that was used to
[RFC7515], Section 4.1.4. generate the JWS signature [RFC7515], Section 4.1.4.
6.5. Example Signature Protected Header 6.5. Example Signature Protected Header
The following is a non-normative example of a signature protected The following is a non-normative example of a signature protected
header. header.
{ {
"alg": "ES256", "alg": "ES256",
"kid": "c2fb760e-f4b6-4f7e-b17a-7115d2826d51" "kid": "c2fb760e-f4b6-4f7e-b17a-7115d2826d51"
} }
7. Example Usage Scenarios 7. Example Usage Scenarios
The examples in this section are non-normative. The examples in this section are non-normative and illustrate the
procedures described in Section 5.2 and Section 5.3.
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 deployed. Both clients and servers
servers are registered members of the federation. In this scenario, are registered members of the federation. In this scenario, clients
clients aim to manage cross-domain user accounts within the service. manage cross-domain user accounts using SS 12000:2018, which is a
The standard used for account management is SS 12000:2018 (i.e., a System for Cross-domain Identity Management (SCIM) extension.
SCIM extension).
+---------------------------------------------+ +------------------------------------------------------+
| | | |
| Federation Metadata | | Federation Metadata |
| | | |
+---+--------------------------+--------------+ +-----+-------------------------------+----------------+
| | | |
(A) (A) (A) (A)
| | | |
v v v v
+---+----+ +------------+--------------+ +-----------+ +--------------------------------+
|Local MD| | Local MD | | Local MD | | Local MD |
+---+----+ +----+------------- ---+----+ +-----+-----+ +------+---------------------+---+
| | | | | |
(B) (C) (F) (B) (C) (F)
| | | | | |
v v v v v v
+---+----+ +----+---+ +----+---+ +-----------+ +--------------+ +-------+
| | | | | | | | | | | |
| Client | | Reverse| | App | | Client +---(D)-->+ Intermediary +---(E)-->+ App |
| +--(D)-->+ Proxy +--(E)-->+ | | | | | | |
| | | | | | +-----------+ +--------------+ +-------+
| | | | | |
+--------+ +--------+ +--------+
A. Entities collect member metadata from the federation metadata. A. Clients and servers retrieve federation metadata and update their
local metadata stores as described in Section 4.2.
B. The client pins the server's public key pins. B. The client selects a server endpoint based on metadata claims and
preloads the pins published for that endpoint.
C. The reverse proxy trust anchor is setup with the clients' C. If certificate chain validation is performed, the TLS client or
certificate issuers. intermediary configures its trust store using the issuers listed
in the federation metadata for the selected entity.
D. The client establishes a connection with the server using the D. The client initiates a TLS connection to the selected base_uri
base_uri from the federation metadata. and presents its client certificate.
E. The reverse proxy forwards the client certificate to the E. If an intermediary terminates the TLS session, it forwards
application. identity material derived from the TLS session to the application
as described in Section 5.3 and Section 5.6.
F. The application converts the certificate to a public key pin and F. The application maps the derived pin to a matching metadata entry
checks the federation metadata for a matching pin. The entity's and uses the associated entity_id for identification and
entity_id should be used as an identifier. authorization.
7.1. Client 7.1. Client Behavior
A certificate is issued for the client and the issuer is published in A certificate is issued for the client. The client's certificate
the federation metadata together with the client's certificate public issuer and public key pins are published in the federation metadata.
key pins
When the client wants to connect to a remote server (identified by an
entity identifier) the following steps need to be taken:
1. Find possible server candidates by filtering the remote entity's When a client initiates a connection to a remote server (identified
list of servers based on tags. by the server's entity_id), the following steps are performed:
2. Connect to the server URI. Include the entity's list of 1. The client selects a server endpoint from the identified entity's
certificate issuers in the TLS clients list of trusted CAs, or servers list whose tags match the required service capabilities.
trust the listed pins explicitly.
3. If pinning is not used during the TLS handshake, the client MUST 2. The client preloads the selected endpoint's pins from its local
perform a post-connection validation against the entity's metadata store. If certificate chain validation is performed,
published pins. the client also loads the issuers listed for the entity.
4. Commence transactions. 3. The client initiates a TLS connection to the selected endpoint
using the base_uri and presents its client certificate.
7.2. Server 4. The client performs pin validation for the server certificate as
described in Section 5.3. This validation may be performed by
the TLS stack during the handshake or by application logic after
the connection is established, but it completes before any
application data is exchanged.
A certificate is issued for the server and the issuer is published in 5. If validation succeeds, the client proceeds with application
the federation metadata together with the server's name and transactions.
certificate public key pin.
When the server receives a connection from a remote client, the 7.2. Server Behavior
following steps need to be taken:
1. Populate list of trusted CAs using all known entities' published To accept inbound connections from a client, the server uses
issuers and required TLS client certificate authentication, or federation metadata to perform pin validation of the public key in
configure optional untrusted TLS client certificate the presented client certificate. The federation metadata publishes
authentication (e.g., optional_no_ca). client public key pins and, for deployments that perform certificate
chain validation, the allowed issuers.
2. Once a connection has been accepted, validate the received client When the server receives a TLS connection attempt from a remote
certificate using the client's published pins. client, the following steps are performed:
3. Commence transactions. 1. The server is configured to request or require a client
certificate. If certificate chain validation is performed, the
trust store is populated using the issuers published in the
federation metadata. Otherwise, the server requests a client
certificate without issuer validation (for example,
optional_no_ca).
2. The server can prefilter the federation metadata to identify the
set of clients it is willing to communicate with and preload only
the pins for those clients, as described in Section 5.2.
3. After the TLS handshake completes, the server derives the
client's pin from the presented certificate and matches it
against the preloaded pins. When a match is found, the server
determines the client's entity_id from the corresponding metadata
entry.
4. If pin validation succeeds, the server proceeds with application
transactions. If pin validation fails, the server terminates the
connection.
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.
readability only.
curl --cert client.pem --key client.key --pinnedpubkey 'sha256//0Ok curl --cert client.pem --key client.key \
2aNfcrCNDMhC2uXIdxBFOvMfEVtzlNVUT5pur0Dk=' https://host.example.com --pinnedpubkey \
'sha256//0Ok2aNfcrCNDMhC2uXIdxBFOvMfEVtzlNVUT5pur0Dk=' \
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 was 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.
Metadata validation is necessary to maintain a stable federation. Metadata validation is necessary to maintain a stable federation.
While manual validation may be sufficient in the early stages of a While manual validation may be sufficient in the early stages of a
federation, it becomes unmanageable as the federation scales. federation, it becomes unmanageable as the federation scales.
Without an automated validation process, incorrect metadata uploaded Without an automated validation process, incorrect metadata uploaded
by members is likely to go undetected, leading to publication of by members is likely to go undetected, leading to publication of
incorrect metadata. incorrect metadata.
The signing key is needed to sign metadata. Under fallback The federation metadata signing private key is required to publish
scenarios, even if metadata can be retrieved from elsewhere, without signed federation metadata. In fallback scenarios, federation
access to the signing key, it is impossible to publish metadata. metadata may be retrieved from an alternate location, but publishing
Therefore, secure and redundant management of the signing key is updated federation metadata requires access to the signing private
crucial to enable fallback mechanisms and ensure reliable signing and key. Therefore, secure and redundant management of the signing
distribution of metadata. If metadata is retrieved from a location private key is necessary to support fallback mechanisms and reliable
other than the official repository, it is mandatory to validate its publication. Recipients MUST validate the JWS signature using the
signature to maintain trust and ensure the authenticity of the federation signature verification key before using federation
metadata. metadata, regardless of where it is obtained.
8.2. Swedish National Agency for Education 8.2. Swedish National Agency for Education
The Swedish National Agency for Education [SkolverketMATF] leverages The Swedish National Agency for Education [SkolverketMATF] leverages
MATF within its digital national test platform to establish a robust MATF within its digital national test platform to establish a robust
authentication mechanism. The platform utilizes an API for client authentication mechanism. The platform utilizes an API for client
verification prior to secure data transfer to the agency's test verification prior to secure data transfer to the agency's test
service, ensuring the integrity and confidentiality of educational service, ensuring the integrity and confidentiality of educational
data. data.
skipping to change at page 26, line 37 skipping to change at line 1283
in enhancing security and interoperability within the educational in enhancing security and interoperability within the educational
sector. sector.
9. Security Considerations 9. Security Considerations
9.1. Security Risks and Trust Management 9.1. Security Risks and Trust Management
The security risks associated with the MATF framework are confined to The security risks associated with the MATF framework are confined to
each individual federation. Both the federation operator and each individual federation. Both the federation operator and
federation members share the responsibility of maintaining trust and federation members share the responsibility of maintaining trust and
security within the federation. Proper handling and management of security. Proper handling of metadata and thorough vetting of
metadata, as well as thorough vetting of federation members, are members are crucial to sustaining this trust.
crucial to sustaining this trust and security. Each federation
operates within a trust framework, which includes its own security Deployments that terminate a session at an intermediary and convey
policies and procedures to ensure the integrity and reliability of identity material to an application introduce a critical trust
the federation. boundary. If the intermediary is compromised or fails to properly
sanitize inbound headers, an attacker could spoof a peer's entity_id.
Therefore, intermediaries that convey identity material to an
application MUST comply with the requirements in Section 5.6.
Implementations SHOULD avoid logging conveyed certificates, pins, or
identity values unless required for diagnostics to prevent the
accidental exposure of session-specific identity material.
9.2. TLS 9.2. TLS
The security considerations for TLS 1.3 are detailed in Section 10 The security considerations for TLS 1.3 are detailed in Section 10
and Appendices C, D, and E of [RFC8446]. and Appendices C, D, and E of [RFC8446].
9.3. Federation Metadata Updates 9.3. Federation Metadata Updates
Regularly updating the local copy of federation metadata is essential Regularly updating the local copy of federation metadata is essential
for accessing the latest information about active entities, current for accessing the latest information about active entities, current
public key pins [RFC7469], and valid issuer certificates. The use of public key pins [RFC7469], and valid issuer certificates. The use of
outdated metadata may expose systems to security risks, such as outdated metadata may expose systems to security risks, such as
interaction with revoked entities or acceptance of manipulated data. interaction with revoked entities or acceptance of manipulated data.
9.4. Verifying the Federation Metadata Signature 9.4. Verifying the Federation Metadata Signature
Ensuring data integrity and security within the MATF framework relies Ensuring data integrity and security within the MATF framework relies
on verifying the signature of downloaded federation metadata. This on verifying the signature of downloaded federation metadata. This
verification process confirms the data's origin, ensuring it comes verification confirms the origin of the metadata by validating the
from the intended source and has not been altered by unauthorized JWS signature using the federation signature verification key trusted
parties. By establishing the authenticity of the metadata, trust is by the recipient. It also confirms that the signed content has not
maintained in the information it contains, including valid member been altered by unauthorized parties. By verifying the signature,
public key pins and issuer certificates. To achieve a robust trust is maintained in the integrity of the information used for
implementation, it is crucial to consider the security aspects validation, including member public key pins and issuer certificates.
outlined in [RFC7515], which describes security considerations To achieve a robust implementation, it is important to consider the
related to algorithm selection, key compromise, and signature security aspects outlined in [RFC7515], which describes security
integrity. considerations related to algorithm selection, key compromise, and
signature integrity.
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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
April 2015, <https://www.rfc-editor.org/info/rfc7468>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning [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 46 skipping to change at line 1381
<https://www.rfc-editor.org/info/rfc7518>. <https://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
2015, <https://www.rfc-editor.org/info/rfc7638>. 2015, <https://www.rfc-editor.org/info/rfc7638>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
13. Informative References 11.2. Informative References
[EGIL] Sambruk, "EGIL - manage your school's digital user [eduGAIN] eduGAIN, "eduGAIN: Interfederation service connecting
accounts efficiently", 2022, research and education identity federations worldwide",
<https://sambruk.se/egil-dnp/>. <https://edugain.org>.
[Moa] The Swedish Internet Foundation, "Machine and Organization [EGIL] Sambruk, "EGIL – smidig hantering av skolans digitala
Authentication", 2022, användarkonton" [EGIL – manage your school's digital user
accounts efficiently], <https://sambruk.se/egil-dnp/>.
[eIDAS] European Union, "Regulation (EU) No 910/2014 of the
European Parliament and of the Council of 23 July 2014 on
electronic identification and trust services for
electronic transactions in the internal market", Official
Journal of the European Union L 257/73,
ELI http://data.europa.eu/eli/reg/2014/910/oj, 23 July
2014, <https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng>.
[Moa] Internetstiftelsens Federationer [The Swedish Internet
Foundation], "Machine and Organization Authentication", 6
October 2025,
<https://wiki.federationer.internetstiftelsen.se/x/ <https://wiki.federationer.internetstiftelsen.se/x/
LYA5AQ>. LYA5AQ>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and "Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>. <https://www.rfc-editor.org/info/rfc8792>.
[SkolverketMATF] [SkolverketMATF]
Swedish National Agency for Education, "Authentication API Skolverket [Swedish National Agency for Education], "API
for User Management", 2023, för autentisering" [Authentication API for User
Management], commit f8c2e93, 4 September 2025,
<https://github.com/skolverket/dnp- <https://github.com/skolverket/dnp-
usermanagement/blob/main/authentication-api/README.md>. usermanagement/blob/main/authentication-api/README.md>.
[eIDAS] European Commission, "eIDAS: electronic Identification,
Authentication and trust Services", 2014,
<https://eidas.ec.europa.eu/>.
[eduGAIN] GEANT Association, "eduGAIN: Interfederation service
connecting research and education identity federations
worldwide", 2023, <https://edugain.org>.
Appendix A. JSON Schema for MATF Metadata Appendix A. JSON Schema for MATF Metadata
The following JSON Schema defines the structure of MATF metadata. It The following JSON Schema defines the structure of MATF metadata. It
conforms to draft 2020-12 of the JSON Schema standard. conforms to draft 2020-12 of the JSON Schema standard.
Version: 1.0.0 Version: 1.0.0
=============== NOTE: '\\' line wrapping per RFC 8792 =============== =============== NOTE: '\\' line wrapping per RFC 8792 ===============
{ {
skipping to change at page 34, line 25 skipping to change at line 1658
"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. 150 change blocks. 
527 lines changed or deleted 631 lines changed or added

This html diff was produced by rfcdiff 1.48.