Re: Ideas about DID explanation

>
> 5) includes the associated DID Document, which may contain material used
>>> to authenticate the DID, the DID Document, and the DID 'owner/controller'
>>>
>>
>> I have run into this sort of verbiage before, that a DID "includes" a DID
>> Document. I think the phrase "is associated with" or "may be associated
>> with" is more accurate. A DID that has been created but not yet written to
>> anywhere that associates it with a DID Document is still a DID, is it not?
>>
>
> <<<ACH: A DID without a DID Document cannot be authenticated, so might not
> be too useful :) 'associated' is from the spec text.
>

Yes, I get that a DID without a DID Doc is not very useful. But we still
can't say that a DID "*includes* the associated DID Document." This is
conflating an identifier with the thing it identifies. Does a domain name
"include the associated web server host name" by definition, or can it be
bound to a hostname (registered in DNS) after the domain name exists in
unregistered form? Likewise, can I create a DID and begin using it as an
identifier in my own records, then decide later which endpoint and keys I
want to use for that DID when I'm ready to share it? If so, what is the
identifier called before it's associated? Surely it's called a DID, right?
Or does it only become a DID when the association is completed, and before
that it's a "potential DID"? What happens for a DID that's not stored on an
immutable ledger, but in a mutable database, such that its registration can
be deleted--does it cease to become a DID at that point?

I know this is splitting hairs, but I have heard this same semantic
shorthand several times, and it is making me uneasy. I think it leads to
assumptions about temporal coupling and about the binding between a DID and
crypto (a single entity must both create the identifier and bind it to
keys+register it in the same event) that are not strictly required by the
spec, and that may be undesirable in some cases.