HIP: Named Service Authority for Handshake

[denuoweb]

Summary

• propose Handshake Named Service Authority (HNSA), an optional authorization layer for application services operated beneath an HNS name
• define a canonical hsa1 TXT root key and epoch, root-signed named service authorizations, and service-signed endpoint delegations
• separate durable HNS name custody from online service and endpoint keys
• provide a transport-independent authority chain that can be consumed by HNSR, direct web, messaging, QUIC, or other separately specified service profiles

Motivation

Handshake authenticates names and DNS resource data but does not provide an implementation-independent format for delegating named application services. Applications otherwise need to expose a name wallet key, invent separate TXT key formats, trust a directory or relay endpoint, or define the same authority chain inside every transport proposal.

HNSA keeps the HNS name as the root of identity while allowing service operators, providers, and devices to use independently scoped and replaceable keys.

User-facing cases

• host one HNS web service across a phone, home server, and optional VPS
• delegate one service to a provider without transferring the HNS name or wallet key
• rotate a compromised service or endpoint key without changing the user-facing identity
• operate web, chat, and files beneath one HNS name with independent keys
• preserve browser origin, permissions, and storage while direct addresses, relays, endpoints, or providers change

Authority chain

current authenticated HNS name state
        -> service-authority root key and epoch
        -> root-signed named service authorization
        -> service-signed endpoint delegation
        -> profile-specific endpoint or route record

The current HNS record provides root replacement and global epoch revocation. Finite service and endpoint authorizations limit stale authority, while separate service keys prevent compromise of one application from affecting unrelated services or name custody.

Scope

This HIP defines service identity, canonical service names, root and endpoint delegation objects, signature domains, replacement and expiry rules, validation, implementation limits, browser-origin requirements, and the interface required from service profiles.

It does not define relay routing, endpoint discovery, HTTP or TLS behavior, IP allocation, ASNs, RPKI, BGP, ports, protocol numbers, link-layer identifiers, or a generic Internet resource registry. Version 1 uses existing HNS version 0 TXT data and requests no consensus change or permanent wire assignment.

Relationship to HNSR

HNSA extracts named-service authority from the transport-specific HNSR design. HNSA authorizes the service and endpoint keys; HNSR may separately discover a currently online endpoint and relay its traffic.

The current HNSR draft uses hnsr1 and HNSR-specific signature domains. The HIP requires a separate HNSR revision or explicit transition before claiming wire compatibility, while unnamed HNSR node rendezvous remains independent.

Implementation path

• shared canonical encoders, signers, and validators for JavaScript and Rust
• wallet support for the hsa1 root record
• deterministic positive and negative vectors
• HNSR named-service adapter
• mobile-browser diagnostic preserving origin across direct and relayed endpoints
• regtest, multi-operator testnet, expiry, revocation, transfer, replay, and no-fallback testing

Validation

• markdownlint-cli2 HIP-xxxx-HNSA.md
• git diff --check origin/master...HEAD
• GitHub-flavored Markdown rendering through the GitHub API