KERI jargon in a nutshell. Part 2: SAID and ACDC.

• Part 1: KERI and AID.
• Part 2: SAID and ACDC.
• Part 3: OOBI and IPEX.
• Part 4: CESR and CESR-Proof Signatures.
• Part 5: TEL and PTEL

TL;DR 1: A SAID is an identifier that is encapsulated by the data content from which the SAID is cryptographically derived. Using a SAID provides enhanced security for managing and reasoning about the identified data.

TL;DR 2: An ACDC is a variant of a W3C Verifiable Credential with extra properties and an enhanced security model derived from the KERI protocol.

This blog continues from the KERI jargon in a nutshell (Part 1) which summarizes the key concepts and terminology related to Key Event Receipt Infrastructure (KERI). The second part here explores SAID (Self-Addressing Identifiers) and ACDC (Authentic Chained Data Container).

These topics are currently under the standardization process by the Internet Engineering Task Force (IETF). I recommend avid readers and developers to check out their IETF drafts, which can be found here:

• KERI Community: https://github.com/WebOfTrust/keri
• SAID IETF Draft: https://datatracker.ietf.org/doc/draft-ssmith-said/
• ACDC IETF Draft: https://datatracker.ietf.org/doc/draft-ssmith-acdc/

Table of Contents

· SAID (Self-Addressing Identifiers)
∘ Content-Addressability
∘ Self-Reference
∘ SAD (Self-Addressing Data)
∘ SAID Protocol
∘ Advantages of Using SAIDs
· ACDC (Authentic Chained Data Container)
∘ Simple ACDC Example
∘ Naive Conversion to a W3C VC
· Distinguishing Features of ACDCs
∘ 1. KERI Security Model
∘ 2. Compact ACDC Format
∘ 3. Composable JSON Schema
∘ 4. ACDC Chaining
∘ 5. Ricardian Contracts
∘ 6. Chain-Link Confidentiality
∘ 7. Graduated Disclosure

Photo by Mediamodifier on Unsplash

SAID (Self-Addressing Identifiers)

A SAID (Self-Addressing Identifier) is an identifier that is content-addressable and self-referential. A SAID is uniquely and cryptographically bound to a serialization of data that includes the SAID as a component (or field) in that serialization.

Note 1: Serialization is defined as a process of translating a data structure or object state into a data format that can be stored, transmitted, and reconstructed at a later time.

Note 2: In KERI, all identifiers are SAIDs. For example, Autonomic Identifiers (AIDs) are SAIDs of their associated key inception events. Identifiers of Authentic Chained Data Containers (ACDCs) and their schemas are also SAIDs.

Content-Addressability

An identifier that is content-addressable is based on an encoded cryptographic digest and is, thus, cryptographically bound to the content that it identifies.

Self-Reference

An identifier that is self-referential appears within the content that it is identifying.

SAD (Self-Addressing Data)

SAD (Self-Addressing Data) of a SAID is defined as a representation of data content from which the SAID is derived. The SAID is both cryptographically bound to (content-addressable) and encapsulated by (self-referential) its SAD.

Note: the example SAID above starts with the character “E”. This is a CESR character code that specifies that the SAID is generated using a Blake3–256 digest.

SAID Protocol

A “naive” cryptographic content-addressable identifier is not self-referential. This is because the naive cryptographic derivation process of a content-addressable identifier is a cryptographic digest of the serialized content. Changing one bit of the serialization content will result in a different digest. Therefore, a self-referential content-addressable identifier requires a special derivation protocol.

The generation and verification protocol of a SAID—which makes it both content-addressable and self-referential—is outlined with an example below:

• Here is an example of a Python dict with the empty field “said”.

{
  "said": "",
  "first": "Sue",
  "last": "Smith",
  "role": "Founder"
}

• Serialize the data into JSON with no extra whitespace.
• Replace the “said” field value in the serialization of data with a dummy string # of the same length as the to-be-generated SAID. Here, we use a Blake3–256 digest with 44 characters.

{"said":"############################################","first":"Sue",
"last ":"Smith","role":"Founder"}

• Compute the digest (Blake3–256) of the serialization that includes the dummy value for the “said” field.

EJymtAC4piy_HkHWRs4JSRv0sb53MZJr8BQ4SMixXIVJ

• The value of the “said” field is now replaced with the computed and encoded SAID to produce the final serialization with embedded SAID.
• The final serialization may be converted to a Python dict by deserializing the JSON.

{
  "said": "EJymtAC4piy_HkHWRs4JSRv0sb53MZJr8BQ4SMixXIVJ",
  "first": "Sue",
  "last": "Smith",
  "role": "Founder"
}

Note: The SAID protocol preserves the insertion ordering of its content. That is, it preserves the order in which elements are added to a data structure

Advantages of Using SAIDs

Here are some advantages of using SAIDs over other types of identifiers:

• SAIDs facilitate greater interoperability, reduced ambiguity, and enhanced security in the management of data.
• A cryptographic commitment—such as a signature, digest, or another SAID—to a given SAID is essentially equivalent to a commitment to its associated serialization.
• Any change to the serialization invalidates its SAID thereby ensuring secure immutability and evident reasoning with SAIDs about serializations or equivalently their SAIDs.
• SAIDs facilitate immutably referenced data serializations for applications such as Verifiable Credentials and Ricardian Contracts.

ACDC (Authentic Chained Data Container)

An ACDC (Authentic Chained Data Container) is a variant of the Verifiable Credential (VC) that is designed to be used with other protocols in the KERI ecosystem.

ACDC or Authentic Chained Data Container has the following meaning:

• Authentic: ACDCs are authentic using digital signatures that are signed and verified by keys associated with AIDs.
• Chained: ACDCs may be chained together as a directed acyclic graph.
• Data Container: A data container is a serialized data structure of label-value pairs. That is, it is a way of bundling together data items.

A Data Container is a way of bundling together data items. An Authentic Data Container (ADC), therefore, is a data container that provides cryptographic verifiability of the integrity and source of its bundled data. In other words, that data is both tamper-proof and is non-repudiably attributable to its source. Authentic Chained Data Containers (ACDCs) are ADCs that are chained/linked together to provide granular proof-of-authorship (i.e., authenticity) of their contained data as a directed acyclic graph.

Note: A directed acyclic graph (DAG) is a directed graph with no directed cycles. That is, it consists of vertices and edges, with each edge directed from one vertex to another, such that following those directions will never form a closed loop.

As a variant of the VC, ACDCs share the same fundamental properties as traditional VCs. However, ACDCs are specifically designed to work with the KERI protocol and consequently benefit from its best-in-class security properties. Unlike W3C VC, ACDC also provides normative support for credential chaining. The features that distinguish ACDCs from traditional VCs will be discussed in detail later in this blog.

Basically, you can think of ACDCs as VCs on steroids!

Note: As defined in W3C Verifiable Credential Data Model v1.1, a verifiable credential is a set of tamper-evident claims and metadata that cryptographically prove who issued it. This definition also applies to ACDCs.

Simple ACDC Example

Here is an example of an ACDC from an issuer to an issuee:

{
  "v": "ACDC10JSON000113_",
  "d": "EFprJkdpcJSet8aLY9PaMicyyUkEFnVjrIRZTmftmhkg",
  "i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
  "a": {
    "d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
    "i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
    "dt": "2021-06-09T17:35:54.169967+00:00"
  }
}

Here, each field has the following description:

• “v” is a version string that provides protocol type (ACDC), version (1.0), serialization type (JSON), the size of the ACDC in the lowercase hexadecimal notation (00113 = 1*16**2 + 1*16 + 3 = 275 characters), and the terminator character (_).
• “d” is the SAID of the ACDC.
• “i” is the AID of the issuer.
• “a” is the block of attributes (claims) of the holder (i.e. the data subject).

There are the following fields inside “a”:

• “d” is the SAID of the nested “a” block.
• “i” is the AID of the holder.
• “dt” is the date-time of the issuance.

Note 1: The primary field labels in ACDCs are compact, i.e., having only one or two characters. This design choice was made so that ACDC can support resource-constrained applications such as those in supply chains and IoT.

Note 2: an ACDC may be untargeted, that is an ACDC without a holder. An untargeted ACDC provides an undirected verifiable attestation or observation of a piece of data. For example, a thermometer may make verifiable non-repudiable temperature measurements and publish them as ACDCs.

Naive Conversion to a W3C VC

The example ACDC above may be converted to a W3C Verifiable Credential (W3C VC) in a “naive” manner as follows:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "issuer": {
    "id": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM"
  },
  "validFrom": "2021-06-09T17:35:54.169967+00:00",
  "credentialSubject": {
    "id": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA"
  }
}

This conversion is naive since some security properties of the ACDC are lost during the conversion. For example, the SAIDs of the ACDC and its attributes do not appear in the W3C VC.

A more secure conversion standard between ACDC and W3C VC is currently being developed by Kevin Griffin from GLEIF in this draft specification:

• https://weboftrust.github.io/vc-acdc/

Note: Unlike W3C VC, an ACDC does not have a “proof” section. A digital signature is attached to the ACDC using the CESR Proof Signature protocol.

Distinguishing Features of ACDCs

ACDCs have features that distinguish them from traditional VCs. Some of the major distinguishing features include:

1. The security model that is derived from KERI,
2. Compact formats for resource-constrained applications
3. Composable JSON Schema,
4. Support for credential chaining,
5. Support for Ricardian contracts,
6. Support for chain-link confidentiality, and
7. Support for graduated disclosure.

1. KERI Security Model

An ACDC inherits its security properties from the KERI protocol that enables the ACDC to be used in a portable but securely attributable, fully decentralized manner.

A security property that I would like to emphasize here is the one that emerges from using SAIDs as identifiers. In fact, all identifiers in ACDCs are SAIDs or URIs that contain SAIDs. Hence, a digital signature on an ACDC provides a cryptographic commitment to the ACDC itself as well as to all the data from which the SAIDs in ACDC were derived. Examples of SAIDs in an ACDC include:

• the top-level identifier of the ACDC itself and the identifiers of nested data blocks inside the ACDC: Using SAIDs as identifiers enables a compact but secure representation of the ACDC and associated blocks.
• the identifier of ACDC’s issuer and holder: The identifiers of the issuer and the holder (i.e., the issuee) are autonomic identifiers (AIDs), which are SAIDs of the inception events of their key event logs (KELs). A digital signature on an ACDC can be verified using the issuer’s KEL while the holder may cryptographically prove its holdership over the ACDC using their KEL.
• the identifier of the ACDC’s status registry: The status of an ACDC is determined by a status registry, called a transaction event log (TEL). The issuance and revocation events of an ACDC are recorded as TEL entries that are anchored to the KEL of the ACDC’s issuer.
• the identifier of the ACDC’s schema: The schema of an ACDC is a JSON schema where the schema id field ("$id") is the SAID of the schema. This ensures that the ACDC schema is static and verifiable to the SAID.

Note: With the use of the SAID protocol, the schema of an ACDC is static, i.e. immutable. This makes the ACDC protected against the schema malleability attack where an adversary attacks the source that provides schema resources.

2. Compact ACDC Format

An ACDC may be expressed in multiple ways including in compacted or uncompacted formats. Simple examples of the same ACDC that is expressed in compacted or uncompacted formats are given below.

# Compacted ACDC variant
{
  "v": "ACDC10JSON000119_",
  "d": "ECh56mUZGxTZtpiTrxaB7wZlQtRsD4N5pY5adc_B1748",
  "i": "EKxICWTx5Ph4EKq5xie2znZf7amggUn4Sd-2-46MIQTg",   
  "ri": "EMrPQvNVXag7MtTXVNtOBtUmjBWj6QLpPH8QBqBITUH_",
  "s": "EAxP7acR20ckPKh581y6bWrqhCMZToBhoGHLoQgqJQtW",
  "a": "EBkbsuJIH_8aCUKNFFpRjT5G5_YsQ6_pZrcrCVQFnzC3"
}

# Uncompacted ACDC variant
{
  "v": "ACDC10JSON00018c_",
  "d": "EDycvNBB5c1cqvgOnCmwBPmcrk80bYyRVfc-G_351kO9",
  "i": "EKxICWTx5Ph4EKq5xie2znZf7amggUn4Sd-2-46MIQTg",
  "ri": "EMrPQvNVXag7MtTXVNtOBtUmjBWj6QLpPH8QBqBITUH_",
  "s": "EAxP7acR20ckPKh581y6bWrqhCMZToBhoGHLoQgqJQtW",
  "a": {
    "d": "EBkbsuJIH_8aCUKNFFpRjT5G5_YsQ6_pZrcrCVQFnzC3",
    "i": "ELjSFdrTdCebJlmvbFNX9-TLhR2PO0_60al1kQp5_e6k",
    "dt": "2023-06-05T00:30:16.261184+00:00",
    "name": "Jane Doe"
  }
}

Here two more fields are introduced:

• "s" is the SAID of the JSON Schema that is used to produce the ACDC.
• "ri" is the identifier of the ACDC’s status registry.

In the compacted variant, the value of "a" is the SAID of the attribute section, which is equal to the value of the digest "d" inside "a" of the uncompacted variant.

Compact ACDCs are useful in resourced-constrained applications where the receivers/verifiers of ACDCs may cache some piece of data with their SAIDs. Other uses of compact ACDCs will also be discussed in later sections of this blog.

3. Composable JSON Schema

The schema used by ACDCs is the JSON Schema. The JSON Schema supports composable schema that enables the use of any combination of compacted and uncompacted sections and subsections in an ACDC. With this property, the ACDC’s verification protocol allows the same ACDC to be expressed in multiple forms while still being verifiable using the same digital signature from an issuer.

For the above examples of compacted and uncompacted ACDC, the schema of their attribute section "a" may be constructed with the keyword "OneOf" as follows:

{
  "a": {
    "oneOf": [
      {
        "description": "Attributes block SAID",
        "type": "string"
      },
      {
        "$id": "ELpLieummE-O6FzaQ7RW-yPV__x36x6XkmdFBr6ua7ec",
        "description": "Attributes block",
        "type": "object",
        "properties": {
          "d": {
            "description": "Attributes block SAID",
            "type": "string"
          },
          "i": {
            "description": "Holder's AID",
            "type": "string"
          },
          "dt": {
            "description": "Issuance date time",
            "type": "string",
            "format": "date-time"
          },
          "name": {
            "description": "Name",
            "type": "string"
          }
        },
        "additionalProperties": false,
        "required": [
          "d",
          "i",
          "name"
        ]
      }
    ]
  }
}

Note: If an ACDC schema allows for multiple variants, the issuer of such an ACDC must digitally sign the most compacted variant. A verifier who subsequently receives an uncompacted variant may convert it into the most compacted variant before verifying it against the digital signature.

4. ACDC Chaining

Unlike the W3C VC data model, the ACDC specification provides normative support for credential chaining. Chaining between ACDCs forms a directed acyclic graph (DAG) where the ACDCs are nodes in the graph. The directed edges between ACDCs are represented by field "e", which specifies the relationships between the connected ACDCs. A simple example is given below where an edge represents a mother-son relationship between Ms. Jane Doe and Mr. John Doe.

# An example ACDC that attests to the identity of Ms. Jane Doe.
{
  "v": "ACDC10JSON00018c_",
  "d": "EDycvNBB5c1cqvgOnCmwBPmcrk80bYyRVfc-G_351kO9",
  "i": "EKxICWTx5Ph4EKq5xie2znZf7amggUn4Sd-2-46MIQTg",
  "ri": "EMrPQvNVXag7MtTXVNtOBtUmjBWj6QLpPH8QBqBITUH_",
  "s": "EAxP7acR20ckPKh581y6bWrqhCMZToBhoGHLoQgqJQtW",
  "a": {
    "d": "EBkbsuJIH_8aCUKNFFpRjT5G5_YsQ6_pZrcrCVQFnzC3",
    "i": "ELjSFdrTdCebJlmvbFNX9-TLhR2PO0_60al1kQp5_e6k",
    "dt": "2023-06-05T00:30:16.261184+00:00",
    "name": "Jane Doe"
  }
}

# An example ACDC that attests to the identity of Mr. John Doe. 
# The edge section indicates that Ms. Jane Doe is his mother. 
{
  "v": "ACDC10JSON000203_",
  "d": "EFh8dlxwT2EjhknxNAP5xIhYmiurtGbeDQ-pS5jOaOlE",
  "i": "EKxICWTx5Ph4EKq5xie2znZf7amggUn4Sd-2-46MIQTg",
  "ri": "ECHkWfh71fLmkeJpeMvic6RQp5P73PizTGQelXB7ZNEE",
  "s": "EAxP7acR20ckPKh581y6bWrqhCMZToBhoGHLoQgqJQtW",
  "a": {
    "d": "EFFD47E5Ev1zJF3zIagGEM7kbTI9DoT3scItzDPq9Jnm",
    "i": "EKW8xHilZH8-CetHzBOddWpG0bS_vJlphrK3zh95u0zF",
    "dt": "2023-06-05T01:07:44.885411+00:00",
    "name": "John Doe"
  },
  "e": {
    "d": "EE12DuT-V4IPumKmRsirulOeroO38aCEb4mjKy8SlE0m",
    "mother": {
      "n": "EDycvNBB5c1cqvgOnCmwBPmcrk80bYyRVfc-G_351kO9"
    }
  }
}

The edge section "e" is the representation of the directed edge that originates from the embedding ACDC. Inside the edge section, the fields have the following meanings:

• "d" is the SAID of the edge section.
• "n" is the SAID of the ACDC to which the edge is directed, i.e., the SAID of Ms. Jane Doe’s ACDC.

Note: The edge section may also be compacted using the section’s SAID.

5. Ricardian Contracts

An ACDC may consist of a rule section "r" to provide a Ricardian Contract. To satisfy the properties of a Ricardian contract, the rule section may be hierarchically structured into sections and subsections with named or numbered clauses in each section. The labels on the clauses may follow such a hierarchical structure using nested maps or blocks.

Note: A Ricardian contract is a type of digital contract that combines legal and financial terms with computer-readable code. It aims to create a machine-readable representation of a legal agreement by embedding the terms of the contract within a digital document. This approach allows both humans and machines to interpret and execute the contract.

An example of an ACDC with a rule section for warranty and liability disclaimers is given below.

# An example ACDC with a rule section
{
  "v": "ACDC10JSON0003e0_",
  "d": "EKZ0qdcyz2Mpl9QNuP0p1Sd0vr1Ov4g4wsDeZ7DJqGh6",
  "i": "EKxICWTx5Ph4EKq5xie2znZf7amggUn4Sd-2-46MIQTg",
  "ri": "ECHkWfh71fLmkeJpeMvic6RQp5P73PizTGQelXB7ZNEE",
  "s": "EAxP7acR20ckPKh581y6bWrqhCMZToBhoGHLoQgqJQtW",
  "a": {
    "d": "EDhg1jZaNPJdYpiNwQRsjlZMiXF6XYAzlNhgkGBfXwMb",
    "i": "EKW8xHilZH8-CetHzBOddWpG0bS_vJlphrK3zh95u0zF",
    "dt": "2023-06-05T01:14:49.919153+00:00",
    "name": "John Doe"
  },
  "r": {
    "d": "ENyB1FGejfsC2MoYXJO9WOFJttmB3lw5NC0y_dSBPlq0",
    "usageDisclaimer": {
      "l": "Usage of a valid, unexpired, and non-revoked credential does not assert that the holder is trustworthy, honest, reputable in its business dealings, safe to do business with, or compliant with any laws or that an implied or expressly intended purpose will be fulfilled."
    },
    "issuanceDisclaimer": {
      "l": "All information in a valid, unexpired, and non-revoked credential is accurate as of the date the validation process was complete. The credential has been issued to the person named in the credential as the subject."
    }
  }
}

In the rule section,

• "r" is the rule section of the ACDC.
• "d" is the SAID of the rule section.
• "l" is the text of a Ricardian contract clause.

Note: A rule section and its subsections may be compacted using the section’s and subsections’ SAIDs, respectively.

6. Chain-Link Confidentiality

One of the most important features of ACDCs (using their rule sections "r") is support for Chain-Link Confidentiality that imposes contractual restrictions and liability on a recipient (i.e. a disclosee) of confidential information. This property provides a powerful mechanism for the protection of personal data and confidential information.

The concept was first coined by Woodrow Hartzog and is defined as follows:

“A chain-link confidentiality regime would contractually link the disclosure of personal information to obligations to protect that information as the information moves downstream. The system would focus on the relationships not only between the discloser of information and the initial recipient but also between the initial recipient and subsequent recipients.”

[Woodrow Hartzog. “Chain-link confidentiality.” Georgia Law Review 46 (2011): 657.]

This approach links recipients of information in a chain, with each recipient bound by the same obligation to protect the information. These chain contracts would contain at least three kinds of terms:

• obligations and restrictions on the use of the disclosed information,
• requirements to bind future recipients to the same obligations and restrictions; and
• requirements to perpetuate the contractual chain.

An exchange of an ACDC compatible with chain-link confidentiality starts with a disclosure offer from a discloser to a recipient. This offer includes a metadata ACDC with the information to be disclosed such that the recipient can agree to those terms. Once the recipient has accepted the terms (with a non-repudiable digital signature) then full disclosure of ACDC may be made.

A simple example of chain-link confidentiality.

7. Graduated Disclosure

A discloser of an ACDC may choose not to reveal the entire content of the ACDC in their initial interaction with the recipient. Instead, the discloser may opt to partially or selectively present the information contained within the ACDC that is needed to further a transaction with the recipient—i.e., revealing only the information that is necessary for the recipient to continue the interaction. Subsequently, the discloser would disclose further information only after the recipient agrees to the terms established by the discloser. This process may involve multiple steps, where the discloser progressively reveals more information as the recipient consents to additional terms. This process is called graduated disclosure.

Note: Here, “graduated” means “arranged in a series” or “divided into different levels.”

ACDC leverages graduated disclosure that enables adherence to the principle of least disclosure, which is expressed as follows:

The system should disclose only the minimum amount of information about a given party needed to facilitate a transaction and no more.

ACDCs employ three types of graduated disclosure mechanisms, including compact, partial, and selective disclosures. Different types of disclosure may be defined as follows:

• Compact disclosure: Compact disclosure of an ACDC discloses the SAID of its content (blocks or sections of the ACDC). Both partial and selective disclosure rely on compact disclosure.
• Partial disclosure: The content of an ACDC can be partially disclosed via the exchange of only the SAID of a given content block, i.e., using compact disclosure. The SAID of a content block provides a cryptographically equivalent commitment to the yet-to-be-disclosed content. A later exchange of the uncompacted content is verifiable to an earlier partial disclosure. Another type of partial disclosure is the disclosure of metadata about the content.
• Selective disclosure: In selective disclosure, the set of attributes is provided as an array of blinded blocks, where each attribute in the set has its own dedicated blinded block. A selectively-disclosable attribute section appears at the top level using the field label A, which is distinct from the field label a for a non-selectively-disclosable attribute section.

To give an example that demonstrates the difference between partial and selective disclosure, let’s consider the following attribute block a:

# An example of an attribute block "a"
"a": {
  "d": "EA5Fm9mP5tWreQTw2xjiXYDDGzuPVtqyfekYIz6y2jMY",
  "i": "ELjSFdrTdCebJlmvbFNX9-TLhR2PO0_60al1kQp5_e6k",
  "name": "Jane Doe",
  "address": "1600 Pennsylvania Avenue NW, Washington, DC 20500, USA"
}

With selective disclosure, the attribute block may be transformed into a selectively-disclosable attribute block as follows:

# An example of a selectively-disclosable attribute block "A"
"A": [
  {
    "d": "EJ1FZBKhdVcAiaZS6eHAHMrL_ANysjLkyyOXTyAEA-lb",
    "u": "0AAJ1MJgB3aqLHNencIF-CcH",
    "i": "ELjSFdrTdCebJlmvbFNX9-TLhR2PO0_60al1kQp5_e6k"
  },
  {
    "d": "EL1EbFKUR_brFCt3knKOW92STd67AuNbRfmUzgplV12G",
    "u": "0ABLGaIT_A5yLMDEBUCCPaF7",
    "name": "Jane Doe"
  },
  {
    "d": "EN-gWdH5AWQwfdyGmK6CSA5ciXKZbvTYEvKXaSE-74rL",
    "u": "0AAlI8guN7866YoSeK7cZR5M",
    "address": "1600 Pennsylvania Avenue NW, Washington, DC 20500, USA"
  }
]

where each selectively-disclosable block has its own SAID d and a random universally unique identifier (UUID) "u".

By using random UUIDs for each selectively-disclosable block, an adversary—which possesses both the schema of the attribute block and its SAID—is not able to discover the remaining contents of the attribute block in a computationally feasible manner by using, e.g., a rainbow table attack. Therefore the UUID "u" field of each attribute block enables the associated SAID "d" field to securely blind the block’s contents.

Note 1: The field labels of the selectively disclosable attributes are also blinded because they only appear within the blinded block. This prevents un-permissioned correlation via contextualized variants of a field label that appear in a selectively disclosable block.

Note 2: The primary difference between partial disclosure and selective disclosure is determined by the correlatability with respect to its encompassing block after its disclosure. A partially disclosable field becomes correlatable to its encompassing block after its disclosure whereas a selectively disclosable field does not. After selective disclosure, the selectively disclosed fields are not correlatable to the so-far undisclosed but selectively disclosable fields in the same encompassing block.