Delegatable Verification (DelVe): A simpler approach to domain verification

Version: 0.1.0-draft
Date: October 2025
Status: Draft Specification

This document specifies the Delegatable Verification Protocol (DelVe), a system for verifying domain ownership across multiple decentralized services through an optional delegate service. DelVe enables domain owners to manage verification across numerous instances through a centralized interface while maintaining full control over authorization decisions, avoiding DNS record limitations, and optionally allowing manual verification for users who prefer direct control.

This is a draft specification. Implementations are encouraged, and feedback is welcome.

1. Introduction
2. Terminology
3. Protocol Overview
4. Discovery Mechanism
5. Verification Flows
6. API Specification
7. Cryptographic Requirements
8. Security Considerations
9. Privacy Considerations
10. IANA Considerations

Users who wish to establish domain-based identity across multiple decentralized services face several challenges:

• DNS providers often limit the number of TXT records per domain (typically 10-25)
• Managing verification records across many services requires frequent DNS modifications
• No centralized audit trail of which services have been verified
• Manual DNS updates are error-prone and lack user-friendly interfaces

• Enable domain owners to verify their identity across unlimited services
• Provide optional delegation to simplify management
• Maintain domain owner control through explicit authorization
• Support both delegated and non-delegated verification modes
• Be protocol-agnostic (works with ActivityPub, ATProto, or custom protocols)
• Ensure cryptographic integrity of verification

• Replace existing DNS-based verification (DelVe is complementary)
• Provide identity management beyond verification
• Specify how services use verified identities

Use Case 1: Multi-Instance Presence
Alice wants to use [email protected] on multiple Fediverse instances, several Matrix servers, and various other decentralized platforms without hitting DNS limits.

Use Case 2: Organization Management
A company wants to manage domain verification for 50+ employees across 20 different platforms with audit trails and revocation capabilities.

Use Case 3: Privacy-Conscious User
Bob prefers to manually sign challenges without delegating to a third-party service, maintaining full control over his cryptographic keys.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Domain Owner: The entity that controls a domain and wishes to verify ownership across services.

Verifier (or Instance): A service that needs to verify a user's ownership of a domain.

Delegate: An optional service that holds cryptographic keys and signs challenges on behalf of the Domain Owner after authorization.

Challenge: A time-limited, unique value generated by a Verifier to prove domain ownership.

Verification Token: A signed challenge that proves domain ownership.

Direct Verification: Verification mode where the Domain Owner manually signs challenges without a Delegate.

Delegated Verification: Verification mode where authorization and signing is performed by a Delegate service.

1. Discovery: Verifier discovers how the domain performs verification (delegated or direct)
2. Challenge: Verifier generates a challenge for the domain
3. Authorization (delegated only): Domain Owner authorizes the Delegate to sign
4. Signing: Challenge is signed (by Delegate or Domain Owner)
5. Verification: Verifier validates the signature using the public key

• Domain Owner sets up delegation via DNS
• Delegate generates and stores keypair
• Domain Owner authorizes signing through Delegate's interface
• Suitable for users managing many verifications

• Domain Owner publishes public key via DNS
• Domain Owner manually signs each challenge
• No third-party involved
• Suitable for privacy-conscious users or technical users

A domain MUST publish verification configuration using a DNS TXT record at:

Fields:

• v: Protocol version (currently "delve0.1")
• mode: "delegate" for delegated mode
• endpoint: HTTPS URL of the delegate service
• key: Base64-encoded Ed25519 public key of the delegate

Fields:

• v: Protocol version (currently "delve0.1")
• mode: "direct" for direct mode
• key: Base64-encoded Ed25519 public key of the domain owner

Domains MAY also publish configuration at:

Example:

Verifiers SHOULD prefer DNS discovery over the well-known endpoint for security reasons.

1. Discovery: Verifier performs DNS lookup for _delve.example.com TXT record
2. Challenge Issuance: Verifier POSTs challenge to Delegate endpoint
3. User Authorization: Delegate notifies Domain Owner and requests authorization
4. Authorization: Domain Owner approves or rejects the request through Delegate UI
5. Token Retrieval: Verifier retrieves signed token from Delegate
6. Verification: Verifier validates signature using public key from DNS

1. Discovery: Verifier performs DNS lookup for _delve.example.com TXT record
2. Challenge Generation: Verifier generates challenge and displays it to user
3. Manual Signing: Domain Owner uses local tooling to sign the challenge
4. Token Submission: Domain Owner submits signed token to Verifier
5. Verification: Verifier validates signature using public key from DNS

All endpoints MUST use HTTPS. All requests and responses use application/json content type.

Request:

Response (202 Accepted):

Response (400 Bad Request):

Response (200 OK - authorized):

Response (202 Accepted - pending):

Response (403 Forbidden - rejected):

Revoke authorization for a specific verifier.

Response (200 OK):

Verifiers MUST:

1. Generate cryptographically secure random challenges (minimum 32 bytes)
2. Set reasonable expiration times (recommended: 15-60 minutes)
3. Validate signatures before accepting verification
4. Cache DNS lookups appropriately (respect TTL)
5. Handle all HTTP error codes gracefully

This specification uses Ed25519 (EdDSA with Curve25519) for all signatures.

Implementations:

• MUST support Ed25519
• MAY support additional algorithms in future versions

Challenges MUST be:

• At least 32 bytes of cryptographically secure random data
• Base64-encoded for transmission
• Include a timestamp component to prevent replay attacks

Recommended format:

The signature covers a canonical JSON representation of:

The signature MUST be computed over the UTF-8 encoded, minified JSON (no whitespace) with keys in lexicographic order.

Verifiers MUST:

1. Retrieve public key from DNS _delve record
2. Reconstruct the canonical signing payload
3. Verify the Ed25519 signature
4. Check that signedAt is within acceptable time window
5. Verify challenge matches the one originally issued
6. Confirm the domain and verifierId match expected values

Threats:

• Delegate service compromise
• DNS spoofing/hijacking
• Man-in-the-middle attacks
• Challenge replay attacks
• Unauthorized signing requests

• Domain Owners retain control through explicit authorization
• Signing requires active user approval (not automatic)
• Revocation mechanism allows removing compromised authorizations
• Encourage self-hosting of delegate services

• Verifiers SHOULD support DNSSEC validation
• Use HTTPS for all delegate endpoints
• Pin delegate public keys in DNS records

• Challenges MUST include timestamps
• Challenges MUST expire (recommended: 15-60 minutes)
• Verifiers MUST track used challenges and reject duplicates
• Signed tokens MUST include signedAt timestamp

• All delegate communication MUST use HTTPS
• Verifiers MUST validate TLS certificates
• Consider certificate pinning for high-security deployments

Delegate services SHOULD implement rate limiting:

• Per domain: 100 challenge requests per hour
• Per IP: 1000 requests per hour
• Per verifier: 10 pending authorizations per domain

Delegate services MUST:

• Implement secure user authentication
• Display verifier identity clearly during authorization
• Support multi-factor authentication (RECOMMENDED)
• Log all authorization decisions
• Provide audit trails to domain owners

What is revealed:

• Domain ownership
• List of services where domain is verified (via delegate logs)
• Timing of verification attempts

What is NOT revealed:

• User activity on verified services
• Content of communications
• Relationship between different domains

Delegate services:

• MUST NOT share authorization data with third parties
• SHOULD allow domain owners to delete historical data
• SHOULD support pseudonymous domain verification where possible
• MUST provide clear privacy policies

Verifiers SHOULD:

• Not include unnecessary metadata in challenge requests
• Respect domain owner's choice of direct vs delegated verification
• Not track or correlate verification attempts across domains

This specification registers the _delve DNS label prefix for domain verification records.

This specification registers the /.well-known/_delve.json URI for domain verification discovery.

1. DNS Configuration:

2. Verifier Issues Challenge:

3. Domain Owner Authorizes (via web UI)

4. Verifier Retrieves Token:

5. Verifier Validates Signature using public key from DNS

1. DNS Configuration:

2. Verifier Displays Challenge to User

3. User Signs Locally:

4. User Submits Signature to Verifier

• DelVe Pro: Scales to unlimited verifications, centralized management
• DNS Pro: Simpler, no third party required
• Use DelVe when: Managing many verifications or hitting DNS limits

The Mikoto Platforms Team