did:artifact is a Decentralized Identifier (DID) method for naming
artifacts—fixed byte sequences such as files, documents, packages,
container images, and proof manifests—by their content. The method-specific
identifier is a CIDv1 whose multihash encodes the hash algorithm and digest of
the artifact's canonical bytes. Because the identifier is derived solely from the
content, a did:artifact DID is self-verifying: any party that
obtains candidate bytes can recompute the identifier and confirm, without trusting any
resolver, registry, host, or mirror, that the bytes are exactly those the identifier
names. The method defines no keys, controllers, or service endpoints; it provides
referential identity, and all trust assertions about an artifact are expressed by
external attestations that reference the DID.
This document is produced by OMA3 as part of its standardization process. It has not yet been ratified by OMA3 membership and is subject to change. Two design decisions are flagged inline as Editorial decisions and are the most likely points to revise before ratification: (1) resolution is generative and offline, and (2) version 1 permits exactly one hash algorithm.
This specification is also being prepared for submission to the [[DID-SPEC-REGISTRIES]].
Most DID methods name a subject whose state lives somewhere—a ledger, a domain, a key—and resolving the DID means reading that state. Because [[DID-CORE]] intentionally leaves resolver selection to implementations, methods whose underlying registry is not globally deterministic (for example, a web origin that may serve different bytes to different clients or over time) may produce different documents from different resolvers for the same DID.
did:artifact avoids this entire class of problem by naming content rather
than mutable state. The identifier is a cryptographic commitment to a specific
byte sequence. There is nothing to look up, so the authoritative content of resolution is
a pure function of the identifier and is identical for every resolver everywhere.
Obtaining the bytes (DID URL
dereferencing) may draw from any source—HTTP, IPFS, a mirror, removable
media—but correctness does not depend on the source being canonical, because the
identifier itself is the oracle: recompute it over the fetched bytes and require equality.
This makes the method well suited to integrity- and audit-oriented use cases, where the subject of an assertion must be exactly the bytes that were examined. A security audit, for instance, is only ever valid for the precise artifact audited; if a single byte changes, the identifier changes, and the prior assertion no longer applies—by construction.
did:artifact identifies a single immutable byte revision. It is intended
to complement, not replace, a durable subject identifier (for example a
did:web, a did:pkh, or an application/plugin DID) that
persists across versions and carries reputation and ownership. A typical attestation
binds the two: "the artifact did:artifact:… is release 2.3.1 of the
application did:web:example.com." Consumers SHOULD NOT treat a
did:artifact as a stable identity for an evolving subject.
This document uses DID document, DID resolution, and DID URL dereferencing as defined in [[DID-CORE]].
An artifact is a finite sequence of octets together with a declared artifact type that determines how those octets are derived. A CIDv1 is a self-describing content identifier as specified in [[CID]], composed of a version, a multicodec content-type code, and a multihash. The artifact type is an out-of-band label, supplied by the referencing context, indicating the procedure used to obtain the artifact's canonical octets (see ).
A conforming resolver is any software that implements the resolution algorithm in . A conforming verifier is any software that implements the verification algorithm in .
The method name that identifies this DID method is artifact.
A DID that uses this method MUST begin with the prefix did:artifact:. The
prefix MUST be in lowercase. The remainder of the DID, the method-specific identifier,
is defined below.
did-artifact = "did:artifact:" artifact-id
artifact-id = "b" 1*( base32-lower ) ; multibase-prefixed CIDv1
base32-lower = %x61-7A / %x32-37 ; "a"-"z" and "2"-"7"
The artifact-id is a [[CID]] in version 1 form, serialized as a
multibase string using the base32 lowercase alphabet,
whose leading character is the multibase prefix b.
To remove every degree of freedom that would otherwise allow the same octets to yield
more than one identifier, version 1 of this method fixes all CID parameters. An
artifact-id MUST be constructed as follows, and a verifier MUST
reject any did:artifact value that does not conform:
0x12 0x20
(function code sha2-256 = 0x12, digest length
0x20 = 32) followed by the 32-octet SHA-256 digest of the canonical
octets.
0x01 (CID version 1), followed by
the multicodec 0x55 (raw), followed by the multihash from
step 2. The total binary CID is 36 octets:
0x01 0x55 0x12 0x20 <32-octet digest>.
b. The resulting artifact-id is the prefix
b followed by 58 base32 characters.
did:artifact:.The following constraints are normative and admit no alternatives in this version:
b).raw (0x55).sha2-256 (0x12) with a
32-octet digest. A verifier MUST read the multihash function code and MUST reject any
value whose code is not sha2-256 (see ).
The multicodec is always raw, so the CID does not by itself reveal the
artifact's type. The artifact type is supplied out of band by the referencing
context and determines the procedure used to obtain the canonical octets that are hashed.
A verifier MUST apply the procedure for the declared type both when constructing
and when verifying an identifier.
For an artifact of type binary, the canonical octets are the artifact's
octets exactly as distributed. No transformation, repacking, normalization, or
canonicalization is applied. This is the default and most general case: any finite
octet sequence can be named this way.
For an artifact of type json, the canonical octets are produced by:
NaN, Infinity,
-Infinity, trailing commas, or any other non-standard extension.
Producers SHOULD avoid IEEE 754 floating-point numbers in artifacts whose identity must be stable across runtimes; where precise numeric values are required they SHOULD be represented as strings or as integers. Producers that embed timestamps or other formatted scalars SHOULD fix their exact lexical form, because JCS canonicalizes JSON structure and number serialization but does not normalize the internal text of string values.
When the artifact is a JSON document, its did:artifact value MUST NOT
appear as a member of the object being hashed. Including the identifier inside the
hashed octets creates a circular dependency, since the identifier would depend on a
field that depends on the identifier. The identifier MUST instead be recorded
externally to the document (for example in a distribution record, registry entry,
package lockfile, deployment configuration, or attestation).
This section is a work in progress and subject to significant revision before ratification. The general approach is described below, but detailed procedures and edge cases require further development.
For an artifact of type container, the canonical octets are the OCI image
manifest octets (application/vnd.oci.image.manifest.v1+json) as stored in
the registry [[OCI-IMAGE]]. Because the manifest is JSON, producers and verifiers MUST
apply the type json procedure above to those manifest octets. The manifest
already commits, by digest, to the image's layers and configuration, so naming the
manifest transitively names the image.
This section is a work in progress and subject to significant revision before ratification. The artifact types described below are provisional; detailed canonicalization procedures and tooling requirements are under active development.
A live website is not a fixed octet sequence and cannot be named directly; instead a proof artifact derived from it is named. This version defines two, each a distinct artifact yielding a distinct DID.
For type website-sri, the canonical octets are those of a Subresource
Integrity manifest [[SRI]] expressed as JSON and processed by the type
json procedure. Such a manifest commits only to the assets it lists;
dynamic or unlisted responses are out of scope and MUST be treated as unverified.
For type website-snapshot, the canonical octets are those of a
deterministic archive of the captured content (for example, with fixed entry ordering
and fixed owner, mode, and timestamp metadata), processed as type binary.
Producers SHOULD use deterministic packaging; non-deterministic archives of identical
content will yield differing identifiers.
Creation is purely generative and requires no registration, ledger write, or network
interaction. A controller creates a did:artifact DID by performing the
construction in over the artifact's canonical
octets. The DID exists for any octet sequence; there is no notion of an unregistered or
not-yet-created did:artifact.
To resolve a did:artifact DID, a resolver MUST:
invalidDid.
The DID document for a did:artifact DID is at minimum:
{
"@context": "https://www.w3.org/ns/did/v1",
"id": "did:artifact:bafkreihdwdcefgh4dqkjv67uzcmw7ojee6xedzdetojuzjevtenpcqyaua"
}
The authoritative content of the DID document is exactly the
@context and id properties; these are derived solely from
the identifier and constitute the verified document. A resolver MUST NOT add
verificationMethod, authentication, or any other
verification relationship. A resolver MAY add non-authoritative service
entries as defined below; such entries are advisory only, are not part of the
verified document, and MUST NOT be relied upon for any trust decision.
A resolver MAY include a service entry of type
ArtifactSource to indicate a location from which the artifact octets
can be retrieved. This does not affect the validity of the DID document—a
document without this field is equally valid—but it provides a convenience
for consumers that need to dereference the artifact.
{
"@context": "https://www.w3.org/ns/did/v1",
"id": "did:artifact:bafkreihdwdcefgh4dqkjv67uzcmw7ojee6xedzdetojuzjevtenpcqyaua",
"service": [{
"id": "did:artifact:bafkreihdwdcefgh4dqkjv67uzcmw7ojee6xedzdetojuzjevtenpcqyaua#source",
"type": "ArtifactSource",
"serviceEndpoint": "https://example.com/artifacts/my-app-v2.3.1.tar.gz"
}]
}
The serviceEndpoint URL is advisory only. The artifact obtained from
this URL MUST still be verified against the DID using the procedure in
. The URL confers no trust; it is a hint for discovery.
Different resolvers MAY return different URLs for the same DID (for example,
pointing to different mirrors), and all are acceptable provided the fetched bytes
pass verification.
A resolver SHOULD return, in the DID resolution metadata, the decoded parameters of
the identifier as a convenience to callers: the multihash function name
(sha2-256), the 32-octet digest as lowercase hexadecimal, the multicodec
name (raw), and the CID version. These values are derived entirely from
the DID and add no information not already present in it.
Update is not supported and MUST be treated as unsupported. A
did:artifact DID is immutable: its document is fixed by the identifier, and
any change to the artifact's octets produces a different DID rather than a new state of
the same DID.
Deactivation is not supported and MUST be treated as unsupported. There is no mutable state to deactivate. Whether a given artifact can still be retrieved is a property of hosting and dereferencing, not of the DID.
Dereferencing obtains the artifact octets named by a did:artifact DID.
Unlike resolution, dereferencing requires a source of bytes, which may be any location:
HTTP(S), an ipfs:// address, a content-delivery mirror, local storage, or
removable media. The referencing context typically supplies one or more candidate
locations; these locations are advisory for discovery and distribution only and confer
no trust.
To verify candidate octets against a did:artifact DID, a verifier MUST:
binary this is the identity
transformation; for type json (and the JSON-based types) the verifier
MUST re-apply JCS canonicalization, because bytes in transit may have been
re-serialized.
artifact-id over the canonical octets per
.
artifact-id. If the values
differ, the candidate octets are invalid for this DID and MUST be rejected,
regardless of the location they were fetched from or any signature that accompanied
them.
A verifier MAY cache the outcome of a successful verification keyed by the DID, but any newly obtained octets MUST be re-verified before use.
[[DID-CORE]] does not designate a canonical resolver for any DID, and resolver multiplexers route to per-method drivers without acting as an authority. For methods whose verifiable data registry is not globally deterministic, two correct resolvers can legitimately return different documents for the same DID, with no defined arbiter.
This method is not subject to that ambiguity, because its correctness does not depend
on resolvers agreeing. The authoritative content of the DID document—its
@context and id—is a pure function of the identifier
and is therefore identical from every conforming resolver. Resolvers MAY additionally
return non-authoritative advisory fields, such as ArtifactSource service
hints, and these MAY differ between resolvers; because such fields carry no trust and
are never relied upon, their variation cannot affect any outcome. Correctness derives
solely from dereferencing candidate bytes and verifying them against the identifier
(see ): any source returning matching octets is acceptable,
any other is rejected, and no resolver, registry, host, or mirror need be trusted. The
contrast with lookup-based methods is therefore not that this method's documents are
byte-identical, but that nothing authoritative can differ—the authority
is the hash, not the resolver.
Under this version, the multihash function MUST be sha2-256, and verifiers
MUST reject identifiers using any other function code even though the multihash format
is self-describing. The function code is retained in the encoding so that a future
version of this specification MAY expand the accepted set without changing the
identifier format.
The security requirement for did:artifact is that it be computationally
infeasible to find either (a) different canonical bytes for a known artifact identifier
(second-preimage resistance), or (b) two distinct canonical artifacts that produce the
same identifier (collision resistance). Version 1 uses SHA-256, which provides
approximately 128-bit collision resistance and 256-bit preimage/second-preimage
resistance under current cryptanalytic understanding. This is sufficient for artifact
identity, while preserving compatibility with existing CID and multihash tooling.
Because a digest under a different algorithm is a different identifier for the same octets, algorithm migration is additive: introducing a new algorithm mints new DIDs alongside existing ones rather than altering any existing DID. Grouping the multiple identifiers that name the same logical artifact across algorithms or representations is out of scope for this method and is expected to be handled by the referencing application layer.
json versus
type binary yields different identifiers. The referencing context MUST
declare the intended type unambiguously, and verifiers MUST apply the declared type, to
prevent an attacker from substituting one interpretation for another.
did:artifact asserts nothing about an
artifact's safety, provenance, or fitness. Such properties are conveyed solely by
external attestations referencing the DID, and consumers MUST evaluate those
attestations under their own trust policy.
did:artifact reveals nothing to any third party,
unlike methods whose resolution contacts a domain or ledger. Network exposure occurs
only at dereferencing time and only toward the chosen byte source.
did:artifact is a hash
of content. Anyone holding a candidate artifact can confirm whether it matches a given
DID, and a DID over low-entropy or publicly known content can be reproduced by anyone.
The identifier therefore should not be treated as concealing the existence or
possession of the named content.
did:artifact cannot be updated or
deactivated. Erasure obligations, where they apply, must be met at the hosting and
attestation layers, since the identifier itself is a permanent commitment to the
content.
The following is a draft entry for submission to the [[DID-SPEC-REGISTRIES]].
| Method Name | artifact |
|---|---|
| Status | Provisional |
| Specification | This document |
| Contact | OMA3 (info@oma3.org) |
| Verifiable Data Registry | None (generative; identifier derived from content) |
| Supports Update | No |
| Supports Deactivate | No |
Before submission, this appendix MUST be populated with worked vectors covering, at
minimum: an opaque binary; a JSON document exercising member-name ordering, number
minimization, and UTF-8 escaping under JCS; an OCI manifest; and an SRI manifest. Each
vector should give the input, the canonical octets (hex), the SHA-256 digest (hex), the
binary CID (hex), and the final did:artifact string, verified to agree across
at least two independent runtimes.
did:artifact
The following OMA3 standards and specifications reference did:artifact as
an identifier for immutable artifacts:
did:artifact to identify specific versions of
applications, APIs, websites, and smart contracts that are the subject of trust
attestations. When an auditor or user submits a reputation attestation, the attestation
references the exact artifact that was reviewed via its did:artifact
identifier, ensuring that trust signals are bound to a precise, verifiable byte
sequence.
did:artifact to identify immutable asset definitions and
payment protocol artifacts that must be verifiable across interoperable metaverse
environments.