notes: events/talks/kericonf26-d2-09-ned-smith-secure-asset-transfer-protocol

This data as json

path title type status classification words body
events/talks/kericonf26-d2-09-ned-smith-secure-asset-transfer-protocol Ned Smith: Secure Asset Transfer Protocol (KERIConf 2026) summary v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation partner 830 # Ned Smith: Secure Asset Transfer Protocol (KERIConf 2026) **Abstract.** Ned Smith, a security engineer and participant in the IETF (Internet Engineering Task Force), gave an overview of SATP (Secure Asset Transfer Protocol), developed by the IETF Secure Asset Transfer working group, and of where KERI (Key Event Receipt Infrastructure), ACDC (Authentic Chained Data Containers) and the vLEI (verifiable Legal Entity Identifier) could fit into it. He covered the protocol's entities and stages, its current standards status, the rechartering to define stage 0, and hardware attestation. The talk is for KERI practitioners interested in contributing to the standard while its open parts are still being defined. ## Summary Smith introduced himself as a long-time security engineer, formerly at Intel, and placed the Secure Asset Transfer working group in the IETF's Applications and Real-Time area. He walked through the working group's canonical use case, built around an asset reference token: an issuer declares an asset to an artifacts registry, mints a token with an on-chain value part and off-chain context data, and a gateway reads the token, validates the context data, and transfers the asset to another network. The protocol's entities are the originator and beneficiary, the gateways that form the protocol's endpoints, asset networks or oracles, the orchestrating user application, a host owner he named to capture legal responsibility, and the artifacts registry, which keeps transfer context and the audit trail. The architecture aims at an atomic two-phase commit with no shared trusted third party and requires versioning, rollback and provenance for tokenized and non-tokenized assets. He observed that the drafts implicitly assume X.509 certificates, although no normative text requires them, which makes integrating KERI an uphill effort. He sketched how vLEI roles could map onto the architecture: GLEIF (the Global Legal Entity Identifier Foundation), QVIs (Qualified vLEI Issuers) and LOUs (Local Operating Units), with OOR (official organizational role) and ECR (engagement context role) credentials for those legally responsible for an asset. Hosts are devices, which the LEI system has no credential for, so a certificate, a DID (decentralized identifier) or a KERI KEL (Key Event Log) could serve. Stages 1 to 3 cover the transfer proposal and its transfer claim, a coarse lock, and a two-phase commit that mints the asset on the receiving side and burns it on the sending side. Several fields in the transfer claim, such as the transfer context identifier, are undefined placeholders. His draft on binding SATP to the vLEI proposes values for these fields and IANA (Internet Assigned Numbers Authority) media types for CESR (Composable Event Streaming Representation) payloads. Stages 1 to 3 are near working group last call, after which they go to the area directors and the IESG (Internet Engineering Steering Group) toward RFC (Request for Comments) status. The group is rechartering to define stage 0: the transfer context identifier, asset identification and ownership, authorization to transfer, travel rule data, gateway ownership and mutual attestation. He likened stage 0 to an inception event, noted that registries on each side need not be the same, and listed the registry properties under discussion, starting with append-only and replicable. Looking ahead, he described trusted platform hardware and confidential computing for gateways, the DICE (Device Identifier Composition Engine) hardware root of trust he helped specify, and attestation evidence written to the registry for use by actuaries assessing risk. He proposed three KERI-aware opportunities: KERI-enabled trusted platforms, artifacts registries built on ACDC and the registrar and observer pattern from Samuel M. Smith's talk, and vLEI-based provisioning of SATP hosts. In questions he said the working group has not weighed X.509's weaknesses and that stage 0 is the moment to engage. The transcript ends mid-answer. ## Key terms SATP, asset reference token, gateway, originator and beneficiary, artifacts registry, transfer context identifier, two-phase commit, stage 0, vLEI binding, attestation, DICE ## Claims and their evidence - The SATP drafts carry an implicit assumption of X.509 certificates, with no normative text requiring them. [presenter-reported] - Stages 1 to 3 of SATP are close to working group last call, and the working group is rechartering to define stage 0. [presenter-reported] - SATP stage 3 completes a transfer by minting the asset in the beneficiary's domain and burning it in the originator's. [informative] - Each side may keep its own artifacts registry; the protocol keeps their contents consistent without a shared trusted third party. [presenter-reported] - Major silicon vendors and bodies such as the TCG (Trusted Computing Group) and OCP (Open Compute Project) have adopted DICE as a hardware root of trust. [presenter-reported] ## Related IETF SATP architecture and protocol drafts, Ned Smith's SATP vLEI binding draft, vLEI ecosystem governance framework, CESR, DICE specifications, Samuel M. Smith's KERIConf 2026 talks on registries and the future of KERI, KERIpy ## Provenance Drafted by Claude on 2026-10-15 from the curated transcript (d2-09-ned-smith-secure-asset-transfer-protocol.md), all minutes read; the transcript stops abruptly at about 39:40, mid-answer in the question period (its header gives the duration as 36:50). No quotations; paraphrase only. Not yet read by Mark.

Links from other tables