RDAP Extension for Structured Reliability Assessment Metadata

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

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

A certification such as ISO/IEC 27001 [ISO27001] or ISO/IEC 27701 [ISO27701] attests conformity against a defined scope at a point in time, through a formal audit process with its own accreditation chain. 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.¶

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 recognise the configuration and to weigh the result accordingly.¶

5.2. Minimal Response

An assessment service MUST NOT be treated 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].¶

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 registration data. An assessment service is not authoritative for registration data, 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

The authors considered, and do not propose, 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.1. Domains

For domain objects, "ldhName" provides the standard lookup key and the query form /domain/<ldhName> 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 only as /entity/<handle>, and the syntax of a handle is specific to the registration provider. The "publicIds" member is a response structure, not a lookup 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.¶

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. 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. The authors raise this as an open question rather than proposing it: it is not clear whether this is a sound use of [RFC8521] given that the assessor would be authoritative for the assessment representation but not for the underlying registration data. Feedback is explicitly sought.¶

The binding for registrars operating under ccTLD registries, and for registrars with no IANA Registrar ID, is likewise unresolved. The "publicIds" member accommodates other identifier types, but this document does not prescribe one.¶

7.1. Extension Identifier

This extension is identified by the string "reliabilityAssessment", to be 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 that section.¶

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¶

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 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 described in the following table.¶

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

Implementers MUST NOT infer normative meaning from the illustrative field values used in the examples in this document or in Appendix C.¶

7.6. Result Status Values

The "status" member, when present, takes one of the following values:¶

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

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

The absence of the "reliabilityAssessment_results" member MUST NOT be interpreted 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 how the assessment envelope MAY appear within an entity object representing a registrar.¶

{
  "rdapConformance": [
    "rdap_level_0",
    "reliabilityAssessment"
  ],
  "objectClassName": "entity",
  "handle": "REGISTRAR-EXAMPLE",
  "roles": ["registrar"],
  "publicIds": [
    {
      "type": "IANA Registrar ID",
      "identifier": "9999"
    }
  ],
  "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 how the assessment envelope MAY appear within a domain object.¶

{
  "rdapConformance": [
    "rdap_level_0",
    "reliabilityAssessment"
  ],
  "objectClassName": "domain",
  "handle": "example.com",
  "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"
    }
  ]
}

9.1. Relationship to draft-loffredo-regext-rdap-verified-contacts

The [I-D.loffredo-regext-rdap-verified-contacts] extension establishes that contact data associated with a domain or registrar has been verified. 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 addresses 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

PIR's Abuse Intervention Program (AIP) and Quality Performance Index (QPI) [PIR-AIP] represent an example of a registry-specific operational assessment program. This document does not standardize such a program; it defines a generic RDAP representation that could carry outputs produced by programs such as PIR/QPI or other assessment frameworks. The authors note that PIR has not, to their knowledge, undertaken RDAP work in connection with these programs.¶

An operational scoring system such as PIR/QPI could, in principle, expose its outputs through the envelope defined in this document, enabling broader interoperability without modifying its internal methodology.¶

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

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 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 and is not specified here.¶

13.1. RDAP Extensions Registry

This document requests the registration of the following entry in the RDAP Extensions Registry, using the template defined in Section 8.1 of [RFC7480]:¶

Extension identifier:

reliabilityAssessment¶

Registry operator:

Any¶

Published specification:

this document¶

Person & email address to contact for further information:

Alessandro Bertoldi alessandro@bertoldicybersecurity.com¶

Intended usage:

COMMON¶

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. Registration is therefore expected to occur upon publication of this document as an RFC, and nothing in this document should be read as reserving the identifier in the interim.¶

13.2. RDAP JSON Values Registry

This document requests the registration of a new value type in the RDAP JSON Values Registry, in accordance with Section 7.2 of [I-D.ietf-regext-rdap-extensions].¶

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 this document as its published specification.¶

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-15, 13 August 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions-15>.

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

[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

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

[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-07, 31 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-versioning-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]

"Information security, cybersecurity and privacy protection -- Information security management systems -- Requirements", ISO/IEC 27001:2022, 2022.

[ISO27701]

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

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

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

A.1. 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.2. 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.¶

• 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.3. 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.4. 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.¶

C.1. Domain Lookup with a Single Result

{
  "rdapConformance": [
    "rdap_level_0",
    "reliabilityAssessment"
  ],
  "objectClassName": "domain",
  "handle": "example.com",
  "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"
    }
  ]
}

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": "REGISTRAR-EXAMPLE",
  "roles": ["registrar"],
  "publicIds": [
    {
      "type": "IANA Registrar ID",
      "identifier": "9999"
    }
  ],
  "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"
    }
  ]
}

C.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": "plain.example",
  "ldhName": "plain.example",
  "events": [
    {
      "eventAction": "registration",
      "eventDate": "2025-06-01T00:00:00Z"
    }
  ]
}

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

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 such as PIR's Quality Performance Index [PIR-AIP] focus on observable abuse outcomes and operational metrics within a single registry context. The assessment dimensions described above focus on structural security posture. The envelope defined in this document is agnostic to the methodology and could carry results from either type of program.¶