{
  "r": "EG71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB"
}

Full Form: The rules field contains the complete rules object with its own SAID:

{
  "r": {
    "d": "EG71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB",
    "usageDisclaimer": "Legal language governing credential usage...",
    "issuanceDisclaimer": "Legal language about issuance conditions..."
  }
}

This dual representation enables selective disclosure patterns where:

• Initial presentations can show only the rules SAID (compact form)
• Full disclosure reveals the actual legal text
• The SAID provides cryptographic commitment to the rules content regardless of which form is presented

Key Components

The rules section typically contains several types of legal clauses:

Usage Disclaimers: Define how the credential may be used, what it does and does not assert, and limitations on reliance. For example, vLEI credentials include disclaimers stating that possession of a valid credential does not assert trustworthiness or legal compliance of the holder.

Issuance Disclaimers: Describe the conditions under which the credential was issued, the verification processes performed, and the issuer's liability limitations. These often include statements about accuracy as of the validation date and reasonable care in the validation process.

Privacy Policies: May include terms governing how disclosed information can be used, stored, or shared by the recipient. These support chain-link confidentiality mechanisms where usage restrictions propagate through credential presentations.

Revocation Terms: Can specify conditions under which credentials may be revoked and the obligations of parties when revocation occurs.

Jurisdiction and Dispute Resolution: May specify applicable law, venue for disputes, and arbitration procedures.

Data Format

Field Definitions

The rules section is identified by the field label 'r' at the top level of an ACDC. The value can be:

1. String (Compact): A SAID referencing the rules block
2. Object (Full): A field map containing:
   • 'd': The SAID of the rules block itself
   • Additional fields: Named clauses containing legal text or structured policy data

Common field names in vLEI credentials include:

• usageDisclaimer: Terms governing credential usage
• issuanceDisclaimer: Terms about credential issuance
• privacyPolicy: Data handling requirements
• liabilityLimitation: Scope of issuer liability

Encoding Format

Rules sections follow standard ACDC encoding requirements:

Serialization: Must support JSON, CBOR, and MGPK serializations with insertion-ordered field maps to ensure deterministic SAID computation.

SAID Generation: The rules block SAID is computed by:

1. Serializing the rules object with the 'd' field set to a placeholder (typically '#' characters of the appropriate length)
2. Computing the cryptographic digest (typically Blake3-256)
3. Encoding the digest using CESR with appropriate derivation code
4. Replacing the placeholder with the computed SAID

Text Encoding: Legal text within rules fields uses standard JSON string encoding with Unicode support for internationalization.

Size and Constraints

Rules sections have no fixed size limits but practical considerations include:

Compactness: While legal text can be verbose, credential designers should balance completeness with transmission efficiency. Typical vLEI rules sections range from a few hundred to a few thousand characters.

Immutability: Once a rules SAID is embedded in a credential and signed by the issuer, the rules content is cryptographically fixed. Any change to the rules text produces a different SAID, making tampering evident.

Schema Validation: Rules sections must conform to the credential's JSON Schema, which may specify:

• Required vs. optional rule fields
• Allowed field names
• Text format constraints
• Maximum lengths for specific clauses

Operations

Creation and Initialization

Rules sections are created during credential schema design and populated during credential issuance:

Schema Design Phase:

1. Legal experts draft contractual language appropriate for the credential type
2. Schema designers structure the language into named fields
3. The schema specifies whether rules are required and which fields must be present
4. The schema may use const constraints to enforce specific legal text

Credential Issuance Phase:

1. The issuer populates the rules section with appropriate legal text
2. The rules block SAID is computed
3. The issuer decides whether to issue in compact or full form
4. The issuer signs the credential, creating a cryptographic commitment to the rules

Updates and Modifications

Rules sections are immutable once issued due to SAID binding:

No In-Place Updates: The rules content cannot be modified after issuance without invalidating the credential signature.

Version Management: If rules need to change:

• A new credential schema version is created with updated rules
• New credentials are issued under the new schema
• Old credentials remain valid with their original rules until expiration or revocation

Disclosure Transitions: A credential can transition from compact to full disclosure:

• Initial presentation shows only the rules SAID
• Subsequent disclosure reveals the full rules text
• The SAID proves the full text matches the original commitment

Verification and Validation

Verifiers must validate rules sections through multiple checks:

SAID Verification:

1. If presented in full form, recompute the rules block SAID
2. Verify it matches the SAID in the 'd' field
3. Verify the rules SAID matches any compact reference in parent structures

Schema Compliance:

1. Validate the rules structure against the credential schema
2. Verify required fields are present
3. Check that field values match schema constraints (e.g., const values)

Legal Review:

1. Human review of legal text for acceptability
2. Verification that terms are consistent with verifier policies
3. Assessment of liability and usage restrictions

Policy Enforcement:

1. Machine-readable policy elements are extracted
2. Automated systems enforce usage restrictions
3. Audit logs track compliance with contractual terms

Usage Context

In Which Protocols

Rules sections are used across the KERI/ACDC protocol stack:

ACDC Specification: Defines the rules section as an optional top-level field in all ACDCs, enabling any credential type to carry contractual terms.

IPEX Protocol: The Issuance and Presentation Exchange protocol supports contractually protected disclosure, where rules sections establish the legal framework for graduated disclosure:

• Schema disclosure precedes data disclosure
• Rules disclosure establishes contractual obligations before sensitive data is shared
• Recipients must agree to terms before receiving full credential content

vLEI Ecosystem: Rules sections are mandatory in vLEI credentials:

• QVI credentials include rules about authorization scope
• Legal Entity credentials include rules about organizational identity assertions
• OOR and ECR credentials include rules about role representation

CESR-Proof Format: When credentials are signed using CESR Proof Signatures, the rules section is included in the signed content, ensuring non-repudiable commitment to the contractual terms.

Lifecycle Management

Rules sections participate in the full credential lifecycle:

Issuance: Rules are embedded during credential creation and become part of the signed commitment.

Storage: Credentials may be stored in compact form (rules SAID only) to save space, with full rules retrievable from schema registries or issuer services.

Presentation: Holders choose whether to present rules in compact or full form based on:

• Verifier requirements
• Privacy considerations
• Contractual negotiation stage

Verification: Verifiers validate rules SAIDs and assess legal terms before accepting credentials.

Revocation: Rules may specify conditions triggering revocation and obligations when credentials are revoked.

Related Structures

Rules sections interact with other ACDC components:

Attributes Section ('a'): Rules govern how attribute data may be used, creating a binding between data and usage policy.

Edges Section ('e'): Rules can propagate through credential chains via edges, implementing chain-link confidentiality where usage restrictions flow from parent to child credentials.

Schema Section ('s'): The schema defines the structure and constraints for the rules section, potentially enforcing specific legal text through const constraints.

Registry ('ri'): Rules may reference credential registries for revocation checking, with contractual terms about revocation obligations.

Implementation Patterns

vLEI Implementation

The vLEI ecosystem provides concrete examples of rules section implementation:

QVI Credential Rules: Include disclaimers that valid credentials do not assert trustworthiness or legal compliance, and statements about accuracy as of validation date.

Legal Entity Credential Rules: Specify that the credential verifies LEI validity but does not assert business trustworthiness or regulatory compliance.

Role Credential Rules: Include privacy disclaimers specific to IPEX/ACDC presentation exchanges and limitations on role authority assertions.

Contractually Protected Disclosure

Rules sections enable sophisticated disclosure patterns:

Progressive Revelation:

1. Initial contact: Share credential schema (including rules schema)
2. Agreement phase: Share rules in full for review and acceptance
3. Data disclosure: Share attributes only after rules acceptance

Chain-Link Confidentiality:

1. Parent credential includes usage restrictions in rules
2. Child credential references parent via edge
3. Verifier must honor parent rules when processing child credential
4. Usage restrictions propagate through the credential chain

Machine-Readable Policy

While rules sections primarily contain human-readable legal text, they can include machine-readable policy elements:

Structured Policy Data: JSON objects within rules fields can encode:

• Allowed usage contexts
• Data retention periods
• Permitted disclosure recipients
• Required audit logging

Policy Enforcement: Automated systems can:

• Parse structured policy elements
• Enforce usage restrictions programmatically
• Generate compliance audit trails
• Trigger alerts on policy violations

Security Considerations

Cryptographic Binding

The rules section's security depends on SAID-based cryptographic binding:

Tamper Evidence: Any modification to rules text changes the SAID, making tampering immediately detectable.

Non-Repudiation: The issuer's signature on the credential creates a non-repudiable commitment to the rules content.

Integrity Verification: Verifiers can independently verify that rules content matches the SAID commitment.

Legal Enforceability

For rules sections to be legally enforceable:

Clear Language: Legal text must be unambiguous and understandable.

Mutual Agreement: Presentation exchange protocols should ensure recipients explicitly accept terms.

Jurisdiction: Rules should specify applicable law and dispute resolution mechanisms.

Record Keeping: All parties should maintain records of rules acceptance and credential presentations.

Privacy Protection

Rules sections support privacy through:

Compact Disclosure: Initial presentations can hide legal text while proving commitment via SAID.

Selective Revelation: Different rules clauses can be disclosed at different stages.

Usage Restrictions: Rules can limit how disclosed data may be used, stored, or shared.

Chain-Link Confidentiality: Usage restrictions propagate through credential chains, protecting data across multiple disclosure events.

Schema Validation: Validate rules structure against the credential schema before accepting credentials.

Policy Extraction: Implement parsers to extract machine-readable policy elements from rules sections for automated enforcement.

Audit Logging: Log all rules acceptances and credential presentations for compliance and dispute resolution.

Performance Optimization

Caching: Cache frequently used rules blocks to avoid repeated SAID computations and schema validations.

Lazy Loading: In compact form, defer loading full rules text until needed for presentation or verification.

Compression: Consider compressing rules text in storage while maintaining ability to reconstruct exact content for SAID verification.

Interoperability

Standard Clauses: Use standardized clause names (usageDisclaimer, issuanceDisclaimer, etc.) for interoperability across implementations.

Schema Registry: Publish schemas to registries so verifiers can retrieve full rules content from compact SAIDs.

IPEX Integration: Ensure rules sections work correctly with IPEX protocol flows for contractually protected disclosure.