Reliance (in an issuer/verifier model)

Reliance, in an issuer/verifier model, is the act of a verifier accepting a credential's claims as true and acting on them, approving an account, granting access, completing a transaction, without independently re-confirming the underlying fact itself. It's the entire point of a Verifiable Credential existing in the first place: the verifier doesn't re-run a background check or re-scan a passport; it checks a signature and a small set of accompanying facts (is the credential unexpired, unrevoked, from a trusted issuer) and, on that basis, relies.

The word matters because it names where trust actually has to sit in a three-party credential model. The issuer did the underlying work once. The holder carries proof of it. The verifier, often called the relying party, and the two terms are used interchangeably across most of the standards this entry cites, is the one making a decision on the strength of someone else's work, and that decision is the whole transaction.

Where the vocabulary comes from

"Relying party" is a formally defined role in public-key infrastructure: IETF RFC 5280, the X.509 certificate framework standard, defines it as the entity that acts on the faith of a certificate someone else issued. The same phrase carries directly into SAML and OAuth 2.0/OIDC (the "RP" in OIDC is literally the application relying on an identity provider's assertion) and into the W3C Verifiable Credentials Data Model, where "verifier" is the equivalent role. Separately, and older, reasonable reliance is a common-law concept from tort and contract law, courts have asked for centuries whether a party's trust in someone else's representation was justified, given what that party knew or should have known, before holding anyone liable for a bad outcome that followed from it. That older doctrine is the honest frame for the hard question underneath any reusable-credential pitch: is it reasonable for a second business to trust a credential it didn't issue, given only what a trust registry and an assurance level can tell it?

Why this is the load-bearing word in the whole reuse pitch

Every claim this Lexicon batch makes about reuse, reuse rate, and cost crossover depends on reliance actually happening, a second party choosing to trust the first party's work instead of redoing it. Trust Registry and Level of Assurance exist specifically to make that reliance reasonable rather than blind: instead of "trust me," a verifier can check "is this issuer accredited, and to what strength," which is a genuinely different, more defensible position than trusting an unverified claim. But a mechanism that makes reliance reasonable is not the same thing as reliance actually occurring at scale: that second step is a business decision every prospective relying party still has to make on its own, one at a time.

Solidus today

The mechanical half of this is real: Solidus's SDK correctly checks a presented credential's signature and its issuer's trust-registry status, running on the live testnet. The market half is not: no real, unaffiliated relying party has chosen, in production, to rely on a Solidus-issued credential instead of running its own check. Until that happens, everything in this entry describes a working capability, not a proven pattern of actual reliance.

See also

Issuer-Holder-Verifier triangle is the full three-role model reliance sits inside. Liability Shift is what happens when reliance turns out to have been misplaced. Trust Registry and Level of Assurance are what's meant to make reliance reasonable rather than blind.