HIP: Handshake Resource Manifests and Named Service Authority

[denuoweb]

Summary

This PR proposes a common Handshake Resource Manifest (HRM) format and defines Handshake Named Service Authority (HNSA) as its first concrete resource profile.

• define an hrm1 TXT commitment to a signed, content-addressed HRM
• define deterministic CBOR resources, controller keys, delegations, validity, replacement, revocation, and verification
• define hns.named-service/v1 for stable services and user-scoped application identities beneath an HNS name
• delegate each named service from the HRM controller to an independently rotatable service key
• keep short-lived endpoint authority outside the complete HRM snapshot
• define the HRM/HNSA adapter for HNSR named routes

No Handshake consensus change or permanent wire assignment is requested.

Motivation

Handshake authenticates current name state, but applications need a shared way to express resources and scoped operational authority without exposing the name wallet key or inventing a separate root format for every protocol.

This branch previously narrowed the generic resource-manifest proposal into a standalone HNSA design because implementing the complete resource system was substantial work. That introduced a parallel hsa1 root and fixed ServiceAuthorizationV1 wire format. The current revision restores HRM Core and makes HNSA a strict HRM profile instead:

current authenticated HNS name state
        -> hrm1 commitment
        -> controller-signed current HRM envelope
        -> hns.named-service/v1 resource
        -> current HRM delegation to a service key
        -> service-signed endpoint delegation
        -> profile-specific endpoint, route, or signed application record

The result is one extensible authority and delegation model for named services and later resource profiles.

User-facing cases

• delegate jaron@denuoweb to Jaron's service key without transferring denuoweb or exposing its wallet key
• let a future payment profile publish HNS, BTC, XMR, invoice, or other destinations for that identity
• host one service across a phone, home server, VPS, direct endpoint, or relay
• delegate a service to a provider and replace it through a newer HRM snapshot
• rotate compromised service and endpoint keys without changing the user-facing identity
• preserve browser origin while endpoints, relays, retrieval locations, and providers change

Application profiles remain responsible for username mapping, payment assets and networks, address validation, proof-of-control requirements, transaction-intent binding, transport behavior, and payload validation.

Documents

Handshake Resource Manifests

Defines:

• authenticated hrm1 commitment selection
• deterministic-CBOR envelope and payload formats
• manifest-controller signatures
• generic resource and delegation objects
• HNS-local, externally proven, and parent-delegated authority
• current-snapshot, transfer, expiry, revocation, caching, and retrieval rules
• the interface required from resource-specific profiles

Named Service Authority

Defines HNSA as the exact hns.named-service/v1 HRM profile:

• canonical named-service identity and resource ID
• ordinary HRM delegation to one service controller
• canonical service-delegation ID and generation
• bounded service-signed endpoint delegations
• application-profile requirements
• username, browser-origin, HIP-0002, wallet-TXT, and DNS-delegation boundaries

HIP-0002 well-known wallet paths and prefixed wallet TXT records remain separate discovery conventions. A payment profile may define an explicit adapter, but those records do not silently become HRM resources or inherit an HNSA user identity.

HRM/HNSA HNSR adapter

Defines the named rendezvous binding:

• version-3, authority-type-2 NamedRouteRecordV3
• stable lookup across manifest, controller, endpoint, relay, and provider rotation
• compact HRM-derived bindings without embedding the complete manifest in every route
• mandatory current HRM/HNSA validation by requesters
• bounded internal validation by relays and rendezvous storage nodes

Unnamed HNSR version-1 routes remain unchanged.

Compatibility and implementation impact

The earlier experimental hsa1, fixed ServiceAuthorizationV1, and version-2/authority-type-1 named-route objects are not wire-compatible with this HRM-backed profile. They are explicitly superseded and must not be silently converted, used as fallback, or share browser/application identity with the new chain.

Existing Rust and JavaScript hsa1 implementations therefore require migration before claiming conformance with these drafts.

Legacy Handshake nodes, resolvers, miners, wallets, and applications may ignore hrm1; the proposal uses existing version-0 resource data and ordinary TXT records.

Validation

• git diff --check
• balanced fenced-code blocks across all three drafts
• deterministic HNSR route-key vector reproduced exactly
• local branch and fork remote verified at commit c7bdd2e