Check the resources to see the idea boards and meetings behind this document
The first version of community credentials that are being implemented.
A participation credential represents a claim from an event organiser that someone has attended a given event. An example could be Catalyst Swarm holding an online Zoom session where anyone who participates in the event can be issued a credential that can be used by the holder to prove they participated.
A completion credential represents a claim from a organisation that someone has completed a certain thing such as a workshop or a specific task. An example could be Catalyst School hosting a workshop on how to become a community advisor. Participants who complete that workshop could be issued a credential that can be used to verify they completed the workshop.
Once initial tooling is created community projects can create user flows for their given use case for either participation or completion credentials. The credentials can be also verified by any number of projects who want to verify people have a given credential.
Below is an example flow where a community member is the holder, Catalyst Swarm is the issuer and projectcatalyst.org is the verifier. Both the issuer and verifier can be easily swapped with other projects that also want to issue or verify these same types of credential.
Example participation flow
Community member (holder) turns up to a live event session hosted by Catalyst Swarm (issuer)
Community member provides their identifier (DID) to the host of the session
Issuer stores the identifiers given by all participants who want a credential
Live event session starts and finishes
Host confirms participation of the community members who requested a participation credential
Host takes the list of identifiers and batch issues participation credentials to each qualifying community member
Credentials get hosted by the issuer for the community members to receive
Host shares link detailing to participants of how to import signed credential
Community member visits link and imports credential to their wallet
Community member visits projectcatalyst.org website (verifier) and presents their credential
projectcatalyst.org website verifies credential is owned by community member and was issued by Catalyst Swarm. If the credential is valid the website then adds the information from the credential to their profile which can now be shown to the community viewing that website.
Restore / import wallet
Store DID on chain (for issuers)
Verify credential(s) - A wallet needs to be able to know when credentials become revoked
Import signed credential
Present credential - Initially presenting whole credential to a verifier as there is no selective disclosure capabilities at present
Issue credential - Should be able to issue a credential based off a schema template explained below
Batch issue credentials
View issued credential(s)
Export issued credentials
Wallet implementation - Requirements above cover everything needed for holder
Wallet implementation - Required for issuing credentials to holder which includes creating a DID for the issuer and issuing, batch issuing, viewing and exporting credentials.
Add and remove DIDs from a temporary list of eligible holders seeking a participation credential
Host signed credentials for holders to import - Exported issued credentials from wallet then hosted by issuer for holder to import
Create credential template for issuer wallet to use
Host credential template to import into wallet
Verify credential is signed by issuer
Verify credential is owned by holder
Store verification result in database or similar
Issuers shouldn't need to write out all of the contents of a credential each time they issue them. Wallets shouldn't have templates hard coded into the wallets that should be multi-purpose and non opinionated. Wallets as a result should be able to import and parse credential templates. Some considerations to note:
Attribute replacement - Fields such as date fields like "createdAt" should be a valid template that at issuance time can be replaced by a timestamp automatically
Issuer value input - A schema should be able to mark which attributes in the schema require user input. A holders DID is one example of one that is always required but there could optionally be others such as the persons name of date of birth.
Pre-defined values - A template can simply store a pre-defined value such as a event participation template could include the name of the event which would stay the same for anytime that specific credential is issued.
Multi-role purposed wallet
People should be able to self attest claims and issue credentials to themselves. Issuers should also be able to receive credentials. Due to this wallets should support all the functionality required for holders and issuers.