Re: Proposal for a new CCG Work Item - Wallet Attached Storage (WAS)

Hi Jesse! :)

I figured Solid / LWS would come up! As you know, I'm a big fan of the
Solid project, wrote the first versions of the solid-auth spec, etc. And I
try to participate in the LWS Working Group whenever I can. I think the
Solid Project experience has a lot to teach this space, and that goes for
any project that has anything to do with storage!

I look at Wallet Attached Storage as basically a simplified, constrained
profile of LWS aimed at ease of developer understanding, and building on
the lessons from Solid.
Like LWS/Solid, WAS has a three-tier logical organization of data
(Space/Collection/Resource to LWS's Storage/Container/Resource). Also
shares the 'linkset' mechanism for metadata (partly because Bengo and I
campaigned for it in LWS WG ;) ).

There's a few differences and constraints, too. Unlike LWS/Solid, WAS does
not allow nested containers -- flat single tier of collections only. The
usecases that Solid generally solves with nested containers, such as
parent-child relationships, WAS aims to solve with just querying across
collections. (Things like "give me all the Comments from the /comments/
collection that have a parent_id that link them to this blog Post".)
WAS aims for multi-modal multi-backend storage, for storing binary blobs,
files and folders, CouchDB-like JSON documents, RDBMS rows, graphs, etc.
It's also designed with provisions for optional multi-primary replication,
different backend storage engines per collection, versioning and conflict
resolution, and client-side encryption. (On the encryption front, it uses
CCG Encrypted Data Vaults -- in fact, API wise, EDVs are basically a
constrained version of WAS, although EDVs precede it by a number of years.
Very similar design though.)

And perhaps the biggest conceptual difference is that WAS explicitly has no
authentication (on purpose), but only an authorization layer based on
primarily zCaps (Authorization Capabilities) but also some policies where
it's necessary.

Heck, I would love to bring the WAS spec to the Linked Web Storage WG, but
I know that the current WG is very tightly scoped and there likely isn't
time for something like WAS before its charter expires.

In any case, I suspect the LWS WG and whatever the CCG taskforce that
handles zCaps and WAS ends up being named, will have a lot of
cross-pollination. And maybe the CCG can incubate some useful specs that
the LWS WG can find useful for the next charter.

Cheers,

Dmitri


On Tue, Apr 7, 2026 at 9:12 AM Jesse Wright <jesse.wright@jesus.ox.ac.uk>
wrote:

> Solid <https://solidproject.org/> (W3C Community Group) and Linked Web
> Storage <https://www.w3.org/groups/wg/lws/> (W3C Working Group) also aim
> to provide a standard storage location for the Web and are often used to
> store digital credentials.
>
> SHARCS <https://www.imec-int.com/en/research-portfolio/sharcs> is an
> example application where Solid has been applied to store digital
> credentials.
>
> There is also a recording
> <http://Hi%20all,%20here%20you%20can%20find%20the%20second%20version%20of%20the%20video.%20Have%20a%20nice%20day!%20https://www.youtube.com/watch?v=sXwZXWMuymM> of
> a demo
> <http://figma.com/proto/WJp0VcDHvfeUONnZUodarJ/Personal-Data-Store--PDS--design-examples---template--Community-?node-id=1-5&p=f&t=bJTVz0ue36JfgLji-0&scaling=scale-down&content-scaling=fixed&page-id=1%3A5&starting-point-node-id=67%3A42597> showcasing
> the UX that the Solid community is working towards for both Web
> applications, and agentic systems. The demo includes storage and sharing of
> digital credentials.
>
> Best,
>
> *Jesse Wright (he/him)*
> *Project Lead, **Solid
> <https://theodi.org/news-and-events/news/odi-and-solid-come-together-to-give-individuals-greater-control-over-personal-data/>*
>
> *From: *Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
> *Date: *Tuesday, 7 April 2026 at 03:14
> *To: *Manu Sporny <msporny@digitalbazaar.com>, Credentials Community
> Group <public-credentials@w3.org>
> *Subject: *RE: Proposal for a new CCG Work Item - Wallet Attached Storage
> (WAS)
>
> A simpler name (and concept) is *Long Term Memory (LTM)*...
>
>
>
>
>
> 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> 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>
> 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/
>
>
>