Trust That Scales With the Stakes: Inside Harvard's Keyring
Harvard's Applied Social Media Lab built Keyring, a reference wallet for the decentralized trust standards taking shape at the Linux Foundation, to make decentralized trust usable. Its engineers believe the social layer of identity needs a graduated alternative to binary KYC and a user experience that catches up with a decade of protocol work.
A lot of identity conversations are very hard-edged, starting at government KYC. When we're looking at social interactions online, it's very appropriate to have a progressive or graduated approach.
The reference implementation for one of the more ambitious attempts to rebuild digital identity began, like most working software, as a survey of what already existed. Having mature building blocks mattered because the lab wanted to spend its effort developing new trust mechanisms and the open standards that define them. That's why Brendan Miller and Alberto Leon, the principal and senior engineers at Harvard's Applied Social Media Lab, went looking for an open-source mobile wallet they could fork and contribute to, but it had to be genuinely decentralized, open source, and actively maintained.
The Government of British Columbia had been issuing verifiable credentials to residents for years via Bifold, and in the process had built the QA pipeline, connection flows, test harness, and push notifications actually needed in deployment.
The Applied Social Media Lab forked Bifold and built the peer-to-peer exchange layer that lets two people who have just met issue each other a credential attesting to the relationship, with no company or government in the middle. That exchange, and the witness layer that lets a trusted community attest it happened in its presence without learning who took part, were drafted in parallel with the credential specification the lab co-authored through the Linux Foundation's Decentralized Trust Graph Working Group.
The wallet is Keyring, and the framework behind it is being specified through the working group, the effort the First Person Project helped catalyze and the same work the Linux kernel project is evaluating to replace its manual PGP web of trust. In that framework, the wallet is the client side of a Personal Network Manager; a full one also manages a cloud-side Verifiable Trust Agent, functionality the lab intends to specify and build. Keyring launched publicly in April at the Berkman Klein Center's Digital Identity Symposium.
It is in alpha, open for review and collaboration, with the wallet and its reusable core on GitHub.
Building blocks, not a wallet war
We're using technology to help people come together.
The Applied Social Media Lab is not trying to out-market Google or Microsoft, and, unlike a startup, it does not need to. Instead, they aim to make the relationship layer reusable. In practice that means packaging the distinctive code as a standalone component others can pull in, and contributing the underlying protocol upstream into the open-source frameworks the wider field already builds on. "We're not trying to win any wallet wars," Miller said. "We want to innovate new trust mechanisms online and contribute back to open projects."
The relationship-credential exchange was built as discrete modules from the start, with extraction in view. "We had the vision that this could potentially be an SDK," Leon said. But the team chose to ship a working application, because maintaining everything as separate packages early would have slowed development. What exists today is a codebase organized for a clean SDK but not yet published as one.
The ambition is broader than a protocol library because self-sovereign identity, Leon argued, has poured its effort into protocol but neglected experience, a serious gap when the thing being built inverts how identity works. "We're not talking about a simple login password anymore," he said. A model in which a person owns their identity rather than renting access to a platform has no inherited interface vocabulary, so it has to be invented.
The contribution Leon and Miller describe is therefore not only exposed functions but a UI toolkit, templates and ready-made interface elements so that a developer adopting the relationship layer inherits the interaction design along with the protocol. Much of that design work, which turned the government wallet they forked into something a stranger could pick up and use, was handled by Keyring's designer, Nicole Brennan. They see the interface as far more than just packaging around the contribution; it is a core piece of it, and, as the field's history suggests, is the part that decides whether anyone adopts it.
Graduated trust
Most identity infrastructure, Miller observed, is designed from the top down, starting at the hardest case. "A lot of identity conversations are very hard-edged, starting at government KYC," he said, the know-your-customer regime that governs banks and financial transactions, where the bar for assurance is set high and set once. That bar is appropriate for moving money. It is badly matched to the texture of social interaction, where the right amount of proof, and of privacy, varies enormously by context and consequence.
The model Miller reached for is the I-9 employment form, with its menu of acceptable documents, one from column A or one from column B together with one from column C, carried into a digital setting. The social layer wants a graduated approach, in which the proof a system demands rises with the stakes of the act. Posting to a forum might call for nothing more than a generic proof of personhood. But suppose that post begins to go viral in the weeks before an election. At that point, a platform or another reader might reasonably want something narrower and harder to fake, whether its author actually lives in the jurisdiction whose vote they are influencing. The demand escalates with the consequence. "As you're having more impact, or going deeper, or doing things of greater consequence, you have to provide a higher level of assurance," Miller said.
Keyring turns that principle into what the team calls "trust signals," discrete pieces of evidence that attach to a connection and accumulate rather than substitute for one another. One is device biometric attestation, where a face or fingerprint unlock signs the credential with a key bound to the phone's secure hardware, evidence that the legitimate owner authorized the exchange. Another, the essential one, is the in-person scan, in which one person shows a QR code, the other scans it, and the two wallets issue each other a credential. The third is the witness. The aim is a flexible toolbox of these signals that combine into meaningful levels of assurance: a connection that carries all three is a stronger claim than one that carries a single signal, and Keyring renders that difference as badges, an attempt to make an otherwise abstract question, how far to trust that a connection is what it claims to be, legible at a glance. Further signals for physical co-location are still being worked out. The team has run into important limitations with local-network discovery over mDNS and HTTP, and plans next to try Bluetooth and GPS geofencing. The locality signal, Miller said, "is still in the works."
What the witness sees
To give a connection weight beyond two strangers vouching for each other, Keyring relies on a witness, the third and outermost of its trust signals. Where the biometric attestation and the in-person scan speak to the two people in the exchange, the witness is the point at which a recognized community attests that an exchange took place within it. That points it at the question every relationship-based trust system eventually faces: in a network where people mint their own identities and no platform stands behind them, how do you know the people are real?
A witness is a service run by what the framework calls a trust community, an institution like the Berkman Klein Center, but also, Miller stressed, something as informal as a softball team or a family. When two people exchange credentials within that community's context, the witness stamps the exchange. Crucially, it does so without learning who anyone is. "It does not know who we are," Miller said. "There's no PII or stable identifier linked to those core relationship credentials." Each connection uses a fresh pairwise decentralized identifier, generated for that relationship alone. Even two people who have met before generate new identifiers when they connect in a different context, a deliberate measure, written into the credential specification by default, against what Miller called "context collapse and correlation." Users have to opt in to revealing who they are; the system's default is non-correlation.
The witness, then, knows only that two members of its community completed an exchange at a particular time and place. Its signature can be verified by anyone later; its knowledge of the participants is nil. There is one exception, and it is opt-in: a reporting feature that issues a stable identifier scoped to a single community that allows that community to assemble a pseudonymous graph of who connected with whom and how strongly, and which signals each connection carried. In the reference app this is on by default, the better to demonstrate it; in a production deployment, Miller said, it would be off, or left to each community to decide. A professional networking group might want the graph; another community might want it absolutely hidden.
One thing the app does not hide is the identifier itself. "We are currently exposing DIDs to the user," Miller said. "This is related to being an academic lab, doing something brand new. People who are more technical want to know more about what's going on."
Interop, and the two credential worlds
If the strategy is to be reused rather than to win, interoperability is the test of whether reuse is possible.
At a recent Internet Identity Workshop, Leon scanned a QR code generated by a wallet built by a developer he had just met. It connected, and the two wallets exchanged messages. Because Keyring rides DIDComm, the peer-to-peer encrypted messaging protocol common to the Credo-based ecosystem, the transport layer interoperated out of the box. What the other wallet could not handle was the relationship-credential exchange itself, which is being specified as an open standard through the working group, and is still too new to be broadly implemented. The developer, as it happened, was a maintainer of Credo, and the conversation turned to contributing the relationship-credential module back upstream, so that any Credo wallet could work with it. Interoperability with H2H Connect, a commercial application built on the same open specification, is, Miller said, possible, held up less by anything fundamental than by a moving specification and the absence, so far, of a conformance suite to test against.
The lab's stack issues credentials as W3C verifiable credentials in JSON-LD, exchanged over DIDComm. The other center of gravity in digital identity is the world of ISO mobile documents and the OpenID protocols for issuing and presenting them, the world of mobile driver's licenses and the European wallet initiative, along with Google's Multipaz framework. Miller described the divergence as one of starting points rather than camps, with Google's emphasis on mobile documents, the Ethereum privacy community's lean toward European selective-disclosure formats, and the lab's own W3C credentials as different origins converging, he hoped, on interoperability through shared open standards.
The zero-knowledge layer is where that will be tested. Real mobile driver's licenses are signed with conventional cryptography that is awkward to prove things about in zero knowledge, a problem several groups are working on. One is a UC Berkeley team led by Sanjam Garg that is collaborating with the Linux Foundation; another is the Privacy Stewards of Ethereum, with a zero-knowledge library they call OpenAC; and there is Google, whose Longfellow library is one option among several. Leon sketched the collaborative version of the future the strategy implies: the lab's relationship-credential module could be contributed to one or more of these as a peer-to-peer option, and Keyring could in turn use one of these libraries for its own zero-knowledge work. The Decentralized Trust Graph Working Group has a zero-knowledge task force, Miller noted, where some of this will have to be reconciled.
The institutional question
Regarding institutional adoption, Miller did not see the challenge as technical. The wallet already holds conventional institutional credentials alongside the self-generated peer ones, and the lab is interested precisely in zero-knowledge proofs that range across both kinds. There are conversations underway, he said, with government jurisdictions and other credential issuers about how the two combine.
What draws a hard line is where financial rules or government mandates apply, and more flexible approaches will have to earn their place by being proven in practice. Miller's hope is that studies can demonstrate that a level of assurance currently written into regulation can also be met by a privacy-preserving, user-controlled mechanism, and that, shown the evidence, perhaps regulation opens up. Architecturally, there didn't need to be a divide between the peer layer and the institutional one.
The bottleneck is in the willingness of institutions to issue, and of regulators to recognize. The framework's first institutional issuer may very well be the Linux Foundation, issuing credentials to the developers it already governs, verifying them against the kernel's own trust community. As a first case it may carry significant leverage. The kernel sits beneath cloud platforms, embedded systems, mobile devices, and most of the open-source supply chain, and the conventions it adopts tend to propagate downstream to everything built on top of it. A trust model proven there would be a reference a great many projects look to before they move.
The network effect, and the offline turn
As for the hardest unsolved problem, Leon did not name a protocol or a cryptographic primitive. "It really comes down to how do you create a network effect," he said.
At Keyring's launch, people exchanged credentials in person, in the same room, "actually seeing each other, confirming they're not bots." An ideal use for such technology was one that follows this pattern and brings people together rather than holding their attention, as a tool for the in-person meetup, the school, or the church gathering. The value, in the lab's telling, does not wait for ubiquity. A trust community gains something useful as soon as its own members start exchanging credentials, and as more communities come online, trust that spans them becomes possible too, so the benefit can scale superlinearly with the number of communities that adopt it.
Identity on today's internet is granted by platforms, where a person exists as a Google account or an X handle, and mediated through devices and networks the user does not control. The premise of the Decentralized Trust Graph Working Group's effort is that identity is the user's own and travels with them across contexts. Carried out, the same primitives that let two people verify each other across a table are the kind of substrate a less device- and platform-bound internet would need, one able to establish who, or what, is on the other end, whether a person across the table or one of the AI agents the broader framework already seats as a node in the same trust graph. Keyring today is a phone app leaning on a mediator someone has to run, but the architecture it implements is more cross-modal than that.
