Comment

Comment on theoretical considerations on identity management

bumblefudge@activitypub.space ⁨22⁩ ⁨hours⁩ ago

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 (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 URL. 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.

source

Sort:hotnew top

gandalf_der_12te@discuss.tchncs.de ⁨3⁩ ⁨hours⁩ ago

redereferencing

omg, what a word :o :D

but in general, yes you’re right, adding DIDs to the game is interesting, and making the DIDs also valid URLs is even more interesting. I have been thinking about a similar DID mechanism, where the DIDs are not URLs but public cryptographic keys. this way, each human could prove that many accounts are all signed with the same key, and therefore belong to the same human.

Edit: oh wait i think the official(?) DID specification (here: www.w3.org/TR/did-1.0/) actually already expresses this concept:

Each DID document can express cryptographic material, verification methods, or services, which provide a set of mechanisms enabling a DID controller to prove control of the DID. Services enable trusted interactions associated with the DID subject. A DID might provide the means to return the DID subject itself, if the DID subject is an information resource such as a data model.

source