DIDs have several ways of supporting multiple authors / devices. The DID Core specification currently defines these properties/features:

• DID controller (controller). A DID Document can have multiple controllers. It is up to the DID Method how these should work, but I believe the default is independent control, i.e. each listed controller gets full control.
• Also Known As (alsoKnownAs) - DID Document property. Similar to SSB sameAs.
• equivalentId and canonicalId - DID Document metadata properties (these exist outside the DID document). Could be used along with alsoKnownAs.

Note that alsoKnownAs, equivalentId, and canonicalId are marked in the spec as feature at risk: if they are not sufficiently implemented, they may be removed from the Core specification, as explained in %OgynFTq.... (But even if removed, the features could still be usable and may be registered in the DID Specification Registries).

DIDs could also support multiple authors / devices, in method-specific ways, without relying on specific properties defined in the specification or registered extensions. For example:

• did:web (DID document served over HTTPS): a domain name could have multiple IP addresses with different web servers serving requests for the DID document; or a single server that retrieves the DID document from other devices, or just allows the DID controller to make changes remotely from different devices.
• did:key (DID document deterministically derived from public key in the DID): the private key could simply exist in multiple locations. The DID Document Update operation is not supported, so there is no issue of ordering update events. (although the signed-ietf-json-patch extension may be used).
• DID Methods based on blockchains rely on the blockchain's consensus mechanism.

Another way would be for a DID Document to contain multiple verification methods. A verification method is typically a public key, for the purpose of authentication, or other purposes (corresponding to verification relationships). A DID document could contain multiple public keys, one for each of the user's devices (for the case where the DID Subject is a person with multiple devices). There is also a proposal for a type of verification method, VerifiableCondition, that could be used to combine verification methods in "m-of-n" configurations.

@cel-desktop thanks for the write up about DID. I'm trying to understand how the system works, so bear with me ;-)

If I understand this correctly, the alsoKnownAs works the same way in as the solution I proposed in feedless identity in that it requires consensus, right? Also is the mechanism for revoking roughly the same?

A controller is expected to immediately revoke any verification method that is believed to be compromised.

@arj

DID Core suggests that applications require the alsoKnownAs relationship to be confirmed/reciprocol. In that case, the relationship is broken if either DID document is updated to remove that relationship. I think it is up to applications to further specify it. I'm not aware of existing applications using alsoKnownAs, as I have not looked into this.

That sentence about revocation is about verification methods. A verification method is typically a public key. A DID Document may contain verification methods for specific purposes. Revoking a verification method would mean updating the DID document to remove that verification method id and/or object from the DID document.

It would also make sense to remove an alsoKnownAs relationship to a DID whose verification methods are believed to be compromised. That would be done by updating the DID document to remove the ID from the alsoKnownAs array/property.