🆔Decentralized Identifiers DIDs

Decentralized Identifiers are a new form of identifier that allows for verifiable and decentralized identities. Unlike federated identities, DIDs can operate without the need for centralized registries, identity providers, and certificate authorities. This allows people to verify without the need for a trusted third party.

Zion utilizes the DID:ION method to act as a person's identifier, and contain cryptographic materials for the purpose of authentication and verification while on the Zion network. They are created when someone creates their Zion account. DIDs are a form of Self Sovereign Identity(SSI) which means that they are owned solely by individuals or entities that make them. Once created, only the owner of the DID can delete it. A DID can identify any subject (person, organization, data model, abstract entity, etc.) based on its controller, which has DID document write-privileges. A DID document specifies the syntax, common data mode, core properties, serialized representations, operations and an explanation of the DID resolution process.

A DID is represented by a Uniform Resource Identifier (URI) for trusted interactions between a DID subject and a DID document. A DID is verified by associating a DID document and URI, and can be universally resolvable with DID methods such as DID:ION Method.

Example DID:

{
"@context": "https://w3id.org/did-resolution/v1",
  "didDocument": {
    "id": "did:ion:test:EiBYyFomj3igVP18KzzkpiKXq8BBScaITb5iX4byCJgWFg",
    "@context": [
      "https://www.w3.org/ns/did/v1",
      {
        "@base": "did:ion:test:EiBYyFomj3igVP18KzzkpiKXq8BBScaITb5iX4byCJgWFg"
      }
    ],
    "service": [
      {
        "id": "#zion_dwn",
        "type": "DecentralizedWebNode",
        "serviceEndpoint": {
          "nodes": [
            "https://dwn.zion.fyi",
          ]
        }
      }
    ],
    "verificationMethod": [
      {
        "id": "#key_d7124cf0",
        "controller": "did:ion:test:EiBYyFomj3igVP18KzzkpiKXq8BBScaITb5iX4byCJgWFg",
        "type": "JSONWebKey2020",
        "publicKeyJwk": {
          "crv": "secp256k1",
          "kty": "EC",
          "x": "SNE1sISNI4oI31Z-dj7khMhNF2XKCmsmPDlroyOXZdA",
          "y": "5IDbE7vkqR2YsPRBZ-HKH2vTwdE2Jf1zjvaxvyRrFLI"
        }
      }
    ],
    "authentication": [
      "#key_d7124cf0"
    ],
    "assertionMethod": [
      "#key_d7124cf0"
    ],
    "keyAgreement": [
      "#key_d7124cf0"
    ]
  },
  "didDocumentMetadata": {
    "method": {
      "published": true,
      "recoveryCommitment": "EiAuqEi0iNnp6XjLg5LhVnkBIBOIEbMwOPmEeQXRpClF4w",
      "updateCommitment": "EiBOjgm4WzIVKhbeU4PqhA4Oz-v81LxO3jWONK0OWCwVYw"
    },
    "canonicalId": "did:ion:test:EiBYyFomj3igVP18KzzkpiKXq8BBScaITb5iX4byCJgWFg"
  }
}

DID Document

A DID document contains all information for a DID to be able to function. This includes authentication keys, service endpoints, short-name alias, free-form text, and other attributes as specified by the controller. Use cases can also be implemented with a protocol modification by updating a DID Document.

Service Endpoints

DID Operations Flow

A DID document must include all metadata necessary for the respective service endpoint type. Service endpoints can be duplicated and hosted across multiple providers (URLs) for enhanced resilience. A controller can specify which service endpoint receives message information, either through code or configuration. See the W3C DID Specification Registries for a standardized list of service endpoints and supporting appropriate documentation: https://www.w3.org/TR/did-spec-registries/#service-types.