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

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

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

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

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

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

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

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

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

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

{
  "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"
    }
  ]
}

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

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. Whether it could be expressed as an addition within this extension or would need a separate one would depend on its design.¶

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:

[BCSEC-RDAP-RA]. Should this document be published as an RFC, the registrant will request that the entry reference the RFC in place of it.¶

Person & email address to contact for further information:

Bertoldi Cybersecurity 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. An Internet-Draft does not satisfy that requirement.¶

The authors have accordingly published a stable specification of this extension at [BCSEC-RDAP-RA], and the registration above is requested against that reference. That document defines the same extension identifier, the same JSON member, the same fields and the same types, so an implementation written against either uses the same wire representation. It differs from this revision 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 authors will bring the divergence introduced by this revision to the attention of the designated experts. Should this document be published as an RFC, the authors will request that the registry entry be updated to reference the RFC in place of it.¶

The -02 revision of this document stated that registration was expected to occur only upon publication as an RFC, and that nothing in it should be read as reserving the identifier in the interim. That statement is superseded. 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.¶

13.2. RDAP JSON Values Registry

Section 7.2 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.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

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

[I-D.ietf-regext-rdap-referrals]

Brown, G. and A. Newton, "Explicit RDAP Redirects", Work in Progress, Internet-Draft, draft-ietf-regext-rdap-referrals-04, 1 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-referrals-04>.

[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.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-06, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-x-media-type-06>.

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

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

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

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

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

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

A.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.10. Changes from -01, retained for continuity

The remainder of this appendix records the changes made in the -02 revision.¶

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

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

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"
    }
  ]
}

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"
    }
  ]
}

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

{
  "rdapConformance": [
    "rdap_level_0"
  ],
  "objectClassName": "domain",
  "handle": "D-PLAIN-1",
  "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 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.¶