RDAP Extension for Structured Reliability Assessment Metadata

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 15 October 2026.¶

Copyright Notice

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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The domain registration ecosystem relies on registrars as critical intermediaries between domain owners and the global DNS infrastructure. Research [DEEPSEC2025] has identified recurring systemic vulnerabilities in registrar processes, including credential recovery, identity verification, and email authentication configurations, that represent structural risks affecting large numbers of domains and their owners. These issues have in several cases remained unaddressed for extended periods despite responsible disclosure.¶

The Registration Data Access Protocol (RDAP), defined in [RFC7480], [RFC7481], [RFC9082], [RFC9083], and [RFC9224], was designed as the successor to WHOIS and introduces structured JSON responses, authentication and authorization support, and a well-defined extensibility model. These properties make RDAP a suitable foundation for exposing structured security and reliability metadata in a standardized, interoperable way.¶

This document defines an RDAP extension that provides an envelope for carrying assessment results related to the security posture and reliability of registrars and domain names. The extension standardizes the transport and referencing of such results; it does not define scoring methodologies, thresholds, or enforcement mechanisms. The protocol enables representation; the ecosystem decides how to populate and consume the exposed fields.¶

The proposal is intended as complementary to [I-D.loffredo-regext-rdap-verified-contacts], which establishes that contact data has been verified. The present extension adds a parallel layer: structured metadata about the security posture of the registrar and the domain itself.¶

2. Terminology

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.¶

The following terms are used throughout this document:¶

Assessment Envelope:

The structured set of fields defined by this extension, representing the result of a security or reliability assessment of a registrar or domain. The envelope carries the result and points to the methodology; it does not define the methodology itself.¶

Score Scheme:

An identifier or URI that denotes the scoring methodology used to produce an assessment result. The scheme defines the semantics of the score value, its range, and its criteria. Scheme definitions are maintained externally to this document.¶

Score Issuer:

An opaque identifier for the entity that performed the assessment and produced the score value. The format and resolution of this identifier are defined by the scoreScheme.¶

Extension Identifier:

The RDAP extension string registered in the IANA RDAP Extensions Registry that identifies this extension.¶

3. Motivation and Problem Statement

Research [DEEPSEC2025] has identified recurring systemic vulnerabilities in domain registrar processes that cannot be addressed by conventional technical security controls. These vulnerabilities arise from weaknesses in the interface between digital systems and human processes, and include deficiencies in credential recovery, identity verification, and email authentication configurations.¶

A notable characteristic of these vulnerabilities is their persistence: in several documented cases, exploitable issues remained unresolved for extended periods following responsible disclosure, reflecting diffuse accountability and the absence of structured incentives for timely remediation.¶

These findings suggest that while technical standards such as SPF [RFC7208], DKIM [RFC6376], and DMARC [RFC7489] are sound, their adoption and correct configuration cannot be reliably ensured without structured, machine-readable signaling mechanisms. The full technical details of the underlying research are documented in [DEEPSEC2025].¶

4. Design Principles

The following principles guide the design of this extension.¶

Separation of concerns:

This document defines the structured assessment envelope and extension points. The governance of who computes scores, the specific scoring methodology, any thresholds applied, and any enforcement actions based on scores belong to the operational and policy layer and are intentionally outside the scope of this document.¶

Envelope, not methodology:

The extension standardizes how assessment results are transported and referenced within RDAP. It does not standardize how assessments are performed, what criteria are evaluated, or what thresholds apply.¶

Extensibility:

The extension is designed to accommodate additional fields without breaking backward compatibility, consistent with RDAP's existing extensibility model.¶

Interoperability:

The extension is not tied to any specific registry, registrar, or policy framework. Any conformant RDAP server may implement it independently.¶

Complementarity:

The extension is designed to coexist with and extend [I-D.loffredo-regext-rdap-verified-contacts], rather than replace or duplicate it.¶

5. RDAP Extension: Data Model

{
  "rdapConformance": [
    "rdap_level_0",
    "rdap_reliability_scoring"
  ],
  "objectClassName": "entity",
  "handle": "REGISTRAR-EXAMPLE",
  "roles": ["registrar"],
  "rdap_reliability_scoring": {
    "scoreScheme": "urn:example:registrar-security-assessment:v1",
    "scoreValue": 8,
    "scoreMaxValue": 10,
    "scoreDate": "2026-01-15T10:30:00Z",
    "scoreIssuer": "example-assessor",
    "evidenceUri": "https://example-assessor.org/reports/reg-example"
  }
}

{
  "rdapConformance": [
    "rdap_level_0",
    "rdap_reliability_scoring"
  ],
  "objectClassName": "domain",
  "handle": "example.tld",
  "ldhName": "example.tld",
  "rdap_reliability_scoring": {
    "scoreScheme": "urn:example:domain-security-posture:v2",
    "scoreValue": 7,
    "scoreMaxValue": 10,
    "scoreDate": "2026-02-01T08:00:00Z",
    "scoreIssuer": "example-assessor",
    "evidenceUri": null
  },
  "events": [
    {
      "eventAction": "registration",
      "eventDate": "2024-01-01T00:00:00Z"
    }
  ]
}

6. Relationship to Existing Work

7. Security Considerations

The fields defined in this extension are informational. They do not constitute enforcement mechanisms and MUST NOT be interpreted as authoritative security certifications.¶

Score integrity:

Without appropriate authentication of the scoring entity, assessment metadata fields are susceptible to manipulation. Access to fields that can be modified programmatically SHOULD require mutual TLS authentication between client and server.¶

Gaming and abuse:

Any publicly visible scoring system creates incentives for gaming. The governance framework, which is outside the scope of this document, SHOULD address verification, audit, and revocation mechanisms.¶

False assurance:

Consumers of assessment metadata MUST NOT treat scores as equivalent to security certifications. A high score value does not guarantee the absence of vulnerabilities. Consumers SHOULD treat scores as one signal among many and SHOULD NOT make high-stakes trust decisions based solely on RDAP assessment fields.¶

Staleness:

Scores reflect the state at the time indicated by the "scoreDate" field. Consumers SHOULD check the freshness of assessment data and SHOULD treat scores that have not been updated recently with appropriate skepticism. Implementers MAY define an expiration policy based on the scoreScheme.¶

Scheme trust:

The reliability of assessment data depends on the trustworthiness of both the scoreIssuer and the scoreScheme. Consumers SHOULD establish out-of-band trust in the scoreIssuer before acting on assessment data.¶

Evidence URI:

The resource identified by evidenceUri is maintained by the scoreIssuer and is outside the control of the RDAP server. Its content may change over time, may be subject to access control, and may become unavailable. Consumers SHOULD NOT assume that the evidence resource is publicly accessible or immutable.¶

8. Privacy Considerations

The fields defined in this extension describe security posture at the registrar and domain level and are not intended to expose personal data. They are designed to be compatible with the access control framework defined in [RFC7481].¶

Implementers MUST ensure that the presence or absence of assessment metadata does not inadvertently reveal information about the identity of natural persons. The separation between assessment metadata, which is intended to be publicly accessible, and contact data, which is subject to access control per [RFC7481], MUST be maintained in conformant implementations.¶

This extension is intended to be compatible with applicable data protection regulations, including the General Data Protection Regulation [GDPR] and equivalent frameworks.¶

The evidenceUri field, if populated, SHOULD NOT point to resources that expose personal data or operationally sensitive details beyond what is necessary for the consumer to understand the assessment result.¶

9. IANA Considerations

This document requests the registration of the following entry in the IANA RDAP Extensions Registry:¶

Extension identifier:

rdap_reliability_scoring¶

Registry operator:

IANA¶

Published specification:

this document¶

Contact:

Alessandro Bertoldi (alessandro@bertoldicybersecurity.com)¶

10. References

Appendix A. Acknowledgments

The authors thank Pawel Kowalik, Mario Loffredo, Maurizio Martinelli, James Gould, and James Galvin for their early engagement and feedback during IETF 125.¶

Appendix B. Example RDAP Responses

The examples in this appendix are provided for illustrative purposes only. Score values, scheme identifiers, and issuer names are fictional.¶

{
  "rdapConformance": [
    "rdap_level_0",
    "rdap_reliability_scoring"
  ],
  "objectClassName": "domain",
  "handle": "example.tld",
  "ldhName": "example.tld",
  "rdap_reliability_scoring": {
    "scoreScheme": "urn:example:domain-security-posture:v2",
    "scoreValue": 9,
    "scoreMaxValue": 10,
    "scoreDate": "2026-01-01T00:00:00Z",
    "scoreIssuer": "example-assessor",
    "evidenceUri": "https://example-assessor.org/reports/example.tld"
  },
  "events": [
    {
      "eventAction": "registration",
      "eventDate": "2024-01-01T00:00:00Z"
    }
  ]
}

{
  "rdapConformance": [
    "rdap_level_0",
    "rdap_reliability_scoring"
  ],
  "objectClassName": "entity",
  "handle": "REGISTRAR-EXAMPLE",
  "roles": ["registrar"],
  "rdap_reliability_scoring": {
    "scoreScheme": "urn:example:registrar-security-assessment:v1",
    "scoreValue": 10,
    "scoreMaxValue": 10,
    "scoreDate": "2026-01-01T00:00:00Z",
    "scoreIssuer": "example-assessor",
    "evidenceUri": null
  }
}

{
  "rdapConformance": [
    "rdap_level_0"
  ],
  "objectClassName": "domain",
  "handle": "unassessed.tld",
  "ldhName": "unassessed.tld",
  "events": [
    {
      "eventAction": "registration",
      "eventDate": "2025-06-01T00:00:00Z"
    }
  ]
}

Appendix C. Illustrative Scoring Dimensions

This appendix describes possible dimensions that an operational scoring program might evaluate when producing assessment results to be carried by the envelope defined in this document. This content is entirely non-normative. Nothing in this appendix constrains implementers or defines mandatory evaluation criteria.¶

The intent is to demonstrate that the envelope model is expressive enough to carry results from real-world assessment programs, including those derived from existing empirical research on registrar security posture [DEEPSEC2025].¶

Authors' Addresses