The did:ru Method

Version 0.1 (draft)

Abstract

did:ru identifies AI agents and autonomous devices that act on behalf of an organization, and the organizations that answer for them. Identifiers are self-certifying (derived from a key), operations on DID Documents are signed by a controller or the owner organization, and every revision is hash-chained so that the history can be verified independently of the storage operator. The verifiable data registry is the Contracteum DID service backed by a Hyperledger Fabric channel.

1. Method Syntax

ru-did          = "did:ru:" entity-type ":" entity-id
entity-type     = "agent" / "device" / "org"
entity-id       = "z" 43*44base58char
base58char      = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
                / %x41-48 / %x4A-4E / %x50-5A / %x61-6B / %x6D-7A

entity-id is z (multibase base58btc) followed by the base58btc encoding of the SHA-256 digest of the RFC 7638 canonical JWK of the first capabilityInvocation key of the initial DID Document (the first authentication key if the document has no capabilityInvocation).

Example: did:ru:agent:zGh1PBrREyLUAehXXqpqNNodgFNv7UCRb4ZJV8bmB4cLX

The identifier carries no information about the subject (no serial numbers, registry numbers or names) and does not change when the registry storage changes.

DID parameters: versionId (resolves a historical version, DID Core §3.2.1).

2. DID Document

Supported properties: id, controller (string or set), owner, verificationMethod (JsonWebKey2020, JWK: Ed25519, X25519, P-256, P-384, P-521, RSA ≥ 2048; optional x5c), authentication, assertionMethod, keyAgreement, capabilityInvocation, capabilityDelegation, service.

owner is an extension property: the DID of the organization on whose behalf the subject acts. Agents and devices MUST have an owner; organizations MAY.

Key relationships for an AI agent:

3. Operations

Operations go through the DID service HTTP API (/api/v1/dids). Every operation carries a DID-Operation-Proof header: a compact JWS (typ: did-operation+jws, kid = DID URL of the signing key) over

{"op": "create|update|deactivate", "did": "<DID>", "prevVersionId": "<versionId being replaced>",
 "bodyDigest": "<base64url SHA-256 of the exact request body>", "iat": <unix seconds>}

Supported alg: EdDSA, ES256, ES384, ES512, RS256, PS256.

Authorization. The signer MUST be a controller of the document (the DID itself when no controller is set) or its owner, taken from the stored version (for Create — from the new document). The signing key MUST be listed in capabilityInvocation of the signer's DID Document (authentication if the signer has no capabilityInvocation). A deactivated DID cannot sign. Setting or changing owner additionally requires the signature of that owner. Ownership transfer: a current controller or owner adds the new organization to controller, then the new organization sets itself as owner.

3.1 Create

POST /api/v1/dids, body = DID Document. The registry checks the syntax, that entity-id is derived from the first capabilityInvocation key, that keys decode to valid public keys (private JWK members are rejected), that agents and devices name an owner, and the proof. An agent or device is created by its owner organization.

3.2 Read (Resolve)

GET /api/v1/dids/resolve?did=<DID>[&versionId=N], or gRPC ResolveDID with a DID URL. Returns the DID Document and didDocumentMetadata (created, updated, versionId, nextVersionId, deactivated). A deactivated DID resolves to 410 with its tombstone. DID URL dereferencing: #fragment (verification method or service).

3.3 Update

PUT /api/v1/dids/{did} (full replacement) or PATCH (JSON Merge Patch); prevVersionId MUST be the current versionId. The identifier is immutable.

3.4 Deactivate

PATCH /api/v1/dids/{did} with {"didDocumentMetadata":{"deactivated":true}}, op: deactivate. Irreversible; the history stays resolvable.

3.5 History

GET /api/v1/dids/{did}/history returns every revision with its proof, signed request body, digest and prevDigest. digest is the base64url SHA-256 over the revision content and the previous digest. GET /api/v1/dids/{did}/history/verify recomputes the chain, re-verifies every proof with the signer key valid at that time and re-derives each signed document from the stored signed body. headDigest is anchored on the Hyperledger Fabric channel.

4. Security Considerations

• Key custody. The registry never receives private keys; keys are generated in the subject's runtime (KMS, HSM, CSP). Private JWK members are rejected.

• Identifier squatting. Self-certifying identifiers cannot be registered without the key.

• Unauthorized changes. Authority is taken from the stored version; a change cannot grant itself controllers. Owner designation requires the owner's signature.

• Replay. Proofs are bound to DID, operation, prevVersionId and request body; iat is accepted within ±5 minutes.

• Registry tampering. Hash chain + signed bodies detect edits of stored revisions, including with recomputed digests; anchoring headDigest in Fabric detects truncation and rewrites of unsigned revisions.

• Key compromise. The owner removes the key (Update) or deactivates the DID; proofs made earlier remain verifiable against the historical version.

• Algorithms. GOST R 34.10-2012 signatures are verified through the Contracteum PKI service (pluggable verifier); qualified certificates are referenced with x5c.

• Transport. The API MUST be served over TLS.

5. Privacy Considerations

• DID Documents hold keys, relationships, controller, owner and service endpoints only. Personal data, registry numbers and serial numbers go into Verifiable Credentials, not DIDs.

• owner intentionally discloses which organization answers for an agent or device.

• Identifiers are derived from keys and carry no information about the subject.

• Resolution is not logged per requester beyond standard access logs.

6. Reference Implementation

did-svc (Go): pkg/didmethod (syntax), pkg/didkey (keys, RFC 7638), pkg/didproof (proofs), internal/did/service (operations, history verification), cmd/didsign (key and proof tool).

Журнал изменений