See also FEP-e3e9 on DID-like redereferencing from an HTTP server of actor objects-that-are-also-DID-docs
using a did:… as an actor.id prop is a little spicy and isn’t exactly backwards compatible with the entirely HTTPS-based fediverse, BUT all web-based did methods in their respective ways (did:web, did:webvh, did:webplus, and even did:plc if you squint a little and hardcode the discovery path to a document cache like plc.directory or a custom resolver like pdsls.dev) let you express a DID not just as a did string but also as a normal URL that dereferences to a DID document that is also a conformant/valid Actor object. if the server does con-neg and returns the actor object as JSON-LD (or debatably even if it ignores con-neg and just already serves a JSON-LD did doc without the appropriate content-type header) then… you just dereferenced an actor conformantly even though what you got back was a “DID Document” in addition to being an actor object.
See also FEP-e3e9 on DID-like redereferencing from an HTTP server of actor objects-that-are-also-DID-docs
using a
did:… as an actor.id prop is a little spicy and isn’t exactly backwards compatible with the entirely HTTPS-based fediverse, BUT all web-based did methods in their respective ways (did:web, did:webvh, did:webplus, and even did:plc if you squint a little and hardcode the discovery path to a document cache like plc.directory or a custom resolver like pdsls.dev) let you express a DID not just as a did string but also as a normal URL that dereferences to a DID document that is also a conformant/valid Actor object. if the server does con-neg and returns the actor object as JSON-LD (or debatably even if it ignores con-neg and just already serves a JSON-LD did doc without the appropriate content-type header) then… you just dereferenced an actor conformantly even though what you got back was a “DID Document” in addition to being an actor object.