What is a Relying Party?

definition

AUTHENTICATION & AUTHORIZATION

A Relying Party (RP) is the entity in a digital authentication flow that relies on a trusted third party to verify a user's identity and grant access to a resource.

In a federated identity system, a Relying Party is the application or service that a user is trying to access. It "relies" on an external Identity Provider (IdP)—such as Google, Apple, or a corporate SSO—to perform the authentication. The RP trusts the IdP's assertion that the user is who they claim to be. This model is the foundation of protocols like OAuth 2.0 and OpenID Connect (OIDC), where the RP is often called the client. For example, when you log into a website using "Sign in with Google," that website is the Relying Party, and Google is the Identity Provider.

The technical interaction involves the RP redirecting the user to the IdP for authentication. Upon successful login, the IdP sends a security token—such as a JSON Web Token (JWT) or an OAuth access token—back to the RP. The RP validates this token's signature and claims to establish a trusted session. This process decouples user credential management from the application, centralizing security and simplifying the user experience. In blockchain contexts, a decentralized identifier (DID) ecosystem also uses Relying Parties; here, the RP trusts verifiable credentials issued by a user's wallet or a decentralized IdP.

Key responsibilities of a Relying Party include defining scopes and permissions, securely handling tokens, and managing user sessions. It must implement proper token validation to prevent attacks like token replay or injection. The relationship is governed by a pre-established trust agreement, often formalized through client registration and the exchange of cryptographic keys. By offloading authentication, RPs can reduce their attack surface and compliance burden, focusing development resources on their core service logic rather than identity management infrastructure.

etymology

TERM HISTORY

Etymology & Origin

The term 'Relying Party' has a long history in legal and security frameworks before becoming a cornerstone of digital identity and blockchain systems.

In the context of digital systems, a Relying Party (RP) is an entity that depends on an assertion or credential—such as a digital signature, a cryptographic proof, or an identity claim—presented by another party to make an authorization or authentication decision. The term originates from trust law and contract law, where a party 'relies' on a representation made by another, establishing a basis for legal liability if that representation is false. This foundational concept was directly adopted into public key infrastructure (PKI) standards in the 1990s, where the RP is the server or service that relies on a certificate authority's validation of a user's digital certificate.

The migration of this term into decentralized identity (DID) and blockchain contexts represents a logical evolution. In these systems, the Relying Party's role remains functionally identical: it consumes and verifies verifiable credentials or proofs. However, the trust model shifts from a centralized Certificate Authority (CA) to decentralized verifiers, cryptographic proofs, and smart contracts. For example, a decentralized application (dApp) acting as an RP might rely on a zero-knowledge proof presented by a user's wallet to verify they are over 18 without revealing their birth date, or a DeFi protocol might rely on a proof of asset ownership to grant a loan.

Understanding the RP's role is crucial for analyzing system security and trust boundaries. The RP carries the business risk of accepting an invalid assertion, making its verification procedures—checking signatures, revocation status, and proof validity—paramount. In blockchain oracles, the oracle service itself can be considered a Relying Party for off-chain data before repackaging it for on-chain smart contracts. This chain of reliance underscores why the term is so pervasive: it precisely defines the entity at the endpoint of a trust decision, whether in a traditional client-server model or a trust-minimized, decentralized network.

key-features

ROLE IN AUTHENTICATION

Key Features

A Relying Party is the entity that depends on a verifiable credential or assertion from an issuer to grant access or a service. It is the final verifier in a decentralized identity or authentication flow.

01

The Verifier

The core function of a Relying Party is to verify credentials. It receives a verifiable credential (like a proof of age or KYC status) from a user, cryptographically checks its validity and the issuer's signature, and then makes an access control decision based on that proof.

02

Decentralized Trust Model

Unlike traditional systems where the RP must know the user directly, it operates on a trust-over-IP model. It trusts the credential because it trusts the issuer (e.g., a government or accredited entity) and the underlying cryptographic proofs, not because it has a direct relationship with the user.

03

Protocol Agnostic

A Relying Party can operate across different standards. Common protocols it interacts with include:

OIDC (OpenID Connect): For federated identity.
SIOP (Self-Issued OpenID Provider): For user-held credentials.
W3C Verifiable Credentials: For portable, cryptographically secure claims. The RP's role is defined by the verification logic, not a single protocol.

04

Minimizes Data Exposure

A key security benefit. The Relying Party requests only the specific claim it needs (e.g., "over 21"), not the underlying raw data (like a birth date). This principle, data minimization, reduces privacy risk and liability for the RP.

05

Example: DeFi Lending Platform

A DeFi protocol requiring accredited investor status acts as the Relying Party. A user presents a verifiable credential from a licensed issuer. The protocol's smart contract (the RP logic) verifies the credential's signature and validity period before allowing access to a private pool, without ever learning the user's identity or net worth.

06

Contrast with Issuer & Holder

To understand the RP's role, contrast it with the other two actors in the trust triangle:

Issuer: Creates and signs the credential (e.g., a university).
Holder: Stores and presents the credential (e.g., a graduate).
Relying Party: Consumes and verifies the credential (e.g., an employer). The RP's trust is placed in the issuer, not the holder.

how-it-works

AUTHENTICATION ARCHITECTURE

How a Relying Party Works

A relying party (RP) is the service or application that relies on an external identity provider to authenticate a user's identity and grant access to its resources.

In a decentralized identity or federated authentication system, the relying party is the entity that depends on a verified claim about a user. It does not issue credentials itself but instead trusts assertions made by a trusted third party, known as an identity provider (IdP) or credential issuer. Common examples include a website that allows users to "Sign in with Google" or a decentralized application (dApp) that accepts a Verifiable Credential from a user's digital wallet. The RP's primary role is to define an authentication policy, request specific user attributes, and validate the proofs presented by the user.

The technical workflow begins when a user attempts to access the RP's service. The RP redirects the user to their chosen identity provider, initiating an authentication request. This request specifies the required claims (e.g., email, age, KYC status) and the type of proof needed. The IdP authenticates the user and issues a security token—such as a JSON Web Token (JWT) or a Verifiable Presentation—containing the attested claims. The user then presents this token back to the relying party. The RP must cryptographically verify the token's signature to ensure it came from a trusted issuer and has not been tampered with, a process known as proof verification.

For the system to function securely, the relying party must establish trust relationships with specific identity providers. This is often done by pre-configuring the RP with the IdP's public keys or Decentralized Identifiers (DIDs) listed in a trusted registry. In Web3 contexts, an RP might trust credentials issued to a user's self-sovereign identity (SSI) wallet. Key considerations for an RP include managing user sessions after successful authentication, handling different authentication protocols like OAuth 2.0, OpenID Connect (OIDC), or W3C Verifiable Credentials, and ensuring compliance with data privacy regulations by only requesting the minimum necessary user data.

examples

REAL-WORLD APPLICATIONS

Examples of Relying Parties

A relying party is a service or application that depends on a verifiable credential or cryptographic proof from a user to grant access or a service. These examples illustrate how they function across different blockchain and digital identity contexts.

01

Decentralized Finance (DeFi) Protocol

A DeFi lending platform is a classic relying party. It requires proof of a user's collateral ownership and creditworthiness before issuing a loan.

Verifies: On-chain proof of asset ownership (e.g., NFT, token balance) via a wallet signature.
Grants: Access to borrowing liquidity against the collateral.
Example: Aave or Compound requiring a signed message proving control of a wallet with sufficient ETH to open a collateralized debt position.

02

Decentralized Autonomous Organization (DAO)

A DAO acts as a relying party when gating participation based on membership or reputation.

Verifies: Proof of token-based governance rights or a soulbound token (SBT) representing membership.
Grants: Voting power on proposals or access to exclusive channels and treasury funds.
Example: A DAO verifying a user holds a specific NFT to grant them voting rights on a snapshot.org proposal.

03

Zero-Knowledge (ZK) Application

Applications using zero-knowledge proofs rely on cryptographic attestations without exposing underlying data.

Verifies: A ZK-SNARK or ZK-STARK proof that confirms a private statement is true (e.g., "I am over 18," "My credit score is >700").
Grants: Access to age-restricted services or preferential loan rates while preserving user privacy.
Example: A ZK-rollup bridge that verifies a proof of funds ownership before allowing asset transfer, without revealing the full wallet history.

04

Cross-Chain Bridge or Router

A bridge is a relying party that must verify asset ownership on a source chain before minting a representation on a destination chain.

Verifies: Cryptographic proof of a burn transaction or lock event on the origin chain, often via relayers or light clients.
Grants: A wrapped or bridged asset (e.g., wBTC, axlUSDC) on the target chain.
Example: The Wormhole bridge verifying a lock-up event on Ethereum before minting wrapped assets on Solana.

05

Web3 Single Sign-On (SSO) Service

A service that allows users to log into multiple dApps using one cryptographic identity.

Verifies: A signed message or decentralized identifier (DID) assertion from a user's wallet (e.g., Sign-In with Ethereum).
Grants: Seamless authentication and personalized access across partnered applications without creating new passwords.
Example: A gaming platform using Sign-In with Ethereum to authenticate a user and load their profile and assets.

06

Credential Issuance Gateway

This is a specialized case where a service acts as a relying party for one process (verifying initial credentials) to become an issuer for another.

Verifies: Proof of completion (e.g., course certificate, KYC check) from a trusted source.
Grants/Issues: A new, verifiable credential (e.g., a soulbound attestation) that can be used with other relying parties.
Example: A university verifying a student's government ID, then issuing a blockchain-based diploma they can present to employers.

VERIFIER ECOSYSTEM

Relying Party vs. Related Roles

Clarifies the distinct responsibilities of a Relying Party within the broader context of identity and authentication systems.

Role / Feature	Relying Party (RP)	Identity Provider (IdP)	Credential Issuer
Primary Function	Consumes and verifies credentials to grant access or services	Authenticates users and manages primary identity sessions	Creates and signs verifiable credentials or attestations
User Relationship	Service provider the user wants to access	Holds the user's master account (e.g., Google, MetaMask)	Trusted entity that certifies specific user attributes
Key Action	Presentation Request & Verification	Authentication & Session Management	Credential Issuance & Revocation
Holds Private Key
Verifies Signatures
Typical Protocol	OpenID Connect, SIWE, VP-based flows	OAuth 2.0, OpenID Connect	W3C Verifiable Credentials, X.509
Data Liability	Liable for decisions based on verified data	Liable for secure authentication and primary data	Liable for the accuracy and validity of issued claims
Example	A decentralized application (dApp)	Google Sign-In, Wallet Provider	University (diploma), KYC provider (proof of identity)

security-considerations

RELYING PARTY

Security & Privacy Considerations

A Relying Party is a service or application that depends on a verifiable credential or proof from a user. This section details the critical security and privacy responsibilities and risks associated with this role.

01

Credential Verification & Validation

The Relying Party must perform rigorous cryptographic verification of any presented credential. This includes:

Checking the digital signature against the issuer's public key.
Validating the credential's schema to ensure data structure is correct.
Confirming the credential has not expired and is not revoked (e.g., by checking a revocation registry or status list). Failure at this stage can lead to accepting fraudulent or invalid claims.

02

Presentation Request Design

The presentation request defines what data the Relying Party asks for. Poor design creates privacy and security risks:

Data Minimization: Request only the specific attributes needed (e.g., "Over 21" vs. full birthdate).
Predicate Proofs: Use zero-knowledge proofs to verify conditions without seeing raw data (e.g., "salary > $50,000").
Selective Disclosure: Allow users to share only parts of a credential. Overly broad requests erode user trust and increase data liability.

03

User Privacy & Data Handling

As the endpoint for user data, the Relying Party has significant privacy obligations:

Correlation Risk: Avoid practices that allow user tracking across sessions (e.g., using persistent, unique identifiers from credentials).
Secure Storage: If personal data is stored, it must be encrypted and protected with the same rigor as any PII.
Retention Policy: Define and adhere to strict data retention and deletion policies. The goal is to verify, not necessarily store.

04

Trust in Issuers & Trust Registries

A Relying Party's security depends on trusting the credential's source. This requires managing trust frameworks:

Issuer Accreditation: How does the Relying Party know an issuer is authoritative? This often involves consulting a trust registry—a decentralized list of approved issuers and their credential schemas.
Registry Integrity: The trust registry itself must be tamper-proof, often implemented on a blockchain or other verifiable data structure.
Dynamic Trust: Policies must adapt as issuers are added or removed from trust registries.

05

Resilience Against Attacks

Relying Parties are targets for specific attacks that must be mitigated:

Replay Attacks: Prevent a valid credential presentation from being reused. This requires using cryptographic nonces and short-lived session challenges.
Phishing & Impersonation: Ensure the user is presenting a credential legitimately bound to them, not one stolen or intercepted.
Man-in-the-Middle (MitM): Secure the communication channel between the user's wallet (holder) and the Relying Party to prevent interception of presentation data.

06

Auditability & Compliance

For enterprise and regulated use cases, Relying Parties must maintain verifiable logs of verification events.

Immutable Audit Trail: Record the fact of verification (e.g., a hash of the presentation), the timestamp, and the issuer's DID, often leveraging blockchain anchoring for non-repudiation.
Regulatory Alignment: Design processes to comply with regulations like GDPR (right to erasure), eIDAS (electronic identification), or industry-specific KYC/AML rules.
Transparency: Be clear to users about what is being verified, logged, and stored.

RELYING PARTY

Common Misconceptions

A Relying Party is a core concept in decentralized identity and authentication, but its role is often misunderstood. These clarifications address frequent points of confusion regarding its responsibilities, trust model, and technical implementation.

Yes, in the context of decentralized identity and Verifiable Credentials (VCs), the terms 'Relying Party' and 'Verifier' are functionally synonymous. Both refer to the entity that requests and validates a credential from a Holder (the user) to grant access to a service or resource. The Relying Party's primary function is to verify the credential's cryptographic proof, check its status (e.g., not revoked), and ensure it meets the required policy (e.g., the user is over 18). This role is distinct from the Issuer, who creates the credential, and the Holder, who presents it.

RELYING PARTY

Frequently Asked Questions

A Relying Party (RP) is a critical component in decentralized identity and authentication systems. These questions clarify its role, responsibilities, and technical implementation.

A Relying Party (RP) is a service or application that accepts and verifies verifiable credentials or decentralized identifiers (DIDs) to grant access or provide a service. It does not issue credentials itself but relies on the cryptographic proofs presented by a holder (user) to authenticate them. The RP's core function is to verify that the credential is valid, unexpired, and was issued by a trusted issuer, and that the presenter is the legitimate holder, without needing to contact the issuer directly for each verification. This enables trustless and privacy-preserving authentication.

Relying Party