You are reading content from Scuttlebutt
@cel-desktop %65eRuSMp1jmLO6ABIhM7FQUnxdlw0q2wVYmNqkFS/VA=.sha256
Re: %6tNYCdB2J

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

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.

@Anders %muAH6yz6MWkhE23AhrTCPOAoxBF6rE1gcFGgj514p44=.sha256

@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.
@cel-desktop %Ft+KkqjuUA/FwFC5SoYUHKPGRy2LeguuUUtZRAblqR0=.sha256


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.

Join Scuttlebutt now