Most compact version

[SmithSamuelM]

The algorithm for computing the “most” compact version of a field map in an ACDC in order to compute its SAID is as follows.

Recursively ascending the document tree of nested blocks.

If a block has a SAID field d then the most compact version for the next higher block that includes that block is the oneOf representation that is the block label with a str value that is its SAID.

The actual SAID of any block that does not have any nested SAIDed blocks must be the full expansion of that block. Otherwise a nested block would have to have a subblock with a SAIDed field in order for it not to be fully expanded.

When ascending the tree any non-nested SAIDed blocks, we call such a block a leaf block. Its SAID must be the fully expanded representations (there are no other variants possible and there is no oneOf in its schema).

A SAIDed non-leaf blocks will have a oneOf for which one of the subschema is just the block label and a string value that is its SAID.

The computation of a SAIDed non-leaf block’s SAID is as follows:

Each SAIDed non-leaf block represents each of its nested SAIDed sub-blocks with str fields where the field value is the SAID of the nested block. Non-SAIDed leaf sub-blocks are fully expanded (they can’t be any other way) and other top level fields are represented as is.

The most compact SAID for any SAIDed non-leaf black can be computed recursively as a depth first search of its top-level fields.

First descend depth first until a leaf is reached then compute the SAID of the leaf and then ascend back up and compute the SAIDs of any siblings (each by recursive descent) then compute the SAID of that non-leaf block and so one until the SAID of the top-level block is computed.

Using this algorithm there is one and only one SAID for any given ACDC as well as any of its parts at any level. The SAID of any block is the SAID of its most compact version so there is never any ambiguity introduced by the oneOf schema operator.

[nkongsuwan]

Do I understand correctly that the "d" field of an ACDC in its uncompacted form, e.g. a fully expanded version, must always be the SAID of its most compacted form?

[SmithSamuelM]

Yes

[SmithSamuelM]

See the examples in the spec of compact vs non compact forms

[nkongsuwan]

I have checked the KLI demo on credential issuance for the QVI vLEI schema (keripy/scripts/demo/credentials/single-issuer.sh), and it seems that the protocol you described above is not implemented in the KLI yet. Is this something on your to-do list? Or am I missing something?

To give you more detail, this is the ACDC I obtain from the script:

{
    "v": "ACDC10JSON000197_",
    "d": "EDeh2Em1o8nHvMPqOcI5Yv2e51H_t0MTU-f4Z6MSTwvh",
    "i": "EKxICWTx5Ph4EKq5xie2znZf7amggUn4Sd-2-46MIQTg",
    "ri": "EEloVTY1iX6TUP9kRVKyYF-qVT8p89pgXMvsFRac7MDK",
    "s": "EBfdlu8R27Fbx-ehrqwImnK-8Cm79sqbAQ4MmvEAYqao",
    "a": {
      "d": "EPGoWl90AsJ-O6BdhBrFCsIHWG7wfVJ3p2TPk_cALmoU",
      "i": "ELjSFdrTdCebJlmvbFNX9-TLhR2PO0_60al1kQp5_e6k",
      "dt": "2023-07-05T13:35:38.335995+00:00",
      "LEI": "5493001KJTIIGC8Y1R17"
    }
}

However, when I tried using kli saidify on its most compacted form, I get a difference SAID:

{
    "v": "ACDC10JSON000119_",
    "d": "EL3uJYzwBNxuGxY5ZJCqJe_6Dtm55HVLfyuOONQGnLmz",
    "i": "EKxICWTx5Ph4EKq5xie2znZf7amggUn4Sd-2-46MIQTg",
    "ri": "EEloVTY1iX6TUP9kRVKyYF-qVT8p89pgXMvsFRac7MDK",
    "s": "EBfdlu8R27Fbx-ehrqwImnK-8Cm79sqbAQ4MmvEAYqao",
    "a": "EPGoWl90AsJ-O6BdhBrFCsIHWG7wfVJ3p2TPk_cALmoU"
}

[SmithSamuelM]

@nkongsuwan Yes the most compact version algorithm is on the todo list for the vLEI. The vLEI was implemented before we resolved how to manage nested partial disclosure in ACDCs