RDAP Can Name an Assessor, Not Authenticate Its Result

Summary

Revision 02 replaces one generic score object with an array of results, each tied to a required scheme and a required issuer URI.
The URI says who a result is attributed to. It does not prove that the named issuer created it, that an intermediary relayed it unchanged, or that the methodology deserves trust.
Leaders should treat an RDAP assessment as a structured claim with a subject, scheme, issuer, publisher, date, lifecycle state and evidence trail—not as a portable verdict.

A green number in a directory response looks decisive. That appearance is precisely why draft-bertoldi-regext-rdap-reliability-scoring-02, filed on September 6, deserves attention. The revision is not merely adding another JSON field. It is trying to stop a machine-readable assessment from borrowing more authority than the protocol can supply.

The authors changed the extension's public name from reliabilityScoring to reliabilityAssessment. They replaced a single object with reliabilityAssessment_results, an array capable of carrying several issuers or schemes. They made scoreScheme and scoreIssuer mandatory, required the issuer to be a stable URI, added validUntil, assessmentId and lifecycle status, and documented that no implementation is known.

Those are valuable corrections. They also reveal the central limit.

A label is not a signature

Revision 02 separates three properties that operational systems often collapse. Identity is the party to whom the result is attributed. Trust is the consumer's reason for relying on that party. Authenticity is proof that the assertion really originated there and reached the consumer unaltered.

scoreIssuer provides the first property. The draft explicitly does not provide the third. A URI under an assessor's control is a durable name; it is not a cryptographic signature over the result. Trust remains an out-of-band decision.

HTTPS does not close the gap. RFC 7481 uses TLS to authenticate the server and protect a response in transit. That can prove which endpoint delivered particular bytes. It does not prove that a third-party assessor named inside those bytes authored the assessment. RFC 7481 also warns against confusing transport integrity with the factual accuracy of directory data. Revision 02 applies the same discipline to evaluative data.

Three identical envelopes, three different trust paths

The draft anticipates an assessor operating its own RDAP assessment service, a registry or registrar republishing somebody else's result, and an operator assessing itself. All three can produce the same JSON shape. They do not create the same assurance.

At a first-party assessor endpoint, endpoint trust and issuer trust may coincide because the relying party configured both together. Under republication, the consumer must trust the assessor and the intermediary; the response alone cannot distinguish the two roles. Under self-assessment, the identity field may be perfectly accurate while the incentive to present the result favourably is strongest.

This is why the draft declines to put assessment services into the RFC 9224 bootstrap used to find authoritative registration-data servers. It also rejects a casual referral from an authoritative server, because such a link could look like endorsement. Discovery would solve reachability, not trust.

The useful object is a tuple, not a score

The array's order carries no precedence, authority or recency. A value of seven under one scheme cannot be assumed equivalent to seven under another. validUntil means the issuer no longer vouches for currency after a date; it does not magically invalidate the historical assertion. Missing status does not mean active. A withdrawn result may remain visible so cached consumers can learn that it was withdrawn. Absence of the entire member says nothing about whether an assessment occurred.

The operational object is therefore a tuple: bound subject, scheme identifier, issuer URI, delivering endpoint, assessment identifier, score date, validity horizon, status and retained evidence. Strip away any of those dimensions and automation begins inventing meaning.

Subject binding is itself uneven. A domain can be queried through its ldhName. A registrar is harder: the assessor uses a service-local entity handle, while an IANA Registrar ID appears only in publicIds after retrieval. A client holding the ID cannot construct the query in-band. RFC 8521 tagging is raised as a possibility, not adopted, and the ccTLD case remains unresolved.

Due process sits outside the envelope

The revision requires every publishable scoring scheme to document a disclosure threat model, notify the assessed party, provide time for remediation or contestation, explain data minimisation and justify domain-level publication. That matters because a poor security result can become a reconnaissance list, and a domain-level label may expose a smaller target than a registrar-level aggregate.

But the protocol does not choose the notice period, adjudicator, governance body or consequence of a successful challenge. Nor should a transport envelope quietly acquire that mandate. Those choices must be visible in the scheme and accountable to the parties who bear the loss.

The result is an unusually candid draft. It admits that a published score is informational, not a certification or enforcement mechanism; that evidence links can change or vanish; that a high value proves no absence of vulnerabilities; and that signed assessment assertions are future work. The right response is not to dismiss the extension. It is to use it at the level of authority it actually has.

RDAP Can Name the Assessor. It Cannot Authenticate the Result

Summary

A label is not a signature

Three identical envelopes, three different trust paths

The useful object is a tuple, not a score

Due process sits outside the envelope

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing