1. Introduction

Dieser Abschnitt bewahrt den RFC-Text fuer MATF, einschliesslich federation trust model, metadata repository, public key pinning, JSON/JWS metadata, usage scenarios, deployments, security considerations und JSON Schema.

1.  Introduction

   This document describes the Mutually Authenticating TLS in
   Federations (MATF) framework, developed to complement multilateral
   Security Assertion Markup Language (SAML) federations within the
   education sector.  These federations often rely on just-in-time
   provisioning, where user accounts are created at first login based on
   information from the SAML assertion.  However, educators need to be
   able to manage resources and classes before students access the
   service.  MATF bridges this gap by using secure machine-to-machine
   communication, enabling pre-provisioning of user information with a
   trust model and metadata structure inspired by SAML federations.

   MATF is designed specifically for secure authentication in machine-
   to-machine contexts, such as RESTful APIs (where "RESTful" refers to
   the Representational State Transfer (REST) architecture) and service-
   to-service interactions, and is not intended for browser-based
   authentication.  Because its applicability in a browser environment
   has not been studied, using MATF within browsers is not recommended.
   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
   standard, and has not achieved community consensus.  It aims to
   address specific federation challenges and provide a framework for
   secure communication.

   TLS is specified by the IETF TLS Working Group.  TLS 1.3 is defined
   in [RFC8446].  Additional information about the TLS Working Group is
   available at <https://datatracker.ietf.org/wg/tls/about/>.

1.1.  Reserved Words

   This document is an Informational RFC, which means it offers
   information and guidance but does not specify mandatory standards.
   Therefore, the keywords used throughout this document are for
   informational purposes only and do not 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 adhere to common
      security policies and standards, using MATF for secure
      communication.

   Federation Member:  An entity that has been approved to join the
      federation and can leverage MATF for secure communication with
      other members.

   Federation Operator:  The entity responsible for the overall
      operation and management of the federation, including managing the
      federation metadata, enforcing security policies, and onboarding
      new members.

   Federation Metadata:  A cryptographically signed document containing
      information about all entities within the federation.

   Metadata Repository:  A centralized repository storing information
      about all entities within the federation.

   Member Metadata:  Information about entities associated with a
      specific member within the federation.

   Member Vetting:  The process of verifying and approving applicants to
      join the federation, ensuring they meet security and
      trustworthiness requirements.

   Trust Anchor:  The federation's root of trust is established by the
      public key used to verify federation metadata signatures, which
      allows participants to confidently rely on the information it
      contains.