Skip to main content

COG-2: Decentralised ID

Status:      Draft 
Version:     1.0 
Created:     2025-09-23 
Authors:     Mike Anderson

This standard specifies the methods for identifying venues and other resources on the grid

Purpose​

The Grid enables secure and efficient collaboration between AI agents, data providers, and compute resources across organisational boundaries.

In order to operate effectively as a protocol, it is necessary to be able to identify venues and resources with stable global IDs.

Specification​

Venue DID​

A venue MUST provide a W3C compatible did, e.g. did:web:venue-3.covia.ai

The DID must utilise one of the following methods:

  • did:web for venues identified by a public URL with HTTPS
  • did:key for other venues
  • did:convex for venues registered on the Convex network

A venue MAY provide multiple equivalent DIDs which resolve to the same venue. If it does so, it MUST provide a canonicalID which specifies its primary DID, and return this as the id property for its DID document.

Asset DID​

Assets MUST have a DID constructed where:

  • The path is /a/{asset-id}
  • {asset-id} is the Asset ID (the Value ID of the asset metadata — see COG-5), in hexadecimal

Example:

did:web:venue-3.covia.ai/a/14a3a6b804629835f5466d03f789dd92a45381474d58c1224dfe344e6934c022

The hexadecimal asset ID MAY be prepended by 0x and/or contain a mix of uppercase and lowercase characters.

The canonical ID of an asset MUST exclude 0x and be in lowercase.

Venues SHOULD be capable of providing a DID document for any asset they host, subject to authorisation.

User DIDs​

A venue MAY assign venue-managed user DIDs to the named users it manages (e.g. after OAuth login — see COG-10). These are standard did:web DIDs formed from the venue's own did:web identity with a :u: path segment:

did:web:{venue-host}:u:{username}

Example: did:web:venue-3.covia.ai:u:alice

  • {username} MUST match [A-Za-z0-9._-]+.
  • No new DID method is introduced: the colon-separated segments are the did:web method's path encoding, so the DID resolves per the did:web specification to https://{venue-host}/u/{username}/did.json. The venue serves this DID document and is the controller of the DID — it signs assertions about the user with its own key pair.
  • A public hostname is required; a venue without one cannot mint resolvable user DIDs.

Note the distinction between principals and resources: principals (venues, users) have DIDs of their own, while assets are resources addressed by a DID URL path (/a/{asset-id}) under their hosting venue's DID.