RDAP Extension for Structured Reliability Assessment Metadata
draft-bertoldi-regext-rdap-reliability-scoring-05
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Alessandro Bertoldi , Simon Pietro Romano | ||
| Last updated | 2026-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bertoldi-regext-rdap-reliability-scoring-05
REGEXT A. Bertoldi
Internet-Draft Bertoldi Cybersecurity
Intended status: Experimental S. P. Romano
Expires: 24 April 2027 UNINA
21 October 2026
RDAP Extension for Structured Reliability Assessment Metadata
draft-bertoldi-regext-rdap-reliability-scoring-05
Abstract
This document defines an extension to the Registration Data Access
Protocol (RDAP) that enables the representation and exchange of
structured reliability assessment metadata for registrars and domain
names. The extension defines a structured assessment envelope
through which an RDAP server can expose assessment results produced
by a registry, registrar, or third-party assessor in a common,
machine-readable format within RDAP responses.
The extension standardizes how assessment results are transported and
referenced, not how they are computed. Scoring methodologies,
thresholds, criteria, and governance frameworks are intentionally
left to the operational and policy layer. This document does,
however, place requirements on the specification of any scheme whose
results are intended for publication through RDAP, because publishing
an evaluative judgement about an identified party without safeguards
for notification, remediation, and contestation is not a safe
practice.
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 24 April 2027.
Bertoldi & Romano Expires 24 April 2027 [Page 1]
Internet-Draft RDAP Reliability Assessment 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. What Distinguishes This Extension . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Motivation and Problem Statement . . . . . . . . . . . . . . 5
3.1. Assessment as an Instrument for Both Directions . . . . . 6
3.2. Relationship to Periodic Certification . . . . . . . . . 6
3.3. Why Protocol-Level Representation Helps . . . . . . . . . 7
4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 7
5. Deployment Model . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Deployment Configurations . . . . . . . . . . . . . . . . 8
5.2. Minimal Response . . . . . . . . . . . . . . . . . . . . 9
5.3. Endpoint Discovery . . . . . . . . . . . . . . . . . . . 10
5.3.1. Entity Objects . . . . . . . . . . . . . . . . . . . 10
5.3.2. Domain Objects . . . . . . . . . . . . . . . . . . . 11
5.4. Publication by an Authoritative Server . . . . . . . . . 12
6. Subject Binding . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Registrars . . . . . . . . . . . . . . . . . . . . . . . 14
6.3. What Remains Unresolved . . . . . . . . . . . . . . . . . 14
7. RDAP Extension: Data Model . . . . . . . . . . . . . . . . . 15
7.1. Extension Identifier . . . . . . . . . . . . . . . . . . 15
7.2. Extension Version Identifier . . . . . . . . . . . . . . 15
7.3. Namespacing Approach . . . . . . . . . . . . . . . . . . 16
7.4. Assessment Envelope . . . . . . . . . . . . . . . . . . . 16
7.5. Field Definitions . . . . . . . . . . . . . . . . . . . . 17
7.6. Result Status Values . . . . . . . . . . . . . . . . . . 20
7.7. Scheme Stability . . . . . . . . . . . . . . . . . . . . 20
7.8. Absence of the Member . . . . . . . . . . . . . . . . . . 21
7.9. Registrar Object Extension . . . . . . . . . . . . . . . 21
7.10. Domain Object Extension . . . . . . . . . . . . . . . . . 22
8. Requirements on Assessment Scheme Specifications . . . . . . 23
9. Relationship to Existing Work . . . . . . . . . . . . . . . . 25
Bertoldi & Romano Expires 24 April 2027 [Page 2]
Internet-Draft RDAP Reliability Assessment October 2026
9.1. Relationship to
draft-loffredo-regext-rdap-verified-contacts . . . . . . 25
9.2. Relationship to PIR Abuse Intervention Program . . . . . 25
9.3. Relationship to RDAP Core Specifications . . . . . . . . 26
10. Applicability and Implementation Status . . . . . . . . . . . 26
11. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11.1. Provenance and Authenticity . . . . . . . . . . . . . . 29
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
13.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 31
13.2. RDAP JSON Values Registry . . . . . . . . . . . . . . . 33
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.1. Normative References . . . . . . . . . . . . . . . . . . 33
14.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Changes from -04 . . . . . . . . . . . . . . . . . . 36
A.1. Changes from -03, retained for continuity . . . . . . . . 37
A.1.1. Where this revision comes from . . . . . . . . . . . 38
A.1.2. Deployment model . . . . . . . . . . . . . . . . . . 38
A.1.3. Attestation without a score . . . . . . . . . . . . . 39
A.1.4. Field semantics clarified . . . . . . . . . . . . . . 39
A.1.5. Subject binding . . . . . . . . . . . . . . . . . . . 40
A.1.6. Requirements on scheme specifications . . . . . . . . 40
A.1.7. Corrections and editorial changes . . . . . . . . . . 41
A.1.8. Considered and not done . . . . . . . . . . . . . . . 42
A.1.9. Changes from -02, retained for continuity . . . . . . 43
A.1.10. Changes from -01, retained for continuity . . . . . . 44
A.1.11. Breaking Changes . . . . . . . . . . . . . . . . . . 45
A.1.12. Additions . . . . . . . . . . . . . . . . . . . . . . 45
A.1.13. Corrections . . . . . . . . . . . . . . . . . . . . . 46
A.1.14. Deferred . . . . . . . . . . . . . . . . . . . . . . 46
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 46
Appendix C. Example RDAP Responses . . . . . . . . . . . . . . . 47
C.1. Domain Lookup with a Single Result . . . . . . . . . . . 47
C.2. Registrar Lookup with Results from Two Issuers . . . . . 48
C.3. Registrar Lookup with an Attestation Carrying No Score . 49
C.4. Domain Lookup without Assessment Metadata . . . . . . . . 49
Appendix D. Illustrative Assessment Dimensions . . . . . . . . . 50
D.1. Possible Registrar Assessment Dimensions . . . . . . . . 50
D.2. Possible Domain Assessment Dimensions . . . . . . . . . . 51
D.3. Note on Existing Operational Programs . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
Bertoldi & Romano Expires 24 April 2027 [Page 3]
Internet-Draft RDAP Reliability Assessment October 2026
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 allows the
inclusion of verification status information for contact fields,
indicating which pieces of contact data have been verified and how.
The present extension adds a parallel layer: structured metadata
about the security posture of the registrar and the domain itself.
1.1. What Distinguishes This Extension
Unlike most registration data fields, this extension carries
evaluative metadata whose interpretation and consequences depend on a
methodology and an issuer external to the RDAP server. This creates
materially different considerations regarding provenance,
contestation, staleness, and disclosure than those that apply to
registration data held by the responding authority. The remainder of
this document is shaped by that difference.
Bertoldi & Romano Expires 24 April 2027 [Page 4]
Internet-Draft RDAP Reliability Assessment October 2026
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 Result: The structured set of fields defined by this
extension representing a single result of a security or
reliability assessment of a registrar or domain, produced by one
issuer under one scheme. A result conveys what the scheme defines
it to convey, which may be a score or an attestation that the
properties the scheme defines were examined, and it points to the
methodology; it does not define the methodology itself.
Assessment Envelope: The array of assessment results carried by the
JSON member defined by this extension.
Score Scheme: An identifier or URI that denotes the assessment
methodology used to produce an assessment result. The scheme
defines the semantics of the result, its criteria, and, where the
result carries a score, its range. Scheme definitions are
maintained externally to this document.
Score Issuer: A globally unique and stable identifier for the entity
that performed the assessment and produced the result.
Assessed Party: The registrar or domain that is the subject of an
assessment result.
Assessment Service: An RDAP service that publishes assessment
results and is not authoritative for the registration data of the
assessed party.
Extension Identifier: The RDAP extension string that identifies this
extension in the IANA RDAP Extensions Registry.
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
Bertoldi & Romano Expires 24 April 2027 [Page 5]
Internet-Draft RDAP Reliability Assessment October 2026
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 [RFC9989] 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].
3.1. Assessment as an Instrument for Both Directions
A published assessment is not only exposure for a party that is
managed poorly. It is equally a means by which a well-run operator
can demonstrate its posture in a form that a third party can verify
and consume automatically. The absence of such a mechanism today
means that operators who invest in security have no interoperable way
to make that investment legible, and that operators who do not have
no structured incentive to change. Both effects are addressed by the
same mechanism.
3.2. Relationship to Periodic Certification
Certification and operational assessment address different needs and
are complementary rather than alternative.
Certification against a standard such as ISO/IEC 27001 [ISO27001] or
ISO/IEC 27701 [ISO27701] attests conformity within a defined scope at
a point in time, through a formal audit, and where the certification
body is accredited it carries the assurance of that accreditation.
An operational assessment can instead represent finer-grained
technical and procedural properties that change over time, such as
how credential recovery is handled or how email authentication is
configured on operator-controlled domains.
The intent of this document is not to displace certification, but to
complement it with a representation capable of expressing a more
frequent and more current view of security posture than a periodic
certification cycle can provide. Nothing in this document should be
read as suggesting that an assessment result is equivalent to, or a
substitute for, a certification.
Bertoldi & Romano Expires 24 April 2027 [Page 6]
Internet-Draft RDAP Reliability Assessment October 2026
3.3. Why Protocol-Level Representation Helps
Structured representation of assessment metadata at the protocol
level offers several complementary benefits relative to existing
operational approaches.
First, machine-readable assessment data, where its publication is
appropriate, creates reputational and commercial incentives for
registrars and domain owners to adopt and maintain security best
practices.
Second, a standardized RDAP extension enables any registry,
registrar, browser, or security tool to consume assessment metadata
through a common interface, eliminating dependency on proprietary or
registry-specific systems. The alternative, in practice, is each
assessor publishing its own HTTP interface with its own object model
and query syntax.
Third, protocol-level representation does not replace operational
scoring or enforcement programs. Rather, it provides a standardized
channel through which the outputs of such programs can be expressed
and consumed by the broader ecosystem.
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 results, the specific methodology, any thresholds
applied, and any enforcement actions based on results belong to
the operational and policy layer and are outside the scope of this
document. The requirements in Section 8 are the single deliberate
exception, and are requirements on a scheme specification rather
than on an RDAP server.
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.
Response extension, not query extension: This document defines no
new query, no new path segment, and no new query parameter. It
extends responses only.
Extensibility: The extension is designed to accommodate additional
fields without breaking backward compatibility, consistent with
RDAP's existing extensibility model.
Bertoldi & Romano Expires 24 April 2027 [Page 7]
Internet-Draft RDAP Reliability Assessment October 2026
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
complement [I-D.loffredo-regext-rdap-verified-contacts], rather
than replace or duplicate it.
5. Deployment Model
The -01 revision of this document described no deployment model.
Discussion at IETF 126 made clear that this was the principal gap,
and this section responds to it.
This revision examines the model by the class of the assessed object,
because the machinery by which an RDAP client reaches a server
differs between domain objects and entity objects. The examination,
prompted by the operator feedback recorded in Section 10, leads for
both classes to the same place: the server authoritative for the
object is the starting point, and an assessor reaches a client
through it or not at all, unless the client has been configured in
advance.
5.1. Deployment Configurations
The configurations below apply alike to registrars, represented as
entity objects, and to domain names. An earlier draft of this
revision distinguished the two by object class; the distinction did
not survive the examination of the discovery mechanisms in
Section 5.3, and this document now anticipates the same arrangement
for both.
Published by the authoritative server: The server authoritative for
the object includes the member defined by this extension in its
own response, either routinely or according to server policy,
including at the request of the client, or publishes a link to a
resource from which the result may be retrieved. For domain
objects no independent service can be discovered through the
bootstrap registries, and for entity objects the object tagging
practice of [RFC8521] is not available to a service that is not
authoritative, for the reasons given in Section 5.3; the
authoritative server is therefore the starting point available to
a client that has not been configured in advance. This is the
configuration this document anticipates, for both object classes.
Section 5.4 describes it.
Assessment service: An RDAP service operated by the assessor,
Bertoldi & Romano Expires 24 April 2027 [Page 8]
Internet-Draft RDAP Reliability Assessment October 2026
distinct from any authority for the registration data of the
assessed party. It is not discoverable through any standard
mechanism, and is reached only by a client configured out of band
with its base URL, or referred to it by an authoritative server.
It serves arrangements in which the parties know each other in
advance; Section 5.2 governs its responses.
Republication by another server: A registrar's RDAP server, an
aggregator, or another server that is not authoritative for the
object publishes an assessment result produced by a third party.
The first configuration above is itself a republication when the
result is produced by a third party, and both introduce an
intermediary between issuer and consumer; Section 11.1 discusses
what that implies for trust in the result.
Attestation published by the assessed party: The assessed party
publishes, or asks the server authoritative for it to publish, a
result issued by an independent assessor that the assessed party
itself commissioned. This is the arrangement familiar from
certification, and it differs from self-assessment in that the
issuer is not the assessed party. It is named here because the
considerations that constrain a registry publishing a judgement
about a registrar do not arise in the same form when the assessed
party asks for the publication.
Self-assessment: An operator publishing an assessment of itself.
This remains possible, but the identity of the issuer conveyed in
"scoreIssuer" allows a consumer to recognise the configuration and
to weigh the result accordingly.
No server is required to implement this extension and no operator is
required to publish a result. Section 7.8 states what may and may
not be inferred when the member is not present.
5.2. Minimal Response
This section applies to the assessment service configuration. Where
a result is carried in the response of the authoritative server, the
response is that server's own response and this section does not
apply to it. It is stated for both object classes: Section 5.3
explains why an assessment service is not discoverable for either,
but a client configured with its base URL may query it for both, and
the response it receives is governed by this section.
Clients MUST NOT treat an assessment service as authoritative for the
registration data of the assessed object.
Bertoldi & Romano Expires 24 April 2027 [Page 9]
Internet-Draft RDAP Reliability Assessment October 2026
An assessment service SHOULD return only the members required to bind
the response to the assessed object, together with the member defined
by this extension. For a domain object this is "objectClassName" and
"ldhName"; for an entity object it is "objectClassName", "handle",
and, where applicable, "publicIds" and "roles". The
"rdapConformance" member is required by [RFC9083].
The list above does not include a "self" link. [RFC9083] states that
a server SHOULD provide a link identifying the object class instance
itself, and an assessment service that can provide one SHOULD do so:
the purpose of this section is to limit the registration data that an
assessment service restates, not to suppress a link that identifies
the object at the assessment service.
An assessment service SHOULD NOT mirror the registration data
returned by the authoritative server and enrich it with assessment
metadata. Such a pattern would place the assessment service in the
position of restating registration data for which it has no authority
and no update path, and it is not a requirement of this document.
5.3. Endpoint Discovery
A client that has not been configured with a base URL discovers an
authoritative server through the bootstrap registries described in
[RFC9224], for the object classes those registries cover. What they
allow differs by object class; this section states the consequence
for each, and the consequence is the same.
5.3.1. Entity Objects
Section 9 of [RFC9224] states that entities are not bootstrapped by
the mechanism that document defines, and Section 6 of that document
points instead to [RFC8521].
[RFC8521] establishes an IANA registry of service provider object
tags. Section 3.1 of that document states that the registry is
populated using a First Come First Served policy, and that a
registration request carries an email address, the requested service
provider identifier, and one or more base RDAP URLs. That procedure
does not require authority over registration data. At the time of
writing the registry contains eight entries.
The -03 raised, and an earlier draft of this revision proposed to
rely on, the possibility that an assessment service register a tag of
its own and be reached through it. The abstract and Section 2 of
[RFC8521] describe the purpose of the mechanism as identifying the
authoritative server for a query, and an assessment service is
authoritative for the assessment representation it publishes but not
Bertoldi & Romano Expires 24 April 2027 [Page 10]
Internet-Draft RDAP Reliability Assessment October 2026
for the registration data of the assessed party. The authors put the
question to a registry operator with implementation experience in
this working group, who replied that such a use lies beyond the
purpose of the mechanism, which exists to bootstrap entity queries
and nothing else. This document adopts that reading. That the
registration procedure of Section 3.1 applies no test of authority
establishes only that it would not reject such a registration; it
does not make the use consistent with the practice, and this document
does not rely on it.
For entity objects, therefore, the position is the same as for domain
objects: an assessment service is not discoverable, and the starting
point available to a client that has not been configured in advance
is the authoritative server, described in Section 5.4. Whether the
working group sees a discovery arrangement this document has missed
is a question the authors will put to it.
5.3.2. Domain Objects
Section 12 of [RFC9224] states that the bootstrap service registries
are generated from the data, processes, and policies maintained by
IANA in its allocation registries, with the addition of RDAP server
information. Entries therefore follow delegation, and no independent
registration procedure exists. A service that does not operate a
top-level domain has no means of appearing there, and consequently no
standard means by which a client would find it.
This is a limit on discovery and not on reachability. A client that
has been configured out of band with the base URL of an assessment
service can query it, as it can query any RDAP service whose base URL
it holds. What the absence of a bootstrap entry removes is the
ability of an arbitrary client to find that service without prior
arrangement, and with it any path that works at the scale at which
RDAP clients operate. For domain objects, therefore, the only
standardized starting point available to a client that has not been
configured in advance is the authoritative server, which may carry
the result itself or refer the client to another service.
Section 5.4 addresses both.
This document does not define a parallel bootstrap. Defining one
would assert an authority this document does not have and does not
seek.
Bertoldi & Romano Expires 24 April 2027 [Page 11]
Internet-Draft RDAP Reliability Assessment October 2026
5.4. Publication by an Authoritative Server
The -03 revision of this document considered, and did not propose, a
mechanism by which an authoritative RDAP server would point at an
assessment service, on the ground that a link so published could
reasonably be read as an endorsement of the assessor. Section 5.3
shows that for both object classes the authoritative server is the
only standardized starting point available to a client that has not
been configured in advance. This revision therefore revisits that
position.
Two arrangements are possible, and they are not equivalent.
Carrying the result: The authoritative server includes the member
defined by this extension in its own response, at the request of
the client. No third party is named as a destination and no
client is directed elsewhere. A mechanism by which a client
signals the extensions it wishes to receive is the subject of
[I-D.ietf-regext-rdap-x-media-type].
Referring to a service: The authoritative server publishes a link to
a resource from which the result may be retrieved.
[I-D.ietf-regext-rdap-referrals] describes a mechanism by which a
client may ask to be redirected to a related resource rather than
retrieve the whole record; that mechanism operates on links a
server already holds and does not create them. In its -05
revision the link is selected by the relation type named in the
request, and none of the relation types defined by that document
or by [I-D.ietf-regext-rdap-extensions] describes the result of an
assessment. This document defines none, and leaves to the Working
Group the question of which document, if any, should.
On the question of endorsement, this document now takes a narrower
view than the -03 did, and states it precisely because the narrow
claim is the only one that holds. A response carrying a result
attributed to the issuer named in the required "scoreIssuer" member
conveys that attribution and nothing further about the publisher:
neither this extension nor core RDAP assigns the carriage of an
assessment result a standardized semantic of agreement or endorsement
by the publishing server. A server that wishes to state a position
on a result it carries has the general means [RFC9083] provides for
free text, and does so in its own words rather than by the act of
carriage. What is absent from the protocol is an encoding of
agreement.
Three things are distinct here, and the -03 ran them together. The
first is what the protocol encodes, which is an attribution and no
more. The second is the choice the publisher makes in carrying one
Bertoldi & Romano Expires 24 April 2027 [Page 12]
Internet-Draft RDAP Reliability Assessment October 2026
result rather than another, which belongs to the publisher whatever
the protocol encodes. The third is the exposure that choice creates,
which is a matter for Section 8 and for the law applicable to the
publisher, and which this document does not purport to settle. The
narrow claim disposes of the first. It does not dispose of the
second or the third, and this revision does not claim that it does.
The earlier concern is therefore not dismissed. A server that
selects one assessor among several, or that publishes on its own
initiative rather than on request, makes a choice that goes beyond
transmission, and in practice a server that carries results at all
has decided whose results it will carry. Publication at the request
of the client, and the identification of the issuer in the result,
narrow that choice; they do not remove it. Publication on request is
a policy a server may adopt, and this document defines no means of
expressing the request; it is not a condition for the extension to
function, and a server may include the member in every response for
which it holds a result.
A third arrangement was suggested to the authors by the registry
operator whose review is recorded in Section 10: a dedicated path
segment served by the authoritative server, which would either return
the result or redirect the client to a service that does. It has the
merit of letting a server refer without holding the data, and of
giving the client a single form of query for both. It would also
make this a query extension as well as a response extension, with the
consequences described in Section 6.2, and it is therefore not
defined in this revision; it is recorded here as a candidate for a
later one.
In every arrangement the decision belongs to the server. Nothing in
this document requires an authoritative server to support this
extension, to publish a result, or to refer to one. An operator that
does publish is expected to do so under a scheme whose specification
satisfies Section 8, which this revision extends to cover the
exposure of the publishing party; the requirements in that section
are addressed to the scheme specification and not to the server.
6. Subject Binding
An assessment result is only meaningful if the object it is attached
to can be bound unambiguously to the assessed party.
Bertoldi & Romano Expires 24 April 2027 [Page 13]
Internet-Draft RDAP Reliability Assessment October 2026
6.1. Domains
For domain objects, "ldhName" provides the standard lookup key: the
query form domain/<domain name> defined in Section 3.1.3 of [RFC9082]
can use the value of "ldhName" unchanged. No additional mechanism is
required.
6.2. Registrars
For entity objects the situation is less straightforward. [RFC9082]
defines entity lookup as /entity/<handle> (Section 3.1.5), where the
syntax of a handle is specific to the registration provider, and
entity search as /entities?fn= and /entities?handle= (Section 3.2.3).
Neither search key is an IANA Registrar ID. The "publicIds" member,
which is where such an identifier would be carried, is a response
structure and is neither a lookup key nor a defined search key.
An assessment service SHOULD use its own service-local handle for
/entity/<handle> lookups, and SHOULD include a "publicIds" member
binding that local object to the assessed registrar, for example
through the applicable IANA Registrar ID. An IANA Registrar ID is
assigned by ICANN to registrars in the gTLD system; a registrar
operating only under a ccTLD registry need hold none, and a scheme
intended for such registrars will need another identifier type in
"publicIds". Where the result is published by the authoritative
server, as Section 5.1 anticipates, the entity object is that
server's own and carries whatever identifiers it already assigns.
This document deliberately does not define a lookup by IANA Registrar
ID. Doing so would convert this extension from a response extension
into a query extension, with the consequences described in
Section 2.3 of [I-D.ietf-regext-rdap-extensions], and the authors do
not consider it warranted at this stage.
6.3. What Remains Unresolved
Two assessors will use different local handles for the same
registrar, and "publicIds" supplies the binding only after the object
has been retrieved. A client that holds an IANA Registrar ID and
wishes to locate the corresponding object at a known assessment
service therefore has no in-band means of constructing the query.
Object tagging [RFC8521] would close that gap where the handle
carries a suffix identifying the RDAP service provider, and an
earlier draft of this revision proposed a convention for it, being
the IANA Registrar ID followed by the assessor's registered provider
tag. The convention is withdrawn. Section 5.3.1 records that the
practice is not available to a service that is not authoritative for
Bertoldi & Romano Expires 24 April 2027 [Page 14]
Internet-Draft RDAP Reliability Assessment October 2026
the registration data, and the convention would in any case have
served only registrars that hold an IANA Registrar ID, which those
operating under ccTLD registries need not. The gap is therefore
stated and left open, as the -03 left it, and this document proposes
no convention for the local part of a handle at an assessment
service.
Where the result is published by the authoritative server, as
Section 5.1 anticipates, the gap does not arise. The entity object
representing the registrar at that server carries the handle that
server assigns, and a client reaches it from the registration data it
already holds, through the "entities" member of a domain object or
through the server's own lookup and search facilities.
7. RDAP Extension: Data Model
7.1. Extension Identifier
This extension is identified by the string "reliabilityAssessment",
which is registered in the IANA RDAP Extensions Registry (see
Section 13). RDAP responses that include this extension MUST include
the extension identifier in the "rdapConformance" array.
Consistent with Section 2.2 of [I-D.ietf-regext-rdap-extensions], the
extension identifier contains no underscore character. The JSON
member defined by this extension is prefixed with the extension
identifier, avoiding the bare extension identifier pattern discussed
in Section 2.2.1 of that document.
7.2. Extension Version Identifier
Section 5.4 of [I-D.ietf-regext-rdap-extensions] states that RDAP
extension identifiers are opaque and that extensions without an
explicitly defined versioning scheme are opaquely versioned. This
extension defines no such scheme, and is therefore opaquely
versioned.
Section 6.1 of [I-D.ietf-regext-rdap-versioning] provides that all
extensions support Opaque Versioning by default and that an extension
document should identify the versioning types it supports together
with the associated extension version identifier. Accordingly:
Versioning type: Opaque Versioning, as described in Section 5.1 of
[I-D.ietf-regext-rdap-versioning].
Extension version identifier: reliabilityAssessment
Bertoldi & Romano Expires 24 April 2027 [Page 15]
Internet-Draft RDAP Reliability Assessment October 2026
This document does not use Point Versioning. It defines a single
version of a single extension, and the machinery for negotiating
concurrent versions is not warranted at this stage. Nothing in this
choice precludes the later adoption of Point Versioning: an extension
supporting another versioning type may still be referred to using
Opaque Versioning.
Implementation of [I-D.ietf-regext-rdap-versioning] is not required
in order to implement this extension, and this document places no
such requirement on clients or servers.
Consistent with Section 5.4 of [I-D.ietf-regext-rdap-extensions], any
change to this extension that is not backward compatible will require
the registration of a new extension identifier and a new
specification.
7.3. Namespacing Approach
This extension groups all its fields under a single top-level JSON
member named "reliabilityAssessment_results". The member name is
prefixed with the extension identifier, while the members of the
objects it contains (scoreScheme, scoreValue, and so on) are not
individually prefixed. This follows the guidance in Section 2.4.2 of
[I-D.ietf-regext-rdap-extensions], which states that prefixing is not
required for children of a prefixed JSON object defined by an RDAP
extension.
7.4. Assessment Envelope
The "reliabilityAssessment_results" member contains a JSON array of
assessment result objects. This member MAY appear within entity
objects (objectClassName: "entity") and domain objects
(objectClassName: "domain"). An entity is considered to represent a
registrar when its "roles" array includes the value "registrar" as
defined in Section 10.2.4 of [RFC9083].
If the member is present, the array MUST contain at least one
element. The order of elements is not significant, and clients MUST
NOT infer precedence, authority, or recency from position. Clients
MUST NOT assume that the array contains exactly one element.
A server SHOULD publish at most one current result for any given
combination of "scoreScheme" and "scoreIssuer".
Each result reports an external assessment and points to the
methodology used. What the result conveys is determined by that
methodology, as Section 7.5 describes. This document does not define
the methodology, the criteria, or the thresholds.
Bertoldi & Romano Expires 24 April 2027 [Page 16]
Internet-Draft RDAP Reliability Assessment October 2026
7.5. Field Definitions
The members of each assessment result object are described in the
following table.
+===============+=============+=====================================+
| Field | Type | Description |
+===============+=============+=====================================+
| scoreScheme | string | REQUIRED. Identifies the |
| | | methodology used to produce the |
| | | result. It SHOULD be a URI |
| | | conforming to [RFC3986]. An |
| | | HTTPS URI under a domain the |
| | | issuer controls is the form this |
| | | document recommends, because the |
| | | domain gives the issuer a name |
| | | space in which it can assign |
| | | scheme identifiers without |
| | | colliding with those of another |
| | | issuer, and because the scheme |
| | | definition may also be made |
| | | retrievable at that address. |
| | | Another URI form that provides an |
| | | equivalent delegated name space, |
| | | such as a URN under a registered |
| | | namespace identifier, serves the |
| | | same purpose. Neither [RFC3986] |
| | | nor this document requires a URI |
| | | to be dereferenceable. Where it |
| | | is not a URI it is an opaque |
| | | string whose meaning is defined |
| | | solely by the issuer identified |
| | | in "scoreIssuer", and it MUST NOT |
| | | be assumed to be unique outside |
| | | that issuer. The scheme defines |
| | | the semantics and criteria of the |
| | | result and, where the result |
| | | carries a score, its range. |
| | | Scheme definitions are maintained |
| | | externally. |
+---------------+-------------+-------------------------------------+
| scoreIssuer | string | REQUIRED. Identifies the entity |
| | (URI) | that performed the assessment and |
| | | issued the result. It MUST be a |
| | | URI conforming to [RFC3986], |
| | | globally unique and stable, and |
| | | SHOULD be under the control of |
| | | the issuer. |
Bertoldi & Romano Expires 24 April 2027 [Page 17]
Internet-Draft RDAP Reliability Assessment October 2026
+---------------+-------------+-------------------------------------+
| scoreValue | number | OPTIONAL. The non-negative |
| | | numeric result of the assessment, |
| | | as defined by the scoreScheme. |
| | | If scoreMaxValue is present, |
| | | scoreValue MUST NOT exceed it. |
+---------------+-------------+-------------------------------------+
| scoreMaxValue | number | OPTIONAL. The non-negative upper |
| | | bound of the range defined by the |
| | | scoreScheme. When this member is |
| | | present the range runs from zero |
| | | to scoreMaxValue inclusive, so |
| | | that together with scoreValue it |
| | | allows a consumer to place the |
| | | numeric result on the scale |
| | | without resolving the scheme. A |
| | | scheme whose range does not begin |
| | | at zero, or whose results are not |
| | | bounded, omits this member. |
+---------------+-------------+-------------------------------------+
| scoreDate | string | OPTIONAL. The date and time at |
| | (date-time) | which the assessment was |
| | | performed, in the format defined |
| | | in [RFC3339]. |
+---------------+-------------+-------------------------------------+
| validUntil | string | OPTIONAL. The date and time |
| | (date-time) | after which the issuer no longer |
| | | asserts the result as current, in |
| | | the format defined in [RFC3339]. |
| | | Its expiry does not render the |
| | | result invalid; it indicates that |
| | | the issuer does not vouch for its |
| | | currency beyond that point. |
| | | Where scoreDate is also present, |
| | | validUntil MUST NOT precede it. |
| | | After validUntil, a status of |
| | | "active" conveys the state the |
| | | issuer last asserted and not a |
| | | current assertion; see |
| | | Section 7.6. |
+---------------+-------------+-------------------------------------+
| assessmentId | string | OPTIONAL. An identifier for this |
| | | specific result, unique within |
| | | the scope of the combination of |
| | | scoreScheme and scoreIssuer. It |
| | | allows a specific result to be |
| | | referenced, in particular in a |
| | | contestation or correction |
Bertoldi & Romano Expires 24 April 2027 [Page 18]
Internet-Draft RDAP Reliability Assessment October 2026
| | | process. |
+---------------+-------------+-------------------------------------+
| status | string | OPTIONAL. The lifecycle state of |
| | | the result as asserted by the |
| | | issuer. Permitted values are |
| | | defined in Section 7.6. |
+---------------+-------------+-------------------------------------+
| evidenceUri | string | OPTIONAL. A URI pointing to |
| | (URI) | supporting documentation, a |
| | | detailed report, or the full |
| | | assessment record maintained by |
| | | the scoreIssuer. |
+---------------+-------------+-------------------------------------+
Table 1
A member for which no value is available is omitted rather than being
included with a null value.
If "scoreValue" is present, "scoreDate" SHOULD also be present, so
that the result can be situated in time. If "scoreMaxValue" is
present, "scoreValue" SHOULD also be present.
A result need not carry a score. "scoreValue" and "scoreMaxValue" are
both OPTIONAL, and a result consisting of "scoreScheme",
"scoreIssuer", and where applicable "scoreDate", "status" and
"evidenceUri", is complete and conformant. Such a result attests
that the properties defined by the scheme were examined by the named
issuer, on the date given where "scoreDate" is present; it expresses
no numeric judgement, and a consumer MUST NOT infer one from its
absence. Since the date is what gives such an attestation its
meaning, "scoreDate" SHOULD be present in a result that carries no
score, as it SHOULD be in one that does.
The distinction matters beyond presentation. A numeric result
invites reading as a rating of the assessed party, with the
consequences described in Section 11. A result carrying no score
reports what was examined and, where "scoreDate" is present, when,
and is closer in kind to the statement that a property has been
verified. A scheme intended for publication through RDAP may be
defined either way, and the choice is the scheme's; this document
records only that the second is available and is not a degraded form
of the first. Appendix C.3 shows a result of this kind.
The field values used in the examples in this document and in
Appendix C are illustrative and carry no normative meaning. Each
example is to be read as if retrieved shortly after the time given in
its "scoreDate".
Bertoldi & Romano Expires 24 April 2027 [Page 19]
Internet-Draft RDAP Reliability Assessment October 2026
Where "scoreScheme" and "scoreIssuer" are compared, for example to
determine whether two results were produced by the same issuer under
the same scheme, they are compared as strings, character by
character, without any URI normalization. An issuer that publishes
results is therefore expected to use one consistent spelling of each
value. Section 6 of [RFC3986] describes why URI equivalence is
otherwise application-dependent.
7.6. Result Status Values
The "status" member, when present, takes one of the following values:
active: The issuer asserts the result as current. Where
"validUntil" is present and has passed, the value conveys the
state the issuer last asserted, and the consumer treats the result
as stale as described in Section 11.
under review: The result is the subject of a review or contestation
process, and the issuer indicates that it may change. Consumers
SHOULD treat a result in this state with additional caution.
withdrawn: The issuer no longer asserts the result. A withdrawn
result MAY continue to be published so that consumers holding a
cached copy can observe the withdrawal.
The absence of the "status" member means that the issuer does not
convey a lifecycle state. Consumers MUST NOT assume a value of
"active" in that case.
These values are scoped to the "status" member of an assessment
result object as defined by this extension. They are distinct from,
and do not interact with, the RDAP status values defined in
Section 10.2.2 of [RFC9083]. This document does not define a
supersession mechanism. A server that publishes only current results
does not require one, and the publication of assessment history is
outside the scope of this document.
7.7. Scheme Stability
If all semantics of a result are defined outside this protocol, the
identity of the scheme must be stable for those semantics to be
resolvable.
Bertoldi & Romano Expires 24 April 2027 [Page 20]
Internet-Draft RDAP Reliability Assessment October 2026
The semantics associated with a given combination of "scoreIssuer"
and "scoreScheme" MUST NOT change in a manner that is not backward
compatible. A revision of a scheme that is not backward compatible
MUST be assigned a new scheme identifier. Where "scoreScheme" is a
URI under the issuer's control the identifier is unique on its own;
where it is an opaque string, its meaning is scoped to the issuer, as
Section 7.5 states, and so is the stability required here.
7.8. Absence of the Member
Clients MUST NOT interpret the absence of the
"reliabilityAssessment_results" member as evidence that the object
has not been assessed, nor as a negative assessment of the object.
The member may be absent because the object has not been assessed,
because it has been assessed but the result is not published, because
publication is withheld under server policy, because the data is
subject to access control and the client is not authorized, or
because the server does not implement this extension.
This document deliberately defines no signal distinguishing "not
assessed" from "assessed but not disclosed". Such a signal would
defeat the purpose of withholding a result, since it would itself
indicate that there is something to withhold, and would reintroduce
the disclosure risk described in Section 11.
7.9. Registrar Object Extension
The following example illustrates a lookup response for an entity
object representing a registrar, carrying the assessment envelope.
The "rdapConformance" member appears because the example is a
complete response; per Section 4.1 of [RFC9083] it appears only in
the topmost object of a response and never in a nested one.
Bertoldi & Romano Expires 24 April 2027 [Page 21]
Internet-Draft RDAP Reliability Assessment October 2026
{
"rdapConformance": [
"rdap_level_0",
"reliabilityAssessment"
],
"objectClassName": "entity",
"handle": "RAR999999",
"roles": ["registrar"],
"publicIds": [
{
"type": "IANA Registrar ID",
"identifier": "999999"
}
],
"reliabilityAssessment_results": [
{
"scoreScheme": "https://assessor.example/schemes/registrar/v1",
"scoreIssuer": "https://assessor.example",
"scoreValue": 8,
"scoreMaxValue": 10,
"scoreDate": "2026-01-15T10:30:00Z",
"validUntil": "2026-07-15T00:00:00Z",
"assessmentId": "a-2026-01-15-0042",
"status": "active",
"evidenceUri": "https://assessor.example/rep/a-2026-01-15-0042"
}
]
}
7.10. Domain Object Extension
The following example illustrates a lookup response for a domain
object carrying the assessment envelope.
Bertoldi & Romano Expires 24 April 2027 [Page 22]
Internet-Draft RDAP Reliability Assessment October 2026
{
"rdapConformance": [
"rdap_level_0",
"reliabilityAssessment"
],
"objectClassName": "domain",
"handle": "D-EXAMPLE-1",
"ldhName": "example.com",
"reliabilityAssessment_results": [
{
"scoreScheme": "https://assessor.example/schemes/domain/v2",
"scoreIssuer": "https://assessor.example",
"scoreValue": 7,
"scoreMaxValue": 10,
"scoreDate": "2026-02-01T08:00:00Z",
"status": "active"
}
]
}
8. Requirements on Assessment Scheme Specifications
This document does not define assessment methodologies. It does,
however, place requirements on the specification of a scheme whose
results are intended for publication through RDAP, because publishing
an evaluative judgement about an identified party without safeguards
is not a safe practice, and because this document creates the channel
through which such publication would occur.
A specification defining a "scoreScheme" whose results are intended
for publication through RDAP:
* MUST document a disclosure threat model, describing what an
adversary could learn from the published result and how that risk
is weighed against the benefit of publication;
* MUST define a notification to the assessed party prior to
publication of a result;
* MUST define a period, following that notification and preceding
publication, during which the assessed party may remediate the
findings or contest the result;
* SHOULD define whether a reassessment performed within that period
replaces the pending result, so that a party that remediates
promptly is not exposed by a result that no longer reflects its
posture;
Bertoldi & Romano Expires 24 April 2027 [Page 23]
Internet-Draft RDAP Reliability Assessment October 2026
* MUST describe how data minimization is applied, stating whether
aggregation, coarse granularity, access control, or delayed
publication are used, and why the chosen granularity is
appropriate;
* MUST state whether its results are intended for publication in
respect of domain objects and, if so, MUST justify that choice
specifically against the targeting risk described in Section 11;
* MUST state the basis on which the party that publishes a result
relies in publishing it, whether contractual, consensual,
statutory, or other, and MUST state how the scheme allocates
between the issuer and the publisher the exposure arising from
publication. Nothing in this document can prevent a claim from
being brought against a publisher, and the requirement is not that
the scheme assert otherwise; it is that the question be answered
in the scheme rather than discovered by the publisher. A scheme
that leaves the consequences of publication entirely with whoever
transmits the result is unlikely to be deployed by anyone;
* SHOULD state the basis of the assessor's standing: whether it is
accredited under a recognised scheme, engaged by the assessed
party, or neither. This document does not require accreditation,
does not name any body competent to grant it, and does not create
one. It asks only that the basis be declared, so that a consumer
can weigh the result knowing what lies behind it.
Where publication of a result is required of an operator by law, the
obligation supplies the basis on which that operator publishes, and
the arrangements that would otherwise govern the decision do not
stand in its way. Where the law prescribes for that publication a
procedure that is incompatible with the notification and the period
required above, the procedure prescribed by law governs, and a scheme
intended for use under such an obligation states which of the
requirements above the obligation displaces. This document neither
creates such an obligation nor assumes one, and states the case only
because it is the one case in which the decision is not the
operator's to make.
This document deliberately does not prescribe the duration of the
remediation and contestation period, the governance of the process,
the body responsible for adjudicating a contestation, or the
consequences of a successful one. Those belong to the scheme and its
operational model.
Bertoldi & Romano Expires 24 April 2027 [Page 24]
Internet-Draft RDAP Reliability Assessment October 2026
There is a tension that this document cannot resolve on its own: the
more actionable a signal is for defenders, the more useful it is to
attackers. The requirements above are intended to force each scheme
to confront that tension explicitly rather than to leave it
unexamined.
9. Relationship to Existing Work
9.1. Relationship to draft-loffredo-regext-rdap-verified-contacts
The [I-D.loffredo-regext-rdap-verified-contacts] extension allows the
inclusion of verification status information for contact fields
associated with a domain or registrar, indicating which pieces of
contact data have been verified and how. The present extension adds
a complementary and orthogonal layer: structured metadata about the
security posture of the registrar and the domain itself.
The two extensions answer different questions. The verified-contacts
extension conveys which contact fields have been verified and how the
verification was performed. The reliability assessment extension
addresses what the assessed security posture of the entity managing
that domain is. Both are expressible within the RDAP framework and
are designed to coexist within the same RDAP response.
9.2. Relationship to PIR Abuse Intervention Program
The Public Interest Registry (PIR) publishes a Quality Performance
Index (QPI) [PIR-QPI], and has described an Abuse Intervention
Program [PIR-AIP]. PIR states that QPI is calculated from three core
key performance indicators, named by PIR as Abuse Takedown, Renewal
Rates, and Domain Usage, and three secondary ones, named by PIR as
SSL, DNSSEC, and ATL. PIR states that it has made the QPI program
and algorithm available to all members of the domain industry rather
than confining them to a single name space.
This document does not standardize such a program; it defines a
generic RDAP representation that could carry outputs produced by
programs such as QPI or other assessment frameworks. An operational
scoring system of this kind could, in principle, expose its outputs
through the envelope defined in this document, enabling broader
interoperability without modifying its internal methodology. The
authors note that PIR has not, to their knowledge, undertaken RDAP
work in connection with these programs.
Bertoldi & Romano Expires 24 April 2027 [Page 25]
Internet-Draft RDAP Reliability Assessment October 2026
9.3. Relationship to RDAP Core Specifications
This extension is designed to be fully conformant with the RDAP core
specifications [RFC7480] [RFC7481] [RFC9082] [RFC9083] [RFC9224]. It
uses the JSON response format defined in [RFC9083], the extensibility
model provided in [RFC7480], and the security framework of [RFC7481].
Query formats follow [RFC9082] and are not extended by this document.
10. Applicability and Implementation Status
The authors are aware of no implementation of this extension at the
time of writing, and state this explicitly rather than leave it to be
inferred.
Since the -03 revision the authors have put the question directly to
registry operators, on the view that a statement that a party would
not use the extension, together with the reason, is worth more than
silence. The results are recorded here because they shaped this
revision.
One European ccTLD registry operating under the Network and
Information Security Directive replied that the extension is not
implementable by it, and gave three reasons. First, its policies are
agreed with its registrars, who are represented in its governing body
and whose obligations are set out in the registry-registrar contract;
it therefore cannot unilaterally publish an assessment of the
reliability of a registrar or of that registrar's domains. Second,
the methodology would need to shield the registry from a claim for
reputational damage brought by a registrar assessed poorly. Third,
the operational cost of consuming or republishing results at the
scale of a production RDAP service, or of producing them in-house
across millions of domains and hundreds of registrars, is
considerable.
The same operator cautioned against generalising from its own
governance model, observing that ccTLD registries each have their
own, that gTLD registries follow rules set by ICANN, and that both
are further subject to the law of the jurisdictions in which they
operate. That caution is recorded here and adopted: this document
does not claim that registries in general cannot publish assessments.
Asked subsequently whether the object tagging practice of [RFC8521]
could be used to reach an assessment service that is not
authoritative for the registration data, the same operator replied
that it could not: the practice exists to bootstrap entity queries
and nothing else. It described the arrangements it considered
practicable within the operational model of RDAP: the authoritative
server carrying the result in its own response; the authoritative
Bertoldi & Romano Expires 24 April 2027 [Page 26]
Internet-Draft RDAP Reliability Assessment October 2026
server publishing a link to a resource that provides it; or a
dedicated path segment at the authoritative server that either
returns the result or redirects to a service that does. It also
noted that an IANA Registrar ID is assigned in the gTLD system and
that registrars operating only under a ccTLD need not hold one. The
operator stated that it is not persuaded that this document should be
adopted, and that its observations are to be read neither as an
endorsement of the document nor as any intention on its part to
implement the extension. They are recorded here on that
understanding.
Four consequences were drawn, and each is visible in this revision.
The constraint applies to a registry publishing a judgement about
parties that co-govern it, which is why Section 5.1 now names the
case in which the assessed party itself asks for publication. The
discovery question is why Section 5.3 was rewritten, and the reply on
object tagging is why the assessment service is no longer the
configuration this document anticipates for registrars, and why
Section 6.3 proposes no handle convention. The protection of the
publishing party is why Section 8 now requires a scheme to address
it. And the dedicated path segment is recorded in Section 5.4 for a
later revision.
A second operator, a gTLD registry, confirmed that the request had
been reviewed internally and that a discussion had been requested,
which had not taken place at the time of writing.
The configurations in which the extension is expected to be useful
are those described in Section 5: a result carried by an
authoritative server at the request of a client, or reached through a
link that server publishes; an attestation published at the instance
of the assessed party; an assessment service operated by a research
group, a security vendor, or a sector body, for clients configured to
reach it; and, more marginally, self-assessment. The consumers
anticipated are RDAP clients operated by registries, registrars,
enterprise security teams, and researchers.
The authors continue to welcome statements of interest, and equally
statements of the contrary with their reasons, from any party that
operates or plans to operate an assessment program, implements RDAP
clients, or would consume this kind of data.
11. Security Considerations
The fields defined in this extension are informational. They do not
constitute enforcement mechanisms, and clients MUST NOT treat them as
authoritative security certifications.
Bertoldi & Romano Expires 24 April 2027 [Page 27]
Internet-Draft RDAP Reliability Assessment October 2026
Reconnaissance and exposure: A published result indicating a weak
security posture is itself a signal that may be used to identify
and prioritise targets. The risk increases where the result is
accompanied by the methodology, the assessment date, evidence, or
the specific dimensions that contributed to it. The risk is
materially greater for domain objects than for registrar objects,
since a domain-level result may identify an individual poorly
defended target, whereas a registrar-level result concerns an
accountable operator of scale. Section 8 requires each scheme to
address this explicitly.
Relationship to risk-based regulatory obligations: The Network and
Information Security Directive [NIS2] does not explicitly prohibit
the publication of a security or reliability result concerning a
domain name or a registrar. Article 21(1) does, however, require
Member States to ensure that essential and important entities take
appropriate and proportionate technical, operational and
organisational measures to manage the risks posed to the security
of the network and information systems those entities use, and
Article 21(2) provides that such measures shall include at least a
list of items, among them "policies on risk analysis and
information system security" at point (a) and security in
acquisition, development and maintenance "including vulnerability
handling and disclosure" at point (e). Systematic and
unauthenticated public disclosure of assessment results may be
difficult to reconcile with those obligations where the disclosure
substantially increases the exposure of the assessed entity.
Implementers operating under that framework, or an equivalent one,
should assess the publication of results accordingly. That
directive is not the only regime that may bear on publication:
data protection law, the law of defamation, trade secret
protection, and applicable national law may each constrain the
publication of an evaluative result about an identified party.
Perception as a rating: An assessment result may be read as a rating
of the assessed party, with consequent reputational, commercial,
and legal exposure, irrespective of the intent of the scheme that
produced it. Publication is therefore not a neutral act, and
Section 8 places requirements on schemes accordingly.
Volatility: A result may change quickly. A value published today
may be higher or lower tomorrow, and a consumer acting on a result
may be acting on a state of affairs that no longer holds. The
"validUntil" and "status" members provide partial mitigation but
do not eliminate this.
Access control and server policy: Publication of assessment metadata
Bertoldi & Romano Expires 24 April 2027 [Page 28]
Internet-Draft RDAP Reliability Assessment October 2026
is not mandatory. A server MAY expose this extension only to
authenticated and authorized clients, and MAY apply different
policies to registrar and domain objects. Nothing in this
document requires that assessment metadata be publicly accessible.
Inference from absence: See Section 7.8. The absence of assessment
metadata is not evidence of anything, and clients MUST NOT treat
it as such.
Result integrity: This document does not define an interface for
creating or modifying assessment metadata. Any administrative or
provisioning interface used for that purpose MUST authenticate and
authorize the submitting entity and MUST provide appropriate
integrity and confidentiality protection. Without authentication
of the issuing entity, assessment metadata is susceptible to
manipulation.
Gaming and abuse: Any visible scoring system creates incentives for
gaming. The governance framework, which is outside the scope of
this document, is expected to address verification, audit, and
revocation mechanisms.
False assurance: Consumers of assessment metadata MUST NOT treat
results as equivalent to security certifications. A high value
does not guarantee the absence of vulnerabilities. Consumers
SHOULD treat results as one signal among many and SHOULD NOT make
high-stakes trust decisions based solely on RDAP assessment
fields.
Staleness: Where "scoreDate" is present, a result reflects the state
at the time it indicates. Consumers SHOULD check freshness where
the result carries the information to do so, and SHOULD treat
results that have not been updated recently, that carry no date,
or that are past their "validUntil", with appropriate skepticism.
Evidence URI: The resource identified by "evidenceUri" is maintained
by the issuer 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.
11.1. Provenance and Authenticity
Three distinct properties are frequently conflated when reasoning
about assessment metadata, and this document separates them
explicitly.
Identity: To whom a result is attributed. The "scoreIssuer" member
Bertoldi & Romano Expires 24 April 2027 [Page 29]
Internet-Draft RDAP Reliability Assessment October 2026
conveys this, and the requirement that it be a stable globally
unique URI ensures that the attribution is unambiguous.
Trust: Whether the consumer has grounds to rely on the named issuer.
This is established out of band and is not conveyed by the
protocol.
Authenticity: Whether the assertion in fact originated with the
named issuer and was relayed unaltered. This is not established
by the protocol.
The "scoreIssuer" member records to whom a result is attributed. It
does not demonstrate that the named issuer produced it, nor that the
publishing server relayed it unaltered.
Where the assessor operates its own assessment service, trust in the
endpoint and trust in the issuer can reasonably coincide, because the
consumer's out of band trust configuration names both. Where a
registry, registrar, or other server republishes an assessor's
result, the consumer must additionally trust the publisher as an
intermediary, and this document provides no means by which a consumer
can distinguish the two cases from the response alone.
This is a known limitation of the present revision, stated here
rather than left implicit. Consumers SHOULD establish out of band
trust in both the issuer and the publishing server before acting on
assessment data. The definition of a signed assessment assertion,
which would permit authenticity to be established in band and would
allow republication without additional trust in the intermediary, is
left to future work. Whether it could be expressed as an addition
within this extension or would need a separate one would depend on
its design.
12. 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 SHOULD assess whether the presence or absence of
assessment metadata can reveal information about the identity of
natural persons, and SHOULD withhold publication or coarsen its
granularity where it can. The separation between assessment
metadata, which is designed to be accessible where server policy and
applicable access controls permit, and contact data, which server
policy commonly places behind access control, is to be maintained in
conformant implementations.
Bertoldi & Romano Expires 24 April 2027 [Page 30]
Internet-Draft RDAP Reliability Assessment October 2026
Assessment results published in respect of domain objects warrant
particular care. A domain may be registered by a natural person, and
a result describing the security posture of that domain may in some
circumstances permit inferences about that person, independently of
whether contact data is disclosed. The requirement in Section 8 that
a scheme justify domain-level publication specifically is intended in
part to address this.
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 result.
13. IANA Considerations
13.1. RDAP Extensions Registry
The extension identifier "reliabilityAssessment" was registered in
the RDAP Extensions Registry on 6 October 2026. The entry, in the
template defined in Section 8.1 of [RFC7480], is:
Extension identifier: reliabilityAssessment
Registry operator: Any
Published specification: [BCSEC-RDAP-RA]
Person & email address to contact for further information: Bertoldi
Cybersecurity alessandro@bertoldicybersecurity.com
(mailto:alessandro@bertoldicybersecurity.com)
Intended usage: COMMON
This document requests no change to that entry.
Registration in this registry is subject to a Specification Required
policy. Section 7.1.2 of [I-D.ietf-regext-rdap-extensions]
additionally requires that an extension be documented in a stable,
non-changing, and readily available reference that is not denoted as
a work in progress. An Internet-Draft does not satisfy that
requirement.
The registration was therefore made against [BCSEC-RDAP-RA], a stable
specification of this extension published by Bertoldi Cybersecurity.
That document defines the same extension identifier, the same JSON
Bertoldi & Romano Expires 24 April 2027 [Page 31]
Internet-Draft RDAP Reliability Assessment October 2026
member, the same fields and the same types, so an implementation
written against either uses the same wire representation. It differs
from this document in that it carries no normative reference to a
work in progress, it requests no registration in the RDAP JSON Values
Registry, it omits passages that solicit review, and it does not
contain the requirement added in Section 7.5 concerning what a
consumer may infer from the absence of a score, the clarifications
added in the same section and in Section 7.7 concerning the range of
a score, the ordering of "scoreDate" and "validUntil", and the scope
of scheme stability, nor the requirements added in Section 8
concerning the basis on which a result is published. The differences
as of its publication are listed in full in an appendix to that
document. The divergence introduced by the -04 revision of this
document was brought to the attention of the designated experts
before the registration was made.
The registration was made on the understanding, stated by the
designated experts and accepted by the authors, that should this
document be published as an RFC it will register a different
extension identifier, under IETF change control, rather than take
over the existing entry. In the terminology of Section 5.4 of
[I-D.ietf-regext-rdap-extensions], the extension defined by such an
RFC would be a superseder of the extension defined by
[BCSEC-RDAP-RA]. This revision does not choose that identifier; the
choice is for the Working Group, should it take up this work.
Until such an RFC is published, this document continues to use
"reliabilityAssessment", so that implementations of this document and
of [BCSEC-RDAP-RA] share one wire representation. The new
identifier, and the transition from the extension defined by
[BCSEC-RDAP-RA], would be specified in the revision intended for
publication as an RFC, taking into account the considerations for
superseders in Section 5.4 of [I-D.ietf-regext-rdap-extensions],
including the possibility that a server provide both extensions
during a transition period.
The -04 revision of this document stated that, should this document
be published as an RFC, the registry entry would be updated to
reference the RFC in place of [BCSEC-RDAP-RA]. That statement is
withdrawn, for the reason given above. The -02 revision stated that
registration was expected to occur only upon publication as an RFC;
that statement was superseded in the -03, because the constraint it
reflected was the absence of a stable reference, and that absence has
been remedied rather than waived. Publication of a separate
specification asserts no consensus of any kind, and nothing in it or
in this document is intended to preclude any decision this Working
Group may take concerning this work, including a decision not to
adopt it.
Bertoldi & Romano Expires 24 April 2027 [Page 32]
Internet-Draft RDAP Reliability Assessment October 2026
13.2. RDAP JSON Values Registry
Section 7.2.1 of [I-D.ietf-regext-rdap-extensions] provides that new
value types in the RDAP JSON Values Registry may be defined by RDAP
extensions defined by the IETF and by other IETF specifications. The
registration below is therefore requested upon publication of this
document as an RFC and not before; the specification cited in
Section 13.1 requests no registration in this registry.
Type: assessment status
JSON field: the "status" member of an assessment result object, as
defined in Section 7.6
The following values are requested for that type: "active", "under
review", "withdrawn". Each is to be registered with the RFC
resulting from this document as its published specification.
14. References
14.1. Normative References
[I-D.ietf-regext-rdap-extensions]
Newton, A., Singh, J., and T. Harrison, "RDAP Extensions",
Work in Progress, Internet-Draft, draft-ietf-regext-rdap-
extensions-16, 20 October 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-regext-
rdap-extensions-16>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/rfc/rfc3339>.
[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/rfc/rfc3986>.
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7480, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/rfc/rfc7480>.
Bertoldi & Romano Expires 24 April 2027 [Page 33]
Internet-Draft RDAP Reliability Assessment October 2026
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7481, DOI 10.17487/RFC7481, March 2015,
<https://www.rfc-editor.org/rfc/rfc7481>.
[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/rfc/rfc8174>.
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/rfc/rfc9082>.
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/rfc/rfc9083>.
[RFC9224] Blanchet, M., "Finding the Authoritative Registration Data
Access Protocol (RDAP) Service", STD 95, RFC 9224,
DOI 10.17487/RFC9224, March 2022,
<https://www.rfc-editor.org/rfc/rfc9224>.
14.2. Informative References
[BCSEC-RDAP-RA]
Bertoldi, A., "RDAP Extension for Structured Reliability
Assessment Metadata, Specification bcsec-RDAP-RA, Version
1", September 2026, <https://bcsec.io/rdap/v1/bcsec-rdap-
reliability-assessment.txt>.
[DEEPSEC2025]
Bertoldi, A. and S. P. Romano, "Forever-Day at Scale:
Hijacking Registrars, Defeating 2FA and Spoofing 17,000+
Domains (Even with DMARC p=reject)", DeepSec Vienna 2025,
2025,
<https://bcsec.io/research/deepsec2025/deepsec2025.pdf>.
[GDPR] European Parliament and Council of the European Union,
"Regulation (EU) 2016/679 of the European Parliament and
of the Council on the protection of natural persons with
regard to the processing of personal data and on the free
movement of such data, and repealing Directive 95/46/EC
(General Data Protection Regulation)", April 2016,
<https://eur-lex.europa.eu/legal-content/EN/
TXT/?uri=CELEX:32016R0679>.
Bertoldi & Romano Expires 24 April 2027 [Page 34]
Internet-Draft RDAP Reliability Assessment October 2026
[I-D.ietf-regext-rdap-referrals]
Brown, G. and A. Newton, "Explicit RDAP Redirects", Work
in Progress, Internet-Draft, draft-ietf-regext-rdap-
referrals-05, 13 October 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-regext-
rdap-referrals-05>.
[I-D.ietf-regext-rdap-versioning]
Gould, J., Keathley, D., and M. Loffredo, "Versioning in
the Registration Data Access Protocol (RDAP)", Work in
Progress, Internet-Draft, draft-ietf-regext-rdap-
versioning-08, 15 October 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-regext-
rdap-versioning-08>.
[I-D.ietf-regext-rdap-x-media-type]
Newton, A. and J. Singh, "The "exts_list" Parameter for
the RDAP Media Type", Work in Progress, Internet-Draft,
draft-ietf-regext-rdap-x-media-type-07, 13 October 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-regext-
rdap-x-media-type-07>.
[I-D.loffredo-regext-rdap-verified-contacts]
Loffredo, M., Martinelli, M., Gould, J., and P. Kowalik,
"Registration Data Access Protocol (RDAP) Extension for
Verified Contact Information", Work in Progress, Internet-
Draft, draft-loffredo-regext-rdap-verified-contacts-04, 24
August 2026, <https://datatracker.ietf.org/doc/html/draft-
loffredo-regext-rdap-verified-contacts-04>.
[ISO27001] ISO/IEC, "Information security, cybersecurity and privacy
protection -- Information security management systems --
Requirements", ISO/IEC 27001:2022, 2022.
[ISO27701] ISO/IEC, "Information security, cybersecurity and privacy
protection -- Privacy information management systems --
Requirements and guidance", ISO/IEC 27701:2025, 2025.
[NIS2] European Parliament and Council of the European Union,
"Directive (EU) 2022/2555 of the European Parliament and
of the Council on measures for a high common level of
cybersecurity across the Union", December 2022,
<https://eur-lex.europa.eu/legal-content/EN/
TXT/?uri=CELEX:32022L2555>.
Bertoldi & Romano Expires 24 April 2027 [Page 35]
Internet-Draft RDAP Reliability Assessment October 2026
[PIR-AIP] Public Interest Registry, "PIR Abuse Intervention Program
and Quality Performance Index", 2025,
<https://icann85.sched.com/event/2GwoE/ssac-work-session-
pir-abuse-intervention-program>.
[PIR-QPI] Public Interest Registry, "Quality Performance Index",
<https://pir.org/our-impact/qpi/>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/rfc/rfc4033>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/rfc/rfc6376>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/rfc/rfc7208>.
[RFC8521] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Object Tagging", BCP 221, RFC 8521,
DOI 10.17487/RFC8521, November 2018,
<https://www.rfc-editor.org/rfc/rfc8521>.
[RFC9989] Herr, T., Ed. and J. Levine, Ed., "Domain-Based Message
Authentication, Reporting, and Conformance (DMARC)",
RFC 9989, DOI 10.17487/RFC9989, May 2026,
<https://www.rfc-editor.org/rfc/rfc9989>.
Appendix A. Changes from -04
This appendix summarizes the changes made in this revision. It is
intended to be removed prior to publication. No change in this
revision alters the extension identifier, the JSON member name, the
wire format, or any normative requirement, and no field or type has
been added, removed, or changed. The revision brings the document up
to date with the registration of the extension identifier and with
the revisions of related Internet-Drafts published since the -04.
* Section 13.1 is rewritten. It records that
"reliabilityAssessment" was registered on 6 October 2026 against
[BCSEC-RDAP-RA], and requests no change to that entry. It
withdraws the statement of the -04 that, should this document be
published as an RFC, the entry would be updated to reference the
Bertoldi & Romano Expires 24 April 2027 [Page 36]
Internet-Draft RDAP Reliability Assessment October 2026
RFC: the designated experts registered the identifier on the
understanding, accepted by the authors, that such an RFC would
register a different identifier under IETF change control. The
section describes that identifier as a superseder in the
terminology of [I-D.ietf-regext-rdap-extensions], leaves its
choice to the Working Group, and states that this document
continues to use "reliabilityAssessment" until such an RFC is
published.
* Section 7.1 describes the identifier as registered rather than to
be registered.
* Section 5.4 adds, for the second arrangement, that the -05 of
[I-D.ietf-regext-rdap-referrals] selects the link by the relation
type named in the request, that none of the relation types defined
by that document or by [I-D.ietf-regext-rdap-extensions] describes
the result of an assessment, and that this document defines none.
* References are updated to draft-ietf-regext-rdap-extensions-16,
draft-ietf-regext-rdap-versioning-08, draft-ietf-regext-rdap-x-
media-type-07 and draft-ietf-regext-rdap-referrals-05. Each
section cited was checked against the new revision. Two citations
change: the bare extension identifier pattern is now cited at
Section 2.2.1 of [I-D.ietf-regext-rdap-extensions] and the
provision on new value types in the RDAP JSON Values Registry at
Section 7.2.1 of that document.
* The XML source no longer declares a submission stream, which an
individual Internet-Draft does not have. The rendered text is
unaffected.
A.1. Changes from -03, retained for continuity
This appendix summarizes the changes made in the -04 revision, and is
retained for continuity; in it, "this revision" refers to the -04.
It is intended to be removed prior to publication. No change in that
revision alters the extension identifier, the JSON member name, or
the wire format, and no field or type has been added, removed, or
changed. Normative language is new in three places: in Section 7.5,
a requirement addressed to consumers, a constraint on the ordering of
two dates, and a recommendation on the presence of "scoreDate"; in
Section 7.7, the scope of an existing requirement; and in Section 8,
a requirement and a recommendation addressed to scheme
specifications. All are identified below.
Bertoldi & Romano Expires 24 April 2027 [Page 37]
Internet-Draft RDAP Reliability Assessment October 2026
A.1.1. Where this revision comes from
The -03 was published on 13 September 2026. Between then and this
revision the authors put the question of use directly to registry
operators. One European ccTLD registry operating under the Network
and Information Security Directive replied that it could not
implement the extension, and set out why; a second operator, a gTLD
registry, opened an internal review. The reasons given in the first
reply, together with a verification of the discovery mechanisms they
prompted, account for most of what follows. A second reply from the
first operator, received after this revision had been drafted,
settled a question the draft had left open and is reflected in it.
Section 10 records both exchanges.
A.1.2. Deployment model
* Section 5 no longer presents the assessment service as the primary
configuration. An earlier draft of this revision distinguished
registrars from domain names, anticipating an assessment service
reached through object tagging for the former and the
authoritative server for the latter. On the reply recorded in
Section 10 the distinction was dropped: the authoritative server,
carrying the result or referring to a service, is the
configuration anticipated for both. The assessment service
remains a configuration, for clients configured to reach it.
* Section 5.3 has been rewritten and split. The -03 argued that no
discovery mechanism was required because trust is established out
of band. That argument does not hold as a general matter:
Section 12 of [RFC9224] states that the bootstrap registries are
generated from IANA allocation registries, so for domain objects
no independent registration procedure exists and a third-party
service cannot be discovered through them. The revision is
careful to state this as a limit on discovery rather than on
reachability, since a client configured out of band with a base
URL can query any RDAP service; what is absent is a path that
works for a client which has not been so configured. For entity
objects [RFC8521] offers a registry populated First Come First
Served, but the practice exists to identify the authoritative
server, and a registry operator consulted by the authors confirmed
that using it to reach an assessment service lies beyond its
purpose. The revision records that reading and does not rely on
the practice.
* Section 5.4 reverses the position of the -03. That revision
declined to propose publication by an authoritative server, on the
ground that it could be read as endorsement of the assessor.
Since for both object classes the authoritative server is the only
Bertoldi & Romano Expires 24 April 2027 [Page 38]
Internet-Draft RDAP Reliability Assessment October 2026
standardized starting point available to a client that has not
been configured in advance, the revision distinguishes carrying a
result from referring to a service, and argues that a result
carried at the request of the client, whose issuer is named in the
data, does not assert agreement. The earlier concern is retained
in narrower form. The section also records a third arrangement
suggested by the operator, a dedicated path segment, as a
candidate for a later revision.
* Section 5.1 names a configuration the -03 did not: an attestation
published at the instance of the assessed party, issued by an
assessor that party commissioned. It differs from self-assessment
in that the issuer is independent, and from republication in that
the publication is requested by the subject.
* Section 5.2 is now scoped to the assessment service configuration,
since it cannot apply where the response belongs to the
authoritative server. It continues to cover both object classes
within that configuration, because an assessment service that a
client has been configured to query may be queried for either.
A.1.3. Attestation without a score
* Section 7.5 now states that a result need not carry a score.
"scoreValue" and "scoreMaxValue" were already OPTIONAL in the -02
and the -03; what the earlier revisions never said is that a
result composed without them is complete and conformant, and
attests that the properties defined by the scheme were examined
rather than expressing a numeric judgement. No field and no type
has changed. One normative requirement is new: a consumer MUST
NOT infer a numeric judgement from the absence of a score.
* Appendix C.3 is a new example showing such a result. The document
previously contained no example without a score, which left the
field names to suggest that a rating was the only intended use.
* "scoreDate" SHOULD be present in a result that carries no score,
since the date is what gives the attestation its meaning; the
section no longer assumes the date to be present when it describes
what such a result attests.
A.1.4. Field semantics clarified
* "scoreMaxValue" now states that the range runs from zero to that
value inclusive. Without a lower bound the claim that a consumer
could place the result on the scale without resolving the scheme
did not hold. A scheme whose range does not begin at zero omits
the member.
Bertoldi & Romano Expires 24 April 2027 [Page 39]
Internet-Draft RDAP Reliability Assessment October 2026
* "validUntil" MUST NOT precede "scoreDate" where both are present,
and a status of "active" after "validUntil" is stated to convey
the last asserted state rather than a current assertion. The two
members could otherwise contradict each other without the document
saying which prevailed.
* Section 7.7 now scopes the stability requirement to the
combination of "scoreIssuer" and "scoreScheme", consistent with
the comparison rule in Section 7.5; an opaque "scoreScheme" is
unique only within its issuer.
* Section 5.4 now states that publication at the request of the
client is a policy a server may adopt and not a condition for the
extension to function, since this document defines no means of
expressing such a request.
A.1.5. Subject binding
* Section 6.3 proposes no convention for the handle of an assessed
registrar. An earlier draft of this revision proposed the IANA
Registrar ID followed by the assessor's registered provider tag;
it fell with the reading of [RFC8521] recorded in Section 5.3.1,
and would in any case have served only registrars that hold an
IANA Registrar ID. The gap is stated and left open, as the -03
left it, and the section notes that it does not arise where the
authoritative server publishes.
* Section 6.2 now notes that an IANA Registrar ID is assigned by
ICANN in the gTLD system, and that a scheme intended for
registrars under a ccTLD registry will need another identifier
type.
A.1.6. Requirements on scheme specifications
* Section 8 adds a requirement that a scheme state the basis on
which the party publishing a result relies in publishing it, and
how the scheme allocates the exposure arising from publication
between issuer and publisher. The omission was pointed out by a
registry operator, for whom it was a condition of deployability
rather than a detail. The requirement is framed as a matter to be
answered in the scheme rather than as an assertion that the
publisher is shielded, which no specification could make good.
* The same section adds a recommendation that a scheme declare the
basis of the assessor's standing. The document does not require
accreditation and names no body competent to grant it; it asks
only that the basis be stated.
Bertoldi & Romano Expires 24 April 2027 [Page 40]
Internet-Draft RDAP Reliability Assessment October 2026
* A paragraph records that where publication is required of an
operator by law, the obligation supplies the basis on which that
operator publishes, and that where the law prescribes a procedure
incompatible with the notification and the period that section
requires, the procedure prescribed by law governs.
A.1.7. Corrections and editorial changes
* The abstract now says that this document defines an extension
rather than proposes one, matching the language of
[BCSEC-RDAP-RA].
* The "Published specification" line of the registration template in
Section 13 has been reworded. Read in isolation it could be taken
to mean that registration awaited publication as an RFC, which is
the position of the -02 that the -03 superseded.
* Section 13 no longer describes [BCSEC-RDAP-RA] as technically
aligned with this document. It now states what the two share,
being the extension identifier, the JSON member, the fields and
the types, and what this revision contains that the published
specification does not, being the normative language identified
above. It also records that the authors will bring the divergence
to the attention of the designated experts.
* Paweł Kowalik is now spelled correctly in the acknowledgments.
* Two informative references have been added,
[I-D.ietf-regext-rdap-x-media-type] and
[I-D.ietf-regext-rdap-referrals]. Neither is normative: both are
works in progress, and this document does not depend on either.
Neither is required for conformance to this extension, and in
particular the case made in Section 5.4 concerns publication at
the request of the client however that request is expressed, and
not the particular mechanism described in the first of them.
* The entity handles used in the examples in Section 7.9,
Appendix C.2 and Appendix C.3 are service-local handles without a
hyphen, so that no final element could be read as a service
provider tag under [RFC8521].
* The acknowledgments state that the inclusion of the reviewers from
the registry operator consulted implies neither endorsement of
this document nor any intention to implement it, which is the
understanding on which their observations were given.
Bertoldi & Romano Expires 24 April 2027 [Page 41]
Internet-Draft RDAP Reliability Assessment October 2026
* Section 13.2 now requests the new value type upon publication as
an RFC and not before, since Section 7.2 of
[I-D.ietf-regext-rdap-extensions] reserves the definition of new
value types to IETF specifications. The -03 named this document
as the published specification, which an Internet-Draft cannot be.
* Section 6.2 and Section 10 describe the IANA Registrar ID as
assigned by ICANN in the gTLD system rather than as held only by
ICANN-accredited registrars, which was too absolute.
* Section 8 is now titled "Requirements on Assessment Scheme
Specifications" rather than "Scoring Scheme", consistent with the
position that a result need not carry a score. The staleness item
in Section 11 no longer assumes that every result carries a
"scoreDate".
* Section 10 has been expanded to record the exchange with registry
operators, the reasons given, and the consequences drawn from
them.
A.1.8. Considered and not done
* The four breaking changes made in the -02 are unchanged, and the
extension identifier is unchanged. It is the subject of a pending
registration request, which the authors did not wish to disturb
for a change no one had asked for. Should this working group
reach consensus on a change to the identifier or to the wire
format, the registration follows the consensus and not the
reverse: the authors would request the corresponding change to the
registry entry, or its withdrawal.
* The choice of Opaque Versioning in Section 7.2 is unchanged in
this revision. The advantages of Point Versioning were set out to
the authors by one of the authors of
[I-D.ietf-regext-rdap-versioning] and are under consideration; the
question is not settled here because changing it now would
compound an architectural revision with a versioning one.
* A dedicated path segment at the authoritative server, returning
the result or redirecting to a service that does, was suggested to
the authors and is recorded in Section 5.4. It is not defined in
this revision, because it would make this a query extension as
well as a response extension; it is a candidate for a later one.
Bertoldi & Romano Expires 24 April 2027 [Page 42]
Internet-Draft RDAP Reliability Assessment October 2026
A.1.9. Changes from -02, retained for continuity
The subsections below record the changes made in the -03 revision.
They are retained so that a reader of this revision can see the whole
sequence.
A.1.9.1. Registration
* Section 13 has been rewritten. The -02 stated that registration
in the RDAP Extensions Registry was expected to occur only upon
publication of this document as an RFC, and that nothing in it
should be read as reserving the identifier in the interim. A
stable specification has since been published at [BCSEC-RDAP-RA],
the registration is requested against that reference, and the
earlier statement is superseded. The reasoning is given in
Section 13 rather than only here.
* The "Published specification" field of the registration template
now names [BCSEC-RDAP-RA] in place of "this document".
A.1.9.2. Corrections
* The description of PIR's Quality Performance Index has been
corrected in Appendix D and in the section on the PIR Abuse
Intervention Program. The -02 described QPI as operating "within
a single registry context" and as focused on abuse outcomes and
operational metrics in contrast to structural indicators. Both
characterisations were wrong. PIR names SSL and DNSSEC among its
three secondary indicators, and those are structural, and PIR
states that it has made the program and its algorithm available to
all members of the domain industry. The error was acknowledged to
PIR before this revision was submitted.
* The -02 changelog omitted a change that the -02 in fact made: the
DMARC reference was updated from RFC 7489 to [RFC9989]. It is
recorded here.
* A reference to [PIR-QPI] has been added, so that the description
of the program cites the program's own documentation rather than
only a conference session.
Bertoldi & Romano Expires 24 April 2027 [Page 43]
Internet-Draft RDAP Reliability Assessment October 2026
A.1.9.3. Technical corrections
* The description of the bootstrap mechanism in Section 5 has been
corrected. The -02 stated that [RFC9224] determines the
authoritative server for registration data without qualification.
Section 9 of that document lists entities among the objects it
does not bootstrap, and Section 6 points to [RFC8521] for them.
The scope is now stated.
* The definitions of "scoreValue" and "scoreMaxValue" contradicted
each other. The -02 described "scoreMaxValue" as the maximum
possible value while permitting a scheme to define a "scoreValue"
exceeding it. "scoreMaxValue" is now the upper bound of the range
defined by the scheme, and "scoreValue" MUST NOT exceed it.
* "scoreScheme" no longer has an undefined non-URI form. A URI is
now RECOMMENDED, and a value that is not a URI is stated to be
opaque and meaningful only relative to its issuer. A rule for
comparing "scoreScheme" and "scoreIssuer" has been added, since
those two members together key the uniqueness requirements of this
document.
* Normative requirements addressed to a document, a response, or an
act of interpretation have been re-addressed to clients, which are
the parties able to satisfy them. The requirement in the Privacy
Considerations that implementers ensure no inference about natural
persons is possible has been reduced to a SHOULD, since the same
section acknowledges that such inferences may occur.
* The minimal response in Section 5 now states that it does not
displace the recommendation in [RFC9083] that a server provide a
link identifying the object class instance itself.
* ISO/IEC 27001 and ISO/IEC 27701 are described as standards against
which a party is certified, rather than as certifications.
* The Abuse Intervention Program is no longer described as being in
operation, since the authors have not verified that from a primary
source.
A.1.10. Changes from -01, retained for continuity
The remainder of this appendix records the changes made in the -02
revision.
Bertoldi & Romano Expires 24 April 2027 [Page 44]
Internet-Draft RDAP Reliability Assessment October 2026
A.1.11. Breaking Changes
* The extension identifier has been changed from
"reliabilityScoring" to "reliabilityAssessment", aligning it with
the title of the document and avoiding the reading of the
extension as a rating mechanism. The document name is unchanged
in order to preserve continuity in the datatracker.
* The JSON member has been renamed from
"reliabilityScoring_assessment" to "reliabilityAssessment_results"
and now carries an array of result objects rather than a single
object. Results from more than one issuer or scheme on the same
object are a natural case, and moving from object to array in a
later revision would itself have been a breaking change.
* "scoreScheme" and "scoreIssuer" are now REQUIRED in each result
object.
* "scoreIssuer" MUST now be a URI. It was previously an opaque
string whose format was defined by the scheme.
These changes are made together in a single revision, and at a point
at which the authors are aware of no implementations.
A.1.12. Additions
* Section 5, describing deployment configurations, minimal response,
endpoint discovery, and the rejected referral mechanism.
* Section 6, describing binding for domains and registrars and
stating the open questions concerning [RFC8521] and registrars
without an IANA Registrar ID.
* Section 8, placing requirements on the specification of any scheme
whose results are intended for publication through RDAP, including
notification, a remediation and contestation period, and a
disclosure threat model.
* Section 11.1, separating identity, trust, and authenticity, and
stating the limitations of the present revision.
* The "validUntil", "assessmentId", and "status" members, and
Section 7.6 defining permitted status values.
* Section 10, stating that no implementations are known.
Bertoldi & Romano Expires 24 April 2027 [Page 45]
Internet-Draft RDAP Reliability Assessment October 2026
* An "Extension Version Identifier" section declaring Opaque
Versioning, following the guidance in Section 6.1 of
[I-D.ietf-regext-rdap-versioning]. The -01 was silent on
versioning.
* Sections on scheme stability and on the absence of the member, the
latter promoted from an appendix in -01 and expanded.
* Expanded Security Considerations covering reconnaissance and
exposure, risk-based regulatory obligations, perception as a
rating, volatility, access control and server policy, and
inference from absence.
* A registration request for the RDAP JSON Values Registry.
A.1.13. Corrections
* The IANA Considerations section now uses the complete template
from Section 8.1 of [RFC7480], including the "Intended usage"
field omitted in -01.
* Section references to [I-D.ietf-regext-rdap-extensions] have been
updated to the numbering of the -15 revision.
* [I-D.ietf-regext-rdap-extensions] has been moved from an
informative to a normative reference. This document depends on it
for identifier syntax, for the treatment of child JSON values, and
for the procedures governing registration of a new value type, and
cannot be implemented conformantly without it.
* The reference to ISO/IEC 27701 has been corrected to the 2025
edition, which carries a revised title.
A.1.14. Deferred
The authors considered and did not include a representation of
confidence or uncertainty, a representation of categorical rather
than numeric outcomes, and a supersession mechanism. In each case no
requirement from an implementer or prospective consumer has been
identified. The restructuring of the member into an array of result
objects means that each could be added later as an additional member
without a breaking change.
Appendix B. Acknowledgments
The authors thank Gavin Brown, James Galvin, James Gould, Jody
Kolker, Paweł Kowalik, Mario Loffredo, Maurizio Martinelli, Jim Reid,
Werner Staub, Richard Wilhelm, and Maarten Wullink.
Bertoldi & Romano Expires 24 April 2027 [Page 46]
Internet-Draft RDAP Reliability Assessment October 2026
The deployment model in Section 5, the treatment of contestation, and
the expanded disclosure considerations are responses to points raised
in the REGEXT session at IETF 126 and in subsequent discussion on the
mailing list.
Mario Loffredo and Maurizio Martinelli of IIT-CNR/Registro.it
reviewed the deployment model in correspondence with the authors, and
Section 10 records the substance of that review. Their inclusion
here acknowledges the review and implies neither endorsement of this
document nor any intention to implement it.
Appendix C. Example RDAP Responses
The examples in this appendix are provided for illustrative purposes
only. Values, scheme identifiers, and issuer identifiers are
fictional.
C.1. Domain Lookup with a Single Result
{
"rdapConformance": [
"rdap_level_0",
"reliabilityAssessment"
],
"objectClassName": "domain",
"handle": "D-EXAMPLE-1",
"ldhName": "example.com",
"reliabilityAssessment_results": [
{
"scoreScheme": "https://assessor.example/schemes/domain/v2",
"scoreIssuer": "https://assessor.example",
"scoreValue": 9,
"scoreMaxValue": 10,
"scoreDate": "2026-01-01T00:00:00Z",
"validUntil": "2026-04-01T00:00:00Z",
"assessmentId": "d-2026-01-01-7781",
"status": "active",
"evidenceUri": "https://assessor.example/rep/d-2026-01-01-7781"
}
],
"events": [
{
"eventAction": "registration",
"eventDate": "2024-01-01T00:00:00Z"
}
]
}
Bertoldi & Romano Expires 24 April 2027 [Page 47]
Internet-Draft RDAP Reliability Assessment October 2026
C.2. Registrar Lookup with Results from Two Issuers
This example illustrates the case for which the array representation
is defined: two issuers, applying different schemes, have published
results in respect of the same registrar. The second result is under
review following a contestation by the assessed party.
{
"rdapConformance": [
"rdap_level_0",
"reliabilityAssessment"
],
"objectClassName": "entity",
"handle": "RAR999999",
"roles": ["registrar"],
"publicIds": [
{
"type": "IANA Registrar ID",
"identifier": "999999"
}
],
"reliabilityAssessment_results": [
{
"scoreScheme": "https://assessor.example/schemes/registrar/v1",
"scoreIssuer": "https://assessor.example",
"scoreValue": 10,
"scoreMaxValue": 10,
"scoreDate": "2026-01-01T00:00:00Z",
"assessmentId": "r-2026-01-01-0003",
"status": "active"
},
{
"scoreScheme": "https://observatory.example/scheme/2026",
"scoreIssuer": "https://observatory.example",
"scoreValue": 62,
"scoreMaxValue": 100,
"scoreDate": "2026-02-10T00:00:00Z",
"assessmentId": "2026-02-10-REG-9999",
"status": "under review"
}
]
}
Bertoldi & Romano Expires 24 April 2027 [Page 48]
Internet-Draft RDAP Reliability Assessment October 2026
C.3. Registrar Lookup with an Attestation Carrying No Score
The result below carries no "scoreValue" and no "scoreMaxValue". It
attests that the properties defined by the scheme were examined by
the named issuer on the given date, and points to the record of what
was found. It is complete and conformant. See Section 7.5.
The handle is a service-local one, as Section 6.2 recommends for an
assessment service. Where the same result were published by the
authoritative server, the handle would be the one that server assigns
to the registrar's entity object.
{
"rdapConformance": [
"rdap_level_0",
"reliabilityAssessment"
],
"objectClassName": "entity",
"handle": "RAR9999",
"roles": ["registrar"],
"publicIds": [
{
"type": "IANA Registrar ID",
"identifier": "9999"
}
],
"reliabilityAssessment_results": [
{
"scoreScheme": "https://assessor.example/schemes/attestation/v1",
"scoreIssuer": "https://assessor.example",
"scoreDate": "2026-03-04T09:00:00Z",
"validUntil": "2026-09-04T00:00:00Z",
"assessmentId": "att-2026-03-04-0007",
"status": "active",
"evidenceUri": "https://assessor.example/att/att-2026-03-04-0007"
}
]
}
C.4. Domain Lookup without Assessment Metadata
When no assessment metadata is conveyed, the
"reliabilityAssessment_results" member is omitted. Its absence MUST
NOT be interpreted as evidence that the object has not been assessed,
nor as a negative assessment. See Section 7.8.
Bertoldi & Romano Expires 24 April 2027 [Page 49]
Internet-Draft RDAP Reliability Assessment October 2026
{
"rdapConformance": [
"rdap_level_0"
],
"objectClassName": "domain",
"handle": "D-PLAIN-1",
"ldhName": "plain.example",
"events": [
{
"eventAction": "registration",
"eventDate": "2025-06-01T00:00:00Z"
}
]
}
Appendix D. Illustrative Assessment Dimensions
This appendix describes possible dimensions that an operational
assessment program might evaluate when producing 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, and nothing in
it should be read as a recommendation that any of these dimensions be
published in the form described.
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].
D.1. Possible Registrar Assessment Dimensions
An operational program might evaluate registrars across dimensions
such as: the strength of customer identity verification procedures;
the adoption and enforcement of multi-factor authentication for
customer-facing and internal systems; the possession of recognized
information security certifications such as ISO/IEC 27001 [ISO27001]
or ISO/IEC 27701 [ISO27701]; the correctness of email authentication
configurations including SPF [RFC7208], DKIM [RFC6376], and DMARC
[RFC9989] on registrar-operated domains; the existence of documented
security policies; and the regularity of cybersecurity training
programs for staff.
Bertoldi & Romano Expires 24 April 2027 [Page 50]
Internet-Draft RDAP Reliability Assessment October 2026
D.2. Possible Domain Assessment Dimensions
An operational program might evaluate individual domains across
dimensions such as: the strength of owner identity verification at
registration or renewal; the level of TLS certificate validation
used; the correctness of SPF, DKIM, and DMARC configurations; the
implementation of DNSSEC [RFC4033]; and the absence of the domain
from monitored abuse blocklists over a defined observation period.
The considerations in Section 11 apply with particular force to
dimensions of this kind, since several of them describe exploitable
weaknesses directly.
D.3. Note on Existing Operational Programs
Existing programs differ in what they measure. PIR's Quality
Performance Index [PIR-QPI] combines observable abuse and commercial
outcomes, being Abuse Takedown, Renewal Rates, and Domain Usage, with
secondary indicators named by PIR as SSL, DNSSEC, and ATL, of which
the first two are structural. The dimensions described above in this
appendix are weighted more heavily toward structural and procedural
security posture, including identity verification and credential
recovery practice, which the published description of QPI does not
list among its indicators.
The two are neither equivalent nor mutually exclusive, and the
envelope defined in this document is agnostic to the methodology. It
can carry results from either, and from both at once, since the
envelope is an array keyed by the combination of scheme and issuer.
Authors' Addresses
Alessandro Bertoldi
Bertoldi Cybersecurity
Italy
Email: alessandro@bertoldicybersecurity.com
Simon Pietro Romano
Universita' degli Studi di Napoli Federico II
Via Claudio 21
80125 Naples
Italy
Email: spromano@unina.it
Bertoldi & Romano Expires 24 April 2027 [Page 51]