Skip to main content
Domain: Datasets
Depends on: Metadata Chain
RFCs: RFC-003, RFC-007, RFC-012

​
Abstract

This spec defines how are identified. It defines the did:odf DID method used to create globally unique dataset identifiers that are tied to a cryptographic key pair and require no central authority, and the human-friendly aliases and references used to refer to datasets within and across .

​
Overview

The identity of a dataset consists of:

​
Unique Identifiers

ODF is designed to be compatible with content-addressable storage. When stored in such storage, all parts of a can be accessed by having only a hash of the last . As grows, however, a reference to a single will only provide access to a subset of its history. To refer to a as a whole a different identifier is needed that can be resolved into a hash of the latest block. Such identifiers must be globally unique, issuable with no central authority, and tied to a proof of ownership over a dataset. ODF follows the W3C DID Identity Scheme using a custom did:odf method. This method is based closely on did:key method that derives the unique identity from a public key of a cryptographic key pair. Example: 
did:odf:fed012126262ba49e1ba8392c26f7a39e1ba8d756c7469786d3365200c68402ff65dc
The identifier is formed by:
  • Generating a cryptographic key pair (e.g. using ed25519 algorithm)
  • Taking the public key part
  • Prepending an appropriate multicodec value to identify the algorithm (e.g. ed25519-pub)
  • Encoding data with multibase encoding using base16 scheme
Or in pseudocode: 
did-odf-format := ‘did:odf:’ + MULTIBASE(
base16,
MULTICODEC(
public_key_type,
public_key_bytes,
)
)
The resulting DID is stored in the first in the chain of every , called (see Metadata Chain). Tying the identity of a dataset to a cryptographic key pair provides a way to create unique identity in a fully decentralized way. The corresponding private key can be used to prove ownership and control over a and to delegate access.
Note that the only difference between did:odf and did:key method is the encoding scheme. ODF uses base16 instead of base58btc for reasons explained in the Hash Representation section. Because conversion between the two encodings is trivial, ODF is compatible with authorization frameworks that work with did:key method. We expect that in future the did:key spec will be extended to allow base16 encoding too, further minimizing the difference.

​
Aliases and References

Formats described below provide human-friendly ways to refer to a certain dataset. Note that they are only meaningful within the boundaries of a . Unlike Dataset IDs they are not collision-free and mutable. Depending on the context we differentiate the following types of references:
  • Local Format - used to refer to a dataset within a local workspace (can be single- and multi-tenant)
  • Remote Format - used to refer to a dataset located in a known provider.
As you will see in the examples below, we recommend (but not require) using the reverse domain name notation for names. Examples: 
// Dataset ID
did:odf:fed012126262ba49e1ba8392c26f7a39e1ba8d756c7469786d3365200c68402ff65dc// Local Format - DatasetName is highlighted
property.parcel-polygons
cities
admin0.countries.10m// Local Multi-tenant Format - AccountName is highlighted
statcan.gc.ca/census.2016.population
ny-newyork/public-safety.ems-incident-dispatch// Remote Format - RepoName is highlighted
statcan.gc.ca/census.2016.population
us.cityofnewyork/public-safety.ems-incident-dispatch
data.gov/ny-newyork/public-safety.ems-incident-dispatch// Remote Url Format
https://opendata.ca/odf/census-2016-population/
ipfs://bafkreie3hfshd4ikinnbio3kewo2hvj6doh5jp3p23iwk2evgo2un5g7km/
Note that name components such as DatasetName, AccountName, RepoName are case-insensitive, i.e. names ny-newyork and NY-NewYork are considered identical during lookups and uniqueness checks within the repository.

​
Grammar

Full PEG grammar:
Remote references in the URL format point directly to the location of a dataset (e.g. a directory served over HTTP or stored in IPFS), where the scheme selects the transfer protocol (see Transfer Protocols).

​
References in Metadata

Datasets can refer to other datasets in their , e.g. a specifies its inputs in the SetTransform event (). Such references:
  • Can be specified using any form of local or remote reference when the dataset is defined
  • Must be resolved into a dataset ID by the time the block is accepted into the chain, to guarantee reproducibility, as aliases can change over time
  • Carry a separate alias under which the input is available in queries, decoupling queries from the names of input datasets

​
Identity of Dataset Resources

The Dataset that describes the desired state of a dataset on a has its own identity that is separate from the identity of the dataset itself (see Resource Framework: Resources and Entities):
  • The resource id identifies the resource within one node, while the did identifies the dataset on the global network. When a dataset is replicated between nodes, every node has its own Dataset resource with a different id but the same did.
  • In resource manifests, datasets are referred to using resource references (e.g. Dataset:acme/sensor-temp), which can also identify the dataset by its did.
Last modified on October 15, 2026