πŸ‘¨πŸ‘©πŸ‘§πŸ‘¦
Community credentials
Requirements
Check the resources to see the idea boards and meetings behind this document

Credentials

The first version of community credentials that are being implemented.
​
Participation credential
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.
​
Completion credential
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.
​

User flow

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.
​

Requirements

Wallet requirements
  • Create wallet
  • Restore / import wallet
  • Create DID
  • Store DID on chain (for issuers)
  • View credential(s)
  • Remove credential
  • 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
​
Holder requirements
  • Wallet implementation - Requirements above cover everything needed for holder
​
Issuer requirements
  • 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
​
Verifier requirements
  • Verify credential is signed by issuer
  • Verify credential is owned by holder
  • Store verification result in database or similar
​

Requirement considerations

​
Credential templates
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.