LogoLogo
  • Welcome to Blerify's docs
  • Blerify Overview
    • User Centric Identity
      • Introduction
      • ID Wallet
      • Digital Credentials
      • Point of Verification (POV)
        • How Does a POV Work in Blerify?
      • Verification Process
    • Quantum-Resistant Cryptography
  • Developers
    • API Documentation
      • Access Token Generation
      • Issuing Verifiable Credentials with the Blerify API
      • Issuing ISO mDL with the Blerify API
    • Point of Verification
      • POVs Creation
      • POV Result
      • POVs Creation via API
    • Versions & Releases
      • Web Portal
        • Web Portal Release 1.5
        • Web Portal Release 1.6
        • Web Portal Release 1.7
      • Blerify APP
        • APP Versión 3.19.0 (386)
        • APP Versión: 3.27.0
        • APP Versión: 3.36.1
  • PRODUCTS
    • Vouchers
      • Orchestration
      • Issuer
      • Redeemption
    • Digital Credentials
      • Issue
        • Licenses
          • ISO/IEC 18013-5 Standard
          • Blerify and ISO/IEC 18013-5
          • Blerify Architecture
        • Verifiable Credentials W3C-VC
        • Benefits, discounts, promotions
      • Verify
        • Web Log In
        • In-Person Access
        • Check Out Experience
        • From Another App
    • Post Quantum Certificates
      • Request
      • Revocation
      • Verify
    • Wallet SDK
  • Resources In-Depth
    • DID Method
      • DID Method did:lac1
      • DID Controller
    • Decentralized Root of Trust
      • Blerify’s Smart-Contract-Based Root of Trust
Powered by GitBook
LogoLogo

Blerify.com

  • Blerify.com
On this page
  • Terminology:
  • Capability:
  • Base Considerations:
  • Smart Contract Considerations:
Export as PDF
  1. Resources In-Depth
  2. DID Method

DID Controller

PreviousDID Method did:lac1NextDecentralized Root of Trust

Last updated 4 months ago

Blerify DID Controller is a set of contracts designed to administer whose is built on top of a blockchain network (e.g. , and DID methods). Setting a contract instance of the DID Controller as the controller of a specific DID will allow to manage the and associated to such DID.

Terminology:

  • Admin

  • Manager

  • Assignor

Capability:

Refers to a privilege inherently owned or granted. Such Capabilities are:

  • Assertion

  • Authentication

  • Key Agreement

  • Capability Invocation

  • Capability Delegation

  • Services

Base Considerations:

There are three main levels of control:

  • Admin level: Any actor with this privilege has full control over a particular identity instance living on a specified DID Registry, can do any action

Smart Contract Considerations:

  • Due to the roles feature that DID Controller has it allows multiple agents controlling a particular DID Registry at the same time.

  • Due to gas limitations, full verification of the payload to be relayed is not made. The contract just resolves the type of property to be added to the DID Document (verification method,service, controller management action) and determines whether the agent calling the contract is authorized to perform such action.

Capability Manager level: Any actor with this privilege can only assign pre defined roles for or custom ones to "assignors"

Assignor level: Actor assigned with this privilege can just call the DID Registry through the DID Controller contract and just add a or a to a user

DIDs
DID Registry
lac
lac1
ethr
services
verifications methods
capabilities
verification relationship
service