What is Ceramic?
Composability has roots in the open-source technology movement and was critical to the Internet's early growth. Web3 needs composability to unlock value for users and foster innovation. In application development, composability refers to the ability to combine existing components and reassemble them to create new products.
In a composable architecture, every component has a specific use case. Developers can then combine these components and add new functionality to build applications—without having to reinvent the wheel or build from scratch.
Ceramic is a decentralized network for composable data. By letting you browse a marketplace of data models, plug them into your app, and store, update, and retrieve data from those models, Ceramic makes creating applications with composable Web3 data simple. Their data is automatically interoperable when various applications reuse the same data models. Ceramic makes data composable and reusable across all applications by decentralizing application databases.
Check out this great article
Decentralized Identifiers (DIDs)
DIDs are globally distinct identities that can be used to interact with any off-chain services or data as well as sign documents on the Ceramic network. More specifically, they are abstract, key-agnostic interfaces used to uniquely identify entities, interoperable sign and encrypt information, authorize authentication/access control to services, and store mappings to additional resources.
A DID can be a user, an organization, an application, a service, a device, etc. because Ceramic makes no assumptions about the type of entity it represents. DIDs are flexible and interoperable across wallets and platforms because they can be controlled by one or several private keys. By using DIDs to manage data stores, data can traverse platforms and blockchains and be associated with any entity, including NFTs.
DID methods
A DID method is defined by a DID method specification, which specifies the precise operations by which DIDs and DID documents are created, resolved, updated, and deactivated. DID methods are DID specifications that have been put into practice.
A DID resolver that can return a DID document given a URI that complies with that specific DID method is required. DID methods must also specify a name for the method in the form of a string (see below), a description of how the DID document is generated statically, and the location of the DID document's storage. The official DID registry maintained by the W3C lists more than 40 DID methods. Ceramic currently supports PKH DID method, 3ID DID method and the Key DID method. DID URIs look like this:
did:<method-name>:<method-specific-identifier>
3ID DID Accounts
The first and most widely used DID method on Ceramic is 3ID. More than 15,000 3IDs are already being used in production. The 3ID DID Method (CIP-79) is a Ceramic-native account which can be used to authenticate to Ceramic to perform transactions on streams.
3ID is a DID method that is implemented natively on Ceramic. The data that makes up the DID document for the 3ID is stored in a mutable stream that is created using the Tile Document StreamType. Since its updates must be anchored into a blockchain and provide explicit versions and proofs of publication at specific points in time, the Tile Document StreamType supports secure key rotation for 3IDs (blockheights). As a result, 3ID inherits this attribute.
The 3ID DID Method is on the W3C's official DID method registry and is fully compliant with decentralized identity standards.
Multiple keys, secure rotations: The DID Document for the 3ID DID Method is implemented using a Ceramic Tile Document, as was previously stated, making it fully mutable and capable of supporting the secure addition and removal (rotation) of keys. This makes it possible for 3ID DIDs to manage multiple keys at once and remove keys as necessary.
Support for blockchain wallets: A 3ID DID can be controlled from a user's current blockchain wallets when used with the Identity Index protocol (CIP-11) and the 3ID Keychain definition (CIP-20). 3ID Connect is in charge of implementing this functionality.
Aggregated identities: All of a user's blockchain and Web3 accounts can control their 3ID DIDs from any L1 or L2 protocol, acting as a cross-chain identifier. Through this, a user's identity can be unified across all other platforms.
Great for end users: Due to all of the reasons above.
3ID Connect
3ID Connect is an authentication system that allows users to use blockchain wallets to interact with browser-based Ceramic apps.
3ID Connect is an account & key management application run in an iFrame, which is privately controlled by users and can be accessed by wallets and applications during onboarding. A user-controlled, iFrame-based application for managing accounts and keys called 3ID Connect can be accessed by wallets and other applications during onboarding. The Oauth consent flows that users have grown accustomed to on web2—such as signing into apps with Facebook, Google, Twitter, or Github—are very similar to the new 3ID Connect flow. However, 3ID Connect offers much more robust, user-centric identity and data storage capabilities for your application.
3ID Connect uses the Ceramic Network’s dedicated 3IDProvider (via IdentityWallet SDK) to deliver a more feature-complete, secure, friendly, and cross-chain experience. There are many reasons to love 3ID Connect, but here are some highlights:
- Secure key material 🔐
- Data consent clarity ✅
- Fewer wallet signatures 🔑
- Standalone 3ID provider 🆔
- Multi-address support 🔗
- Multi-network support 🕸
- Contract wallet support 🛡
- Ceramic Network compatibility 🔸
To improve the onboarding flow in your application and get started with 3ID Connect today, check out this tutorial
Further Reading
Check out the other posts in this three-part series on 3ID Connect:
- What is 3ID Connect?
- Add authentication with new blockchains in 3ID Connect
- ID DID Method specification
- W3C DID specification
- TileDocument StreamType
DID PKH (CIP-79)
There are hundreds of billions of on-chain, balance-holding accounts across the major 50 or so blockchains, all secured and namespaced using similar technologies. Most of them use public keys that are provided at the time of the transaction and are hashed or otherwise obscured as their identifiers.
These accounts are used to protect billions of dollars in assets and critical digital infrastructure. Governments and businesses are also actively experimenting with and utilising them. They are quickly developing into a significant form of shared data infrastructure across continents and industry verticals. DIDs should favor usability where possible, and it is extremely beneficial from a security & human computer interaction perspective to have DIDs that readily correspond to their equivalents on decentralized networks.
The primary goal of the DID PKH method is to allow any valid blockchain address to "spin up" a feature-limited but valid and widely interoperable DID and DID Document, valid in a limited context where accounts are represented by DIDs. By enabling interoperability between blockchain accounts and DIDs, PKH DID accounts enable users to directly sign, authorise, and authenticate using their blockchain account. The related blockchain account has complete control over a PKH DID account; key rotations, changes, deactivation, etc. are not supported.
This approach's extreme narrowness and neutrality enable a variety of implementations. For example, the validity of each address to be wrapped in a DID is checked according to the CAIP-10 standard before generating, to prevent a did:pkh being presented as valid that would not be on its corresponding blockchain. Implementers may still decide to gate generation to on-chain accounts or balance-holding accounts based on the needs of their particular use case even though no additional validation is assumed or offered in the reference implementation.
Additional reading
Key DID
A DID method statically generated from any Ed25519 key pair. Key DIDs are typically used for developer accounts. Key DID is lightweight, but the drawback is that its DID document is immutable and has no ability to rotate keys if it is compromised.
It is the most basic DID method. When resolved, it merely encrypts a public key in the DID string and turns it into a DID Document. Key DID is on the W3C's official DID method registry and is fully compliant with decentralized identity standards. Before choosing to apply the Key DID Method to your project, carefully read the considerations listed below:
One key only: The DID Document for a Key DID is specifically linked to a solitary cryptographic key. In order to control the DID, only one key can ever be used, and it can never be changed in the event that it is compromised. It cannot support multiple keys in the DID document, nor can it support key rotation.
For advanced users: The Key DID Method is generally not suitable for identities for non-technical end users because it is only suitable for advanced users who will only ever want to use one keypair to control their DID and who have strong key security practises, such as a developer.
Additional reading
NFT DID (experimental and not recommended for production use)
NFT is a DID method that uses the Ceramic network to resolve DID documents for NFTs. A DID method for any NFT on any blockchain. The DID document is statically generated from on-chain data. The DID associated with the blockchain account of the asset's current owner (using CAIP-10 Links) is the only entity authorized to act on behalf of the NFT DID, authenticate in DID-based systems, and make updates to streams or other data owned by the NFT DID. When ownership of the NFT changes, so does the controller permissions.
Any non-fungible token on any blockchain can be turned into a decentralised identifier using the NFT DID Method, where the NFT's owner serves as the DID's controller. This is accomplished by describing NFT assets and blockchain accounts using Chain Agnostic Improvement Proposals, and by locating the NFT owner's DID on the Ceramic network.
Extensible, mutable NFT metadata – At the moment, NFTs have fixed metadata that is created at token issuance. What happens, though, if we want an NFT to be able to gather data over time? With the help of NFT DID, an NFT owner can annotate an NFT with extra information that changes over time, such as a social graph for the NFT, a background story for the artefact, owner-restricted content, or, for instance, a certificate for carbon offsetting.
How does it work? When resolving an NFT DID account, Ceramic and the did-nft-resolver perform the following steps:
- Using a subgraph on the The Graph protocol, Query a blockchain for the owner(s) of the NFT.
- For each owner, find a corresponding CAIP-10 Link (CIP-7), which provides a link from blockchain account to Ceramic account. This determines who can write to the stream.
- When a transaction is sent to the stream owned by the NFT, verify the Ceramic account that signed the message is linked to the blockchain account that is a current owner.
Additional reading
- NFT DID Method (CIP-94) Specification
- Full implementation of CIP-94
- NFT DID Resolver
- Project that is using NFT DID Resolver
- Asset Reference for the ERC721 Asset Namespace - CAIP-22
Safe DID (experimental and not recommended for production use)
A DID method for a Gnosis Safe smart contract on any blockchain. Typically used for organizations, DAOs, and other multi-sig entities.
Accounts with the Gnosis Safe DID Method (CIP-101) can conduct stream transactions. The active participants in a Gnosis Safe smart contract manage the Safe DID accounts. Despite being fully compliant with decentralised identity standards and being listed on the W3C's official DID method registry, Safe DID is still very experimental. Use at your own risk.
Safe account
Every Gnosis Safe contract becomes a Ceramic account with the ability to send transactions to streams on Ceramic thanks to the Safe DID Method. It is similar to the NFT DID account method in both design and application.
Only the DIDs of the blockchain accounts that manage the Gnosis Safe contract are allowed to write permissions for streams whose controller is set to a Safe DID. The write permissions to streams owned by the Gnosis Safe also change when the controller permissions for the Safe are modified on-chain.
Additional reading
That’s it for this tutorial! Hope you found it useful and thanks for reading 😁.
Top comments (0)