§ The `did:webvh` AnonCreds Method
v0.1 / Editor’s Draft

did:webvh Logo

Specification Status: EDITORS DRAFT

At this time, the Editor’s Draft contains the initial version of the specification.

Current Specification: Editor’s Draft

Specification Version: v0.1 (see Changelog)

Source of Latest Draft: https://github.com/decentralized-identity/didwebvh/spec-anoncreds-method

Previous Versions:

None

Information Site: https://didwebvh.info/

Editors:: Stephen Curran; John Jordan, BC Gov; Andrew Whitehead; Brian Richter; Michel Sahli; Martina Kolpondinos; Dmitri Zagdulin
Participate:: GitHub repo; File a bug; Commit history
Implementations:: didwebvh Server in Python; ACA-Py

§ Abstract

This did:webvh AnonCreds Method specification defines how [ANONCREDS] objects should be registered (written) and resolved when rooting them in a did:webvh DID. This specification parallels other DID-specific AnonCreds methods that are registered in the AnonCreds Methods Registry.

The specification introduces the concept of an Attested Resource that enables verifiable identifiers that resolve to resources (files) managed by a did:webvh Controller. We anticipate later extracting the Attested Resources concept into a separate specification on its own. Each of the published AnonCreds objects (schema, CredDef, RevRegDef, and RevRegEntry are treated as Attested Resources in this AnonCreds method.

For information beyond this did:webvh AnonCreds Method specification, the (did:webvh) DID method, and how (and where) it is used in practice, please visit https://didwebvh.info/.

§ Definitions

Schema: A JSON object that defines the schema for an AnonCreds verifiable credential. A schema for a given verifiable credential type rooted to a did:webvh DID can be resolved as an Attested Resource associated with that DID. The AnonCreds schema is defined in the Schema publishing section of the [ANONCREDS] specification.
CredDef: A JSON object that contains the public keys that enables verification of an an AnonCreds verifiable presentation derived from a verifiable credential from a specific Issuer. A CredDef for a given verifiable credential type rooted to a did:webvh DID can be resolved as an Attested Resource associated with that DID. An AnonCreds CredDef object is defined in the CredDef generation section of the [ANONCREDS] specification.
RevRegDef: A JSON object that contains the metadata and public key published by the Issuer that enables verification of an AnonCreds non-revocation proof that a holder includes in a presentation of a revocable credential. A RevRegDef for a given AnonCreds CredDef rooted to a did:webvh DID can be resolved as an Attested Resource associated with that DID. An AnonCreds RevRegDef object is defined in the RevRegDef creation section of the [ANONCREDS] specification.
RevRegEntry: A JSON object that contains the accumulator and current state (revoked or not) of all credentials within an AnonCreds revocation registry. The RevRegEntry data is used by the Holder to create a non-revocation proof. A verifier must get the accumulator from the same RevRegEntry used by the holder to verify the non-revocation proof. A RevRegEntry for a given AnonCreds RevRegDef rooted to a did:webvh DID can be resolved as an Attested Resource associated with that DID. An AnonCreds RevRegEntry object is defined in the RevRegEntry creation section of the [ANONCREDS] specification.
Attested Resource: A JSON object, published as a resource associated with a did:webvh DID. The resolvable identifier for the resource includes the hash of the resource, and there is a Data Integrity proof signed by the DID Controller attached to the JSON object that includes the resource. The hash and proof are used to verify that the resolved resource has not been altered, and was published by the DID Controller.
Data Integrity: W3C Data Integrity is a specification of mechanisms for ensuring the authenticity and integrity of structured digital documents using cryptography, such as digital signatures and other digital mathematical proofs.
DID Controller: The entity that controls (create, updates, deletes) a given DID, as defined in the [DID-CORE].

§ `did:webvh` AnonCreds Method Specification

§ Overview

The did:webvh AnonCreds Method defines how AnonCreds objects (Schemas, CredDefs, RevRegDefs, and RevRegEntries) are registered (published, written) by a DID Controller using a did:webvh DID, and how others can resolve and verify those objects. The method makes use of Attested Resources, resources (objects, files) that are generated with a deterministic, verifiable identifier, that contains a hash of the resource, published at a resolvable web location – typically (but not necessarily) to the same web server as the DID Controller's did:webvh DID Log, and attested to by the DID Controller. The next section of the specification focuses on the publication and resolution of the AnonCreds objects.

The specification of an Attested Resource is found later in this specification and may later be extracted into a standalone specification. For those new to Attested Resources, here is a brief summary of their important attributes:

Attested Resources are JSON structures that embed a complete resource (e.g., an AnonCred object, an encoded image, or any other resource published by the DID Controller), plus metadata about the resource.
- Note that a DID Controller using did:webvh does not have to publish resources as Attested Resources. It is just a usefully verifiable data model.
The identifier for an Attested Resource is resolvable and verifiable, in that it contains a deterministic hash of the resource, allowing a resolver to verify that the content of the identified resource has not been altered. A resolver typically gets the identifier from another party and resolves it some later date, so there is value in verifying that the resolved resource is bound to the identifier. For example, a Verifier gets the identifier for an AnonCreds CredDef from the Holder who has embedded it in the generated AnonCreds verifiable presentation, possibly years after the Issuer created the CredDef and issued the credential.
The Attested Resource includes a Data Integrity proof of the Attested Resource JSON (the resource, and metadata), signed by the DID Controller.
A did:webvh Attested Resource is typically found at a relative path on the same web server as the DID Log. However, the DID’s DIDDoc MAY use a DID service ([DID-CORE]) to indicate resources are based on a different URI.

§ AnonCreds Objects as Attested Resources

Each didwebvh rooted AnonCreds object is the resource in an Attested Resource published to the did:webvh. The identifier for each resource consists of three parts – <did>/path/to/resource/<hash>, as follows:

<did>: The did:webvh DID.
/path/to/file: The location relative a base URI of a DIDDoc service where the Attested Resource is located. Unless explicitly overridden in the did:webvh DIDDoc, the base URI is defined by the did:webvh DID-to-HTTP Transformation.
<hash>: The deterministic hash of the Attested Resource (based on this generation algorithm).

Each did:webvh AnonCreds object is created by an AnonCreds verifiable credential Issuer, used to generate an Attested Resource, and published. Generating the Attested Resource produces the object’s identifier, and that identifier is in turn embedded into other objects (such as issued verifiable credentials) available to parties (Holders, Verifiers) that need to resolve the object.

The following sections define how each AnonCreds object type is published as an Attested Resource.

§ AnonCreds Schema

An AnonCreds Schema is the resource embedded in an Attested Resource. The resulting schema identifier is placed into an Issuer’s AnonCreds CredDef based on the Schema. Holders and Verifiers resolve the schema identifier retrieved from a resolved AnonCreds CredDef. The resourceType MUST be anonCredsSchema. The resourceName SHOULD be the name of the Schema.

The following is an example AnonCreds Schema Attested Resource, with the identifier: did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a/resources/zQmSPbRK7h8SCQKMXyNvtHZuSQnqL6yCCQ8UMe2Rfa4ucP9

{
  "@context": [
    "https://w3id.org/security/data-integrity/v2"
  ],
  "type": [
    "AttestedResource"
  ],
  "id": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a/resources/zQmSPbRK7h8SCQKMXyNvtHZuSQnqL6yCCQ8UMe2Rfa4ucP9",
  "content": {
    "issuerId": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a",
    "attrNames": [
      "attributeClaim",
      "predicateClaim"
    ],
    "name": "Demo Credential",
    "version": "1.0"
  },
  "metadata": {
    "resourceId": "zQmSPbRK7h8SCQKMXyNvtHZuSQnqL6yCCQ8UMe2Rfa4ucP9",
    "resourceType": "anonCredsSchema",
    "resourceName": "Demo Credential"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5ZTaBaz8pQz2Ne5S2aNAJW2K41eZmbXNqiyhNK3ejXiobAjVpYbKN3NLPVj9bXeYJdkA8Tfw7hbE5kTr52QxGzjK",
    "verificationMethod": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a#key-01"
  }
}

§ AnonCreds CredDef

An AnonCreds CredDef is the resource embedded in an Attested Resource. The resulting CredDef identifier is placed in the verifiable credentials issued by that Issuer. Holders retrieve the CredDef identifier embedded in an AnonCreds verifiable credential and place the CredDef identifier into verifiable presentations sent to Verifiers. Verifiers resolve the CredDef identifier in the presentation to resolve the CredDef. The resourceType MUST be anonCredsCredDef. The resourceName SHOULD be the tag of the CredDef.

The following is an example AnonCreds CredDef Attested Resource (with long values truncated with ellipses), with the identifier: did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a/resources/zQma3iMYNvMzNNxPsj9cW1cHhN3R1cb3QNMmqhrvhtEhoQe

{
  "@context": [
    "https://w3id.org/security/data-integrity/v2"
  ],
  "type": [
    "AttestedResource"
  ],
  "id": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a/resources/zQma3iMYNvMzNNxPsj9cW1cHhN3R1cb3QNMmqhrvhtEhoQe",
  "content": {
    "issuerId": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a",
    "schemaId": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a/resources/zQmSPbRK7h8SCQKMXyNvtHZuSQnqL6yCCQ8UMe2Rfa4ucP9",
    "type": "CL",
    "tag": "Demo Credential",
    "value": {
      "primary": {
        "n": "10477...",
        "s": "95653...",
        "r": {
          "predicateclaim": "66593...",
          "attributeclaim": "16362...",
          "master_secret": "99918..."
        },
        "rctxt": "7455...",
        "z": "21627..."
      },
      "revocation": {
        "g": "1 210BA9...",
        "g_dash": "1 20817...",
        "h": "1 0230F...",
        "h0": "1 01772...",
        "h1": "1 203E6...8",
        "h2": "1 0956C...",
        "htilde": "1 1A344...",
        "h_cap": "1 19C5C...",
        "u": "1 1549...",
        "pk": "1 1921FF...",
        "y": "1 13DFD..."
      }
    }
  },
  "metadata": {
    "resourceId": "zQma3iMYNvMzNNxPsj9cW1cHhN3R1cb3QNMmqhrvhtEhoQe",
    "resourceType": "anonCredsCredDef",
    "resourceName": "Demo Credential"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3wmGc1ciG79i2w1WWKEczdPx5oSJb8txvL1sW8nR9zsmLPDtZt2YD5F7HwycYVRBGRMUjsDNENzZcLRypCxUfSnR",
    "verificationMethod": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a#key-01"
  }
}

§ AnonCreds RevRegDef

An AnonCreds RevRegDef is the resource embedded in an Attested Resource. The resulting RevRegDef identifier is placed in the revocable verifiable credentials issued by its Issuer. Holders retrieve the RevRegDef identifier embedded in an AnonCreds verifiable credential issued to them. Holders place the RevRegDef identifier into verifiable presentations sent to Verifiers, who resolve the RevRegDef identifier to retrieve the RevRegDef. The resourceType MUST be anonCredsRevocRegDef. The resourceName SHOULD be the tag of the RevRegDef.

Unlike the other objects, the RevRegDef Attested Resource also contains required metadata in the Attested Resource links field that is outside of the RevRegDef itself. Notably, links contains the list of all RevRegEntry timestamps and identifiers associated with the RevRegDef (see the example below). Each time, a new RevRegEntry is published by the Issuer, a new RevRegDef must be created that adds the new RevRegEntry to the links list. Since the links item is not part of the resource (the RevRegDef) of the AttestedResource, the RevRegDef identifier (and more specifically, the hash within the identifier) does not change. The Data Integrity proof is updated, since the payload for the proof’s signature includes the RevRegEntry the resource and the metadata (including the links item).

The following is an example AnonCreds RevRegDef Attested Resource (with long values truncated with ellipses), with the identifier: did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a/resources/zQmZBQmoX6dp6fwMVvR52VrQGz5yAyfMVAinoDAuVWrXMf4. The RevRegDef has four RevRegEntries.

{
  "@context": [
    "https://w3id.org/security/data-integrity/v2"
  ],
  "type": [
    "AttestedResource"
  ],
  "id": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a/resources/zQmZBQmoX6dp6fwMVvR52VrQGz5yAyfMVAinoDAuVWrXMf4",
  "content": {
    "issuerId": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a",
    "revocDefType": "CL_ACCUM",
    "credDefId": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a/resources/zQma3iMYNvMzNNxPsj9cW1cHhN3R1cb3QNMmqhrvhtEhoQe",
    "tag": "0",
    "value": {
      "publicKeys": {
        "accumKey": {
          "z": "1 0EBD9..."
        }
      },
      "maxCredNum": 100,
      "tailsLocation": "https://tails.anoncreds.vc/hash/BKVA1GTg3FQC9yxQjzWWtXC3b5GXSVEem5a1rT2nSiC8",
      "tailsHash": "BKVA1GTg3FQC9yxQjzWWtXC3b5GXSVEem5a1rT2nSiC8"
    }
  },
  "metadata": {
    "resourceId": "zQmZBQmoX6dp6fwMVvR52VrQGz5yAyfMVAinoDAuVWrXMf4",
    "resourceType": "anonCredsRevocRegDef",
    "resourceName": "0"
  },
  "links": [
    {
      "id": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a/resources/zQmVsQB44FzYVcr6FnWnVTo2WtjrLyDTMTkJdExb7SFWQPm",
      "type": "anonCredsStatusList",
      "timestamp": 1739148281
    },
    {
      "id": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a/resources/zQmRhDPirwc4EPJmWkw61o5DFQKydmN11WNKCH18kBjC6ES",
      "type": "anonCredsStatusList",
      "timestamp": 1739150045
    },
    {
      "id": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a/resources/zQmZ1bZWBu9AHoydWPPkwvgvkAEUvunUvDHD14gY39TqWod",
      "type": "anonCredsStatusList",
      "timestamp": 1739150385
    },
    {
      "id": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a/resources/zQme7JEpPw2PjoReBhyWjLDbivAXUvFJ8NJCpTXBBzX1GJg",
      "type": "anonCredsStatusList",
      "timestamp": 1739212933
    }
  ],
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5eGXSAoDVN9NpX5R5dL6uvZ7wRCbvou4zFRUJo7xzUkP1mRVLC53mM86k34NuPDAAWzvH927K5RZN6VheBLz3z2F",
    "verificationMethod": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a#key-01"
  }
}

§ AnonCreds RevRegEntry

An AnonCreds RevRegEntry is the resource embedded in an Attested Resource – an object that contains the full state of the revocation registry, the timestamp of the state, the associated accumulator, and the status of each verifiable credential in the RevRegEntry. While a RevRegEntry Attested Resource is saved like other AnonCreds resources, the discovery of its identifier and the resolution of that identifier is more involved, as described below. The resourceType MUST be anonCredsStatusList. The resourceName SHOULD be the tag of the parent RevRegDef.

An Issuer adds the RevRegEntry timestamp and identifier to the list of RevRegEntry timestamp/identifier pairs listed in the RevRegDef. A new version of the Attested Resource for the object is generated and the old version is overwritten with the new. As noted earlier, since the RevRegDef resource does not change, the identifier (and specifically, the hash embedded in the identifier) also does not change.

Holders, when generating a presentation using the revocable verifiable credential, retrieve the RevRegDef identifier embedded in an AnonCreds verifiable credential issued to them. The Holder then finds the RevRegEntry identifier associated with the appropriate timestamp (based on the requirements in the presentation request they received), and resolves the corresponding RevRegEntry identifier. The Holder embeds the RevRegDef identifier and the timestamp of the RevRegEntry used in generating the verifiable presentation into the verifiable presentation and sends it to the Verifier.

The Verifier extracts the RevRegDef identifier and timestamp from the verifiable presentation, resolves the identifier, finds within the RevRegDef Attested Resource the RevRegEntry identifier associated with the timestamp. The Verifier then resolves the RevRegEntry identifier, extracts the information necessary to verify the revocation part of the verifiable presentation.

The following is an example AnonCreds RevRegDef Attested Resource, with the identifier: did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a/resources/zQme7JEpPw2PjoReBhyWjLDbivAXUvFJ8NJCpTXBBzX1GJg

{
  "@context": [
    "https://w3id.org/security/data-integrity/v2"
  ],
  "type": [
    "AttestedResource"
  ],
  "id": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a/resources/zQme7JEpPw2PjoReBhyWjLDbivAXUvFJ8NJCpTXBBzX1GJg",
  "content": {
    "issuerId": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a",
    "revRegDefId": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a/resources/zQmZBQmoX6dp6fwMVvR52VrQGz5yAyfMVAinoDAuVWrXMf4",
    "revocationList": [0,1,1,1,...],
    "currentAccumulator": "21 12566...",
    "timestamp": 1739212933
  },
  "metadata": {
    "resourceId": "zQme7JEpPw2PjoReBhyWjLDbivAXUvFJ8NJCpTXBBzX1GJg",
    "resourceType": "anonCredsStatusList",
    "resourceName": "0"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5QkTd5MFQ952vmn6514ivt51vzY92kEa92kitX4ZZ9DYwVG9ZtsSx1FyC54KFYPJCgTUoRgy919A8rPsXVFhdffv",
    "verificationMethod": "did:webvh:QmdhkLDvMUxSmf8LweLPergW5refqjL1S1YKpBihwvmXs6:id.anoncreds.vc:demo:8d2bebfe-6492-4915-b53c-4c3bf2c9711a#key-01"
  }
}

§ Attested Resources

Attested Resources are JSON objects stored on a web server associated with a did:webvh with a deterministic identifier generated based on the hash of an embedded resource. The structure of the JSON object is defined (below), formalizing where an arbitrary resource is placed (<resource>). A Data Integrity proof (an attestation, hence the Attested Resource name) is attached to the JSON object. The ID for the resource is derived from hashing the <resource>.

The key properties in the Attested Resource Data Model are:

id
- A DID URI value resolving to the attested resource. The right most path components of the URI MUST be the digestMultibase value of the content object.
content
- An arbitrary json object containing the subject of the attested resource, the <resource>.
metadata
- An object borrowing attributes from the DID linked resource metadata. These should be used for dereferencing.
links
- An array of relate links objects. These object MUST contain an id, and a type and may contain other data specific to the type of the Attested Resource.

§ The Attested Resource Data Model

{
    "@context": [
        "https://example.com/attested-resource/v1",
        "https://w3id.org/security/data-integrity/v2"
    ],
    "type": ["AttestedResource"],
    "id": "did:webvh:{SCID}:example.com/<path>/<to>/<resource>/{digestMultibase}",
    "content": {<resource>},
    "metadata": {
        "resourceId": "{digestMultibase}",
        "resourceType": "",
        "resourceName": ""
    },
    "links": [
        {
            "type": "RelatedLink",
            "id": "https://example.com",
            "digestMultibase": "{digestMultibase}"
        }
    ],
    "proof": {
        "type": "DataIntegrityProof",
        "cryptosuite": "eddsa-jcs-2022",
        "verificationMethod": "did:webvh:{SCID}:example.com#key-01"
    }
}

§ Calculating the Attested Resource `digestMultibase`

Both the Attested Resource creator/publisher and resolver/verifier MUST calculate the digestMultibase using: multibase(multihash(jcs(<resource>), 'sha-256'), 'b58btc'). The calculation MUST apply these specifications:

jcs: JSON Canonicalization Scheme, Specification: [RFC8785]
sha-256: SHA-256 hashing, Specification: [RFC6234]
b58btc: Base58 (Bitcoin) Encoding Specification: [DRAFT-MSPORNY-BASE58-03]
multihash: MultiHash Specification: [[spec:multihash]]
multibase: Multibase Specification: [MULTIFORMATS]

§ Data Integrity Proof Generation

The Data Integrity proof ([VC-DATA-INTEGRITY]) attached to Attested Resources MUST use the eddsa-jcs-2022 cryptosuite schema as referenced in [DI-EDDSA-V1.0].

§ Creation and Publishing

The following process MUST be followed to create an Attested Resource. The input to this process is the resource – a JSON item.

Take the <resource> and calculate the digestMultibase value using the `digestMultibase algorithm.
Set the metadata.ResourceId to be the value of the calculated digestMultibase.
Define the DID URL of the Attested Resource, which defines the resolvable location of the published resource. The DID MUST be the did:webvh of the Issuer and the last component of the DID URL MUST be the calculated digestMultibase value. Examples:
- did:webvh:{SCID}:example.com/ + {digestMultibase}
- did:webvh:{SCID}:example.com/path/to/resource/ + {digestMultibase}
- did:webvh:{SCID}:example.com:namespace:identifier/resources/ + {digestMultibase}
Attach a Data Integrity proof of the full object using a valid verificationMethod from the Issuer’s DID as specified here.
Upload the resulting Attested Resource to a web server that MUST publish the resource at the location defined by its identifier.

§ Resolving Attested Resources

The following process MUST be followed to resolve an Attested Resource. The input to this process is the did:webvh DID URL for the Attested Resource.

Resolve the DID and validate the did:webvh DID Log.
Do a DID URL to HTTP URL transformation on the Attested Resource identifier using the the resolved DIDDoc. An example implicit did:webvh transformation:
- did:webvh:{SCID}:example.com/{digestMultibase} to
- https://example.com/{digestMultibase}
Resolve the HTTP URL and retrieve the Attested Resource.
The digestMultibase portion of the Attested Resource identifier (the last component) MUST match the metadata.resourceId item in the resolved object.
Verify the attached Data Integrity proof, as specified here.
Extract the <resource> from the Attested Resource and calculate the digestMultibase value using the specified `digestMultibase algorithm.
The digestMultibase portion of the Attested Resource identifier (the last component) MUST match the calculated digestMultibase.
The metadata.resourceType MUST be the type of the expected resource.
Process the <resource> as the expected object.
If necessary, use the Attested Resource object links JSON item in processing the result.

§ Attested Resource JSON-LD Context

The following is the [JSON-LD] context file for an attested-resource object.

{
    "@context": {
        "@protected": true,
        "id": "@id",
        "type": "@type",
        "undefined": "https://www.w3.org/ns/credentials/undefined-term#",
        "digestMultibase": {
          "@id": "https://w3id.org/security#digestMultibase",
          "@type": "https://w3id.org/security#multibase"
        },
        "AttestedResource": {
            "@id": "undefined:AttestedResource",
            "@protected": true,
            "@context": {
                "content": {
                  "@id": "undefined:content",
                  "@type": "@id",
                  "@vocab": "undefined"
                },
                "metadata": {
                  "@id": "undefined:metadata",
                  "@type": "@id",
                  "@vocab": "undefined"
                },
                "links": {
                  "@id": "undefined:links",
                  "@type": "@id"
                }
            }
        }
    }
}

§ References

ANONCREDS: AnonCreds. Mike Lodder; Stephen Curran; 2023-01-27. Status: Internet Draft.
DI-EDDSA-V1.0: Data Integrity EdDSA Cryptosuites v1.0. Dave Longley; Manu Sporny; 2024-12-08. Status: W3C Technical Recommendation.
DID-CORE: Decentralized Identifiers (DIDs) v1.0. Manu Sporny; Amy Guy; Markus Sabadello; Drummond Reed; 2022-07-19. Status: REC.
DRAFT-MSPORNY-BASE58-03: The Base58 Encoding Scheme. S. Nakamoto; Manu Sporny; 2021-03-31. Status: Internet Draft.
JSON-LD: JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler; 2020-11-03. Status: REC.
MULTIFORMATS: The Multibase Data Format. Juan Benet; Manu Sporny; 2024-02-21. Status: Internet Draft.
RFC1035: Domain names - implementation and specification. P. Mockapetris; 1987-11. Status: Internet Standard.
RFC1123: Requirements for Internet Hosts - Application and Support. R. Braden, Ed.; 1989-10. Status: Internet Standard.
RFC2181: Clarifications to the DNS Specification. R. Elz; R. Bush; 1997-07. Status: Proposed Standard.
RFC2234: Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed.; P. Overell; 1997-11. Status: Proposed Standard.
RFC3491: Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN). P. Hoffman; M. Blanchet; 2003-03. Status: Proposed Standard.
RFC3912: WHOIS Protocol Specification. L. Daigle; 2004-09. Status: Draft Standard.
RFC3986: Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter; 2005-01. Status: Internet Standard.
RFC4033: DNS Security Introduction and Requirements. R. Arends; R. Austein; M. Larson; D. Massey; S. Rose; 2005-03. Status: Proposed Standard.
RFC4034: Resource Records for the DNS Security Extensions. R. Arends; R. Austein; M. Larson; D. Massey; S. Rose; 2005-03. Status: Proposed Standard.
RFC4035: Protocol Modifications for the DNS Security Extensions. R. Arends; R. Austein; M. Larson; D. Massey; S. Rose; 2005-03. Status: Proposed Standard.
RFC5895: Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008. P. Resnick; P. Hoffman; 2010-09. Status: Informational.
RFC6125: Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS). P. Saint-Andre; J. Hodges; 2011-03. Status: Proposed Standard.
RFC6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF). D. Eastlake 3rd; T. Hansen; 2011-05. Status: Informational.
RFC6902: JavaScript Object Notation (JSON) Patch. P. Bryan, Ed.; M. Nottingham, Ed.; 2013-04. Status: Proposed Standard.
RFC8030: Generic Event Delivery Using HTTP Push. M. Thomson; E. Damaggio; B. Raymor, Ed.; 2016-12. Status: Proposed Standard.
RFC8484: DNS Queries over HTTPS (DoH). P. Hoffman; P. McManus; 2018-10. Status: Proposed Standard.
RFC8785: JSON Canonicalization Scheme (JCS). A. Rundgren; B. Jordan; S. Erdtman; 2020-06. Status: Informational.
RFC9110: HTTP Semantics. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.; 2022-06. Status: Internet Standard.
RFC9233: Internationalized Domain Names for Applications 2008 (IDNA2008) and Unicode 12.0.0. P. Fältström; 2022-03. Status: Proposed Standard.
RFC9457: Problem Details for HTTP APIs. M. Nottingham; E. Wilde; S. Dalal; 2023-07. Status: Proposed Standard.
RFC9525: Service Identity in TLS. P. Saint-Andre; R. Salz; 2023-11. Status: Proposed Standard.
VC-DATA-INTEGRITY: Verifiable Credential Data Integrity 1.0. Manu Sporny; Dave Longley; Greg Bernstein; Dmitri Zagidulin; Sebastian Crane; 2023-12-10. Status: CR.

§ `did:webvh` AnonCreds Methof Version Changelog

The following lists the substantive changes in each version of the specification.

Version 0.1
- Initial version of the specification

§ The did:webvh AnonCreds Methodv0.1 / Editor’s Draft