did:operon - DID Method Specification

1. Introduction

The did:operon method defines a decentralized identifier (DID) namespace fully operated by Operon.Cloud. It prioritizes simplicity: a single free-form identifier segment, an Operon-managed resolver, and optional future anchoring to distributed ledgers such as Hedera.

• One method-specific identifier segment that can be human-friendly or system generated.
• Resolver and registry are maintained solely by Operon Cloud.
• No dependency on external ledgers (future anchoring optional).
• DIDs remain opaque, flat, and globally unique.

This specification covers DID syntax, DID Document structure, lifecycle operations, and supporting governance, privacy, and security considerations.

2. Terminology and Roles

This document follows the definitions in the W3C DID Core specification and introduces the roles below:

• Method Operator – Operon Cloud, which operates the resolver and registry.
• DID Controller – The entity authorized to modify a DID Document.
• Registry Service – Authoritative backend storing DID Documents.
• Resolver Service – Public service resolving DIDs into DID Documents.

Business constructs (customer, workspace, workstream, etc.) remain outside of the DID string and base specification.

3. DID Method Name

did:operon
did:operon:<method-specific-id>

5. DID Document Format

Operon adopts the DID Core JSON representation.

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "did:operon:root",
  "verificationMethod": [
    {
      "id": "did:operon:root#key-01kaq22re3b68b4qbt8h2qf6bf",
      "type": "JsonWebKey2020",
      "controller": "did:operon:root",
      "publicKeyJwk": {
        /* EdDSA (Ed25519) JWK goes here */
      }
    },
    {
      "id": "did:operon:root#key-01kaq22re39m1maknzmnkmw3tg",
      "type": "JsonWebKey2020",
      "controller": "did:operon:root",
      "publicKeyJwk": {
        /* ES256 (P-256) JWK goes here */
      }
    },
    {
      "id": "did:operon:root#key-01kaq22rewvfr45zscvxtnqm8b",
      "type": "JsonWebKey2020",
      "controller": "did:operon:root",
      "publicKeyJwk": {
        /* ES256K (secp256k1) JWK goes here */
      }
    }
  ],
  "authentication": [
    "did:operon:root#key-01kaq22re3b68b4qbt8h2qf6bf",
    "did:operon:root#key-01kaq22re39m1maknzmnkmw3tg"
  ],
  "assertionMethod": [
    "did:operon:root#key-01kaq22re39m1maknzmnkmw3tg"
  ]
}

6. DID Operations

All lifecycle operations are executed through the Operon Registry Service.

GET https://did.operon.cloud/1.0/identifiers/{did}

7. Method-Specific Considerations

• Domain Authority: Proved through https://operon.cloud/.well-known/did-configuration.json.
• Environments: Non-production domains (for example, dev.operon.cloud) may be used without altering syntax.
• Metadata: Registry stores timestamps and deactivation status for auditing.

8. Security Considerations

• Controllers must generate and store private keys securely.
• All registry operations require authentication.
• Transport must enforce HTTPS.
• Future versions may optionally anchor registry events to Hedera.

9. Privacy Considerations

• DIDs must not contain PII.
• DID Documents should only include minimum required information.
• Real-world mappings remain application-level concerns.

10. Governance

Operon Cloud manages resolver uptime, registry integrity, domain linkage proofs, and ongoing specification evolution.

11. Examples

did:operon:pa-service

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:operon:pa-service",
  "verificationMethod": [],
  "authentication": [],
  "service": []
}

12. Versioning

Semantic Versioning:

• MAJOR – Breaking changes.
• MINOR – New features.
• PATCH – Fixes and clarifications.

Version 0.2.0 introduces free-form identifiers and supporting clarifications.

13. References

• W3C DID Core
• DID Resolution v1.0
• JSON Web Key (RFC 7517)