Delegate volatile data to another DID, such as entries for Endpoints and Beacon Descriptors (imported)

[dcdpr]

This is a requirement to allow DIDs as serviceEndpoints in DID Documents. The motivation is to discard data churn and increase privacy; these separate DIDs can have shorter lifetimes than the parent DID, and once the parent DID Document is updated to not refer to one, it need not be presented for validation.

This is currently supported by the DID core and DID resolution specifications. We are documenting this issue to capture the use case and ensure the specs remain supportive of this feature.

This issues is migrated from the old repo's hashtag-77, created Sep 4, 2024.

---

[previous description, which underwent expansion and rewrite for Github audience in February, 2025]

In did:btc1, DID Controllers are responsible for distributing their data to Resolvers, if it is not already cached. Fast-changing data in a DID Document with a long history is made much easier to handle if it can be pushed down into a DID that can be discard later on. Fast changing data could be an endpoint (IPv4 address) or a Beacon Descriptor (BIP380). Then, spec encodings that take up a bit more data, like zCaps (old repo hashtag-43), are not a problem.

Imagine that you are okay updating your top-level DID once a month. But your ISP changes your IPv4 address every 2 hours. How can you keep your endpoint information updated, without being responsible for a multi-megabyte upload every time someone wants to verify your DID? Well, you create a new DID for your endpoints once a month, and update the persistent DID to point at the fresh one. Then, every month you can throw away the old DID for endpoints. Old endpoints are definitely never needed by Resolvers. And, given known use cases, only the current endpoint is required by a Verifier such as a party attempting to initiate contact.

Another use case for quickly changing info in a DID Document might be certain advanced forms of Aggregate Beacons that allow the group to eject cohorts that are failing to sign transactions advancing progress. Dynamic group membership like this might help the group to scale to very large numbers of reliably-online cohorts, such as 50,000 people keeping their servers running. The address for the next Beacon Signal might still change every hour, based on people falling offline. An Aggregate Beacon made of a shifting group of this type will create a unique Bitcoin address every time group membership changes, through an online Schnorr multisig protocol, which will be used to find that Aggregate Beacon's updates on-chain. Here, the ideal delegation for any member of the group will be to list the Aggregate Beacon's volatile Beacon Descriptor DID. The volatility refers to a matter of updating the DID Document - not changing the ID. Using the Beacon's static DID (assuming they have one) would be a type error: that's not a document about a Beacon Descriptor. Given a shifting group, using the Aggregator Beacon's current Bitcoin address would require the Controller to update their DID Document as often as the group shifts.

In verifying the Controller's DID Document, the Resolver has a dispensable option to follow resolution into endpoints that the DID Controller lists as DIDs (given the assumption of no critical use cases as asserted above), yet there is a critical need for a Resolver to reconstruct the full record of the DID Controller's chosen Beacon Descriptors (that is, the list of addresses where Beacon updates may be found on-chain). The DID Controller MUST be responsible for providing to the Relying Party (possibly via satisfying the Resolver directly), as sidecar data, all of the Beacon Descriptors used by any Aggregate Beacon it has pointed at with a DID (instead of a static Bitcoin address as the Beacon Descriptor). In practice, this means the full history of updates to the Beacon Descriptor DID Document. The Aggregate Beacon can also maintain its Beacon Descriptor DID Document history under some highly reliable (IPFS) CID, so that the need to actually ship this history around as sidecar data can be engineered away.

Comments from that thread (all from October, 2024):

---

This is worth bubbling up to the DID core work. We need to make sure a serviceEndpoint can be a DID that triggers another resolution working in DID core.

---

The distinction here is that transclusion creates a necessary history to store, whereas this Method-level indirection is not kept in DID Document history.

---

There are two seemingly relevant open issues in DID resolution:

• Supporting a DID as a serviceEndpoint - Support DIDs as serviceEndpoint? w3c/did-resolution#7
• Proxy serviceEndpoints - Support "proxy" service type? w3c/did-resolution#35