The W3T coalition will be focused on catalyzing a Web3 hyper-growth moment. Creating space for an identity hyperstructure to emerge.

Initial Responsibilities:

• Public Key Infrastructure

• Verifiable Credential Schemas

• Data Stream Standards

Why

Next generation Internet applications require a new foundation. A robust information taxonomy system. Decentralized and distributed systems demand standards, specifications and interoperability.

Without a shared substrate to connect our applications we can't build a better Web3.

Interested in joining the Web3 of Trust?

Apply to join the coalition at web3oftrust.app

Together lets grow a Web3 of Trust - people, organizations and companies committed to catalyzing an Identity hyper-growth moment.

Why?

Because blockchains are terrible for data storage, and thus most dApps forgo utilizing any user data. This leads to a degraded user experience where:

1. Authentication wholly relies on private keys, not people’s identities

2. Technical complexity in connecting multiple services requires users to sign numerous messages

3. Authorization is granted based on predefined rules instead of dynamically shared capabilities

4. Permissions cannot be applied across multiple execution environments, i.e. Ethereum, Optimism, Polygon, Fuel, Celestia, etc.

5. Dapps cannot recognize a user with multiple wallets

6. Users aren’t notified when important events are emitted

These complications are hard on both users and developers. Users have a hard time understanding what they’re signing and expressing their intentions to an dApp, and developers struggle with the technical complexities of connecting multiple services.

Decentralized identity and data storage layers have emerged as the leading solution to web3’s data problem, but interoperability between these off-chain resources and on-chain actions remains unsolved. 

We are introducing the Trust Anchor Gateway (TAG) architecture to bridge off-chain data and on-chain access controls, so developers can build seamless user experiences that are private and secure for their users. Designed to be lightweight and flexible, a TAG provides a path forward for using verifiable credentials and other off-chain information to generate just-in-time access controls for smart contracts.

In this article, we’ll explain:      1. What is a just-in-time (JIT) access control      2. Why use a Trust Anchor Gateway      3. How District builds for access controls at scale

What is a JIT Access Control

A JITAccessControl is a method of granting real-time granular access to an application or resource to perform a task. Instead of giving always-on access (standing access) to a resource, JITAccessControls allow developers to limit access to a specific time frame, mitigating the risk of privileged account abuse.

In the web3 context, the JITAccessControl is executed via a signed delegation and invocations using the Delegatable framework. Delegatable uses a combination of new and existing smart contract patterns (meta-transactions, nonce-queues and caveat enforcers) to establish a smart contract implementation of executable transaction conditionals.

Executable transaction conditionals (via caveat enforcers) enable the expression of intentions via rules and conditions for when a transaction can be executed without a prior write to a smart contract’s storage. This is the opposite approach to the one taken by many of today’s smart contract permissions and access control systems like AccessControl.sol in OpenZeppelin, NFT minting whitelists, DAO resources (Moloch, Aragon, etc.) which all require prior interactions with a blockchain before an Account is granted permissions to a resource.

In other words, without a direct write to the blockchain, JITAccessControls enable TrustAnchorGateways to enforce when a transaction should execute: between timestamp ranges, only if a user has an ENS domain, if a user holds a specific Soulbound item, etc...

Why use a Trust Anchor Gateway (TAG)

The TAG architecture is designed to be a horizontally scalable solution for generalized permissions systems in a multi-blockchain world. The design builds upon the long-standing concepts behind Trust Anchors, Web of Trust, Public Key Infrastructure, Self-sovereign Identity, and the more recently ratified W3C Verifiable Credential specification, and applies them to the web3 context.

Like Trust Anchors in a Web of Trust, a TAG acts as an arbiter of truth when migrating data between environments (physical and digital) which cannot easily be done using cryptographically verifiable methods. Simply put, the TAG is a trusted intermediary when it’s impossible to create a link from statement to cryptographically verifiable statement, attesting to the truth (or expressed truth) about a fact of the physical/digital world.

The structure allows a TAG to provide just-in-time on-chain access controls, bridging the gap between off-chain data and resources, like self-sovereign identity or verifiable credentials, and on-chain smart contract actions like lending in a permissioned pool or minting an NFT. 

Instead of relying on smart contract registries to manage permissions, which are inherently unscalable in a multi-chain and multi-execution environment world, users are given access to smart contracts via JITAccessControls which can be codified with dynamic rules and conditions at the time of issuance.

This greatly expands the scope of what’s possible on-chain, including fully permissioned DeFi that marries institutional-grade compliance standards with code-enforced transparency, permissioned liquidity pools that are compliant with KYC/AML standards, and unified user experiences across blockchains and wallets.

Dynamic Permissions & Access Controls

What’s most unique about Trust Anchor Gateways is the ability to define dynamic and complex rules for when and how a transaction should be executed.

Execution rules are encoded inside Delegations (off-chain) and validated at run-time i.e. when the transaction is being executed. The conditional transaction execution rules rely on modular and composable enforcers responsible for “enforcing” a very specific conditional:

• Before/After/Between Timestamps

• Before/After/Between Block Numbers

• ERC20 Token Spending Allowance

• Account has ownership of 5 unique NFTs

• Governance proposal outcomes (Pass/Fail)

• And much more!

Trust Anchor Gateways have flexibility when it comes to defining conditional transaction execution rules. This is because enforcers can easily be composed together i.e. dynamic access controls without redeploying smart contracts or re-architecting the underlying protocols permissioning system, when it’s time to introduce new execution conditionals.

The conditional transaction execution pattern unlocks a new product development space for sybil resistant smart contracts. Specifically smart contracts that require just-in-time access controls and fine-tuned permissions systems using dynamic off-chain authentication systems.

Delegations enable privacy preserving features like using new/unfunded wallets to perform on-chain actions, but have been verified off-chain using decentralized identifiers and verifiable credentials.

TrustAnchorGateways can also be privacy preserving by default. Decoupling a “root” account which has been issued Verifiable Credentials and “leaf” accounts which are given the JITAccessControl to take actions unlocked by the root accounts VCs. 

Instead of a single account (which is simply bad operational security) granted permissions across many different services, and leaving an easily traceable digital footprint, a TrustAnchorGateway is able sign JITAccessControls for “leaf” accounts also owned by the “root” account, but which have no direct correlation on-chain. Allowing a User to access a cryptographically secured resource, without revealing to the world who they are or why they have these permissions/credentials.

Delegatable’s caveat enforcer pattern will change how we handle everything from DAO resource management to institutions integrating KYC into their decentralized finance flows.

Modularity and composability are incredibly powerful. Creating space for experimentation and growth.

TrustAnchorGateway Networks.

A Trust Anchor Gateway can act alone or it can be part of a network. 

Why join a TAG network?

Security.

If a smart contract relies on a single off-chain TrustAnchorGateway and that TAG is compromised (or starts to act maliciously) the smart contract inheriting it’s security from the gateway is also compromised.

But, if a smart contract inherits security from a network of TrustAnchorGateways, and the TAGs also operate independently, the ability for a bad actor to compromise the smart contract’s access control system is greatly diminished, because it becomes exponentially more difficult to compromise multiple (professionally operated) TrustAnchorGateways.

How District Builds for Access Controls at Scale

A Trust Anchor Gateway is designed to sit between a Decentralized Identity Gateway, like Disco, and public blockchains execution environments like Ethereum and Optimism.

With access to a private key (EVM Account) the Trust Anchor Gateway is able to sign valid Ethereum transactions. 

The transactions, using the Delegatable framework, are encoded with conditional transaction execution rules using counterfactual statements. Or put more simply, the TAG can issue JITAccessControls with bounded rules, like the transaction must be submitted between two timestamps or before/after a specific block number without ever requiring a direct write to smart contract storage before the transaction is submitted.

Conclusion

The underlying capabilities (inherited from Delegatable framework) of TrustAnchorGateways emulates properties found in planned Ethereum upgrades like EIP-4337: Account Abstraction.

When native account abstraction support arrives, the TrustAnchorGateway patterns and networks will be directly applicable and the enforcer pattern underpinning Delegatable will supercharge native Account Abstraction. 

How? 

Individual accounts can instantly gain access to advanced social recovery and dead-man switch infrastructure via established TrustAnchorGateway networks. We see a future world where TrustAnchorGateways help onboard 1,000,000’s of Users into Web3, because we make it easy, safe and scalable for the everyday user to experience the power of decentralized technologies, without sacrificing security and sovereignty.

Why is this important? 

TrustAnchorGateways are designed to grow in complexity overtime.

Gall’s Law: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

http://principles-wiki.net/principles:gall_s_law

https://twitter.com/JasonRogues/status/1608532240123760641

In the future TrustAnchorGateways can include threshold cryptography, multi-party compute, zero-knowledge proofs, plus other combinations of yet to be discovered cryptographic ceremonies for constructing decentralized and distributed access control systems… once the hard work of finding product market fit is complete.

Right now Districts Labs is focused on bringing verifiable credentials into blockchain execution environments without sacrificing privacy. Taking into account the constraints/standards we have today, while also preparing to meet the demands of tomorrow. 

District Labs is preparing for this future (millions of Web3 users) by creating the infrastructure, networks and protocols for a safe, secure and scalable User experience in a decentralized world.

Ready to join us?

Learn more at www.DistrictLabs.com

Authors,

Kames Geraghty, CTO at District Labs

Justin Bassey, CEO of District Labs

Verifiable credentials (VCs) are an essential building block to fully realizing web3’s vision. Spearheaded by the teams at uPort, Disco, and others, VCs provide a new way to image digital identity by inverting the trust model of the internet, putting the holder of a credential at the center of trust, as opposed to companies like Facebook and Google.

As blockchain technology gains popularity, self-sovereign identity will become a fundamental mechanism in governing the exchange of data and monitoring who has access to what resources. However, VCs live off-chain, so how can we use verifiable credentials to provide on-chain access controls across public blockchains?

The Underlying Problem

Generally speaking, verifiable credentials are not a blockchain technology. Blockchains are public ledgers and registering personal identifying and private information on-chain largely defeats the inherit privacy preserving properties of VCs.

Verifiable Credentials enable the cryptographic verification of data authenticity, without relying on a centralized authority to verify the legitimacy of the supplied attestations/information. In this context, utilizing public blockchains to register decentralized identifiers or act as public key infrastructure is a great use case, but ultimately blockchains should not be considered a piece of the Decentralized Identifier and Verifiable Credential stack.

Verifiable credentials, by themselves help solve several core problems with today’s Internet:

1. Data Authenticity i.e. where did this information come from

2. Credential Verification i.e. why is information important and to whom

3. Privacy Preserving i.e can be stored anywhere without losing properties 1 and 2

However,a scalable, secure, and private identity stack is meaningless unless it is able to interoperate with the other systems around us, primarily blockchains like Ethereum. Whether it’s a close-knit DAO operating an on-chain treasury or regulated entities interoperating with decentralized finance hyperstructures, unlocking real-time access controls in smart contracts is essential to the growth and evolution of Web3.

Large institutions have to consider compliance and regulatory constraints when interacting with DeFi protocols, a significant obstacle to institutional web3 adoption today. Organizations like J.P. Morgan have already begun experimenting with using Verifiable Credentials to unlock access controls in blockchain systems.

https://twitter.com/blockworks_/status/1587777026286657539

So, how can we bring together self-sovereign identity and public blockchains like Ethereum?

District Labs has a few ideas.

Web3 of Trust - Next Generation Access Controls

Verifiable Credentials and Decentralized Identifiers are two closely related W3C (World Wide Web Consortium) specifications. When used together the two specifications can enable what is called a Web of Trust.

A Web of Trust is where Internet native digital identities can begin to emerge.

Instead of relying on centralized authorities to control our digital identities, we can start to form connections and relationships using cryptography: with or without blockchains.

What we really want (and need) is the ability for trust to have transitive properties. To allow our digital identities to be utilized and contextualized across a range of digital environments, whether that’s in small localized networks (friends/family) or global coordination systems like the Ethereum blockchain.

Unlocking Smart Contracts using Verifiable Credentials

The root of our problem starts with the fact that smart contracts on public blockchains have limited access control capabilities and are prone to sybil attacks. That’s on purpose. Blockchains are designed to be open and accessible for everyone. Because it needs to be. It’s a global coordination system.

But that does not mean we want every public smart contract method to be accessible by everyone. In fact quite the opposite. We want people and organizations to have real-time access controls for blockchain smart contracts.

Can we solve these problems inherent to blockchains?

Yes! And it starts with building a trust network.

TrustAnchorGateway

The question we really need to ask now is… “Can Verifiable Credentials solve the smart contract access control problem and also help address sybil resistance at scale, without sacrificing the primary benefits of Verifiable Credentials?”

The District Labs TrustAnchorGateway V0 is a proof of concept to help answer that question.

The TrustAnchorGateway is an off-chain API service designed and developed by District Labs and Disco. The gateway converts verifiable credentials into smart contract access controls using counterfactual delegation via the Delegatable framework.

http://delegatable.org

https://github.com/delegatable/delegatable-sol

Providing a pathway from off-chain data to on-chain permissions via a simple and easy-to-understand architecture, while also preserving the privacy of the verifiable credential holder. User’s are given permissions in real-time i.e a just-in-time access control.

Before we get into the specifics of the implementation let’s first take a step back.

A traditional Web of Trust uses Trust Anchors to issue Verifiable Credentials.

https://en.wikipedia.org/wiki/Web_of_trust

https://en.wikipedia.org/wiki/Trust_anchor

A Trust Anchor Gateway is an extension of the Trust Anchor concept applied to Web3.

Trust Anchors, in a Web of Trust issue Verifiable Credentials.

Trust Anchor Gateway in a Web3 of Trust issue JITAccessControls from Verifiable Credentials.

Similar to Trust Anchors in a traditional Web of Trust, the Trust Anchor Gateway in a Web3 of Trust acts as arbiters of “truth” about the world from a non-blockchain perspective. In other words, a TrustAnchorGateway is designed to be an intermediary between off-chain data and on-chain access controls.

Why TrustAnchorGateways?

The short answer: The Verifiable Credential specification was designed to be privacy preserving.

And as it stands blockchains are less than ideal when it comes to preserving privacy for users. Until we have robust zero-knowledge infrastructure and better Verifiable Credential adoption and usage we need solutions that address today’s problems.

**We don’t want to compromise on security.**But we also want something that will meet today’s needs.

The Trust Anchor Gateway is designed to maintain privacy preservation of Verifiable Credentials, while also adding scalable sybil resistance at the smart contract access control level.

**The long answer: **Zero-knowledge proofs in a public blockchain environment provide a lot of utility.

One of which is access controls using privacy preserving methods. Identity systems like iden3.io and semaphore.appliedzkp.org play a big part in scaling of Web3 ecosystems; both at a blockchain protocol layer, and when applied in the right context at the application layer.

But, they’re also complex and don’t lend themselves to shorter development lifecycles, where flexibility is equally important as functionality.

Zero-knowledge proofs are intricate, require specialized knowledge to do right, and much of the underlying technology is still very new. If the underlying smart contract containing the zero-knowledge circuits contains a bug the security of the entire system is compromised.

A strong focus on standards, flexibility, and simplicity

TrustAnchorGateways take a pragmatic approach to on-chain access controls using off-chain data.

1. Use existing standards i.e. Verifiable Credentials and Decentralized Identifiers.

2. Easily scalable architecture and customizable off-chain API infrastructure.

3. Signing standard (EIP712) that is both human readable and machine interpretable. Balancing developer experience, security, and functionality.

A TrustAnchorGateway Live Demonstration

Want to see a TrustAnchorGateway in action? Do you have an official Disconaut Credential that is publicly accessible? Visit https://disco.districtlabs.com and mint a Disco District NFT today.

The Disco District NFT is available on the Ethereum and Optimism networks.

Conclusion

Verifiable Credentials and Decentralized Identifiers are W3C specifications reshaping the building blocks for modern digital identities. Blockchain technologies (Ethereum, Optimism, Celestia, etc…) are fundamentally changing the way we coordinate at scale.

Together these two Web3 technologies (self-sovereign identity and blockchains) will change how we think about ourselves and the world around us. A launchpad into a new digital frontier.

As a previous member of uPort (one of the original teams pushing forward Decentralized Identity in Web3) and early contributor to the 3ID specification (product design and name) I’m excited to see the resurgence of Verifiable Credentials thanks in large part to the Disco team.

Authors,

Kames Geraghty, CTO at District Labs

Justin Bassey, CEO at District Labs

The convergence of these technologies has given us web3, where data is stored in the fabric of the internet itself and information is owned and managed by users rather than applications.

This paradigm shift creates new challenges for users who are increasingly responsible for managing the flow of information online, but lack the tools to govern how their data is shared. In other words, even though web3 allows people to own their information, it’s hard for them to understand who can see it or if it’s even safe.

Web3 Identity & Data Ownership

As web3 scales beyond self-contained ecosystems to interoperate with other chains, data, and resources, identity plays an increasingly important role in ensuring a consistent and secure experience.

In web2, interoperability was primarily enabled by federated identity, in which information stored across separate identity management systems are linked together. Under this model, authentication, authorization, and personal data are managed centrally by organizations and services rather than the individual to whom it belongs.

Web3 flips this dynamic in favor of self-sovereign identity (SSI) that gives individuals full ownership and control of their digital identities and how their personal information is shared and used.

This identity includes on-chain information like what tokens or NFTs you own, as well as off-chain data like verifiable credentials and other private information. Collectively, the data builds a digital identity that can be used to access restricted resources or prove a claim across environments.

Because users are in full control of how and what data is being shared, SSI creates a decentralized and definitive mechanism for establishing trust between users and applications while preserving individual privacy.

However, while SSI has the potential to upend the internet’s approach to identity and access management, it also has the potential to make things much more complex for users and developers alike.

Everything Needs Permission

Authorization and permission management is the single most important factor in web3 security that’s rarely talked about. Every contract, dApp, and transaction requires authorization from an account before it can interact with its users’ funds or data store. 

Take Uniswap as an example. Just to provide liquidity, users need to sign two permissions before depositing their tokens into a pool. Worse still, Uniswap and many other dApps request an unlimited allowance from the user such that the smart contract doesn’t need further permissions to perform actions with the user’s tokens. 

This is a conscious tradeoff that developers make, sacrificing security for usability. In doing so, web3 developers expose their users to unnecessary risk. Software is notoriously soft, and there’s no such thing as perfectly written code. Bugs and exploits can happen even in established projects and by requesting unlimited allowances, dApps not only expose deposited balances to theft, but also the tokens held “safely” within users’ wallets.

At a high level, everything in crypto is about authorization and permission management. Smart contracts and decentralized applications are programs that define arbitrary rules for ownership, transactions, and execution conditions. In many cases these functions are fully permissionless (i.e., anyone is free to interact with the code), but still require authorization to administer their tasks.

More advanced use cases require fine-grained access controls to function at scale. For example, how might a tokenless DAO conduct governance or provide access to on-chain resources exclusively to its members? How can a lending pool limit access to only KYC’d individuals or institutions? How do fans give creators permission to charge them a monthly subscription on-chain? 

These are complex conditions that require a mix of on and off-chain data to function properly. Moreover, the potential value capture and compliance necessities make these high-stakes commitments that developers and communities can’t afford to get wrong. 

To-date, the only solution for implementing this manner of access controls has been via whitelists. But whitelists lack the dynamism to function at scale. Anyone who’s managed a whitelist before knows that they are a frustratingly analog process that is prone to error. Nevertheless, we see them being used for NFT drops, organization management, and permissioned pools despite their significant drawbacks. 

We’re building District to solve the permissions layer of web3. There doesn’t need to be a tradeoff between functionality, security, and usability. The best security measures allow for seamless protection while enhancing user experience. In creating the next generation identity and access management protocol, we strive to improve web3 security and experiences without compromising on privacy. 

Welcome to District

District is the easiest way to improve the security and usability of web3 applications. We are laying the foundation for universal authorization based on user-controlled data and are excited to introduce fine-grained access controls to web3. 

Because web3 inverts the data ownership paradigm of the internet, we had to rethink identity and access management from the ground up. Cryptographic signatures make user authentication trivial, but few mechanisms exist to govern authorization.

Traditionally, authorization was done using access controls lists (ACLs) in which a list of rules specifying which users or systems are granted access to objects determines authorization. However this model is incompatible with smart contracts as it doesn’t support dynamically changing permissions well and is hard to control programmatically, resulting in both security and scalability issues.

Instead, District’s access control model is based on object capabilities (ocaps). In the ocaps model, authorization is managed by creating, sharing, signing, and invoking “capabilities” instead of relying on a list of rules. If you have a valid capability, you have the authorization to use it.

These capabilities can be chained together, allowing for the delegation of authority and “caveats” can be attached to restrict the scope of its use, for example enabling revocation, limiting access to between specified block numbers, or a range of other conditions. 

The structural properties of District’s access control model allow for fine-grained authorizations to be made, while adhering to the principle of least authority. This allows users to grant applications just enough authorization to execute seamlessly, while maintaining a high level of security. 

Going back to our Uniswap example, a user could delegate the Uniswap smart contracts a token allowance of up to 10 ETH per month until blockNumber 24,000,000, enabling Uniswap to maintain the same user experience of the unlimited allowance method, while minimizing the attack surface in the case of an exploit.

District unlocks these fine-grained authorizations through accessible building blocks that make it simple for developers and their applications to request and manage permissions. With our secure APIs and SDKs, developers can build more secure dApps with better user experiences quickly.

What’s Coming Next

For the past several months, we’ve been working on delegatable, an open source framework pioneered by the team at Metamask. Delegatable is a set of tools enabling delegation on Ethereum and is designed to address a number of challenges with EVM transactions ahead of native account abstraction support.

While delegation currently acts as the core of District’s access control model, the framework supports other high order functions like transaction bundling, meta-transactions, and subscriptions that we are bringing to market soon.

Our team is already working on several exciting partnerships to integrate District, and we can’t wait to show you how we’re helping apps improve their functionality, security, and usability.

Our mission is to make every transaction safe, secure, and human. If you’re building an application on Ethereum, let’s talk.

- DISTRICT TEAM