- From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
- Date: Tue, 7 Apr 2026 02:13:10 +0000
- To: Manu Sporny <msporny@digitalbazaar.com>, Credentials Community Group <public-credentials@w3.org>
- Message-ID: <IA3PR13MB7541C20175840C0AB5B2E3B9C35AA@IA3PR13MB7541.namprd13.prod.outlook.com>
A simpler name (and concept) is Long Term Memory (LTM)... [cid:image001.jpg@01DCC601.C887EB50] Michael Herman Chief Digital Officer Web 7.0 Foundation -----Original Message----- From: Manu Sporny <msporny@digitalbazaar.com> Sent: Monday, April 6, 2026 10:38 AM To: Credentials Community Group <public-credentials@w3.org> Subject: Re: Proposal for a new CCG Work Item - Wallet Attached Storage (WAS) DB is supportive of a work item in the vein of Wallet Attached Storage and sees it as a good starting point. Some thoughts, which are not necessary to address before adoption of the work item: * The first half of the spec is good -- strong alignment with the goal (we need easier interfaces than EDVs for most Web Developers) * We'd like the solution to be more generalized (why focus on Wallets -- though that's an important use case) -- maybe something along the lines of "Coercion Resistant Storage" * We might want to see what S3 bucket / Google Drive / Dropbox APIs are doing today to see if those are a good model to follow (higher level interface than EDVs) Clearly, those are things for the work item group to discuss, but the answers there would help us understand our level of interest. To summarize: +1 for monthly ZCAP calls to start. +1 for monthly EDV calls to start. +1 for exploration work on WAS. Perhaps we can wrap all of those into a single monthly call as they're meant to be a part of some sort of self-sovereign / coercion-resistant storage. -- manu On Thu, Apr 2, 2026 at 4:57 AM Amir Hameed <amsaalegal@gmail.com<mailto:amsaalegal@gmail.com>> wrote: > > Hi Dmitri, > > This is a very good proposal. A standardized backend for wallet storage is a critical piece of infrastructure that I have experienced fragmented for too long. I see strong potential for WAS to evolve into a transport-agnostic protocol. Moving beyond purely HTTP/HTTPS—toward models such as DIDComm or other peer-to-peer approaches—would be important for supporting offline-first and edge environments. > > Keeping the core specification minimal while enabling modular extensions as implementations mature feels like the right direction. > > I’m happy to express support for adopting WAS as a CCG work item. > > > Best, > > Amir > > > > > On Thu, 2 Apr 2026 at 6:13 AM, Dmitri Zagidulin <dzagidulin@gmail.com<mailto:dzagidulin@gmail.com>> wrote: >> >> Hi all, >> >> Over the past year or so, the Digital Credentials Consortium (DCC) team at MIT Open Learning, along with colleagues from the RIPL/Arkansas Launch project (led by Judson Neer), as well as several others (big shoutout to Benjamin Goering for all his hard work on the spec and implementations), has been working on a storage protocol and data model useful for verifiable credential wallets and other adjacent systems. >> And I think the CCG might find it useful, since it builds on several CCG-incubated specifications (DIDs, zCaps, secure storage of Verifiable Credentials, and is meant to work with Encrypted Data Vaults to provide optional end-to-end encryption). >> >> The current working name for the spec is WAS (Wallet Attached Storage); some other names that have been bandied about included Web Spaces API, or Agentic Storage API. >> >> It's basically an HTTP REST API that's meant to be a general purpose front end for any kind of permissioned storage. It uses a familiar three tiered data model -- Spaces (equivalent to a disk drive partition, a cloud storage workspace, or a relational database), Collections (equivalent to a file system directory, folder, object storage Bucket, or database table), and Resources (any data item you'd want to read and write, from structured JSON documents to images or binary blobs). >> Reads, writes, and collections listings are modeled with HTTP CRUD verbs. And zCaps are used for DID-based authorization (not authentication :) ). >> >> It's particularly useful to serve as a general purpose standardized back end for Verifiable Credential wallets, but can also be used for any sort of permissioned AI agent storage, or as a component to user-centric "Bring Your Own Storage" type of apps. >> >> Some links: >> * DCC Blog post: >> https://blog.dcconsortium.org/what-is-wallet-attached-storage-439917b >> a4fa5 >> * Poster at ePIC2025 in Paris: >> https://drive.google.com/file/d/16rd2WpYHvjwHhCiXyl26XtO2dSsXyGON/vie >> w >> * WAS Specification: >> https://digitalcredentials.github.io/wallet-attached-storage-spec/ >> >> The DCC team would be very interested in collaborating on this spec and donating it to the CCG. Several members of the community (including Phil Long and several others) have expressed preliminary interest in collaborating. >> >> As always, though, for a spec to be adopted as a CCG work item, we need at least one more party to formally express interest / support for this work. Hence the question to the group -- is this something that would be of interest to the community? >> >> (Happy to answer any questions of course.) >> >> Dmitri >> -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. https://www.digitalbazaar.com/
Attachments
- image/jpeg attachment: image001.jpg
Received on Tuesday, 7 April 2026 02:13:20 UTC