selfdriven-digital-interaction-framework

Files (1)

• SKILL.md

SKILL.md (first lines)

# selfdriven Digital Interaction Framework

Build interactive info sites, documentation, diagrams, and reference materials based on the selfdriven Digital Interaction Framework — a layered trust architecture for self-sovereign digital relationships.

## Overview

The Digital Interaction Framework defines how verifiable digital relationships are established, maintained, and dissolved using KERI/ACDC cryptographic infrastructure. It organises trust into five interdependent layers, a six-stage relationship lifecycle, a tiered agent network, a governance model with Architecture Decision Records, and four interconnected policy domains.

This skill should be used alongside the `selfdriven-ecosystem` skill which provides the brand system, design tokens, typography, and visual language. This skill provides the **conceptual framework and content model**.

### Trigger Contexts

Consult this skill for any mention of:
- Trust layers, layered trust model, or the five-layer stack
- Digital interaction types: transactional vs interactional
- Relationship lifecycle stages: discovering, co-creating, proposing, using, updating, archiving
- Trust assurance concepts: fidelity, confidence, provenance, risk calibration
- Agent network, trust tiers (Tier 1 direct, Tier 2 shared), teammate/dependable nodes
- Policy stacks: technical, financial, human, agent policy domains
- Agent autonomy levels (L1–L5)
- Architecture Decision Records (ADRs) for selfdriven identity infrastructure
- Policy domain interaction matrices
- The Digital Interaction Framework as a reference or citation

## Five-Layer Trust Model

Every digital interaction rests on a stack of interdependent layers. Each layer builds assurance and reduces risk for the layers above. Layers are numbered bottom-up (01 = foundation, 05 = surface).

### Layer 01 — Policy Stacks (Foundation)

The most stable layer, changing infrequently. Four interconnected policy domains:

| Domain | Scope | Key Elements |
|--------|-------|-------------|
| Technical | Infrastructure & security | Ed25519 signing, X25519 exchange, AES-256-GCM at rest, TLS 1.3 in transit, HSM key storage, 2-of-3 witness topology, OpenAPI 3.1 contracts, 7yr audit retention |
| Financial | Economic & regulatory | Transaction limits, velocity controls, NPP/BPAY/SWIFT settlement, AUSTRAC AML/CTF, APRA CPS 234, CDR consent, cross-border governance |
| Human | Conduct & privacy | Conductor 70/30 model, role-to-credential access mapping, graduated disclosure, OAIC compliance, escalation authority chains, consent management |
| Agent | Delegation & autonomy | Action whitelists, 24h default time limits, all ixn logged, anomaly/threshold escalation, ACDC-gated access, A2A protocol rules, L1–L5 classification |

**Policy Domain Interactions** — strong dependencies exist between: Technical ↔ Agent (infra constrains agent capability), Financial ↔ Human (limits constrain decisions), Human ↔ Agent (conductors set agent boundaries), Technical ↔ Financial (protocols enable compliance).

### Layer 02 — Governance

Rules, structures, and oversight that shape how technology is deployed.

- **KEL Governance**: Witness thresholds (2-of-3 default), rotation policies, delegation rules via `dip` events
- **Credential Governance**: ACDC issuance rules, revocation policies, schema management, trust chain requirements
- **Organisational Rules**: Human Conductor oversight, 8 Areas of Focus alignment, decision authority matrices
- **Delegation Framework**: AI agent delegation via `dip` — scope boundaries, time limits, escalation triggers, human-in-the-loop checkpoints

### Layer 03 — Technology

The cryptographic substrate. Eight technology domains, each with specific detail:

| Domain | Detail |
|--------|--------|
| AuthN / AuthZ | FIDO2/WebAuthn passkeys bound to KERI AIDs via `ixn`. ACDC-derived authorisation scopes. Passkey public key anchored to AID via ixn event. |
| Protocols | KERI events (`icp`, `rot`, `ixn`, `dip`, `drt`), OOBI discovery, A2A agent-to-agent communication |
| Encryption | AES-256-GCM at rest, TLS 1.3 in transit, X25519 end-to-end agent messages |
| Cryptology | Ed25519 signing, X25519 key exchange, SHA-256 event digests, SHA-512/HKDF key derivation |
| Privacy | ACDC graduated disclosure, selective correlation control, protocol-level data minimisation |
| Path History | Complete identifier traversal record, ixn sequence gap detection, forensic KEL replay |
| Key Management | Mandatory pre-rotation, HSM integration for high-value AIDs, M-of-N multi-sig thresholds |
| Witness Network | 2-of-3 default (high-value: 3-of-5), geographic distribution across 2+ AZs, watcher duplicity detection |

### Layer 04 — Trust & Assurance

Establishing the level of risk tolerance for each interaction:

- **Fidelity**: Signal integrity via cryptographic anchoring and witness corroboration. Degraded fidelity triggers re-verification.
- **Confidence**: Certainty built through credential verification, reputation, and historical track record across the lifecycle.
- **Provenance**: Chain of custody via KEL event logs and ACDC credential chains. Gaps reduce confidence scores.
- **Risk Calibration**: Transactional interactions accept lower fidelity thresholds; interactional relationships demand progressive trust accumulation.

### Layer 05 — Digital Interaction & Relationship (Surface)

The interaction itself — where value is exchanged:

- **Transactional** (Ephemeral): Short-lived, utility-focused. Bounded failure cost. Lifecycle: seconds to hours.
- **Interactional** (Enduring): Relationship-building across shared domains. Trust compounds over time. Lifecycle: days to years.
- **Shared Context**: Enterprise Workflow Model links interaction purpose to organisational function.
- **Activity Binding**: Each interaction scoped to a specific activity with defined inputs, outputs, and success criteria.

### Layer Comparison Reference

| Layer | Rate of Change | Primary Actor | KERI Primitive | Failure Mode |
|-------|---------------|---------------|----------------|-------------|
| 05 — Interaction | Per-exchange | Both parties | `ixn` | Context mismatch, scope creep |
| 04 — Trust | Progressive | Verifier | ACDC chain | Fidelity degradation, confidence erosion |
| 03 — Technology | On rotation | Infrastructure | `icp`, `rot` | Key compromise, witness failure |
| 02 — Governance | Periodic | Human Conductor | `dip`, rules | Authority gap, escalation failure |
| 01 — Policy | Infrequent | Foundation | ADR | Regulatory non-compliance |

## Relationship Lifecycle

Six stages from discovery to dissolution. Each stage maps to specific KERI primitives and trust requirements.

### Stage 1 — Discovering

- AIDs published to discovery registries; watchers monitor for matching identifiers
- ACDC schema-based capability matching connects seekers with providers
- Zero trust: all claims unverified until co-creation begins
- **KERI actions**: `icp` → AID genesis, `ACDC` → capability publish, `oobi` → endpoint discovery

### Stage 2 — Co-Creating

- Bilateral credential exchange: each party presents ACDC claims, other verifies against issuer KEL
- Shared domain, purpose, and activity scope established
- Initial trust seeded through credential verification; history begins accumulating
- **KERI actions**: `ixn` → context binding, `ACDC` → credential present, `TEL` → issuance verify

### Stage 3 — Proposing

- Interaction terms encoded as ACDC credential schemas
- Governance agreements: dispute resolution, escalation paths, credential refresh cadence, rotation expectations
- If agents will operate: `dip` events establish delegated AIDs with scoped authority
- **KERI actions**: `dip` → agent delegation, `ACDC` → terms credential, `ixn` → agreement anchor

### Stage 4 — Using

From selfdriven-octo/skillzeb, CC0-1.0.

More from selfdriven-octo/skillzeb