4. Metadata Repository

This section preserves the RFC text for MATF, including federation trust model, metadata repository, public key pinning, JSON/JWS metadata, usage scenarios, deployments, security considerations, and JSON Schema.

4.  Metadata Repository

   The MATF metadata repository acts as a central vault, securely
   storing all information about all participating federation members
   and their respective entities.  This information, known as federation
   metadata, is presented as a JSON Web Signature (JWS) [RFC7515] to
   ensure its authenticity and integrity.

   The metadata repository is subject to stringent security measures to
   safeguard the integrity of the stored information.  This MAY involve:

   *  Member management: The federation operator can centrally enforce
      security policies and vet new members before they are 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 ensure data recovery in
      case of unforeseen circumstances.

   Before member metadata is added to the federation's repository, the
   submitted metadata MUST undergo a validation process.  This process
   verifies the accuracy, completeness, and validity of the information
   provided by a member.  Metadata that does not pass validation MUST be
   rejected.  The validation process MUST include, at a minimum, the
   following checks:

   *  Format validation: The submitted metadata is checked to ensure
      that 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
      ensure that the entity_id value, as defined in Section 6.1.1, is
      not already registered by another member.

   *  Unique public key pin digests: The submitted metadata is checked
      to ensure that pins entries, as defined in Section 6.1.1.1, do not
      introduce a digest value that is already registered to a different
      entity_id.  While reuse of the same digest value within the same
      entity_id is permitted, uniqueness across different entities is
      REQUIRED to prevent identity collisions and to support the
      resolution of 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 ensure that they are
      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 ensure that they conform to the defined tag syntax.  If the
      federation defines an approved set of tag values, submitted tags
      are checked to ensure that they are 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 is up to the federation, through its governance and operational
   processes, to determine which channels are provided to members for
   submitting their metadata to the metadata repository.  Members
   typically have the option to upload the metadata directly to the
   repository, provided such functionality exists, or to 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.  Such measures may
   include verifying the checksum of the metadata through another
   channel.  The choice of submission channel may depend on factors such
   as the federation's guidelines and the preferences of the member.

4.2.  Maintaining Up-to-Date Metadata

   In a MATF federation, accurate and current metadata is essential for
   ensuring secure and reliable communication between members.  This
   necessitates maintaining up-to-date metadata accessible by all
   members.

   *  Federation metadata: The federation operator publishes a JWS
      containing an aggregate of all entity metadata.  This JWS serves
      as the source of truth for information about all members within
      the federation.  Outdated information in the JWS can lead to
      issues such as failed connections, discovery challenges, and
      potential security risks.

   *  Local metadata: Each member maintains a local metadata store
      containing information about other members within the federation.
      This information is retrieved from the federation's publicly
      accessible JWS.  Outdated data in the local store can hinder a
      member's ability 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
      role 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, ensuring 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 adhering to these responsibilities, the federation ensures that
   information remains valid for the defined timeframe and that caching
   mechanisms utilize up-to-date data effectively.