ATProto-specific service entries in DID should support absolute references in a stable way

[trwnh]

Describe the bug

Relative references should not be used without a base to clearly expand against

To Reproduce

Look at an example DID document intended for use with ATProto: https://web.plc.directory/did/did:plc:ewvi7nxzyoun6zhxrhs64oiz

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/multikey/v1",
    "https://w3id.org/security/suites/secp256k1-2019/v1"
  ],
  "alsoKnownAs": [
    "at://atproto.com"
  ],
  "id": "did:plc:ewvi7nxzyoun6zhxrhs64oiz",
  "service": [
    {
      "id": "#atproto_pds",
      "serviceEndpoint": "https://enoki.us-east.host.bsky.network",
      "type": "AtprotoPersonalDataServer"
    }
  ],
  "verificationMethod": [
    {
      "controller": "did:plc:ewvi7nxzyoun6zhxrhs64oiz",
      "id": "did:plc:ewvi7nxzyoun6zhxrhs64oiz#atproto",
      "publicKeyMultibase": "zQ3shunBKsXixLxKtC5qeSG9E4J5RkGN57im31pcTzbNQnm5w",
      "type": "Multikey"
    }
  ]
}

Expected behavior

IDs like #atproto_pds should be possible to expand to an absolute reference. (I assume that did:plc:ewvi7nxzyoun6zhxrhs64oiz#atproto_pds is the intended result? It's currently ambiguous.)

Additional context

#atproto_pds isn't the only place where this is an issue. Looking at https://atproto.com/specs/label#labeler-service-identity it appears that the documentation refers to a service entry "with ID #atproto_labeler and type AtprotoLabeler", as well as a key with an exact ID of #atproto_label instead of simply "ending [with] #atproto_label" as https://atproto.com/specs/did#did-documents describes.

This can be most easily resolved by consistently using absolute ids and clarifying in the documentation that these ids should "end in" the fragment component instead of saying that the id exactly matches some fragment component.

Another option might be to use the JSON-LD @base keyword.