Creating a Attestation
Pre-Readings: Verifiable Attestations
On the official site, we provide interfaces to create attestations. However, you can also self-generate locally and upload via the BitBadges API as well. Below, we provide information on how it works behind the scenes.
![](https://docs.bitbadges.io/~gitbook/image?url=https%3A%2F%2F2198930329-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F7R34Y0QZwgpUGaJnJ4dq%252Fuploads%252FQ5O2EHLijXnQXjj0R4wX%252Fimage.png%3Falt%3Dmedia%26token%3D892b9711-abab-4328-9db7-6412a70e5f78&width=768&dpr=4&quality=100&sign=a5f81075&sv=1)
The creation interface is as follows. All attestations are a series of one or more attestationMessages which can be either in 'json' or 'plaintext' messageFormat. The schema of the message is left up to the issuer.
Schemas
Like mentioned above, we leave the schema system up to the issuer. The only thing we store about the schema is the messageFormat = 'json' or 'plaintext'. Feel free to use existing models such as the W3C Verifiable Credentials model, or create your own.
You may also choose to reuse some data on the BitBadges or other blockchains as well (ex: must own this badge ID or issuer = manager of this collection or revocation = is this asset burned?). It is up to you how to define this in your schema.
If you are pointing to on-chain data, you should also consider privacy concerns. All data on the blockchain is public, so for example, you may not want to use on-chain revocations through badge transfers because anyone can see when/if that badge was revoked. Or, if you do use it, you may consider using privacy-preserving techniques (indistinguishable metadata, one-time use only addresses) so that nothing unintended can be learned.
Example W3C Verifiable Credentials
Data Integrity
The integrity of the data is committed to by a cryptographic signature as we will show below. This proves to any potential verifier that the issuer did indeed issue this attestation because a cryptographic signature cannot be forged. The signatures are stored by the holders along with the credential and presented to verifiers.
In a a system like this, typically, the attestation gains its credibility from the issuer, so there is inherently some trust there. However, you may also opt to use additional protection measures against a malicious issuer. For example:
On-chain map of ID -> signatures to protect against an issuer issuing duplicate IDs
On-chain map of badge ID -> attestation IDs to protect against duplicate attestations issued per badge
Anchor the signature on-chain to prove existence by a certain time and to maintain data integrity (more on this in the next page with anchors)
Standard Signatures
For standard signatures (scheme = 'standard'), you can sign 1 message (so attestationMessages.length = 1), and the dataIntegrityProof will be the resulting signature of the only message from your main key pair supported natively by BitBadges. See the signing transaction flow for more information on manually implementing signatures. No proofOfIssuance is required (can be left blank).
BBS+
For BBS+ signatures (scheme = 'bbs'), you can sign N attestationMessages and the dataIntegrityProof will be the BBS signature of those N message. On the BitBadges site, all BBS+ key pairs are one-time use only. The key pair is generated, signs the transaction, and then is discarded because it is never needed again.
Because BBS+ are not actually signed by your "main" address, we also require a proofOfIssuance to establish this link.
Public Keys
Public keys are currently only needed to be provided for Cosmos signatures in order to verify. Otherwise, you can leave them blank.
Metadata
Each attestation has metadata attached to it for display purposes (i.e. name, image, description). This metadata should be considered public and viewable by all parties (issuer, verifier, and holder).
Last updated