The attribute section follows a hierarchical organization within the ACDC structure:

ACDC
├── v (version)
├── d (SAID of ACDC)
├── i (issuer AID)
├── ri (registry identifier)
├── s (schema SAID)
├── a (attributes) ← Primary attribute section
│   ├── d (SAID of attributes block)
│   ├── i (issuee AID)
│   ├── dt (datetime)
│   └── [domain-specific attributes]
├── e (edges)
└── r (rules)

The attribute section can be represented in two forms:

1. Compact Form: Only the SAID of the attributes block is included ("a": "ELGgI0fkloqKWREXgqUfgS0bJybP1LChxCO3sqPSFHCj")
2. Expanded Form: The complete attribute field map is included with all property values

This dual representation enables compact disclosure where credentials can be presented showing only the SAID initially, with full attributes revealed later after contractual protections are established.

Key Components

Attribute sections typically contain several standard components:

Attribute Block SAID (d): A self-addressing identifier computed over the canonical serialization of the attribute block, providing content-addressable integrity.

Issuee Identifier (i): When present, specifies the AID of the entity to whom the credential is issued. This field is optional - credentials without an issuee are called untargeted ACDCs.

Issuance Datetime (dt): ISO 8601 formatted timestamp indicating when the credential was issued, enabling temporal validity checks.

Domain-Specific Attributes: Custom fields defined by the credential schema, such as LEI numbers for Legal Entity credentials, role descriptions for OOR credentials, or engagement context details for ECR credentials.

Data Format

Field Definitions

Attributes are structured as ordered field maps where field order is deterministic and preserved across serialization/deserialization cycles. This ordering requirement is critical for SAID computation and verification.

The ACDC specification mandates insertion-ordered field maps rather than lexicographic (alphabetical) ordering. This means fields appear in the order they were added to the structure, not sorted by field name. Modern programming languages like Python 3.7+, JavaScript, and Rust support ordered dictionaries/hash maps that maintain insertion order.

Example attribute structure from a QVI credential:

{
  "d": "ELGgI0fkloqKWREXgqUfgS0bJybP1LChxCO3sqPSFHCj",
  "i": "EpDA1n-WiBA0A8YOqnKrB-wWQYYC49i5zY_qrIZIicQg",
  "dt": "2024-01-15T09:30:00.000000+00:00",
  "LEI": "506700GE1G29325QX363",
  "gracePeriod": 90
}

Field order matters: d, i, dt, LEI, gracePeriod must appear in this exact sequence for SAID verification to succeed.

Encoding Format

ACDC attributes support multiple serialization formats:

JSON: The primary format for human-readable credentials and development. JSON serialization must preserve field ordering and use compact representation (no whitespace) for SAID computation.

CBOR: Concise Binary Object Representation for efficient binary transmission. CBOR maintains the same logical structure as JSON but with smaller byte footprint.

MGPK: MessagePack format, another binary serialization option with similar efficiency characteristics to CBOR.

CESR: Composable Event Streaming Representation for streaming protocols where attributes may be encoded as part of larger CESR streams.

The version string (v field) in the ACDC indicates which serialization format is used, enabling parsers to correctly deserialize the credential.

Size and Constraints

Attribute sections have several size-related considerations:

SAID Length: Attribute block SAIDs are typically 44 characters (Base64 encoding of 32-byte Blake3-256 digest with CESR derivation code).

Field Label Length: Field labels should be concise to minimize credential size. The ACDC specification uses short labels like i, d, dt rather than verbose names like issuer, digest, datetime.

Value Constraints: Individual attribute values are constrained by their JSON Schema definitions. For example, LEI fields must conform to ISO 17442 format (20 alphanumeric characters), datetime fields must be ISO 8601 format.

Total Size: While no hard limit exists, practical considerations suggest keeping attribute sections under several kilobytes for efficient transmission and storage. Large data should be referenced via SAIDs rather than embedded directly.

Operations

Creation and Initialization

Attribute creation follows a specific workflow:

1. Schema Selection: Choose the appropriate JSON Schema that defines required and optional attributes for the credential type.

2. Field Population: Populate attribute fields according to schema requirements, ensuring all mandatory fields are present and values conform to type constraints.

3. Ordering Enforcement: Arrange fields in the canonical order specified by the schema. This order must be consistent across all instances of the credential type.

4. SAID Computation: Compute the attribute block SAID:

   • Serialize the attribute block to compact JSON (or other format)
   • Replace the d field with placeholder characters (# repeated to match SAID length)
   • Compute Blake3-256 digest of the serialization
   • Encode digest with CESR derivation code (typically E for Blake3-256)
   • Replace placeholder with computed SAID

5. Schema Validation: Validate the completed attribute block against its JSON Schema to ensure structural correctness.

Example Python-like pseudocode:

def create_attributes(schema, values):
    # Initialize ordered dict with required fields
    attrs = OrderedDict()
    attrs['d'] = '#' * 44  # Placeholder for SAID
    
    # Add fields in schema-defined order
    for field in schema.field_order:
        if field in values:
            attrs[field] = values[field]
    
    # Compute SAID
    serialized = json.dumps(attrs, separators=(',', ':'))
    digest = blake3(serialized.encode())
    said = 'E' + base64_url_safe(digest)
    
    # Replace placeholder
    attrs['d'] = said
    
    # Validate against schema
    validate(attrs, schema)
    
    return attrs

Updates and Modifications

ACDC attributes are immutable by design. Once a credential is issued with specific attributes, those attributes cannot be modified. This immutability is fundamental to the integrity model:

No In-Place Updates: Attributes cannot be updated in place. Any change to attribute values would invalidate the attribute block SAID, which would invalidate the ACDC SAID, breaking all cryptographic bindings.

Revocation and Reissuance: If attribute values need to change, the original credential must be revoked via the TEL (Transaction Event Log), and a new credential with updated attributes must be issued.

Versioning: Credential schemas may evolve over time, but each schema version is identified by its own SAID. Credentials issued under different schema versions are distinct credentials, not updates of existing ones.

Verification and Validation

Attribute verification involves multiple layers:

SAID Verification:

1. Extract the attribute block SAID from the d field
2. Replace the d field with placeholder characters
3. Serialize the attribute block to canonical format
4. Compute digest and encode with CESR
5. Compare computed SAID with extracted SAID
6. Verification succeeds if SAIDs match

Schema Validation:

1. Retrieve the schema identified by the ACDC's s field
2. Validate attribute structure against schema requirements
3. Check required fields are present
4. Verify field types match schema definitions
5. Validate field values against constraints (regex patterns, enums, ranges)

Semantic Validation:

1. Verify issuee AID (if present) is a valid KERI identifier
2. Check datetime values are reasonable (not in future, not too old)
3. Validate domain-specific fields (e.g., LEI format, role descriptions)
4. Verify cross-field consistency (e.g., grace period is positive integer)

Cryptographic Chain Verification:

1. Verify the ACDC SAID includes the attribute block SAID
2. Verify the issuer's signature on the ACDC
3. Verify the issuer's KEL to establish current key state
4. Verify any edge references to parent credentials

Usage Context

In Which Protocols

Attributes are used across multiple KERI-related protocols:

ACDC Issuance: The IPEX (Issuance and Presentation Exchange) protocol uses attributes to convey credential claims from issuers to holders. During issuance, the issuer creates an ACDC with populated attributes and transmits it to the holder.

ACDC Presentation: When holders present credentials to verifiers, they may use selective disclosure to reveal only specific attributes. The IPEX protocol supports graduated disclosure where attributes are revealed progressively.

ACDC Verification: Verifiers use the IPEX protocol to request specific attributes from holders and validate the received attribute data against schemas and cryptographic commitments.

TEL Management: The Transaction Event Log tracks credential lifecycle events (issuance, revocation) that reference credentials by their SAIDs, which include attribute block SAIDs.

Lifecycle Management

Attribute lifecycle follows the credential lifecycle:

Creation Phase: Attributes are created during credential issuance when the issuer populates the attribute section according to the credential schema.

Storage Phase: Holders store credentials with their attributes in secure storage (keystores, wallets). Attributes may be stored in compact form (SAID only) or expanded form (full field map).

Disclosure Phase: During presentation, holders decide which attributes to disclose:

• Compact disclosure: Share only the attribute block SAID
• Partial disclosure: Share some attributes while keeping others compact
• Selective disclosure: Share specific selectively-disclosable attributes
• Full disclosure: Share all attributes in expanded form

Verification Phase: Verifiers validate disclosed attributes against schemas, SAIDs, and cryptographic signatures.

Revocation Phase: When credentials are revoked, the attributes become invalid. The TEL records the revocation event, and verifiers checking credential status will discover the attributes are no longer trustworthy.

Related Structures

Attributes interact with several related ACDC structures:

Schema Section (s): Defines the structure and validation rules for attributes. The schema SAID in the ACDC references a JSON Schema document that specifies required attributes, types, and constraints.

Edge Section (e): May reference attributes from other credentials. For example, an OOR credential's edge section references the Legal Entity credential, creating a verifiable chain where the OOR attributes depend on the LE attributes.

Rule Section (r): Contains legal disclaimers and usage terms that govern how attributes may be used. Rules may specify that certain attributes are confidential or subject to chain-link confidentiality.

Selective Attribute Section (A): A separate top-level section for attributes that support selective disclosure. These attributes are structured as arrays or aggregates where individual elements can be disclosed independently.

Advanced Attribute Patterns

Nested Attributes

Attributes may contain nested field maps for complex data structures:

{
  "d": "ELGgI0fkloqKWREXgqUfgS0bJybP1LChxCO3sqPSFHCj",
  "i": "EpDA1n-WiBA0A8YOqnKrB-wWQYYC49i5zY_qrIZIicQg",
  "dt": "2024-01-15T09:30:00.000000+00:00",
  "personal": {
    "legalName": "John Smith",
    "dateOfBirth": "1980-05-15",
    "nationality": "US"
  },
  "contact": {
    "email": "[email protected]",
    "phone": "+1-555-0123"
  }
}

Nested structures enable logical grouping of related attributes while maintaining a single attribute block SAID for the entire structure.

Attribute Arrays

Attributes may include arrays for multi-valued properties:

{
  "d": "ELGgI0fkloqKWREXgqUfgS0bJybP1LChxCO3sqPSFHCj",
  "i": "EpDA1n-WiBA0A8YOqnKrB-wWQYYC49i5zY_qrIZIicQg",
  "dt": "2024-01-15T09:30:00.000000+00:00",
  "roles": [
    "Chief Executive Officer",
    "Board Director"
  ],
  "certifications": [
    "ISO 27001",
    "SOC 2 Type II"
  ]
}

Array-based attributes enable representation of multiple values for a single property type.

Attribute References

Attributes may reference external data via SAIDs:

{
  "d": "ELGgI0fkloqKWREXgqUfgS0bJybP1LChxCO3sqPSFHCj",
  "i": "EpDA1n-WiBA0A8YOqnKrB-wWQYYC49i5zY_qrIZIicQg",
  "dt": "2024-01-15T09:30:00.000000+00:00",
  "documentSAID": "EBfdlu8R27Fbx-ehrqwImnK-8Cm79sqbAQ4MmvEAYqao",
  "imageSAID": "ENPXp1vQzRF6JwIuS-mp2U8Uf1MoADoP_GqQ62VsDZWY"
}

This pattern enables attributes to reference large data objects without embedding them directly, keeping credential size manageable.

Privacy and Security Considerations

Selective Disclosure

The attribute structure supports privacy-preserving disclosure patterns:

Compact Disclosure: Share only the attribute block SAID, revealing structure but not values. Verifiers can confirm the credential exists and is properly formed without learning attribute values.

Partial Disclosure: Share some attributes while keeping others compact. For example, disclose dt and LEI but keep personal information compact.

Graduated Disclosure: Progressively reveal attributes as trust develops. Initial interactions use compact disclosure, later interactions reveal more attributes after contractual protections are established.

Correlation Resistance

Attribute design impacts correlation resistance:

Unique Identifiers: Attributes containing unique identifiers (LEI, email, phone) enable correlation across presentations. Holders should be aware that disclosing such attributes links presentations.

Blinded Attributes: The ACDC specification supports blinded attributes using UUIDs as salty nonces. These attributes can be disclosed without enabling correlation to other presentations of the same credential.

Selective Attribute Aggregates: The A section enables selective disclosure of individual attributes from a set, where disclosed attributes are not correlatable to undisclosed attributes from the same set.

Attribute Integrity

Several mechanisms ensure attribute integrity:

SAID Binding: The attribute block SAID cryptographically binds all attributes together. Any modification to any attribute invalidates the SAID.

ACDC SAID Binding: The ACDC SAID includes the attribute block SAID, creating a chain of cryptographic commitments from the issuer's signature through the ACDC SAID to the attribute block SAID to individual attribute values.

Schema Validation: JSON Schema validation ensures attributes conform to expected structure and constraints, preventing malformed or invalid attribute data.

Immutability: Attributes cannot be modified after issuance, preventing tampering or unauthorized updates.

Implementation Best Practices

Schema Design

When designing attribute schemas:

1. Minimize Required Fields: Only mark fields as required if they are truly essential. Optional fields provide flexibility for different use cases.

2. Use Concise Labels: Short field labels reduce credential size. Use i instead of issuer, dt instead of datetime.

3. Define Clear Constraints: Use JSON Schema constraints (regex, enum, min/max) to validate attribute values and prevent invalid data.

4. Version Schemas: When schemas evolve, create new schema versions with new SAIDs rather than modifying existing schemas.

5. Document Field Semantics: Provide clear documentation of what each attribute field means and how it should be used.

Attribute Population

When populating attributes:

1. Validate Input Data: Validate all input data against schema constraints before creating attributes.

2. Preserve Field Order: Maintain consistent field ordering across all credential instances of the same type.

3. Use Standard Formats: Use ISO standards for dates (ISO 8601), identifiers (ISO 17442 for LEI), and other common data types.

4. Minimize PII: Only include personally identifiable information when necessary. Consider using references (SAIDs) to external data instead of embedding PII directly.

5. Test SAID Computation: Verify SAID computation produces consistent results across different implementations and serialization libraries.

Disclosure Strategy

When disclosing attributes:

1. Start Compact: Begin with compact disclosure to minimize information leakage.

2. Establish Contracts: Use contractually-protected disclosure to establish legal protections before revealing sensitive attributes.

3. Disclose Progressively: Reveal attributes incrementally as trust develops and requirements are met.

4. Consider Correlation: Be aware that disclosing unique identifiers enables correlation across presentations.

5. Verify Verifier: Authenticate the verifier before disclosing sensitive attributes to ensure you're sharing with the intended party.

Caching: Cache computed SAIDs to avoid redundant digest computation. SAIDs are deterministic and can be safely cached.

Lazy Expansion: Implement lazy expansion of compact attributes - only deserialize and expand attribute blocks when actually needed for verification or disclosure.

Error Handling

SAID Mismatch: If computed SAID doesn't match the d field value, the attribute block has been tampered with or incorrectly serialized. Reject the credential immediately.

Schema Validation Failure: If attributes don't conform to schema, the credential is malformed. Log the specific validation errors for debugging.

Missing Required Fields: If required attributes are missing, the credential is invalid. Don't attempt to use or verify credentials with incomplete attributes.

Testing Requirements

Round-Trip Testing: Verify that attributes can be serialized, SAID-computed, deserialized, and re-serialized producing identical results.

Cross-Implementation Testing: Test SAID computation across different programming languages and libraries to ensure consistent results.

Schema Compliance Testing: Create comprehensive test suites validating all schema constraints, including edge cases and boundary conditions.