Log Format

[brianorwhatever]

The following was pulled in from here

Proposed DID history format

The history consists of a set of JSON-formatted arrays. Each line is in the format:

[version hash, version ID, timestamp, params, data, proofs]

Within each line the properties are as follows:

version hash

• The hash corresponding to the current line. See version hash calculation.

version ID

• An incrementing integer value corresponding to the line index. The first line is index 1.

timestamp

• A timestamp associated with the current update. This must be formatted according to ISO8601 with the timezone offset included.

params

• A JSON object containing the parameters updated by the current line. See parameters.

data

• A JSON object containing the updates to the document state. See data updates.

proofs

• An array of proofs for the current update, used to establish key ownership as well as continuity from the previous state. See proofs.

Parameters

There is currently 2 supported parameters.

method

• An identifier for the document versioning method. This will establish the calculation method for the self-certifying document identifier as well as the supported proof formats.

scid

• The self-certifying identifier derived from the initial document. This will also be included in the method specific identifier (the DID).

hash

• The hash function that is used.

The first line of the history must establish these parameters.

Example (parameters only):

{"method": "did:webnext:1", "scid": "abc123abc123abc123abc123", "hash": "sha256"}

Data updates

Each data update contains one of:

value

• Establishing the full contents of the document, or

patch

• Containing a JSON patch from the previous content of the document.

Examples (data only):

{"value": {"@context": ["https://www.w3.org/ns/did/v1", "https://w3id.org/security/data-integrity/v2", "https://w3id.org/security/multikey/v1"], "id": "did:webnext:example.com:menetsyqymts6yhpmtfebtym", "authentication": ["did:webnext:example.com:menetsyqymts6yhpmtfebtym#kbaEzdWJd6UFDcifYo158dh2mXysTB7INj51JcgpCqg"], "verificationMethod": [{"id": "did:webnext:example.com:menetsyqymts6yhpmtfebtym#kbaEzdWJd6UFDcifYo158dh2mXysTB7INj51JcgpCqg", "type": "Multikey", "controller": "did:webnext:example.com:menetsyqymts6yhpmtfebtym", "publicKeyMultibase": "z6Mkn4z9ze2ESZhWL2HKGdQcGFdT8dH5Ht9zDnBoiPJfANyz"}]}}

{"patch": [{"op": "add", "path": "/alsoKnownAs", "value": ["did:web:example.com"]}]}

The first line of the history must contain a value property.

Version hash calculation

• Take the version hash of the previous line as last hash. For the first line, use the empty string ("").
• Calculate the raw digest as hash(JCS([last hash, version ID, timestamp, params, data]))
• Output version hash = base32lower(digest)

Example:

hash input: JCS([
        "zQmcPRLmBy5KwV74epZ9fvoEngjbukRphUdaZS1nxqKfM16",
        2,
        "2024-03-19T23:39:37Z",
        {},
        {"patch": [{"op": "add", "path": "/controller", "value": ["did:alt:controller"]}]},
    ])
output: zQmSMxhxGp1CQ6SL5vi1rSCRXXfR9RMkzPTLLVF26wEAztE

Proofs

Data integrity proofs (cryptosuite TBD) are created with an authentication purpose, including the version hash as a challenge and using the new state of the document. The proofs are extracted from the signed document and included in the log entry. These are injected back into the document as proof when verifying the log entry.

Example:

[{"type":"DataIntegrityProof","created":"2024-03-28T08:18:57Z","verificationMethod":"did:tdw:jNQ4MKr87HBoox9iXKjRKt3S#FFhXVfsx","cryptosuite":"eddsa-2022","proofPurpose":"authentication","challenge":"z3dY6uzgy4CK3tFC29TSjES6MrhhyvnbE4KfccvbzU8PQ","proofValue":"zBK6pMkFBnzXH1qYPn2iEsi2jo3y7pBcNuqrGH99GKp2mvCH9VvRK1EPZPiXvzzQoxwEhveBBPs1Jk6spUXVsfme"}]

Full example

(With invalid hashes)

["zQmNQFTHCUc1S3iiNoZ5TzPevXQqwfT1xuiuYsC4hrc97Kz", 1, "2024-03-25T18:51:50Z", {"method": "did:webnext:1"}, {"value": {"@context": ["https://www.w3.org/ns/did/v1", "https://w3id.org/security/data-integrity/v2", "https://w3id.org/security/multikey/v1"], "id": "did:webnext:example.com:menetsyqymts6yhpmtfebtym", "authentication": ["did:webnext:example.com:menetsyqymts6yhpmtfebtym#kbaEzdWJd6UFDcifYo158dh2mXysTB7INj51JcgpCqg"], "verificationMethod": [{"id": "did:webnext:example.com:menetsyqymts6yhpmtfebtym#kbaEzdWJd6UFDcifYo158dh2mXysTB7INj51JcgpCqg", "type": "Multikey", "controller": "did:webnext:example.com:menetsyqymts6yhpmtfebtym", "publicKeyMultibase": "z6Mkn4z9ze2ESZhWL2HKGdQcGFdT8dH5Ht9zDnBoiPJfANyz"}]}, [{"type": "DataIntegrityProof", "cryptosuite": "eddsa-jcs-2022", "verificationMethod": "did:webnext:example.com:menetsyqymts6yhpmtfebtym#did:webnext:example.com:menetsyqymts6yhpmtfebtym#kbaEzdWJd6UFDcifYo158dh2mXysTB7INj51JcgpCqg", "created": "2024-03-25T18:51:50Z", "challenge": "zQmNWMPLDMx3QyYtiNarjELQ9RCvHm1hAMHRrrrqNQ7kbvt", "proofPurpose": "authentication", "proofValue": "z4Por1indyg8WgytdzKkHD1FqWUfzPHrKsWvr5zn4r3bn6grLMP54ahfqQ9hPdYuTjSWeqjsTRF8M9ujnK2BzqcCG"}]]
["zQmbfhXs7E8FMJNNN2Gc98hDsUatAjZ53K7gdwWEKx5ZJWs", 2, "2024-03-25T18:51:50Z", {}, {"patch": [{"op": "add", "path": "/controller", "value": ["did:webnext:example.com:menetsyqymts6yhpmtfebtym", "did:example:controller"]}, {"op": "add", "path": "/verificationMethod/1", "value": {"id": "did:example:controller#tWMK1fLzevQaBJc_bl4vJ6waLI32bQwTIcVv9BXTiGA", "type": "Multikey", "controller": "did:example:controller", "publicKeyMultibase": "z6Mks2wuUH1sgBYUxnd48LV9TxS5fACun4ZdCAGy8ujRLzJx"}}, {"op": "add", "path": "/authentication/1", "value": "did:example:controller#tWMK1fLzevQaBJc_bl4vJ6waLI32bQwTIcVv9BXTiGA"}]}, [{"type": "DataIntegrityProof", "cryptosuite": "eddsa-jcs-2022", "verificationMethod": "did:webnext:example.com:menetsyqymts6yhpmtfebtym#did:example:controller#tWMK1fLzevQaBJc_bl4vJ6waLI32bQwTIcVv9BXTiGA", "created": "2024-03-25T18:51:50Z", "challenge": "zQmbfhXs7E8FMJNNN2Gc98hDsUatAjZ53K7gdwWEKx5ZJWs", "proofPurpose": "authentication", "proofValue": "zfr2rcCyQdvsy6ixvVkjFjB14Z3ncb2GqvPEGd49zG9WgJtM96HBoQVaTbs1MwtCcWq3szY28cw63SQ8nUxPDfyY"}]]
["zQmbbT3zAxR6vWibmzN9PxhM5e6kDRDTUsbhnwnP9tiFLbU", 3, "2024-03-25T18:51:50Z", {}, {"patch": [{"op": "add", "path": "/alsoKnownAs", "value": ["did:web:example.com"]}]}, [{"type": "DataIntegrityProof", "cryptosuite": "eddsa-jcs-2022", "verificationMethod": "did:webnext:example.com:menetsyqymts6yhpmtfebtym#did:webnext:example.com:menetsyqymts6yhpmtfebtym#kbaEzdWJd6UFDcifYo158dh2mXysTB7INj51JcgpCqg", "created": "2024-03-25T18:51:50Z", "challenge": "zQmbbT3zAxR6vWibmzN9PxhM5e6kDRDTUsbhnwnP9tiFLbU", "proofPurpose": "authentication", "proofValue": "z2j9sGp6aTxFZyMX7r8xYtbNJEw5gBGktdEj7M58G6FiC4FtugVUVZHWRdr1NZHhr7DsP7uVFXuf9PRbo3fGreouG"}]]

[swcurran]

Question: Given that the scid can appear in multiple places in the id string (the DID) do we need to call out the scid so that the SCID verification can be deterministically completed? Or can we extract the scid from the id in a reliable way?

[andrewwhitehead]

Question: Given that the scid can appear in multiple places in the id string (the DID) do we need to call out the scid so that the SCID verification can be deterministically completed? Or can we extract the scid from the id in a reliable way?

I think that it should always be the last component of the method-specific ID, then the resolution process is straightforward:

• Remove the last component
• Resolve the history as you would resolve the document in did:web (with a different filename)
• Load the history (up to the requested versionId/versionTime), checking the SCID derivation on the first entry
• Check that the full ID matches on the resolution result

[swcurran]

I think that it should always be the last component of the method-specific ID, then the resolution process is straightforward:

I disagree is it adds yet another artificial enforced constraint to be different than did:web. The closer we get to did:web the better. So — did:tdw:<scid>.cloudcompass.ca should be allowed. As should did:tdw:cloudcompass.ca:<scid>. The DID URL to HTTPS URL rules should be identical to did:web except that there MUST be a SCID in the DID.

[andrewwhitehead]

I think that implies that for did:tdw:cloudcompass.ca:<scid> the DID history will be in https://cloudcompass.ca/<scid>/ and not in .well-known, for consistency with did:web. But I don't see why we need that.

[swcurran]

I think we totally need that. I can see that using did:tdw:cloudcompass.ca:dids:<scid> for all of my DIDs (of different purposes), that I store inhttps://cloudcompass.ca/dids/<scid>/. For example, a company might have DIDs for the products in products/<scid>.

[brianorwhatever]

I ended up putting a scid param into the first log line I think it's a clean solution that allows flexiblity. Other than that the only difference I think I have to the original post here is I'm not using the empty string for the previousHash of the first line I'm using the genesis doc hash. See https://github.com/bcgov/didwebnext/pull/18#discussion_r1542362667

[swcurran]

@brianorwhatever -- can you please add the Proof implementation to the initial description above?

[brianorwhatever]

Will do.

@andrewwhitehead are you ok with putting the scid into the possible params?

[andrewwhitehead]

Yup I'll update mine to add the scid as a parameter and adjust the previousHash.

[brianorwhatever]

This has been included in the spec now