Thanks.
If I understand you correctly: there are a number of approaches that various systems are using already for DID-linked resources. This might eventually become standardized by the DID Linked Resources working group. Rather than attempting to re-specify DID syntax specifically for the IPNS use case, we should allow different DID method resolvers to adapt their target systems’ DID document linked resource syntax to allow for more generic discovery. In that sense, the proposal over-specifies when it comes to the DID side of things. This all makes sense to me.
I believe UCANs can be worked into the link file structure, which I think addresses @SgtPooki’s use case, among others. The link would still be “owned” by the DID (as interpreted by the resolver), but this allows the DID controller to delegate signature authority for new link files. This also makes sense. The entity that makes the link file also needs permission to update consensus system state related to the IPNS name (DID+fragment, however we represent it), but the precise mechanism for doing that can be left as a system-specific implementation detail, as is the storage of the link file CID; from the perspective of the IPNS resolution core code, an IPNS name can be resolved to a link file CID; the link file can be validated to ensure it was created with the proper UCAN-based authorization.
There is a slight semantic mismatch between the expiration time of the UCAN and the lifetime of the validity of the link. That is, it may be impossible to prove that the link file was created during the time period when the UCAN was valid. But assuming the attacker in this scenario does not have the ability to update the DID document to reference the new link, this is probably a manageable issue.
I like where this is going. I will work on reshaping the proposal.