RFC 9932

Mutually Authenticating TLS in the Context of Federations

📅 published April 2026, from ietf

RFC 9932: Mutually Authenticating TLS in the Context of Federations ✨

  • Number: RFC 9932
  • Title: Mutually Authenticating TLS in the Context of Federations
  • Authors: S. Halén (The Swedish Internet Foundation) and J. Schlyter (Kirei AB) 👑
  • Stream: Independent Submission
  • Category: Informational
  • ISSN: 2070-1721
  • Date: April 2026
  • Obsoletes / updates: the title block doesn't list any RFCs this one obsoletes or updates 🙈

Abstract

okay so this is an Informational Independent Submission to the RFC Series, and it's all about using TLS 1.3 to do machine-to-machine mutual authentication inside federations 🔐 This memo is not a standard. It doesn't change the TLS protocol at all, and it doesn't need any changes to common TLS libraries either. TLS itself is specified and standardized by the IETF's TLS Working Group 💜

The framework is all about interoperable trust management for federated machine-to-machine communication ✨ It brings in a centrally managed trust anchor and a controlled metadata publication process, so only authorized members can be identified inside the federation. These pieces help with unambiguous entity identification and lower the risk of impersonation, which keeps interactions secure and policy-aligned even when they cross organizational boundaries 🫶

Status of This Memo

this document is not an Internet Standards Track specification 🌸 It's published purely for informational purposes.

It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment 🙈 Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard. See Section 2 of RFC 7841 for that.

For info about the current status of this document, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9932 🦋

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 💅

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜

Table of Contents

   1.  Introduction
     1.1.  Reserved Words
     1.2.  Terminology
   2.  Diverse Design Patterns
   3.  Trust Model
     3.1.  Role of the Federation Operator
     3.2.  Federation Members' Responsibilities
     3.3.  Chain of Trust
     3.4.  Member Vetting
     3.5.  Metadata Authenticity
   4.  Metadata Repository
     4.1.  Metadata Submission
     4.2.  Maintaining Up-to-Date Metadata
   5.  Authentication
     5.1.  Public Key Pinning
       5.1.1.  Benefits of Public Key Pinning
     5.2.  Pin Discovery and Preloading
     5.3.  Verification of Received Certificates
     5.4.  Failure to Validate
     5.5.  Certificate Rotation
     5.6.  Implementation Guidelines
   6.  Federation Metadata
     6.1.  Federation Metadata Claims
       6.1.1.  Entities
     6.2.  Metadata Schema
     6.3.  Example Metadata
     6.4.  Metadata Signing
     6.5.  Example Signature Protected Header
   7.  Example Usage Scenarios
     7.1.  Client Behavior
     7.2.  Server Behavior
     7.3.  SPKI Generation
     7.4.  Curl and Public Key Pinning
   8.  Deployments of the MATF Framework
     8.1.  Skolfederation Moa
     8.2.  Swedish National Agency for Education
     8.3.  Sambruk's EGIL
   9.  Security Considerations
     9.1.  Security Risks and Trust Management
     9.2.  TLS
     9.3.  Federation Metadata Updates
     9.4.  Verifying the Federation Metadata Signature
     9.5.  Time Synchronization
   10. IANA Considerations
   11. References
     11.1.  Normative References
     11.2.  Informative References
   Appendix A.  JSON Schema for MATF Metadata
   Acknowledgements
   Authors' Addresses

1. Introduction 🧚

this doc describes the Mutually Authenticating TLS in Federations (MATF) framework 💖 It was built to complement multilateral Security Assertion Markup Language (SAML) federations in the education sector. Those federations often rely on just-in-time provisioning, where a user account gets created at first login based on the info in the SAML assertion. The catch is that educators need to manage resources and classes before students ever touch the service 😭 MATF fills that gap with secure machine-to-machine communication, which lets user info get pre-provisioned. It uses a trust model and metadata structure inspired by SAML federations ✨

MATF is designed specifically for secure authentication in machine-to-machine contexts, like RESTful APIs (where "RESTful" refers to the Representational State Transfer (REST) architecture) and service-to-service interactions. It is not meant for browser-based authentication 🙅‍♀️ Because its applicability in a browser environment hasn't been studied, using MATF within browsers is not recommended. Doing so may bring risks that differ from the ones standard browser security models usually handle 👀

This work is not a product of the IETF, isn't a standard, and hasn't reached community consensus. It aims to tackle specific federation challenges and give a framework for secure communication 🌈

TLS is specified by the IETF TLS Working Group. TLS 1.3 is defined in [RFC8446]. More info about the TLS Working Group lives at <https://datatracker.ietf.org/wg/tls/about/> 🦋

1.1. Reserved Words

this is an Informational RFC, which means it offers information and guidance but doesn't specify mandatory standards 💅 So the keywords used throughout this document are for informational purposes only, and they don't imply any specific requirements 🙈

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🔥

1.2. Terminology

Federation: a trusted network of entities that follow common security policies and standards, using MATF for secure communication 🫶

Federation Member: an entity that has been approved to join the federation and can use MATF for secure communication with other members 🌸

Federation Operator: the entity in charge of the overall operation and management of the federation. That includes managing the federation metadata, enforcing security policies, and onboarding new members 👑

Federation Metadata: a cryptographically signed document holding information about all entities within the federation 🔐

Metadata Repository: a centralized repository that stores information about all entities within the federation 🗂️

Member Metadata: information about the entities tied to one specific member within the federation 🧸

Member Vetting: the process of verifying and approving applicants to join the federation, making sure they meet security and trustworthiness requirements 🕵️‍♀️

Trust Anchor: the federation's root of trust, established by the public key used to verify federation metadata signatures. This is what lets participants confidently rely on the info inside 💎

2. Diverse Design Patterns 🌈

MATF is built to be flexible and adaptable to the different needs of different federations 🦋 Federations can vary a lot in size, scope, and security requirements, so it's hard to prescribe a one-size-fits-all trust framework and security measures 🙃

For example, in the European Union, Regulation (EU) No 910/2014 (the electronic identification, authentication, and trust services (eIDAS) Regulation) [eIDAS] sets up a regulatory framework for electronic identification and trust services for electronic transactions in the internal market. The eIDAS Regulation provides a basis for cross-border recognition of notified electronic identification schemes and for regulated trust services 🇪🇺

National federations, like the ones in education or healthcare, often have their own trust frameworks and security measures tailored to their specific needs ✨ These federations may use existing national identification systems or other trusted credentials to establish member identities and keep interactions secure 🛡️

Organizations can also set up their own federations, tailored to their own security requirements and trust models. A private business federation, for instance, might set up its own vetting processes and trust framework based on what its business does and how sensitive the data it exchanges is 💼

Because federations get to tailor their trust frameworks and security measures, MATF can support a wide range of use cases 🎀 That flexibility is crucial for handling the different requirements and challenges federations face, and it keeps trust-building and secure communication both safe and adaptable 💖

3. Trust Model 💜

The MATF framework runs on a trust model that's central to its design and how it works. This section walks through the key pieces of that trust model and what they mean for federation members and the federation operator 🧠

3.1. Role of the Federation Operator 👑

The federation operator plays a critical role in the MATF framework. This entity is responsible for:

  • Managing the central trust anchor, which is used to establish trust across different domains within the federation.
  • Vetting federation members to make sure they meet the required standards and policies.
  • Maintaining and securing the federation metadata, which includes public key pins [RFC7469], issuer certificates, and other essential info.

Also, the federation operator SHOULD develop their own threat models to proactively spot potential risks and threats 🕵️‍♀️ This means looking at the operating environment, weighing both internal and external threats, and figuring out how vulnerabilities could be exploited. The goal of the threat model is to help the federation operator come up with mitigation strategies for the risks they identify 🛡️

The security and stability of the federation depend on the integrity and competence of the federation operator. Members have to be able to fully trust this central authority, because its role is essential to keeping the federation reliable and secure 💅

3.2. Federation Members' Responsibilities 🫶

Federation members share the responsibility for keeping trust and security up across the federation 🌸

Their responsibilities include:

  • Following the federation's security policies and procedures.
  • Making sure their metadata submissions are accurate and timely.
  • Cooperating with the federation operator's vetting and security measures.

When members do all of this, they help sustain the trust framework that makes secure and reliable communication possible across the federation 🦋

Federation members submit member metadata to the federation. As part of federation operations, the federation MUST ensure the authenticity and integrity of submitted member metadata, and the authenticity of the submitting member. 🔥 That's the big one, bestie, so don't skip it 🥹

To be continued in part 2 🎀💜

3.3. Chain of Trust 🔗✨

okay so every federation runs inside its own trust framework, bestie 🫶 and that framework has its own security policies and procedures. The whole goal is keeping communication inside the federation safe: integrity, authenticity, AND confidentiality. no cap, that's the security trifecta 💅 The key pieces of this framework are:

  • Public key pinning [RFC7469] and preloading to stop on-path attacks 🛡️ A peer gets rejected if the public key in its presented certificate doesn't match a pin published in the federation metadata. so sus peers are out 🙅‍♀️
  • Regular updates and verification of federation metadata, so nobody is using outdated or compromised info 🧹

The federation operator is the one who aggregates, signs, and publishes the federation metadata 👑 It combines every member's member metadata with extra federation-specific info. When members trust the federation and its federation metadata signature verification key, they're also trusting everything inside the federation metadata. it's giving teamwork 🤝

The trust anchor for the whole federation is the federation metadata signature verification key 🔑 This is a seriously critical piece, so it needs to be distributed and verified securely. To do that, the signature verification key material gets shared using a JSON Web Key (JWK) Set [RFC7517]. This is super flexible because a JWK Set can expose multiple public keys at once, like the current signature verification key plus keys for rollover 🌈 That means members can easily grab the keys they need for verification. so organized 🎀

There's also an extra layer of security with thumbprint verification [RFC7638] 🦋 Federation members can check the key's authenticity on their own by comparing the calculated cryptographic thumbprint of the key with a trusted value, which makes sure it hasn't been tampered with. The really iconic part is that this check can happen through channels separate from the JWK Set itself. so there's no single point of failure, no reliance on just one distribution mechanism 😤✨

This whole trust framework is essential for smooth, secure interoperability across different trust domains within the federation 🌸

3.4. Member Vetting 🕵️‍♀️

To keep the MATF framework secure and intact, member vetting is essential 💜 Detailed vetting processes are out of scope for this document, but established frameworks like eIDAS and eduGAIN can guide them.

The following are non-normative references to those established frameworks 📚

  • eIDAS: The eIDAS regulation can give guidance for member vetting and identity assurance practices 🪪
  • eduGAIN: eduGAIN is an interfederation service connecting identity federations worldwide, mostly in the research and education sector 🎓 Its documentation on participation requirements and federation practices can inform member vetting processes [eduGAIN].

3.5. Metadata Authenticity 📜

Making sure metadata is authentic is necessary for keeping the MATF framework secure and trustworthy 🫧 This document specifies the mechanisms for protecting and verifying the authenticity of federation metadata, including JWS signing. Operational procedures for authenticating member metadata submissions are outside this document's scope. They're defined by the federation operator or applicable regulatory bodies 🏛️

4. Metadata Repository 🗄️✨

The MATF metadata repository is basically a central vault 🔐 It securely stores all the information about every participating federation member and their respective entities. This information, known as federation metadata, is presented as a JSON Web Signature (JWS) [RFC7515] so its authenticity and integrity can be verified 🧾

The metadata repository gets stringent security measures to protect the integrity of what's stored in it. This MAY involve:

  • Member management: The federation operator can centrally enforce security policies and vet new members before they're added to the repository 🙋‍♀️
  • Access controls: Access to repository management functions and member metadata submission endpoints SHOULD be restricted to authorized federation members 🚪
  • Regular backups: Robust backup procedures make sure data can be recovered in case of unforeseen circumstances 💾

Before member metadata gets added to the federation's repository, the submitted metadata MUST undergo a validation process 🧐 This process checks the accuracy, completeness, and validity of the info a member provided. Metadata that doesn't pass validation MUST be rejected 🚫 The validation process MUST include, at a minimum, the following checks:

  • Format validation: The submitted metadata is checked to make sure it conforms to the schema and format specifications defined in Section 6.2 and Appendix A 📐
  • Unique entity identifier: The submitted metadata is checked to make sure the entity_id value, as defined in Section 6.1.1, isn't already registered by another member 🆔
  • Unique public key pin digests: The submitted metadata is checked to make sure pins entries, as defined in Section 6.1.1.1, don't introduce a digest value that's already registered to a different entity_id. Reusing the same digest value within the same entity_id is allowed, but uniqueness across different entities is REQUIRED to prevent identity collisions and to support resolving a unique entity_id from a derived pin, as specified in Section 5.2 🧩
  • Issuer certificate checks: The issuer certificates in issuers, as defined in Section 6.1.1, are checked to make sure they're syntactically valid, not expired, and use algorithms that meet the federation's security requirements 🔍
  • Tag validation: tags, as defined in Section 6.1.1.1, are checked to make sure they follow the defined tag syntax. If the federation defines an approved set of tag values, submitted tags are checked to make sure they're members of that set 🏷️

The metadata repository provides a controlled location for storing member metadata and for producing federation metadata for distribution to federation members 💖

4.1. Metadata Submission 📤

It's up to the federation, through its governance and operational processes, to decide which channels members get for submitting their metadata to the metadata repository 🗳️ Members typically can upload metadata directly to the repository, if that functionality exists, or send it to the federation operator through a designated secure channel. If an insecure channel is used, additional measures MUST be taken to verify the authenticity and integrity of the metadata 🙅‍♀️ Those measures may include verifying the checksum of the metadata through another channel. The choice of submission channel can depend on things like the federation's guidelines and the member's preferences 🎀

4.2. Maintaining Up-to-Date Metadata ⏰

In a MATF federation, accurate and current metadata is essential for secure and reliable communication between members 💅 That means up-to-date metadata has to be maintained and accessible to all members.

  • Federation metadata: The federation operator publishes a JWS containing an aggregate of all entity metadata. This JWS is the source of truth for info about all members in the federation 👑 Outdated info in the JWS can lead to failed connections, discovery challenges, and potential security risks 💀
  • Local metadata: Each member keeps a local metadata store with info about the other members in the federation. This info is retrieved from the federation's publicly accessible JWS. Outdated data in the local store can make it harder for a member to discover and connect with other relevant entities 🙈

The following outlines the procedures for keeping metadata up to date:

  • Federation Operator Role: The federation operator plays a crucial part in maintaining data integrity within the federation 🧠 Their responsibilities include:
    • Defining rules for metadata management that MUST include, at a minimum, expiration and cache time management 📅
    • Implementing mechanisms to update the published federation metadata, making sure it adheres to the expiration time (exp as defined in Section 6.1) and cache TTL (cache_ttl as defined in Section 6.1) specifications ⏳
  • Member Responsibility: Members must follow the federation's metadata management rules and refresh their local metadata store according to the defined expiration and cache regulations 🔄

By sticking to these responsibilities, the federation makes sure info stays valid for the defined timeframe and that caching mechanisms use up-to-date data effectively 🌟

5. Authentication 🪪💫

All communication established within the federation uses TLS 1.3 [RFC8446] with mutual authentication 🤝 This mechanism makes sure both communicating parties are authentic, which builds a robust foundation for secure data exchange 💪

5.1. Public Key Pinning 📌

MATF implements public key pinning based on [RFC7469] 🎯 Public key pinning associates one or more public key pins with each federation endpoint, and those pins are published in the federation metadata. During a connection, clients and servers extract the public key from the presented certificate and check that it matches the preconfigured public key pins retrieved from the federation metadata 🔎

5.1.1. Benefits of Public Key Pinning 🌷

The decision to use public key pinning in the MATF framework came from several critical factors aimed at boosting security and building trust 🧡

5.1.1.1. Interfederation Trust 🌍

In interfederation environments, where multiple federations need to trust each other, public key pinning stays effective 🌐 Members can validate entities in other federations using pins published through shared metadata, which keeps trust intact across boundaries. Unlike private certificate chains, which can get complicated and hard to manage across multiple federations, public key pinning gives you a straightforward way to establish trust 😌 MATF interfederation tackles this by aggregating metadata from all participating federations into a unified metadata repository. This shared metadata lets entities in different federations communicate securely, with consistent key validation and robust cross-federation trust and security 🦋

5.1.1.2. Fortifying Security Against Threats 🏰

Public key pinning is a robust defense because it directly binds a peer to a specific public key 🔒 This makes sure only the designated key is trusted, which stops attackers from exploiting fraudulent certificates 🙅‍♀️ Since it doesn't rely on external trust intermediaries, this approach seriously boosts resilience against potential threats 🛡️✨

5.1.1.3. Use of Self-Signed Certificates 🪄

Using self-signed certificates within the federation leverages public key pinning to establish trust 🫶 By skipping external Certificate Authorities (CAs), servers and clients rely on the federation's own mechanisms to validate trust. Public key pinning makes sure that only the specific self-signed public keys, identified by key pins in the metadata, are trusted 🔑

5.1.1.4. Revocation ✨

Okay, so revocation is where certificate chains get messy 😭. In setups that rely on certificate chains and revocation mechanisms, revoking things can be complex and slow, because a certificate that can no longer be trusted (and possibly other certs in the chain) might need to be revoked and reissued. Public key pinning helps here 🦋 because clients base their trust decisions on pinned public keys instead of whole certificate chains.

If a public key can no longer be trusted inside a MATF federation, its pin gets removed 🗑️. Updated metadata gets published, and that metadata includes a new pin for the public key in the replacement certificate. This takes pressure off revocation mechanisms and moves trust over to the specific, updated public key, identified by its pin 💜.

5.2. Pin Discovery and Preloading 🎀

Peers in the federation grab their public key pins from the federation metadata 🧚. These pins act as preconfigured trust parameters for validation, as laid out in Section 5.3.

The federation MUST define discovery rules. These describe how peers use federation metadata claims like organization and tags to find the relevant endpoints and their pins 🔍.

Before starting or accepting a connection, a peer MUST preload the pins for the selected or authorized endpoints from its local metadata store. How that local store is maintained, including refresh behavior and expiry handling, is covered in Section 4.2.

To support peer identification, the preloaded state MUST enable mapping from a derived pin to the corresponding entity_id. One way to get there is 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 🔐

Upon connection establishment, both endpoints MUST verify that the public key in the presented peer certificate matches a pin published in the federation metadata. This check MAY be done by the TLS stack or by application logic.

In setups where an intermediary terminates the TLS session, pin validation MUST be performed by either the intermediary or the application. If the application does the pin validation, the intermediary MUST forward the peer certificate or a derived pin to the application. The application MUST be able to work out the peer entity_id from the forwarded information and the federation metadata. This resolution relies on the client pin digest uniqueness property specified in Section 6.1.1.1.

If the intermediary does the pin validation, it MUST propagate the peer certificate, the derived pin, or the entity_id to the application so authorization can happen.

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 ⛔

A received certificate that fails validation MUST result in the immediate termination of the connection. That includes cases where the derived pin doesn't match any preloaded pin, or where the peer identity can't be resolved. This strict enforcement makes sure that only authorized and secure communication channels get set up within the federation 🔒.

5.5. Certificate Rotation 🔄

To replace a certificate, whether because it expired or for some other reason, the following procedure MUST be followed:

  1. Submitting updated metadata: When a certificate is scheduled for rotation, the federation member submits updated metadata that adds the pin for the new public key alongside the already published pins. The federation operator republishes the signed federation metadata aggregate, making the new pin available to all federation members.
  2. Propagation period: Federation members MUST refresh their local metadata stores as specified in Section 4.2. The rotating member MUST allow sufficient time for peers to refresh and preload the new pin before switching to the new certificate.
  3. Switching to the new certificate: After the propagation period has elapsed, the rotating member updates its TLS stack to present the new certificate. This allows peers that have preloaded the new pin to validate the rotated certificate.
  4. Removing the old pin: Following a successful transition, the rotating member MUST submit updated metadata excluding the old pin. The federation operator republishes the aggregate, ensuring that only current public keys remain trusted within the federation.

5.6. Implementation Guidelines 🛠️

The placement of pin validation depends on the deployment architecture. For clients, validation is typically done by the component that starts the TLS connection. For servers using an intermediary, the communication channel between the intermediary and the application MUST be integrity protected to prevent tampering with forwarded peer identity material.

When an intermediary passes along peer identity material (like the peer certificate, a derived pin, or the entity_id) using HTTP header fields, those header fields are the mechanism used to fulfill the requirements in Section 5.3. For each header field name used for this purpose, the intermediary MUST remove any instance of that header field received from the peer and then set the header field value itself. This makes sure the application only processes identity material derived directly from the TLS session, so it can match the peer to the federation metadata and apply authorization policy based on federation metadata claims. Header fields that aren't 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.

Implementations SHOULD, when possible, rely on libraries with built-in support for pinning. libcurl, for example, supports pinning via the CURLOPT_PINNEDPUBLICKEY option. In Python, the cryptography library can extract public keys, and application code can compare the derived pin to a configured value. Go provides crypto/tls and crypto/x509 for certificate inspection and public key extraction. In Java, java.security.cert.X509Certificate enables public key extraction, while java.net.http.HttpClient allows pinning enforcement using a custom SSLContext and TrustManager. The choice of library is left to the discretion of each implementation.

6. Federation Metadata 📜

Federation metadata is published as a JSON Web Signature (JWS) [RFC7515]. The payload contains statements about entities of federation members 💌.

Metadata is used for authentication and service discovery. A client selects a server based on metadata claims like organization and tags. To establish a connection, the client uses the base_uri, pins, and, if needed, issuers of the selected server.

6.1. Federation Metadata Claims 🏷️

This section defines the set of claims that can be included in metadata.

  • iat (REQUIRED)
    • Identifies the time at which the federation metadata was issued.
    • Data Type: Integer
    • Syntax: NumericDate as defined in [RFC7519], Section 4.1.6.
    • Example: 1755514949
  • exp (REQUIRED)
    • Identifies the expiration time on or after which the federation metadata is no longer valid. Once the exp time has passed, the metadata MUST be rejected regardless of cache state.
    • Data Type: Integer
    • Syntax: NumericDate as defined in [RFC7519], Section 4.1.4.
    • Example: 1756119888
  • iss (REQUIRED)
    • A URI uniquely identifying the issuing federation. This value differentiates federations, prevents ambiguity, and ensures that entities are recognized within their intended context. Verification of the iss claim enables recipients to determine the origin of the information and to establish trust with entities within the identified federation.
    • Data Type: String
    • Syntax: StringOrURI as defined in [RFC7519], Section 4.1.1. In MATF, this value MUST be a URI.
    • Example: "https://federation.example.org"
  • version (REQUIRED)
    • Indicates the schema version of the federation metadata. This ensures compatibility between members of the federation by defining a clear versioning mechanism for interpreting metadata.
    • Data Type: String
    • Syntax: The value MUST follow Semantic Versioning (see https://semver.org).
    • Example: "1.0.0"
  • cache_ttl (OPTIONAL)
    • Specifies the duration in seconds for caching downloaded federation metadata, allowing for independent caching outside of specific HTTP configurations. This is particularly useful when the communication mechanism is not based on HTTP. In the event of a metadata publication outage, members can rely on cached metadata until it expires, as indicated by the exp claim in the JWS payload, defined in Section 6.1. Once expired, metadata MUST no longer be trusted. If omitted, a mechanism to refresh metadata MUST still exist to ensure the metadata remains valid.
    • Data Type: Integer
    • Syntax: Integer representing the duration in seconds.
    • Example: 3600
  • entities (REQUIRED)
    • Contains the list of entities within the federation.
    • Data Type: Array of Objects
    • Syntax: Each object MUST conform to the entity definition, as specified in Section 6.1.1.

6.1.1. Entities ✨

okay so the metadata has a list of entities that can talk to each other inside the federation 🫶 each entity covers one or more endpoints owned by a member. here's what every entity gets:

  • entity_id (REQUIRED) 🆔

this is a URI that uniquely identifies the entity. it MUST NOT collide with any other entity_id in the federation, or in any other federation the entity talks to. no duplicate besties allowed 💅

  • organization (OPTIONAL) 🏢

a name for the organization that the entity's metadata represents. the federation operator MUST make sure there's a mechanism in place to verify that the organization claim belongs to the rightful owner of the info exchanged between nodes. this is crucial for the trust model, because you need to be certain who everyone actually is 🔍 the federation operator SHOULD pick whatever approach fits the specific needs and trust model of the federation.

  • Data Type: String
  • Syntax: A name identifying the organization represented by the entity.
  • Example: "Example Org"
  • issuers (REQUIRED) 🪪

a list of the certificate issuers that are allowed to issue certificates for the entity's endpoints. for each issuer, the issuer's root CA certificate MUST be included in the x509certificate property and encoded in the Privacy-Enhanced Mail (PEM) format. certificate verification leans on public key pinning, and the allowed-issuers list is only used when a certificate chain validation mechanism is unavoidable 🌸 for self-signed certificates, the certificate is its own issuer and MUST be listed as such in the metadata. main character energy for sure 👑

  • Data Type: Array of Objects
  • Syntax: Each object contains an issuer certificate encoded as PEM, as specified in [RFC7468]. The Base64 content MUST be wrapped so that each line consists of exactly 64 characters, except for the final line. In JSON text, line breaks in the PEM value are represented using the "\n" escape sequence.
  • Example: Issuer truncated for readability.
   "issuers": [{
     "x509certificate": "-----BEGIN CERTIFICATE-----\nMIIDDD"
   }]
  • servers (OPTIONAL) 🖥️

contains the list of servers within the entity.

  • Data Type: Array of Objects
  • Syntax: Each object MUST conform to the server definition, as specified in Section 6.1.1.1.
  • clients (OPTIONAL) 📱

contains the list of clients within the entity.

  • Data Type: Array of Objects
  • Syntax: Each object MUST conform to the client definition, as specified in Section 6.1.1.1.

6.1.1.1. Servers / Clients 🧚

here's the tea on the entity's servers and clients 🫖

  • description (OPTIONAL) 📝

a human-readable text describing the server or client.

  • Data Type: String
  • Syntax: Free-form text describing the server or client.
  • Example: "SCIM Server 1"
  • base_uri (REQUIRED for servers, OPTIONAL for clients) 🔗

the base URL of the server. this claim is REQUIRED for server endpoints. the value MUST be an absolute URI as defined in Section 4.3 of [RFC3986]. it works as the base URI for resolving relative references to server resources, as described in Section 5 of [RFC3986] 🧭

  • pins (REQUIRED) 📌

a list of objects representing public key pins [RFC7469] 💖

  • Data Type: Array of Objects
  • Syntax: A list of objects, where each object represents a single public key pin with the following properties:
    • alg (REQUIRED) 🧪

the name of the cryptographic hash algorithm. right now the RECOMMENDED value is 'sha256'. as more secure algorithms come out over time, federations should be ready to adopt the newer options for extra security ✨

  • Data Type: String
  • Syntax: The name of the algorithm.
  • Example: "sha256"
  • digest (REQUIRED) 🫧

the public key of the end-entity certificate, converted to a Subject Public Key Information (SPKI) fingerprint, as specified in Section 2.4 of [RFC7469]. for clients, the digest value MUST be unique across entities in the federation metadata so the peer can be identified without any confusion 🕵️‍♀️ within the same entity, the same digest value MAY be assigned to multiple clients.

  • Data Type: String
  • Syntax: SPKI fingerprint.
  • Example: "+hcmCjJEtLq4BRPhrILyhgn98Lhy6DaWdpmsBAgOLCQ="
  • Example:
   "pins": [{
     "alg": "sha256",
     "digest": "+hcmCjJEtLq4BRPhrILyhgn98Lhy6DaWdpmsBAgOLCQ="
   }]
  • tags (OPTIONAL) 🏷️

a list of strings that describe the endpoint's capabilities.

  • Data Type: Array of Strings
  • Syntax: Strings describing endpoint capabilities.
  • Pattern: ^[a-z0-9]{1,64}$
  • Example: ["scim", "xyzzy"]

tags are super important for discovery inside a federation, helping both servers and clients figure out who's a good match 🦋

  • Server Tags: tags on servers are how clients find the servers that offer the services they need. clients can search by tags that show supported protocols or the kind of data a server handles, so they can discover compatible servers 🔎
  • Client Tags: tags on clients are how servers spot clients with specific characteristics or capabilities. for example, a server might only accept connections from clients that support particular protocols. by filtering incoming requests on these tags, servers can pick out the suitable clients 💅

Federation-Specific Considerations: tags belong to individual federations and do distinct jobs in each one, so a few things matter to keep tag usage clear and consistent 🎀

  • Well-Defined Scope: each federation MUST set a clear scope for its tags, spelling out their intended use, allowed tag values, what they mean, and any relevant restrictions. keeping a well-defined, easy-to-reach registry of approved tags is essential for the federation 📚
  • Validation Mechanisms: putting validation mechanisms in place for tags is highly recommended. this can be a dedicated operation or service that checks tag validity and compliance with the federation's rules. that keeps things consistent by stopping unauthorized or irrelevant tags from getting in 🚫

6.2. Metadata Schema 🗂️

the MATF metadata schema is defined in Appendix A. it lays out the format for describing the entities involved in MATF and their associated info 🧾

Note: The schema in Appendix A is folded due to line length limitations as specified in [RFC8792].

6.3. Example Metadata 🍓

here's a non-normative example of a metadata statement, so you can see the vibe. the line breaks in the issuers claim example are only there for readability 🙈

   {
     "iat": 1755514949,
     "exp": 1756119888,
     "iss": "https://federation.example.org",
     "version": "1.0.0",
     "cache_ttl": 3600,
     "entities": [{
       "entity_id": "https://example.com",
       "organization": "Example Org",
       "issuers": [{
         "x509certificate": "-----BEGIN CERTIFICATE-----\nMIIDDDCCAf
         SgAwIBAgIJAIOsfJBStJQhMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV\nBAM
         MEHNjaW0uZXhhbXBsZS5jb20wHhcNMTcwNDA2MDc1MzE3WhcNMTcwNTA2MD
         c1\nMzE3WjAbMRkwFwYDVQQDDBBzY2ltLmV4YW1wbGUuY29tMIIBIjANBgk
         qhkiG9w0B\nAQEFAAOCAQ8AMIIBCgKCAQEAyr+3dXTC8YXoi0LDJTH0lTfv
         8omQivWFOr3+/PBE\n6hmpLSNXK/EZJBD6ZT4Q+tY8dPhyhzT5RFZCVlrDs
         e/kY00F4yoflKiqx9WSuCrq\nZFr1AUtIfGR/LvRUvDFtuHo1MzFttiK8Wr
         wskMYZrw1zLHTIVwBkfMw1qr2XzxFK\njt0CcDmFxNdY5Q8kuBojH9+xt5s
         ZbrJ9AVH/OI8JamSqDjk9ODyGg+GrEZFClP/B\nxa4Fsl04En/9GfaJnCU1
         NpU0cqvWbVUlLOy8DaQMN14HIdkTdmegEsg2LR/XrJkt\nho16diAXrgS25
         3xbkdD3T5d6lHiZCL6UxkBh4ZHRcoftSwIDAQABo1MwUTAdBgNV\nHQ4EFg
         QUs1dXuhGhGc2UNb7ikn3t6cBuU34wHwYDVR0jBBgwFoAUs1dXuhGhGc2U\
         nNb7ikn3t6cBuU34wDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQsFAA
         OCAQEA\nrR9wxPhUa2XfQ0agAC0oC8TFf8wbTYb0ElP5Ej834xMMW/wWTSA
         N8/3WqOWNQJ23\nf0vEeYQwfvbD2fjLvYTyM2tSPOWrtQpKuvulIrxV7Zz8
         A61NIjblE3rfea1eC8my\nTkDOlMKV+wlXXgUxirride+6ubOWRGf92fgze
         DGJWkmm/a9tj0L/3e0xIXeujxC7\nMIt3p99teHjvnZQ7FiIBlvGc1o8FD1
         FKmFYd74s7RxrAusBEAAmBo3xyB89cFU0d\nKB2fkH2lkqiqkyOtjrlHPoy
         6ws6g1S6U/Jx9n0NEeEqCfzXnh9jEpxisSO+fBZER\npCwj2LMNPQxZBqBF
         oxbFPw==\n-----END CERTIFICATE-----"
       }],
       "servers": [{
         "description": "SCIM Server 1",
         "base_uri": "https://scim.example.com/",
         "pins": [{
           "alg": "sha256",
           "digest": "+hcmCjJEtLq4BRPhrILyhgn98Lhy6DaWdpmsBAgOLCQ="
         }],
         "tags": [
           "scim"
         ]
       }],
       "clients": [{
         "description": "SCIM Client 1",
         "pins": [{
           "alg": "sha256",
           "digest": "+hcmCjJEtLq4BRPhrILyhgn98Lhy6DaWdpmsBAgOLCQ="
         }]
       }]
     }]
   }

6.4. Metadata Signing 🔐

federation metadata is signed using JWS and published with the JWS JSON Serialization, following the general JWS JSON Serialization syntax defined in [RFC7515]. signatures on federation metadata are RECOMMENDED to be made with ECDSA using P-256 and SHA-256 ("ES256"), as defined in [RFC7518]. but since crypto keeps evolving, alternative algorithms MAY be used, as long as they meet the security requirements of the federation 💜

federations might need to move to post-quantum cryptographic algorithms, both for metadata signatures and for endpoint certificate public key types. MATF can handle those transitions through key rollover and by updating published pins as new key types roll out 🌈

the following JWS Protected Header parameters are REQUIRED:

  • alg (Algorithm) ⚙️

identifies the algorithm used to generate the JWS signature [RFC7515], Section 4.1.1.

  • kid (Key Identifier) 🗝️

identifies the key in the issuer's key set that was used to generate the JWS signature [RFC7515], Section 4.1.4.

6.5. Example Signature Protected Header 🧁

here's a non-normative example of a signature protected header, just so you can picture it 🦋

   {
       "alg": "ES256",
       "kid": "c2fb760e-f4b6-4f7e-b17a-7115d2826d51"
   }

7. Example Usage Scenarios ✨

okay so these examples are NOT normative (they're just vibes and illustrations 💅), and they show off the procedures from Sections 5.2 and 5.3. 🫶

Picture this: a federation called "Skolfederation" where MATF is deployed. Clients and servers are both registered members, and the clients manage cross-domain user accounts with SS 12000:2018, which is a System for Cross-domain Identity Management (SCIM) extension. 🦋

+------------------------------------------------------+
|                                                      |
|                  Federation Metadata                 |
|                                                      |
+-----+-------------------------------+----------------+
      |                               |
     (A)                             (A)
      |                               |
      v                               v
+-----------+         +--------------------------------+
| Local MD  |         |            Local MD            |
+-----+-----+         +------+---------------------+---+
      |                      |                     |
     (B)                    (C)                   (F)
      |                      |                     |
      v                      v                     v
+-----------+         +--------------+         +-------+
|           |         |              |         |       |
|  Client   +---(D)-->+ Intermediary +---(E)-->+  App  |
|           |         |              |         |       |
+-----------+         +--------------+         +-------+
  • A. Clients and servers retrieve federation metadata and update their local metadata stores as described in Section 4.2. 📥
  • B. The client selects a server endpoint based on metadata claims and preloads the pins published for that endpoint. 🎯
  • C. If certificate chain validation is performed, the TLS client or intermediary configures its trust store using the issuers listed in the federation metadata for the selected entity. 🔐
  • D. The client initiates a TLS connection to the selected base_uri and presents its client certificate. 🤝
  • E. If an intermediary terminates the TLS session, it forwards identity material derived from the TLS session to the application as described in Sections 5.3 and 5.6. 🎁
  • F. The application maps the derived pin to a matching metadata entry and uses the associated entity_id for identification and authorization. 👑

7.1. Client Behavior

okay so the client gets a certificate issued, and its certificate issuer and public key pins get published in the federation metadata. 💖

When a client starts a connection to a remote server (identified by that server's entity_id), these are the steps, in order:

  1. The client picks a server endpoint from the identified entity's servers list, one whose tags match the service capabilities it needs. 🧚
  2. The client preloads the selected endpoint's pins from its local metadata store. If certificate chain validation is performed, the client also loads the issuers listed for the entity. 📦
  3. The client starts a TLS connection to the selected endpoint using the base_uri and presents its client certificate. 🔌
  4. The client does pin validation on the server certificate as described in Section 5.3. The TLS stack might handle this during the handshake, or application logic might handle it after the connection is up, but it has to finish before any application data gets exchanged. 🙈
  5. If validation succeeds, the client moves on to application transactions. ✅

7.2. Server Behavior

To accept inbound connections from a client, the server uses federation metadata to do pin validation on the public key in the presented client certificate. The federation metadata publishes client public key pins and, for deployments that do certificate chain validation, the allowed issuers. 🛡️

When the server gets a TLS connection attempt from a remote client, these are the steps:

  1. The server is set up to request or require a client certificate. If certificate chain validation is performed, the trust store gets filled 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 figure out which clients it's willing to talk to, and preload only the pins for those clients, as described in Section 5.2. 🧹
  3. After the TLS handshake finishes, the server derives the client's pin from the presented certificate and matches it against the preloaded pins. When it finds a match, the server gets the client's entity_id from that metadata entry. 🔍
  4. If pin validation succeeds, the server moves on to application transactions. If pin validation fails, the server ends the connection. 🚪

7.3. SPKI Generation

Here's how you can use OpenSSL to generate an SPKI fingerprint from a PEM-encoded certificate. Bookmark this one, it's so useful 🔖

  openssl x509 -in <certificate.pem> -pubkey -noout | \
  openssl pkey -pubin -outform der | \
  openssl dgst -sha256 -binary | \
  openssl enc -base64

7.4. Curl and Public Key Pinning

And here's public key pinning with curl. Pinning is giving security-guard energy 🌸

  curl --cert client.pem --key client.key \
  --pinnedpubkey \
  'sha256//0Ok2aNfcrCNDMhC2uXIdxBFOvMfEVtzlNVUT5pur0Dk=' \
  https://host.example.com

8. Deployments of the MATF Framework 🌈

MATF has proven its practical value and robustness through successful deployments in several environments, and honestly it's been a whole success story 🏆

8.1. Skolfederation Moa

Skolfederation Moa [Moa] is a federation built to keep communication between digital educational resources and schools secure. MATF was developed to meet Moa's needs, and it enables secure data exchange for schools, municipalities, educational platforms, and services across Sweden. 🇸🇪🎓

The community is a huge part of this kind of federation. Members are active participants, and the federation operator makes sure the federation runs smoothly and serves their needs. Moa's success shows how much collaboration matters, with members and the operator working together to keep trust, security, and interoperability in the education sector. 🫶

The MATF deployment in Swedish education taught a few key lessons. Keeping an accurate registry of metadata ownership, with reliable contact info, is essential for troubleshooting and accountability. The deployment also showed how important it is to set reasonable expiration times for metadata. If it expires too fast, it gets harder to have contingency plans for publishing new metadata during outages. 📅

Metadata validation is necessary for a stable federation. Manual validation might be fine in the early days, but it gets unmanageable as the federation grows. Without an automated validation process, incorrect metadata uploaded by members is likely to go undetected, which leads to incorrect metadata getting published. 😬

The federation metadata signing private key is required to publish signed federation metadata. In fallback scenarios, federation metadata may be retrieved from an alternate location, but publishing updated federation metadata requires access to the signing private key. So secure and redundant management of that key is necessary to support fallback mechanisms and reliable publication. Recipients MUST validate the JWS signature using the federation signature verification key before using federation metadata, regardless of where it is obtained. This one is non-negotiable, bestie 🔒

8.2. Swedish National Agency for Education

The Swedish National Agency for Education [SkolverketMATF] uses MATF in its digital national test platform to set up a robust authentication mechanism. The platform uses an API for client verification before secure data transfer to the agency's test service, which keeps the integrity and confidentiality of educational data intact. 📝✨

8.3. Sambruk's EGIL

Sambruk's EGIL [EGIL], a platform that provides digital services to municipalities, has successfully integrated the MATF framework. This deployment shows how adaptable the framework is across a wide range of digital service infrastructures. 🧩

These deployments really highlight how effective MATF is at boosting security and interoperability in the educational sector. Iconic 👑

9. Security Considerations 🔐

This section is serious business, so we're keeping every bit of it 💀

9.1. Security Risks and Trust Management

The security risks tied to the MATF framework are confined to each individual federation. The federation operator and the federation members both share responsibility for keeping trust and security intact. Proper handling of metadata and thorough vetting of members are crucial to sustaining that trust. 🧐

Deployments that terminate a session at an intermediary and pass identity material on to an application introduce a critical trust boundary. If the intermediary is compromised or doesn't properly sanitize inbound headers, an attacker could spoof a peer's entity_id. So 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 they're required for diagnostics. This keeps session-specific identity material from being exposed by accident. 🙊

9.2. TLS

The security considerations for TLS 1.3 are detailed in Section 10 and Appendices C, D, and E of [RFC8446]. Go read those, they're the main event 📖

9.3. Federation Metadata Updates

Regularly updating your local copy of federation metadata is essential for getting the latest info about active entities, current public key pins [RFC7469], and valid issuer certificates. Using outdated metadata can expose systems to security risks, like talking to revoked entities or accepting manipulated data. Yikes 😭

9.4. Verifying the Federation Metadata Signature

Keeping data integrity and security intact in the MATF framework relies on verifying the signature of downloaded federation metadata. This verification confirms where the metadata came from by validating the JWS signature with the federation signature verification key trusted by the recipient. It also confirms the signed content hasn't been altered by unauthorized parties. Verifying the signature keeps trust in the info used for validation, including member public key pins and issuer certificates, intact. 🪪

To build a robust implementation, it's important to consider the security aspects outlined in [RFC7515], which covers security considerations related to algorithm selection, key compromise, and signature integrity. Do your homework, babe 📚

9.5. Time Synchronization

Keeping clocks synchronized across all federation members is critical for the security of the MATF framework. Inaccurate timestamps can compromise the validity of digital signatures and certificates, make reliable log analysis harder, and potentially expose the system to time-based attacks. So all federation members MUST employ methods to ensure their system clocks are synchronized with a reliable time source. ⏰🔥

10. IANA Considerations 🧚

This document has no IANA actions. Nothing to register here, no cap 💖

11. References 📚

The reference list keeps going in the next part, so we'll wrap it up there 🫶

11.1. Normative References 📚

Okay bestie, these are the must-read receipts 🧾 Anything that's normative is stuff you need to have read to really get the spec.

11.2. Informative References 🌸

These ones are the extra reading for when you want the full story. They're not required to get the core spec, but they're honestly so worth a look 👀

Appendix A. JSON Schema for MATF Metadata ✨

Here's the JSON Schema that defines what MATF metadata looks like 🧩 It follows draft 2020-12 of the JSON Schema standard, so it's giving very official and very organised 💅

Version: 1.0.0

=============== NOTE: '\\' line wrapping per RFC 8792 ===============

{
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "$id": "https://mtlsfed.se/schema/matf-metadata-schema.json",
    "title": "JSON Schema for Mutually Authenticating TLS in the con\
\text of Federations",
    "description": "Version: 1.0.0",
    "type": "object",
    "additionalProperties": true,
    "required": [
        "iat",
        "exp",
        "iss",
        "version",
        "entities"
    ],
    "properties": {
        "iat": {
            "title": "Issued at",
            "description": "Time at which the metadata was issued (U\
\NIX timestamp)",
            "type": "integer",
            "minimum": 0,
            "examples": [
                1755514949
            ]
        },
        "exp": {
            "title": "Expiration time",
            "description": "Time at which the metadata expires (UNIX\
\ timestamp)",
            "type": "integer",
            "minimum": 0,
            "examples": [
                1756119888
            ]
        },
        "iss": {
            "title": "The federation issuing the metadata",
            "description": "A URI that uniquely identifies the feder\
\ation that issued the metadata",
            "type": "string",
            "format": "uri",
            "minLength": 1,
            "examples": [
                "https://example.com/federation"
            ]
        },
        "version": {
            "title": "Metadata schema version",
            "description": "Schema version follows semantic versioni\
\ng (https://semver.org)",
            "type": "string",
            "pattern": "^\\d+\\.\\d+\\.\\d+$",
            "examples": [
                "1.0.0"
            ]
        },
        "cache_ttl": {
            "title": "Metadata cache TTL",
            "description": "How long in seconds to cache metadata. T\
\he effective maximum is bounded by the exp claim.",
            "type": "integer",
            "minimum": 0,
            "examples": [
                3600
            ]
        },
        "entities": {
            "type": "array",
            "minItems": 1,
            "items": {
                "$ref": "#/$defs/entity"
            }
        }
    },
    "$defs": {
        "entity": {
            "type": "object",
            "additionalProperties": true,
            "required": [
                "entity_id",
                "issuers"
            ],
            "properties": {
                "entity_id": {
                    "title": "Entity identifier",
                    "description": "Globally unique identifier for t\
\he entity.",
                    "type": "string",
                    "format": "uri",
                    "examples": [
                        "https://example.com"
                    ]
                },
                "organization": {
                    "title": "Name of entity organization",
                    "description": "Name identifying the organizatio\
\n that the entity's metadata represents.",
                    "type": "string",
                    "examples": [
                        "Example Org"
                    ]
                },
                "issuers": {
                    "title": "Entity certificate issuers",
                    "description": "A list of certificate issuers th\
\at are allowed to issue certificates for the entity's endpoints. Fo\
\r each issuer, the issuer's root CA certificate is included in the \
\x509certificate property (PEM-encoded).",
                    "type": "array",
                    "minItems": 1,
                    "items": {
                        "$ref": "#/$defs/cert_issuers"
                    }
                },
                "servers": {
                    "type": "array",
                    "items": {
                        "$ref": "#/$defs/endpoint"
                    }
                },
                "clients": {
                    "type": "array",
                    "items": {
                        "$ref": "#/$defs/endpoint"
                    }
                }
            }
        },
        "endpoint": {
            "type": "object",
            "additionalProperties": true,
            "required": [
                "pins"
            ],
            "properties": {
                "description": {
                    "title": "Endpoint description",
                    "type": "string",
                    "examples": [
                        "SCIM Server 1"
                    ]
                },
                "tags": {
                    "title": "Endpoint tags",
                    "description": "A list of strings that describe \
\the endpoint's capabilities.",
                    "type": "array",
                    "items": {
                        "type": "string",
                        "pattern": "^[a-z0-9]{1,64}$",
                        "examples": [
                            "xyzzy"
                        ]
                    }
                },
                "base_uri": {
                    "title": "Endpoint base URI",
                    "type": "string",
                    "format": "uri",
                    "examples": [
                        "https://scim.example.com"
                    ]
                },
                "pins": {
                    "title": "Certificate pin set",
                    "type": "array",
                    "minItems": 1,
                    "items": {
                        "$ref": "#/$defs/pin_directive"
                    }
                }
            }
        },
        "cert_issuers": {
            "title": "Certificate issuers",
            "type": "object",
            "additionalProperties": false,
            "required": [
                "x509certificate"
            ],
            "properties": {
                "x509certificate": {
                    "title": "X.509 Certificate (PEM)",
                    "type": "string",
                    "pattern": "^-----BEGIN CERTIFICATE-----(?:\\r?\\\
\\n)(?:[A-Za-z0-9+/=]{64}\\r?\\n)*(?:[A-Za-z0-9+/=]{1,64}\\r?\\n)---\
\--END CERTIFICATE-----(?:\\r?\\n)?$"
                }
            }
        },
        "pin_directive": {
            "title": "RFC 7469 pin directive",
            "type": "object",
            "additionalProperties": false,
            "required": [
                "alg",
                "digest"
            ],
            "properties": {
                "alg": {
                    "title": "Directive name",
                    "type": "string",
                    "enum": [
                        "sha256"
                    ],
                    "examples": [
                        "sha256"
                    ]
                },
                "digest": {
                    "title": "Directive value (Base64)",
                    "type": "string",
                    "pattern": "^[A-Za-z0-9+/]{43}=$",
                    "examples": [
                        "HiMkrb4phPSP+OvGqmZd6sGvy7AUn4k3XEe8OMBrzt8\
\="
                    ]
                }
            }
        }
    }
}

Okay bestie, let's wrap this up 🎀✨

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 💌

Stefan Halén The Swedish Internet Foundation Email: stefan.halen@internetstiftelsen.se

Jakob Schlyter Kirei AB Email: jakob@kirei.se

That's the whole doc, bestie! 🦋 Thanks to everyone who reviewed it and to Stefan and Jakob for writing it. Slay. 👑💅

📦 where this page comes from