As mentioned in Civil CEO Matthew Iles' post The Trusted Web, trust in the news and information on the internet is at an all-time low. Determining what is true and what is false is a concern at Civil and is a large part of our plans for Civil ID, a new universal identity layer for the web. Some important components to achieving our goals with Civil ID are decentralized identities that can issue verifiable credentials on themselves or other entities. This will allow anyone to cryptographically prove authenticity on the web.
One of the centerpieces of Civil ID is the Civil ID Hub, which is a universal, decentralized service for storing identities and verifiable credentials. Civil ID Hub is open source under the Apache 2.0 license.
Identities
Decentralized identities represent an entity with cryptographic public keys used to verify data signed with their private key. The entity will securely store that private key, building public trust that only the holder of that private key can sign data related to that identity.
To represent a decentralized identity, the W3C has specified a standard identifier called “Decentralized Identifiers” or DIDs. A DID must be resolvable to a DID document that contains public keys and services associated with the DID. Civil ID Hub abides by this specification and also resolves to its own DID type or method. There will be a future post on our proposal for this DID method, but in short, it will assist in resolving DIDs to various ID Hubs across the web, leveraging Ethereum to make this publicly verifiable on-chain. Civil ID Hubs will store the DID documents for DIDs within this method specification. Work on a specification and resolver for this method is on the roadmap.
Storing and distributing decentralized identities require standards for interoperability. For that, there are emerging specifications for “Identity Hubs” by the Decentralized Identity Foundation. The DIF lays out the idea of “hubs and agents” in which agents act on behalf of an entity to negotiate credentials and identities. These credentials and identities can be stored and made query-able on hubs on behalf of the entity by the agent. Civil ID Hub is working towards abiding by the hub specifications and concepts to become a good citizen in the ecosystem.
Verifiable credentials
Once identities have been established via the Civil ID Hub DID method or via any other DID method, verifiable credentials can be generated against those identities for a variety of situations, from checking the age of an individual to the provenance of content ownership. The keys specified in DIDs will be used to verify proofs that exist within the credentials.
To represent a verifiable claim, the W3C has specified a standard “Verifiable Credentials Data Model” format from which ID Hub will abide. Our goal is to have Civil ID Hub store any type of claim document with any DID, but initially will focus on journalism and publisher content ownership credentials signed with Civil ID Hub DIDs. The identities will be used to issue and verify these credentials.
Civil ID Hub will leverage the fantastic work from iden3 which helps build Merkle trees of credentials from which we can generate a fingerprint from the root. While we still store these credentials and trees into the local database on the Civil ID Hub, we will periodically publish this fingerprint on-chain to Ethereum. Validators can use these roots to verify the temporal existence of a claim. Validators can generate proofs for these credentials to ensure the data is consistent.
Putting it all together
The Civil ID Hub will exist as public nodes that live within the various public and private infrastructure across the web. Much like many services on the decentralized web, the nodes will be run by interested parties like corporations, individuals and/or institutions. A simple diagram of this idea is displayed below.
Each of the Civil ID Hubs in this diagram may exist in different networks’ infrastructure and are publicly available to ensure that the data is not centralized in a single site or organization. An entity may choose where they would like to store their identity and can even store their identity or credentials on multiple ID Hubs.
In the “Person 1” example above, this individual created a DID and decided to store it on Civil’s own ID Hub. They purchase a widget from corp.com and are issued a verified claim of this purchase by corp.com’s identity. This individual decides to store this licensing claim at corp.com’s ID Hub. This claim can be checked by corp.com or by anyone to prove their purchase of the widget by retrieving corp.com’s DID and verifying the proof against their public key.
In the second example, this company needs to have a permit renewed by an institution. In this case, the company’s identity is stored on its own ID Hub. When the permit information is verified, the institution may issue a new verifiable claim to the company that states that the permit was renewed. The company then chooses to store the claim on their own ID Hub.
Lastly, the “Person 2” example is more of the same: an institution may issue a new verifiable claim to this individual that states that their driver’s license is valid. The individual may choose to store it in any ID Hub (in this case, an independent non-profit’s ID Hub).
The future
We are actively developing the Civil ID Hub and we have just started building on all the concepts and ideas mentioned above. It is not production-ready yet and the APIs / codebase is not stable, but we are working hard to reach those goals soon.
While we will run a Civil ID Hub initially, we encourage other organizations to kick the tires and run one (or several) for all their decentralized identity and verifiable credential needs.
Other things we are working on / Looking towards the future
- Server UI v1 to access claims and identities, along with claims verification and proofs.
- Integration with Kirby, which provides an simple user interface for logging in with DIDs, as well as storing and using verified claims to access content or other authorized-only use cases.
- As mentioned above, work on specifications and developing our DID method including reference resolvers and smart contracts.
- Work on generically handling DIDs and claims from other sources.
- As standards in this ecosystem emerge, moving ID Hub towards those standards.
- Peer-to-peer data sync to ensure redundancy and data consistency.
- Ensuring the cost of running and maintaining an ID Hub is as low as possible.
Contribute
The source code for Civil ID Hub is available here and is open for any code contributions, suggestions or ideas. Let us know what you think about Civil ID Hub and where it could fit or overlap with other projects.
Keep a lookout for future posts on the details mentioned above. We plan on talking more about our DID method, how we handle verified credentials and our future plans.
Thanks to Dan Kinsley, Megan Libby and Walker Flynn for their editing skills and contributions.
