Privacy and scope: what the resolver does not do

OLPN verification has a narrow, well-defined scope. Knowing what it does not claim is as important as knowing what it does.

What verification means

A successful verification answers one question:

Do the documents at these two domains agree with each other about this claim?

Nothing more. A verified credential says "the issuer's public record and the subject's public record both name this credential, in a consistent way". That's it.

What verification does not mean

It does not prove identity

A resolver does not know who controls a domain. It observes that a domain serves a document. The act of controlling a domain is the only identity signal in the system. If a bad actor obtains jane.law after Jane Doe's registration lapses, that bad actor can publish anything at /olpn.json and the resolver will happily verify it.

This is the same security assumption as HTTPS, email, DNS itself, and every other identity system that treats domain control as the primary signal. It is a weak one for small domains and a strong one for institutional domains with active security teams.

It does not vouch for credential accuracy

A verified "Attorney" credential from firm.com says the firm's public record lists this person as an attorney. It does not say the person passed the bar, is licensed in any jurisdiction, is in good standing, or is currently employed. The issuer attests to what it attests to; the protocol only confirms the attestation is authentic.

Consumers building on OLPN should think carefully about what an issuer's attestation actually means. A bar association's "Active Member" credential carries more weight than a firm's "Contributor" credential, but the protocol treats them the same way. The trust gradient lives in the mind of the consumer, not in the protocol.

It does not do revocation lists

Revocation is implicit: the issuer removes or changes the credential document, and verification stops working the next time a resolver fetches. There is no "this credential has been revoked as of 2026-01-03" signal. A resolver that caches fetches will continue to show a stale credential as verified until its cache expires. The reference resolver does not cache, so this gap is invisible on olpn.org; other implementations may expose it.

It does not timestamp anything

The last_updated field on an entity document is not authenticated. Neither is the timestamp in a resolver trace. Nothing in the protocol prevents an issuer from back-dating a credential, and nothing distinguishes a credential that was valid yesterday and is still valid today from one that was never valid. Consumers who need trustworthy timestamps (litigation, compliance) should layer their own signing and archival on top.

What the resolver collects

A resolver fetches public documents from public URLs. It does not collect personal data about the user performing the search, beyond the usual HTTP server logs. The reference resolver at olpn.org does not set cookies on searchers, does not track across visits, and does not share fetch logs with third parties.

Self-hosted resolvers follow their own privacy policies.

What is left out on purpose

The protocol deliberately does not include:

• Signatures. Documents are not cryptographically signed. Trust is grounded in the cost of controlling a domain, not in key material.
• Rotation. No key or identifier rotation mechanism. If you change domains, issuers have to update.
• Delegation. An entity cannot authorize another party to act on its behalf. Each entity publishes its own documents.
• Aggregation. No index, no crawl surface, no directory. Consumers who want aggregated views build their own.
• Payments, reputation scores, ratings. Out of scope. The protocol verifies; anything else is layered.

Each of these could be added by a future version. None of them are present today, and the protocol's core value comes from being narrow enough that anyone can implement the spec in a long afternoon.