notes: events/talks/kericonf26-d2-05-rayback-did-webs

This data as json

path title type status classification words body
events/talks/kericonf26-d2-05-rayback-did-webs Jonathan Rayback: KERI Bridge to the DID World (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 759 # Jonathan Rayback: KERI Bridge to the DID World (KERIConf 2026) **Abstract.** Jonathan Rayback, co-chair of the did:webs task force in the KERI Stack Working Group at Trust over IP and chair of the DID Methods Working Group at the Decentralized Identity Foundation (DIF), explained the did:webs method, which brings KERI (Key Event Receipt Infrastructure) into the family of web-based DID (decentralized identifier) methods. He covered DIDs in general, did:keri, did:web, what did:webs adds, its specification status, and a short demonstration. The talk assumed familiarity with KERI but not with DIDs. ## Summary Rayback introduced himself and his co-chair Kent Bull, then described DIDs as a W3C (World Wide Web Consortium) recommendation: a URI (uniform resource identifier) that resolves to a DID document listing keys, verification methods and services. Each DID method defines its own identifier format and how to create, resolve, update and deactivate DIDs; there are hundreds of methods, many tied to blockchains and a few to the web. He noted that did:keri exists but its specification is an early, largely unfilled draft from before OOBIs (out-of-band introductions), and says nothing about how to discover the KEL (Key Event Log), which limits its practical use. did:web, an unofficial W3C draft used in production, resolves by turning the identifier into a web address (URL, uniform resource locator) and fetching a did.json file. It has no key history and is exposed to web attacks such as DNS (Domain Name System) hijacking. An audience member who co-created did:web said it was meant as training wheels and that proposals to add key history were declined. did:webs separates discovery from verification: the web is used to find the DID document, and verification comes from a KERI event stream served alongside it as a keri.cesr file in CESR (Composable Event Streaming Representation). The identifier looks like a did:web with the controller's AID (autonomic identifier) as its last segment, and the stream must begin with that AID's inception event. In did:webs the DID document is always derived from the event stream, the reverse of methods such as did:webvh, where the document's history produces the verifiable record. Because it is KERI-based, did:webs supports multi-signature, AID delegation, and KERI services such as witnesses, agents, mailboxes and OOBI endpoints. A distinctive requirement is that the controller must authorize the host and path in its identifier with an ACDC (Authentic Chained Data Container), so every did:webs event stream includes at least one ACDC. Kent Bull added that he had once tried to define a KEL-only version but concluded the explicit authorization was needed for security. Rayback contrasted this with the implicit authorization in did:webvh and said long-lived identifiers that move between hosts are simpler to manage in did:webs. He walked through required alsoKnownAs entries (always including the did:keri form, and optionally an authorized did:web), verification methods, parameters such as versionId, equivalentId in the metadata, and the ConditionalProof2022 type used to express multi-signature thresholds. On status, a final draft is under review in the KERI Stack Working Group, an IANA (Internet Assigned Numbers Authority) media type is registered, and the method is in final review to become a DIF recommended method. The demonstration created an AID, issued the authorizing ACDC, generated simple and multi-signature DID documents, and resolved a did:webs DID through the Universal Resolver, using a driver written by Kent Bull, and through a command-line fetch of the annotated event stream. ## Key terms DID, DID document, DID method, did:keri, did:web, did:webs, did:webvh, KERI event stream, keri.cesr, designated aliases, alsoKnownAs, equivalentId, ConditionalProof2022 ## Claims and their evidence - A did:webs DID document is always derived from the KERI event stream, never written by hand. [informative] - A valid did:webs requires an ACDC from the controller authorizing the host and path information in the identifier. [normative] - If a did:webs document includes verification relationships, each published key must be authorized for both authentication and assertion. [normative] - did:webs is the only web-based DID method that lets a verifier confirm the controller explicitly authorized the hosting location. [presenter-reported] - did:webs has a final draft under review at Trust over IP, a registered IANA media type, and is in final review as a DIF recommended method. [presenter-reported] ## Related W3C DID Core 1.0, did:web (W3C draft), did:keri, did:webs specification (KERI Stack Working Group, Trust over IP), did:webvh, did:iota, ConditionalProof2022, Universal Resolver, KERI, ACDC and CESR specifications ## Provenance Drafted by Claude on 2026-10-15 from the curated transcript (d2-05-jonathan-rayback-keri-bridge-to-the-did-world.md), all minutes read; a few audience exchanges and the demonstration narration are partly inaudible. No quotations; paraphrase only. Not yet read by Mark.

Links from other tables