URL Usage in KERI

Discovery vs. Trust Separation

KERI implementations must maintain strict separation between URL-based discovery and cryptographic trust. URLs are used only for initial introduction—never for authentication. After resolving an OOBI URL, implementations must verify all received data cryptographically through KERI's key event logs and witness receipts.

OOBI Resolution Process

1. Receive OOBI URL (via QR code, email, social media, etc.)
2. HTTP GET request to the URL to retrieve AID and endpoint information
3. Cryptographic verification of the AID's key event log
4. Witness validation to confirm key state
5. Store verified endpoint for future communication

The URL is discarded after initial resolution—subsequent communication uses the cryptographically verified AID and endpoints.

URL Encoding Considerations

When embedding AIDs in URLs:

• AIDs use Base64 URL-safe encoding (RFC 4648) compatible with URL path components
• No additional URL encoding needed for AID prefixes in paths
• Query parameters should be URL-encoded if they contain special characters
• Fragment identifiers can reference specific resources or key states

Security Considerations

• DNS hijacking: URLs may point to compromised servers, but KERI's cryptographic verification prevents exploitation
• BGP attacks: Network-level attacks cannot compromise KERI security due to end-verifiable authentication
• TLS not required: KERI's security does not depend on HTTPS—HTTP is sufficient for OOBI discovery
• Privacy: URLs may leak correlation information; use blind OOBIs or private channels when privacy is required