Explain that DID URL dereferencer acts as client of a DID resolver

[peacekeeper]

This tries to address some confusion about clients, resolvers, and dereferencers, by stating explicitly that a DID URL dereferencer acts as a client of a DID resolver.

This does NOT mean that a DID resolver is a remote service; it can also be an entirely local process.

This does NOT mean that a DID URL deferencer exposes an endpoint; it can also be an entirely local process.

---

Preview | Diff

[msporny]

Using the word "client" here is going to confuse people. Much of the "client-server" language used in IETF specs, and a number of W3C ones, really does mean "A remote system". People won't think "caller of a software library function" when they read "client".

[peacekeeper]

I agree, but in the context of DIDs, we have always been using the term "client" in this way. If you execute a local library to resolve a did:key, then according to the current spec, you also have a "client" which invokes a "resolver", even if it's done via a local binding. This is why in the terminology about client, we say this:

The term client does not imply any specific network topology.

If we want to avoid this confusion, maybe we should use another term instead? E.g. "caller"?

[swcurran]

If we have used the term "client" in this way, we should stop. Perhaps In other words, the <a>DID URL dereferencer</a> invokes a <a>DID resolver</a> during this process.

"Client" should be reserved for the logical external component that passes in a DID URL, gets back some sort of resource, and who handles the fragment given the resource returned.

[msporny]

Suggested change

	This process depends on <a>DID resolution</a> of the <a>DID</a>
	contained in the <a>DID URL</a>. In other words, the <a>DID URL dereferencer</a>
	acts as a <a>client</a> of a <a>DID resolver</a> during this process.
	This process depends on <a>DID resolution</a> of the <a>DID</a>
	contained in the <a>DID URL</a>. In other words, the <a>DID URL dereferencing</a>
	process happens after, and is dependent upon, the <a>DID resolution</a> process.

[peacekeeper]

I'm fine with this change, but I think @jandrieu wanted to explicitly mention that a dereferencer is a "client" to a resolver, e.g. see this comment #311 (comment) .

[swcurran]

The use of "after" is a bit tricky here. It is part of the DID URL Dereferencing process if for now other reason than there may be DID parameters used in DID resolution. It is always a DID URL passed in by the client and dereferencing must begin by resolving the DID using the DID and any relevant parameters.