Bloom donates WACI

A simple starting point for cross-stack Wallet-Credential Interactions

WACI = Wallet And Credential Interactions

WACI was introduced at the annual IIW32 Workshop, where it was received quite warmly as a step forward for open specification. Its goal is simple: to specify interactions between a wallet and a Relying Party (RP) such as an issuer or a verifier, in an ergonomic and agnostic way.

At its core, WACI can be thought of as a handshake using classic, industry-standard JWTs: the “Relying Party” signs a token given to the end-user’s wallet, and the wallet signs over a “challenge” contained within it, proving ownership of a DID.

From there, credentials can be issued or exchanged on the basis of the resulting channel. This channel can also double as a secure authentication, an application “log in” (for DID-based accounts), and a WACI is to offer a way to log into an application without a password with Verified Credential (VC) based authentication that cannot be faked.

Here’s lead editor Jace Henley giving a demo of Bloom’s sample implementation, demostrating the flows being specified further at DIF:

WACI at DIF

Bloom has been a core member of DIF’s Claims and Credentials WG for years, and a core contributor to many of its work items, which focus on specifying and standardizing protocols and libraries that create, exchange, and verify what the SSI community calls “[verifiable] credentials,” and what other sectors of the software industry call “claims” [about a subject]. In fact, WACI evolved out of the earlier, more foundational Presentation Exchange specification, and like its sister specification, the Credential Manifest, its primarily function is to extend the functionality of PE and create an onramp to adoption and implementation of it as a protocol. In a nutshell, Presentation Exchange’s scope ends at how the data is sent between the holder and issuer/verifier, which is where WACI’s begins.

WACI isn’t being donated as a snapshot or as a reference implementation of a finished protocol, however; it’s being donated as a starting point for an ongoing work item in C&C WG that will round out the spec to be more robust and flexible. A first application of this set of interactions is a complex interoperability exercise, developing an interoperability profile for quickly achieving tentative wallet-credential interactions between systems that have implemented all of Presentation Exchange OR all of DIDComm– without having to implement all of both. On the basis of this prototyping experiment, the WACI group expects to fold some extensions and refinements back into the next generation of the WACI specification.

Next Steps for Bloom and C&C collaborators

1. Achieve v1 release of WACI-Presentation-Exchange specification.
2. Fold back in lessons and extensions from #1 and then flush out remaining sections to achieve v1 feature-completeness for v1 of the WACI specification and sample implementation
3. Potentially, work on a new profile (“WACI-OIDC”?) when the next-generation of specifications currently being incubated with DIF participation at the OIDF AB/Connect working group are published
4. Register a custom URI schema (waci://)