LogoLogo
  • 👋Introduction
    • Zion v2
  • 🏗️Zion Protocol Architecture
    • Overview
    • 🆔Decentralized Identifiers DIDs
      • DID Document
      • Service Endpoints
      • Sidetree
      • DID Universal Resource Identifier
        • Short Form URI
        • Long Form URi
      • DID Operations
        • Signing
        • Verification
      • Verifiable Credentials
    • ⚙️Decentralized Web Nodes
      • Messages
        • Basic Message
        • Signed Data
        • Authorization
        • Encrypted Data
      • DWN Requests
    • ⚡Bitcoin Lightning Network
      • Invoices
      • Payments(HTLC)
      • Taro
        • Non fungible Assets
        • Assets
        • Multi-Hop Taro Transfers
        • Asset Exchange
  • 📲Zion Social
    • Zion App
      • DID Account Creation
      • Social Profiles
      • Lightning Wallet
      • Creator Communities
      • Community Posts
    • Guide
  • 💫Web5 Interoperability
    • Why Web5?
    • Future Thoughts
    • FAQs
  • 📧Contact and Media
    • Contact Us
    • Social Media
Powered by GitBook
On this page
  • DID Document
  • Service Endpoints

Was this helpful?

  1. Zion Protocol Architecture

Decentralized Identifiers DIDs

PreviousOverviewNextSidetree

Last updated 1 year ago

Was this helpful?

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 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 write-privileges. A 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 for trusted interactions between a DID subject and a . A DID is verified by associating a and , and can be universally resolvable with DID methods such as 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

A 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: .

🏗️
🆔
Decentralized Identifiers
DID:ION
Uniform Resource Identifier (URI)
URI
DID:ION
DID document
DID document
DID document
DID document
https://www.w3.org/TR/did-spec-registries/#service-types
DID document
DID Operations Flow