Re: Idea for a Proposal: Notation for resolving a DID identifier directly to the underlying object or collection of objects associated with the DID identifier

If the DID URL did resolve directly to the object itself, wouldn't that
eliminate any ability to do any "verifiable" stuff until *after* the object
had been resolved (i.e. after a subsequent fetch of the DID document)? If
verifiability is important, and it can't be accomplished without the DID
Document, why would it be useful to fetch the object prior to fetching the
DID Document?

bob wyman


On Sat, Dec 18, 2021 at 10:24 PM Michael Herman (Trusted Digital Web) <
mwherman@parallelspace.net> wrote:

> The default expected behavior when resolving a DID identifier is
> receive/return all or a portion of the DID Document associated with the
> identifier (if it exists).
>
> The DID Document may or may not contain the URL for one ore more Agents
> (aka service endpoints) that can then be interacted with to perform CRUD
> (or other) operations on the underlying object or collection of objects
> associated with the DID identifier.
>
> What is a suitable notation to short circuit all of the above steps to
> simply return the underlying object or collection of objects associated
> with a particular DID identifier in a more direct way?
>
> In the C programming language, if a variable foo contains the address of
> an object, a developer can dereference the underlying object using the
> notation: *foo
>
> What do people think about supporting a similar convention for DID
> identifiers? ...for example, the string "*did:example:12345" would
> automatically resolve to and return the underlying object or collection of
> objects associated with did:example:12345.
>
> This idea would greatly improve developer productivity and adoption,
> reduce bugs and improve correctness, and decrease the cost of projects that
> incorporate decentralized technology.
>
> Your thoughts?
>
> Michael Herman
> Founder
> Trusted Digital Web
>
>
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
>