A schema is a representation or configuration that defines the type and structure of data that is presented in the making of an attestation. Schemas create standards that allow an attestation to be accurate, composable, and insightful for any observer(verifier).

A Schema Registry serves as a central location for storing and referencing schemas for use in the creation of attestations. It also acts as a focal coordination point for the cultivation and curation of standards and processes that drive efficient and innovative capabilities of schemas.

A Schema Builder is a tool that is used to generate new and innovative schemas that make it possible for attesters to create rich, insightful, and certified attestations for all their needs.

Sign Protocol is designed to cater to a broad range of needs and use cases for attesters by offering diverse and versatile schemas. To achieve this, Sign Protocol provides a comprehensive suite of tools and features. This includes a Schema Registry, a Schema Builder, and a Schema Explorer, all of which are invaluable for those interested in creating, discovering, and utilizing schemas for attestations.

A helpful analogy to understand a schema is to envision it as a blueprint for an attestation.

The Purpose of a Schema

The primary purpose of a schema is to establish the rules that control what kind of data may be used in the creation of an attestation and how this must be organized to ensure that the attestation can be parsed and insightful to the verifier that is receiving and reviewing it to determine the validity of the attestation as a whole.

These rules effectively define an organizational structure and strict selection criteria for the data points that are introduced to provide context and provability in the making of an attestation.

An attestation is meant to vouch for the credibility of a given claim or assertion, such as an event, statement, etc. A schema facilitates how an attester provides the much-needed context and confirmation in the attestation they wish to create.

The use of a schema shapes the fashion and standards expected of an attestation, leading to significant efficiency enhancements in the functions of trust systems within a given ecosystem or setting.

Design of a Schema

Sign Protocol introduces a general configuration for schemas that consists of two core modules. These core modules and their respective sub-components are:

  1. Header - This module houses key metadata regarding the attestation that is being made. This allows a verifier to begin to infer relevant information about the attestation right from the header, even before analyzing the remaining attestation details. The header of a schema is made up of the following sub-components:

    • Attestation ID: A unique identifier for the Attestation, aiding in future cross-checks and references.

    • Claim Reference: Points to a pending or existing claim or assertion, represented as a URL or specific identifier.

    • Attester ID: A unique identifier (name, email, public key address, etc.) for the entity creating the Attestation.

    • Attester/Witness Signature: The cryptographic signature of the Attestation’s creator, serving as a self-certification.

    • Schema Registry ID: An identifier for referencing the schema used to generate the Attestation from a schema registry.

  2. Body - This module houses the full detailed context and data points of an attestation. It is where the Attester can provide extensive data and comprehensive information that aid in confirming the validity of a claim or assertion. The body of a schema is made up of the following sub-components:

    • Timestamp: Indicates the specific period when the attester observed the event or occurrence of the claim.

    • Subject ID (Claimant): An identifier for the subject entity that the attestation vouches for. This identifier typically points to the claimant.

    • Boolean: Enables the attester to explicitly indicate if the claim or assertion is true or false.

    • Cryptographic Proof: Cryptographic data that is used to prove the integrity and correctness of the details provided in the attestation. In some setups, it even ensures the privacy of the details while still being verifiable.

    • Evidence Data: A field that conveys rich details to support (or debunk) the claim or assertion being attested to. It comprises one or more fields of descriptive information.

Building a Schema

A schema is typically implemented in the style of a JSON structure which follows a key-value pair format for organizing data. With that said, a trivial way to build a schema is using a text editor, like Notepad, and saving it as a text file, or even in the post composer field of your favorite social media app and submitting it as a post.

Alternatively, there are more involved ways to build and deploy a schema, such as implementing it as blockchain-based scripts(a.k.a. smart contracts) and submitting it to a blockchain.

Sign Protocol empowers anyone to build rich and resourceful schemas for use in creating attestations, via the provision of a Schema Builder. The Schema Builder streamlines the schema-building process by offering intuitive flows and abstracts away some of the complexities and overhead faced when crafting a schema.

Sign Protocol’s Schema Builder provides a streamlined process for submitting custom schemas to a schema registry. Once submitted, these schemas can be accessed and utilized by attesters globally. Additionally, users have the flexibility to choose their preferred platforms for storing their schemas, such as a Blockchain or Data Storage system.

TL;DR: Schemas are a vital methodology that defines the nature of attestations, ensuring insightfulness, clarity, integrity, and standardization. A well-crafted schema forms the basis for a robust attestation ecosystem, influencing its comprehensiveness, utility, and versatility.

You can learn more about schemas in our blog post: Schemas: The Blueprint of Attestations

Last updated