A. Bertoldi Bertoldi Cybersecurity 13 September 2026 RDAP Extension for Structured Reliability Assessment Metadata Specification bcsec-RDAP-RA, Version 1 Canonical URL https://bcsec.io/rdap/v1/bcsec-rdap-reliability-assessment.txt Mirror https://raw.githubusercontent.com/alessandrobertoldi/ bcsec-rdap-reliability-assessment/v1/ bcsec-rdap-reliability-assessment.txt Status of This Document This document is a permanent and stable specification. It is not an Internet-Draft, it is not a work in progress, and it is not on any standards track. This document will not change. The bytes served at its canonical URL are fixed, and no correction, not even an editorial one, will be applied to them. Two retrievals of that URL at any two times return the same document. Where an error is found, it is recorded in a separate errata document at . That document is not part of this specification, does not amend it, and carries no normative weight; it exists so that a reader of this document can learn what its author considers to be wrong with it. A correction that affects interoperability is instead published as a new specification at a different URL, and this document remains available, unchanged, at the URL above. The mirror listed above carries the identical text and exists so that the specification remains retrievable if the canonical host becomes unavailable. Where the two differ, the canonical URL governs. This document is published by Bertoldi Cybersecurity, which is the applicant for, and the named contact of, the IANA registration requested in Section 13. Comments on this document may be sent to the contact address in Section 15. Copyright (c) 2026 Bertoldi Cybersecurity. This document is licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0). It may be copied, redistributed, and adapted for any purpose, including commercially, provided that attribution is given to Bertoldi Cybersecurity, a link to the license is provided, and any changes are indicated. The license is at . The document is provided as-is and without warranties of any kind, to the extent permitted by that license. This license applies to this document. It does not apply to the Internet-Draft named in the following section, which is subject to the copyright and licensing terms stated in that document. Relationship to Work in the IETF The technical content of this document is also the subject of an individual Internet-Draft submitted to the IETF, currently draft-bertoldi-regext-rdap-reliability-scoring, co-authored by Alessandro Bertoldi and Simon Pietro Romano of the University of Naples Federico II. That document is a work in progress, is subject to change, and is not the reference for the IANA registration described in Section 13. This document is. This specification is published by Bertoldi Cybersecurity alone. The technical design it describes was developed jointly with Simon Pietro Romano in the course of the IETF work, and the attribution of that joint work rests with the Internet-Draft named above. The two are maintained in parallel and are intended to remain technically aligned. Standardization of this extension is being pursued in the IETF Registration Protocols Extensions (REGEXT) Working Group. Publication of this specification does not substitute for that process, does not assert consensus of any kind, and is not intended to foreclose any decision the Working Group may take, including a decision not to adopt the work. Where this document and the Internet-Draft differ, the difference is recorded in Appendix C. 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. Table of Contents 1. Introduction 2. Terminology 3. Motivation and Problem Statement 4. Design Principles 5. Deployment Model 6. Subject Binding 7. RDAP Extension: Data Model 8. Requirements on Scoring Scheme Specifications 9. Relationship to Existing Work 10. Applicability and Implementation Status 11. Security Considerations 12. Privacy Considerations 13. IANA Considerations 14. References 15. Contact Appendix A. Example RDAP Responses Appendix B. Illustrative Assessment Dimensions Appendix C. Differences from the IETF Internet-Draft Appendix D. Errata 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. 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. 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 carries the outcome and 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 scoring methodology used to produce an assessment result. The scheme defines the semantics of the result, its range, and its criteria. 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 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. 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. Interoperability: The extension is not tied to any specific registry, registrar, or policy framework. Any conformant RDAP server may implement it independently. Coexistence: The extension occupies its own namespace and is designed to coexist with any other RDAP extension carried in the same response, rather than to replace or duplicate one. 5. Deployment Model 5.1. Deployment Configurations Three configurations are anticipated. Assessment service: An RDAP service operated by the assessor, distinct from any authority for the registration data of the assessed party. This is the primary configuration anticipated by this document. Republication: A registry, registrar, or other RDAP server that publishes an assessment result produced by a third party. This configuration introduces an intermediary and is discussed in Section 11.1. 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 recognize the configuration and to weigh the result accordingly. 5.2. Minimal Response Clients MUST NOT treat an assessment service as authoritative for the registration data of the assessed object. 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 The bootstrap mechanism defined in [RFC9224] determines the authoritative server for the scopes it covers, being domain names, IP addresses, and Autonomous System numbers. Section 9 of [RFC9224] states that entities are not bootstrapped by that mechanism, and Section 6 of that document points instead to [RFC8521]. An assessment service is not authoritative for registration data in any of those scopes, and this document therefore does not place assessment services in that bootstrap and does not define a parallel one. Where a consumer has established trust in an issuer out of band, the endpoint of that issuer's assessment service is provisioned as part of the same trust configuration, and no separate discovery mechanism is required. A consumer that has not established such trust has no basis on which to act on a result in any case, as discussed in Section 11.1. 5.4. Referral from an Authoritative Server This document considered, and does not define, a mechanism by which an authoritative RDAP server would point at an assessment service using a "links" member with the "related" relation. The "related" relation is already used for registry-to-registrar referrals. Reusing it for this purpose would require precise semantics, an expected media type, and clear client processing rules. Defining a new relation would require its registration. In either case, a link published by the authoritative server could reasonably be read as an endorsement of the assessor, which is not a property this document intends to create. 6. Subject Binding An assessment result is only meaningful if the object it is attached to can be bound unambiguously to the assessed party. 6.1. Domains For domain objects, "ldhName" provides the standard lookup key and the query form /domain/ defined in [RFC9082] works unchanged. No additional mechanism is required. 6.2. Registrars For entity objects the situation is less straightforward. [RFC9082] defines entity lookup as /entity/ (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/ lookups, and SHOULD include a "publicIds" member binding that local object to the assessed registrar, for example through the applicable IANA Registrar ID. 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, and this document does not do so. 6.3. Known Limitations 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] can bootstrap an entity query where a client already holds a tagged handle whose suffix identifies the RDAP service provider. One conceivable profile would use the IANA Registrar ID as the local portion of the handle and the assessor's registered provider tag as its suffix, making the full handle derivable once the assessor is known out of band. This document does not define such a profile and takes no position on whether it would be a sound use of [RFC8521], given that an assessor is authoritative for the assessment representation but not for the underlying registration data. The binding for registrars operating under ccTLD registries, and for registrars with no IANA Registrar ID, is likewise not resolved by this document. The "publicIds" member accommodates other identifier types, but this document does not prescribe one. 7. RDAP Extension: Data Model 7.1. Extension Identifier This extension is identified by the string "reliabilityAssessment", for which registration in the IANA RDAP Extensions Registry is requested in Section 13. RDAP responses that include this extension MUST include the extension identifier in the "rdapConformance" array. The extension identifier contains no underscore character. The JSON member defined by this extension is prefixed with the extension identifier followed by an underscore, and does not use the bare extension identifier as a member name. 7.2. Extension Version Identifier RDAP extension identifiers are opaque and carry no explicit version. This extension defines no versioning scheme of its own and is therefore opaquely versioned. For implementers who also support [RDAP-VERSIONING], which provides that all extensions support Opaque Versioning by default: Versioning type: Opaque Versioning Extension version identifier: reliabilityAssessment 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 for it. 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 [RDAP-VERSIONING] is not required in order to implement this extension, and this document places no such requirement on clients or servers. Any change to this extension that is not backward compatible requires the registration of a new extension identifier and a new specification. The version number in the URL of this document identifies the document, not the extension. 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, since collision is already avoided by the prefixed parent. 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 carries the outcome of an external assessment and points to the methodology used. It does not define the methodology, the criteria, or the thresholds. 7.5. Field Definitions The members of each assessment result object are as follows. 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 the value 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, range, and criteria of the result. Scheme definitions are maintained externally. scoreIssuer (string, URI) REQUIRED. Identifies the entity 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. 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. Together with scoreValue it allows a consumer to interpret the numeric result without resolving the scheme. A scheme whose results are not bounded omits this member. scoreDate (string, date-time) OPTIONAL. The date and time at which the assessment was performed, in the format defined in [RFC3339]. validUntil (string, date-time) OPTIONAL. The date and 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. 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 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, URI) OPTIONAL. A URI pointing to supporting documentation, a detailed report, or the full assessment record maintained by the scoreIssuer. 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. 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. The field values used in the examples in this document and in Appendix A are illustrative and carry no normative meaning. Each example is to be read as if retrieved shortly after the time given in its "scoreDate". 7.6. Result Status Values The "status" member, when present, takes one of the following values, which are defined by this document: active: The issuer asserts the result as current. 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. The semantics associated with a given "scoreScheme" identifier 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. 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. { "rdapConformance": [ "rdap_level_0", "reliabilityAssessment" ], "objectClassName": "entity", "handle": "REGISTRAR-EXAMPLE", "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. { "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 Scoring 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: o 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; o MUST define a notification to the assessed party prior to publication of a result; o MUST define a period, following that notification and preceding publication, during which the assessed party may remediate the findings or contest the result; o 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; o 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; o 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. 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. 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 Contact Verification Metadata Verification metadata and assessment metadata answer different questions and are orthogonal. Verification metadata records which contact fields have been checked and how; assessment metadata records what the assessed security posture of the party managing the object is. Neither implies the other, and both can appear in the same RDAP response without conflict, since each occupies its own namespace. Work in this area is in progress in the IETF; see [VERIFIED-CONTACTS] for one such proposal. This document takes no position on it and does not depend on it. 9.2. Relationship to the PIR Quality Performance Index The Public Interest Registry (PIR) publishes a Quality Performance Index (QPI) [PIR-QPI]. 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 capable of carrying outputs produced by programs such as QPI or other assessment frameworks. An operational scoring system of this kind could expose its outputs through the envelope defined in this document, enabling broader interoperability without modifying its internal methodology. Bertoldi Cybersecurity is not aware of RDAP work undertaken by PIR in connection with these programs. 9.3. Relationship to RDAP Core Specifications This extension is designed to be fully conformant with the RDAP core specifications [RFC7480], [RFC7481], [RFC9082], [RFC9083], and [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 As of the date of this document, no implementation of this extension is known to Bertoldi Cybersecurity. This is stated explicitly rather than left to be inferred. The configurations in which the extension is expected to be useful are those described in Section 5: an assessment service operated by a research group, a security vendor, or a sector body; a registry or registrar republishing a third-party result; and, more marginally, self-assessment. The consumers anticipated are RDAP clients operated by registries, registrars, enterprise security teams, and researchers. Parties that operate or plan to operate an assessment program, implement RDAP clients, or would consume this kind of data may report an implementation or a statement of interest to the contact address in Section 15. A statement that a party would not use the extension, together with the reason, is equally welcome. Reports received will be reflected in the IETF document rather than in this specification, which does not change. 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. Reconnaissance and exposure: A published result indicating a weak security posture is itself a signal that may be used to identify and prioritize 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 organizational 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, and nothing in this document should be read as an assurance that publication is permitted in any given jurisdiction. 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 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: Results reflect the state at the time indicated by "scoreDate". Consumers SHOULD check freshness and SHOULD treat results that have not been updated recently, 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 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 this specification, 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. This document does not define a signed assessment assertion. Such a mechanism would permit authenticity to be established in band and would allow republication without additional trust in the intermediary; defining it would require a further specification, and 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. 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 Registration of the following entry in the RDAP Extensions Registry is requested, using the template defined in Section 8.1 of [RFC7480]. Extension identifier: reliabilityAssessment Registry operator: Any Published specification: this document, at https://bcsec.io/rdap/v1/bcsec-rdap-reliability-assessment.txt Person and email address to contact for further information: Bertoldi Cybersecurity Intended usage: COMMON Registration in this registry is subject to a Specification Required policy. This document is offered as the required specification. It is permanent, stable, non-changing, and publicly retrievable without restriction or registration, and it is not denoted as a work in progress. Section "Status of This Document" above states the terms on which it is maintained. Should the parallel IETF document be published as an RFC, the registrant will request that this entry be updated to reference the RFC in place of this document. 13.2. RDAP JSON Values Registry No registration in the RDAP JSON Values Registry is requested by this document. The values defined in Section 7.6 are scoped to the "status" member of an assessment result object defined by this extension and are given their meaning by this document. Registration of a new value type in the RDAP JSON Values Registry is pursued through the IETF document referred to in "Relationship to Work in the IETF" above, and not here. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, . [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", STD 95, RFC 7480, March 2015, . [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", STD 95, RFC 7481, March 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access Protocol (RDAP) Query Format", STD 95, RFC 9082, June 2021, . [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the Registration Data Access Protocol (RDAP)", STD 95, RFC 9083, June 2021, . [RFC9224] Blanchet, M., "Finding the Authoritative Registration Data Access Protocol (RDAP) Service", STD 95, RFC 9224, March 2022, . 14.2. Informative References [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005, . [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011, . [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, April 2014, . [RFC8521] Hollenbeck, S. and A. Newton, "Registration Data Access Protocol (RDAP) Object Tagging", BCP 221, RFC 8521, November 2018, . [RFC9989] Herr, T., Ed. and J. Levine, Ed., "Domain-Based Message Authentication, Reporting, and Conformance (DMARC)", RFC 9989, May 2026, . [RDAP-EXTENSIONS] Newton, A., Singh, J., and T. Harrison, "RDAP Extensions", Work in Progress, Internet-Draft, draft-ietf-regext-rdap-extensions, . [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, . [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, . [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. [GDPR] European Parliament and Council of the European Union, "Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 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) (Text with EEA relevance)", OJ L 119, 4.5.2016, p. 1, . [NIS2] European Parliament and Council of the European Union, "Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive) (Text with EEA relevance)", OJ L 333, 27.12.2022, p. 80, . [PIR-QPI] Public Interest Registry, "Quality Performance Index", . [GNA-128] GCVE, "GNA 128 - bcsec (Bertoldi Cybersecurity)", GCVE Numbering Authority directory, . [DEEPSEC2025] Bertoldi, A. and S. Romano, "Forever-Day at Scale: Hijacking Registrars, Defeating 2FA and Spoofing 17,000+ Domains (Even with DMARC p=reject)", DeepSec Vienna 2025, 2025, . 15. Contact Bertoldi Cybersecurity Italy Email: alessandro@bertoldicybersecurity.com This is the contact given for the IANA registration requested in Section 13, and the address for any correspondence concerning this document. Bertoldi Cybersecurity operates two domains: bcsec.io, which carries its research and publication resources, including this specification, and bertoldicybersecurity.com, which carries its managed services and its mail. Both belong to the same company. Bertoldi Cybersecurity is registered as GCVE Numbering Authority 128 under the short name "bcsec" [GNA-128], and publishes security advisories and a vulnerability disclosure policy at https://bcsec.io/. Appendix A. Example RDAP Responses The examples in this appendix are provided for illustrative purposes only. Values, scheme identifiers, and issuer identifiers are fictional. A.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" } ] } A.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": "REGISTRAR-EXAMPLE", "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" } ] } A.3. 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. { "rdapConformance": [ "rdap_level_0" ], "objectClassName": "domain", "handle": "D-PLAIN-1", "ldhName": "plain.example", "events": [ { "eventAction": "registration", "eventDate": "2025-06-01T00:00:00Z" } ] } Appendix B. 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]. B.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. B.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. B.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. Appendix C. Differences from the IETF Internet-Draft This appendix records the respects in which this document differs from draft-bertoldi-regext-rdap-reliability-scoring. The data model is identical. The differences are the following. 1. References to Internet-Drafts are informative in this document. The IETF document carries a normative reference to [RDAP-EXTENSIONS]; a normative reference to a work in progress is not appropriate in a document intended as a stable specification, so the requirements taken from it that bear on interoperability are restated here in this document's own terms. 2. This document requests no registration in the RDAP JSON Values Registry. See Section 13.2. 3. Passages in the IETF document that solicit review, describe open questions, or characterize the present text as a revision of an earlier one have been removed or restated as statements of what this document does and does not define. No normative statement was changed in doing so. 4. The description of the PIR Quality Performance Index in Section 9.2 and Appendix B.3 corrects an error present in revision 02 of the IETF document, which described QPI as confined to a single registry context and as not addressing structural indicators. Neither is accurate. 5. References to contact verification work are reduced. The IETF document positions this extension as complementary to [VERIFIED-CONTACTS] in its introduction, in its design principles, and in a dedicated subsection. That framing belongs to a discussion between authors within a working group. This document is intended to remain valid without revision for an indefinite period, and [VERIFIED-CONTACTS] is an individual Internet-Draft that may be superseded or may expire without being published. A permanent specification should not define itself by reference to a document that may cease to exist, so the relationship is stated once, in Section 9.1, in terms of the two kinds of metadata, with a single informative pointer to that work and no dependency on it. No normative statement is affected: this document has never depended on that work. Appendix D. Errata This document is not amended. Errata, if any, are published at and are not part of this specification.