7Block Labs
Blockchain in Governance

ByAUJay

Blockchain for Local Government: How to Run a Pilot Without Creating a New Silo


What “no silo” really means in 2026

A no-silo blockchain pilot is really about simplifying things and adding some much-needed flexibility. Here’s what it involves:.

  • It’s created using open and popular standards that everyone trusts for handling things like issuing, presenting, and revoking information. This means you can easily switch out any wallet, verifier, or ledger that meets the requirements later on.
  • Your personal info? It’s kept off the chain. The pilot just holds onto the proof of any tampering or revocation stuff, and it’s totally in sync with public records and retention rules.
  • It integrates seamlessly with your IAM, case management, and document systems through reliable APIs, rather than relying on some vendor's proprietary SDK.
  • Plus, it checks all the boxes for third-party security certifications like GovRAMP and StateRAMP, and it stays in line with NIST’s digital identity standards. If you want to dive deeper into that topic, feel free to check it out here.

Awesome news! By 2025, we’ll have the key credential and transport standards all wrapped up and ready to go on popular platforms. It's going to make everything so much easier!


The standards stack that prevents silos

If there's one thing you should really take to heart, it's this. We've laid out some basic requirements for every public-sector pilot. This way, we can keep things running smoothly both now and over the next five years.

  • Data model: So, we're diving into the W3C Verifiable Credentials Data Model version 2. It officially got the green light on May 15, 2025. Think of this model as your trusty sidekick for sharing digital credentials. It helps out everyone involved--issuers, holders, and verifiers--making the whole process smoother. Take a look at it over on w3.org. You might find it interesting!
  • Cryptographic packaging: So, there’s this awesome recommendation from the W3C called "Securing VCs using JOSE and COSE." It came out on May 15, 2025, and it really dives into how to handle JSON and CBOR signatures. Plus, it tackles the whole selective disclosure thing, making it super relevant for anyone interested in secure data sharing. Check out all the details over at w3.org. You’ll find a lot of great info there!
  • Oh, and just a heads-up: we’ve got Selective Disclosure for JWTs, and it’s officially IETF RFC 9901 as of November 2025. This really helps to keep the amount of data shared with each transaction on the smaller side. If you want to dive deeper into it, check out rfc-editor.org for more info.
  • Current Status and Revocation: So, we’re looking at the W3C Bitstring Status List version 1. There's also a suggestion from May 15, 2025, that introduces a neat, privacy-friendly approach which works really well for different groups of people. If you're looking for more details, check out w3.org. They’ve got some great info there!
  • Protocols:
  • So, let's talk about the OpenID for Verifiable Credential Issuance, or OID4VCI for short. This thing is version 1, and it's all about making credential issuance smoother and more reliable. The OpenID Foundation wrapped things up with version 0 in 2025, and it's already starting to roll out in conformance programs and products from various vendors. Hey, take a look at this on GitHub. It's pretty interesting!
  • And let’s not forget about OpenID for Verifiable Presentations, or OID4VP. It's pretty cool because it's already integrated into big platforms, like the Android DigitalCredential API. Basically, if a wallet sticks to the right standards, it can show off its stuff to any verifier that's also up to par. Learn more at androidcentral.com.
  • Identifiers: We're checking out the W3C Controlled Identifiers (CIDs) version 1. So, we’re looking at 0 here, and it's actually a part of VC 2. 0 family. This makes it possible to create identifier documents that can be verified using cryptography, along with the service endpoints. If you're curious and want to dive deeper into it, check out the details on w3.org. It's a great resource!
  • Trust Registries: We're talking about the Trust Over IP (ToIP) Trust Registry Query Protocol version 2. Let’s have the verifiers check if a specific issuer has the green light to issue credential type X under governance Y. It's super flexible and can easily adapt to different registries. If you want to dive deeper into this, check out trustoverip.org for all the details!
  • Security baselines: Finally, we’ve got NIST SP 800-63-4, which wrapped up in July/August of 2025. It really offers some great tips for wallets that subscribers can manage themselves, helps with authentication that’s resistant to phishing, and also lays out some important fraud prevention measures. Use this to set up the assurance levels for your proofing and presentations. Check out nist.gov if you want to dive deeper into the details!

Why does this even matter? Well, with these components, you can easily switch between wallets, ledgers, or even different vendors without having to go through the headache of reissuing all your credentials or rewriting every single one of your verifiers. Pretty convenient, right?


Real‑world momentum you can reuse

  • California DMV Titles on Avalanche: Guess what? The California DMV has just made a big move and digitized an impressive 42 million vehicle titles by utilizing a chain they manage themselves. How cool is that? This big upgrade has really sped things up! Now, instead of waiting weeks for title transfers, it only takes a matter of minutes. How awesome is that? The main point to remember isn’t just to slap blockchain onto everything. It's really about making sure that the ledger stays open with APIs and credential standards. This way, your DMV app and any future verifiers can avoid being tied down to just one vendor or blockchain.
    “Take a look over at Reuters for some interesting info!”

Hey, check this out! British Columbia just launched something pretty awesome called OrgBook BC. It’s designed to make it super easy to issue and verify organization credentials on a massive scale--like we’re talking millions of verifiable credentials here. How cool is that? It's based on open-source technology and follows established standards, showing that registries can share reliable data about organizations that people can actually trust. For all the info you need, check out Digital.gov.bc. You’ll find everything laid out nicely there!

  • Utah’s legal game plan: In Utah, they've really crafted a smart legal setup along with a pilot program to roll out digital verifiable credentials across the state. Plus, they’ve got the central DTS backing them up and some approachable agency support channels to help out. This model could really assist other states in kicking off their own county and city pilot programs. If you want to dive deeper into this topic, check out Justia for more details!
  • EU EBSI and EUDI Wallet pilots: Over in Europe, there’s some exciting stuff happening! They’re testing out some public-sector pilots that span multiple countries, focusing on issuing verifiable credentials for things like education and public services. And the best part? It’s all running on a public-governed infrastructure. Pretty cool, right? This really highlights that VC/OID4VC interoperability is making strides and functioning well across the entire continent. Even if you're mainly focused on the U.S. These pilots are an awesome resource for spotting trends when it comes to trust registries, wallet attestations, and making sure everything checks out with compliance. Check out Interoperable Europe to learn more about it!
  • **U.S. Hey there! So, the DHS Science and Technology team just launched their 2025 awards. These funds are specifically meant for wallets and verifiers that align with the W3C VCDM and DID standards from the very start. Pretty cool, right? It’s pretty obvious that federal pilots and grants are shifting their focus towards open-standard credentials. Dive deeper at DHS.
  • Platform support: Here’s some exciting news to celebrate--Android has rolled out native APIs that support OID4VCI and OID4VP! How cool is that? So, this basically means we can finally wave goodbye to that annoying “which wallet should I pick?” headache during RFPs! If you’re looking for more info, check out Android Central. They've got all the details you need!

A 90‑day pilot plan that won’t box you in

Day 0-10: Problem Framing and Scope

First things first, let's choose a use case that gets a lot of attention but doesn’t stir up too much debate. Ideally, go for something that has one or two trustworthy data sources backing it up. Check out these great examples: Make sure to grab proof of your business license from your city or county registrar. The procurement and zoning departments will need to check it, so don’t forget that step! We’ve verified the contractor’s permit credentials by checking them out during inspections and the procurement process.

  • Parking permits or fleet credentials that have been checked and confirmed by enforcement devices.
  • It’s super important to figure out your success metrics right from the get-go. Make sure to keep tabs on a few important things: how long it takes to issue stuff, how quickly we can verify information, the rate of fraud cases, how often people are reaching out to the call center, and the opt-in rate. These are key factors to watch!

Day 11-20: Governance and Data Guardrails

  • Map Data Classes: It's crucial to tell the difference between PII, or Personally Identifiable Information, and non-PII. It’s super important to know exactly what data you’ve got and where it’s hanging out--whether it’s chilling in your wallet or stored in your agency systems. Let’s make a promise that we won't store any personally identifiable information (PII) on the blockchain. Instead, we’ll just use things like hashes or non-personal status lists to keep everything secure and private. When it comes to revoking access, we can make good use of Bitstring Status Lists. Feel free to take a look at it here!
  • Set Assurance Levels: If you're diving into identity proofing and figuring out authenticator assurance, I suggest checking out NIST SP 800-63-4. It's a great resource to help guide you through it! Whenever you can, it's definitely smart to go for phishing-resistant methods. They really help keep your info safe! If you want to dive deeper, just take a look at the guidelines here. It’s got all the info you need!
  • Think About Public Records from the Get-Go: It’s a good idea to keep public records in mind right from the beginning. In Vermont, for example, blockchain-registered digital records are pretty cool because they can actually serve as self-authenticating evidence. This makes them super useful for things like audits and legal matters! We should also remember that the Public Records Acts come into play when it comes to disclosure and how long we keep records. If you want to dive deeper into this topic, check it out here. You’ll find all the info you need!

Day 21-45: Architecture and Build

  • Prioritize standards before vendors:
  • Issuance: Let's stick with OID4VCI 1. You're using SD-JWT VC and/or VCDM 2. 0 Data Integrity credentials. Choose what resonates the most with your verifier audience. (github.com).
  • Presentation: When you're working on OID4VP, it's a good idea to test it out with at least two different wallets. You could try it with an Android-native wallet and also explore an open-source option from the OpenWallet Foundation, like Credo. It’ll give you a better feel for how everything works across different platforms! (androidcentral.com).
  • Status: I'm currently hosting a Bitstring Status List 1. Zero, right under your own domain. (w3.org).
  • Trust and authorization: Don't forget to set up a ToIP Trust Registry (or a federation) to clearly outline which issuers are good to go for the various types of credentials. This way, everyone knows who's got the green light! (trustoverip.org).
  • Integration:
  • Just keep using your current IAM system (whether it’s OIDC or SAML) for staff applications. No need to create a whole new identity silo! It’ll save everyone some hassle.
  • Ensure that your issuer and verifier endpoints are easy to find by mapping them to well-known paths and routing them through your current API gateway. And hey, remember to log all that activity to your SIEM - it's super important for keeping track of everything!
  • When it comes to ledgers, just keep it straightforward. You can totally go with an enterprise-run EVM network, like Hyperledger Besu, or even a public chain subnet. Just make sure to use it for anchoring integrity proofs or registry pointers. And definitely avoid storing any personal information about citizens--that’s a big no-no! The title project in California really shows how to maintain a strong link in the chain of APIs. It's a solid example of what effective management looks like! (reuters.com).
  • Security: Make sure to store your keys in a FIPS 140-validated Hardware Security Module or Key Management System.
    Make sure to use JOSE/COSE suites that align with W3C guidelines, and keep yourself prepared for any changes in cryptography. It's all about staying flexible! (w3.org).

Day 46-70: Usability, Inclusion, and Conformance

  • Inclusion Plan: We're excited to announce that we're introducing printable paper credentials with QR codes for anyone who doesn't have a smartphone. Frameworks like MOSIP's Inji show us how to make things run smoothly for both paper forms and USSD. The best part? It doesn’t skimp on verification at all! Check it out here.
  • Choosing Your Wallet: It’s great for users to have the option to pick any wallet that fits the bill. You shouldn’t be tied down to just one vendor’s app! We're going to be checking out the Android DigitalCredential processes, and we'll also take a look at at least one independent wallet using OID4VP.
    If you’re looking for more info, you can check it out here. It’s got all the details you might need!
  • Conformance: We’ll be running some interoperability tests with OID4VCI/OID4VP, a big shoutout to the OpenID Foundation for that! We'll also make sure everything lines up with SD-JWT according to RFC 9901. We're going to keep an eye on any issues and share them in a public test report. If you’re looking for some extra details, feel free to check out this link here. It’s got some great info!

Day 71-90: Pilot Operations and Measurement

Make sure to track the KPIs we agreed on by using a real unit or department. It’s a good idea to test things out with somewhere between 100 and 1,000 credentials. Just a quick reminder to share the credential schema, the status list URL, issuer metadata, and the trust-registry entry. This way, external verifiers can easily find everything they need without any hassle. Alright, let’s get your “off-ramp” ready! We should put together a section in the Playbook that explains how to bring in another wallet, verifier, or ledger. The goal here is to make sure it all happens smoothly without having to go through the hassle of re-issuing any credentials. Let’s make it easy for everyone!


Copy‑paste procurement language we’ve seen work

When you're working on an RFP or SOW, be sure to add in requirements like these. This will help you avoid getting caught in a lock-in situation later on.

  • Standards compliance The system should be able to both issue and accept W3C VC Data Model v2. 0 credentials. You can definitely go with either the Data Integrity or JOSE/COSE security suites, and they both need to support SD-JWT selective disclosure as outlined in RFC 9901. (w3.org). It's super important to get OpenID for Verifiable Credential Issuance (OID4VCI) set up! 0 and OpenID for Verifiable Presentations, often referred to as OID4VP. Just a heads up--make sure you upload the discovery metadata onto the agency's DNS. (github.com).
  • You need to make sure the credential status is published using the W3C Bitstring Status List version 1. So, the agency's got to take care of hosting this. (w3.org).
  • It needs to work with a Trust Registry that’s ToIP-compatible (think TRQP v2). Make sure you either have a compatible device or grab an adapter! (trustoverip.org).
  • Data and privacy Just a heads-up: you can't store any personal info or sensitive data on a blockchain. It's a strict no-go for anything that could identify someone! When it comes to on-chain writes, it's a good idea to stick to non-personal integrity proofs and public status artifacts. Let’s keep things secure and transparent!
  • It’s super important that data stored in wallets can be easily exported to other compliant wallets, without having to go through a middleman. For those folks who don’t have smartphones, we definitely need to offer printable credentials that come with a QR code you can verify. (biometricupdate.com).
  • Security and operations So, basically, you need to handle keys using FIPS-validated modules, and everything you do should meet the NIST SP 800-63-4 assurance levels that the agency laid out. (nist.gov).
  • If you’re using any cloud services, they need to comply with GovRAMP or StateRAMP standards that are appropriate for the specific data classification. (govramp.org).
  • Exit and interoperability The agency has control over the schemas, status lists, and trust registry entries. The vendor needs to set us up with migration tools and some solid documentation. This way, we can integrate a second wallet or verifier within 60 days, and we won’t have to worry about reissuing anything.

Architecture pattern: how to wire this into what you already have

  • Issuer service
  • It links up with reliable systems like licensing, permitting, and registries by using the APIs that are already in place. Credentials are created using OID4VCI and are signed with either JOSE/COSE or Data Integrity, depending on the verifier involved.
  • It also puts out a Status List credential that lets you revoke or suspend access without messing around with any personal information. (w3.org).
  • Wallets Residents have the option to use either wallets that are integrated with Android or go for third-party wallets. Also, the staff testers have the choice to use an OWF-based wallet to explore the different flows. (androidcentral.com).
  • Verifier service You can easily integrate this right into your case-management portal or even your handheld enforcement devices. It relies on OID4VP and takes a look at trust registries to make sure that the issuer is actually authorized. (trustoverip.org).
  • Optional ledger
  • If you find your policy needs an audit anchor, you’ve got the option to jot down a hash of the credential template or registry entry. Just a heads up--you shouldn’t write down the credential itself. You can do this on a permissioned EVM chain or on a public subnet that your organization takes care of. A perfect example of this is California’s DMV. They really nail it when it comes to making the details behind their agency APIs a whole lot simpler. (reuters.com).

What We Deploy

  • Type of credential: This is the City Business License Credential, version 1.
  • Subject: Choosing between a business organization or going solo as a sole proprietor.
  • Who’s in Charge: City Business Licensing Authority.
  • Binding: So, we’re using an SD-JWT VC that’s signed with ES256. This means we've got holder binding in place to protect against replay attacks, which is pretty cool. Plus, the binding typically lasts around 1 to 3 years. (rfc-editor.org).
  • Status: We're keeping tabs on everything with the Bitstring Status List v1. 0 gets updated whenever there's an issuance, suspension, or revocation. (w3.org).
  • Issuance: We’re tapping into the OID4VCI authorization-code flow, which means we can make the most of the city’s current OIDC login for business reps. (github.com). Alright, here’s the scoop: OID4VP is where it all kicks in. You’ve got some key players involved, like the procurement portal, zoning folks, inspections, and even those handheld devices used by parking enforcement. It's all connected! Thanks to Android DigitalCredential routing, our team can finally breathe easy. They don’t have to stress over which wallet is being used anymore! (androidcentral.com).
  • Authorization: So, when procurement verifiers want to make sure everything’s in order, they contact the regional trust registry and ask something like, “Hey, is City A allowed to issue the CityBusinessLicenseCredential?” If they get the green light, we store that info for later use and keep a record of it. (trustoverip.org).

Why It Avoids Silos

  • Any department or nearby town can take a look at things without having to rely on an API to connect to your back-office system. A business can easily change wallets later on without the headache of reissuing everything. If you’re thinking about switching from your cloud service to one run by the state for revocation, it’s pretty straightforward. Verifiers can just check out the status list URL that’s included in the credential metadata.

Lessons from the field (what not to do)

  • Steer clear of creating credentials in a custom JSON format just because it looks simpler. It might be tempting, but it’s usually not the best way to go. This is going to be a bit of a headache for verifiers. It means they'll have to come up with their own code, which really puts a damper on sharing work across different jurisdictions. Instead, just go with VCDM 2. It's a solid choice! The focus here is on contexts and JOSE/COSE, as well as the Data Integrity suites. (w3.org).

Just a quick tip: make sure to avoid putting names, addresses, or any personal info on the blockchain. It's better to keep that stuff private. Just make sure to jot down record revocations, status updates, or integrity proofs on the ledger. California's situation really highlights that it’s possible to keep the nitty-gritty details of the ledger tucked away behind APIs. (reuters.com).

  • Make sure you don’t limit yourself to just one wallet vendor. Don't forget to try out at least a couple of options, and make the most of platform features, like Android's DigitalCredential API. It’s a great way to keep your choices open and flexible! (androidcentral.com).

Please don’t make your own trust list. Instead, go ahead and use ToIP TRQP. This way, others can easily verify who's authorized without having to dig into individual agreements. It just makes things a lot simpler! (trustoverip.org).


Measuring value: concrete targets for a 12‑week pilot

  • Issuance time: Our goal is to trim that down from a few days to less than 10 minutes. Let's make it happen! Can you imagine how the DMV is really stepping up their game? They're actually working on cutting down the title transfer process from what used to take weeks to just a few minutes! How awesome is that? You can check out the details over at Reuters.
  • Verification time: We’re aiming for something super quick--like, under 2 seconds if you're online. Oh, and when it comes to caching trust-registry lookups? We're looking at speeds of under a second! Talk about efficiency! (trustoverip.org).
  • Fraud Signal: Picture this - being able to spot and shut down revoked or suspended credentials as they happen. How cool would that be? We can make this happen by using bitstring status updates instead of counting on mailing lists or doing batch exports. Wow, now that’s a total game changer! Check it out over at w3.org. You won’t want to miss this!
  • Inclusion: Let's make sure that at least 10% of our verifications can be done using printable QR credentials or some other method that doesn’t rely on a smartphone. It's important to keep things accessible for everyone! This way, we can make sure we're meeting everyone's needs! You can check out more about it here: (biometricupdate.com).
  • Interop: How about we tackle the OID4VCI/OID4VP interop suite using two separate wallets? Sounds like a fun challenge! This is going to bring us the variety we really need in terms of compatibility! Check it out here: biometricupdate.com.

Emerging practices to watch in 2026

Hey there! So, you know how open-source IAM solutions are really starting to make a name for themselves? Well, take Keycloak, for example. They're really upping their game by adding support for OID4VCI issuer roles, and it's all in line with the latest specs. Pretty cool, right? This really simplifies the process of adding issuance to your current login system. Take a look at it on GitHub! You might find it interesting!

  • Government wallet reference stacks: There are some exciting things happening with projects from the OpenWallet Foundation, such as Credo. They're working on adding high-assurance profiles and integrating Key Management Systems (KMS). Plus, they're making sure everything lines up with EU and ISO standards. It’s great to see so much effort going into making these systems secure and reliable! This is really handy for agencies that want an open baseline instead of wrestling with a black-box app. If you want to dive deeper into the details, check out the OpenWallet Foundation's website. They've got some great info about what's coming up in 2025, including the releases of versions 0.5 and 0.6, and how they're stepping up to be a key player in global interoperability. You can find it all here. Happy exploring!
  • Better privacy right out of the box: With the help of RFC 9901 for SD-JWT and some really solid support from platforms, selective disclosure is turning into a must-have for keeping personal info under wraps in public services. If you want to get into the nitty-gritty details, be sure to check out RFC Editor. There’s a lot of good stuff waiting for you there!

Checklist: your “no‑silo” pilot in one page

  • VCDM 2. You're working with a data model that includes JOSE/COSE, plus some Data Integrity suites. And let's not forget about SD-JWT for selective disclosure! (w3.org).
  • We’ve tested OID4VCI/OID4VP using two independent wallets, and that even includes routing on Android! (androidcentral.com).
  • We’re now keeping track of status using the Bitstring Status List v1. Just to clarify, there’s absolutely no personally identifiable information (PII) stored on any of the ledgers. (w3.org). Hey there! Just a quick update: we’re currently doing trust registry lookups with ToIP TRQP. Also, we’ve started publishing issuer authorization entries. Exciting stuff! (trustoverip.org).
  • So, we've got a mapping for NIST SP 800-63-4 that lays out the IAL, AAL, and FAL stuff. Plus, we're all set with phishing-resistant authentication, and our keys are securely stored in FIPS-validated HSM/KMS. Pretty solid setup, right? (nist.gov). Hey everyone! We’ve rolled out some cool new printable credentials that come with verifiable QR codes. This is especially for those residents who don’t have smartphones. (biometricupdate.com). We're all set when it comes to security! Our approach is in line with GovRAMP and StateRAMP for any cloud elements we use. (govramp.org).
  • We've rolled out some schemas, metadata, and a migration plan. This way, we can smoothly add a second wallet, verifier, or ledger without having to re-issue anything.

How 7Block Labs can help

So, here’s the deal with our public-sector plan: it’s laid out for a 12-week program, and here’s how it all breaks down:

  • Week 1: We're starting things off by figuring out exactly what we want to achieve, setting some key metrics, and mapping out the public records we’ll be working with.
  • Weeks 2-6: After that, we’ll jump right into setting up the issuer, verifier, and status services. During this phase, we’ll also work on weaving in your IAM and APIs for a seamless experience.
  • Weeks 7-10: In these weeks, we’ll dive into multi-wallet conformance testing (OID4VCI/OID4VP). We’ll also spend time working on the Android flows and ensure we're not missing any accessibility and inclusion options for everyone. It’s all about making sure we’ve got all bases covered!
  • Weeks 11-12: We're in the home stretch! During these weeks, we’ll finish up the pilot operations, create a metrics dashboard to keep track of everything, and put together an off-ramp plan. It’s all about tying up loose ends and getting ready to move forward! This plan will walk you through the process of adding or swapping out wallets, verifiers, or ledger components without the hassle of having to re-issue anything. It's pretty straightforward!

When you’re diving into a county or city use case, it’s smart to start with business licensing, contractor permits, or maybe even parking issues. Go for the option that’ll give you the fastest return on investment (ROI), but also think about how it can set up reusable components for the next department. It’s all about finding that sweet spot!


Bottom line

The key difference between a flashy blockchain demo and a successful, lasting upgrade really boils down to how you kick things off from the very beginning. Just a heads up--make sure your pilot is all set and aligned with VCDM 2. You're looking at a bunch of technical stuff here: OID4VCI, OID4VP, SD-JWT, and those Bitstring Status Lists. It all ties into NIST 800-63-4 and a trust-registry model. Quite a mix, right? That's the key to seeing real results in just 90 days! And the best part? Your next wallet, verifier, or even ledger can hook up seamlessly without messing up all the hard work you've already put in. How great is that? (w3.org).


Like what you're reading? Let's build together.

Get a free 30-minute consultation with our engineering team.

7BlockLabs

Full-stack blockchain product studio: DeFi, dApps, audits, integrations.

7Block Labs is a trading name of JAYANTH TECHNOLOGIES LIMITED.

Registered in England and Wales (Company No. 16589283).

Registered Office address: Office 13536, 182-184 High Street North, East Ham, London, E6 2JA.

© 2026 7BlockLabs. All rights reserved.