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.
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
Expected behavior
IDs like
#atproto_pds
should be possible to expand to an absolute reference. (I assume thatdid: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 aservice
entry "with ID#atproto_labeler
and typeAtprotoLabeler
", 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.