Your credentials explained
A breakdown of every credential type in SOTRU — what each one proves, what data it contains, and how contacts verify it.
Personal credentials
These credentials are issued to you as an individual and live in your personal workspace wallet.
Person ID Credential
Issued after completing personal identity verification (KYC). This is the foundational individual credential on SOTRU — most other features and credentials require it first. It confirms your legal name, that you passed a document scan and liveness check, and that your identity is linked to your SOTRU account.
Person Bank Account Credential
Issued after verifying a South African bank account against your personal identity through an AVS (Account Verification Service) check. Confirms that a specific bank account belongs to you as a verified individual. Your Person ID Credential must be issued first before you can earn this one.
Business credentials
These credentials are issued to your organisation and live in your organisation workspace wallet.
Business ID Credential
Issued after completing business identity verification (KYB). The foundational business credential on SOTRU — required before your organisation can share verified credentials with contacts. It confirms your company is a registered legal entity, with the following fields verified directly against CIPC records:
- Commercial Name
- Registration Number
- Commercial Type (e.g. Private Company)
- Commercial Status (e.g. In Business)
- Registration Date
- Tax Number
- Country of Registration
- Verified Against Source (CONTACTABLE | CIPC)
- Source Verification Date
Bank Account Credential
Issued after verifying a South African bank account against your business identity. Confirms that a specific account belongs to your verified organisation. Your Business ID Credential must be issued first.
Personal and business credentials are completely separate. Your Person Bank Account Credential lives in your personal workspace; your organisation's Bank Account Credential lives in the organisation workspace. Contacts see whichever set of credentials corresponds to the workspace they are connected with.
How sharing works
When you share a credential with a contact, you're not sending a PDF or a screenshot — you're sharing a verifiable presentation. This is a cryptographically signed package that lets the recipient verify the credential's authenticity for themselves, without needing to contact SOTRU or the issuer.
The recipient can independently confirm:
- The credential was signed by the stated issuer and hasn't been modified
- The issuer hasn't revoked it since it was issued
- The credential was issued to your account specifically — not copied from someone else
Shared credentials appear in the contact's Trust Vault and can be re-verified at any time.
A contact viewing your Trust Vault only sees credentials you've made visible to connections. Sharing additional credentials in a conversation — for example, in response to a verification request — requires your explicit action each time.
How SOTRU determines if a credential is trusted
When you receive a credential from a contact or view one in a Trust Vault, SOTRU evaluates it against three trust pillars. All three must pass for the credential to be considered fully trusted.
Cryptographic trust
This confirms the credential hasn't been forged or tampered with. SOTRU runs three checks automatically:
Signature check. Confirms the credential was digitally signed by the stated issuer and that the contents haven't been altered since it was issued. If even a single character has changed, this check fails.
Revocation check. Confirms the issuer hasn't withdrawn the credential. Issuers can revoke credentials at any time (for example, if a company is deregistered). SOTRU checks revocation status each time you view or verify a credential.
Holder binding check. Confirms the credential was issued to this specific account and hasn't been transferred from another. This prevents someone from copying a credential that was issued to a different person or organisation.
If all three cryptographic checks pass, the credential is structurally sound. If any check fails, the credential is flagged and should not be trusted.
Ecosystem trust
This confirms the issuer is part of SOTRU's trusted ecosystem. Not just anyone can issue credentials on SOTRU. Ecosystem trust means the issuer has been recognised and approved within the SOTRU network as an authoritative source for that type of credential. For example, business identity credentials are verified against CIPC through trusted verification providers. A credential issued by an unrecognised source outside the SOTRU ecosystem would not pass this check.
Content trust
This confirms the information inside the credential is still current and reliable. A credential can be cryptographically valid and issued by a trusted source, but if the underlying data is outdated, it may no longer reflect reality. Content trust evaluates whether the attributes in the credential (company status, registration details, bank account information) are stale or have been superseded by newer information. The source verification date on each attribute shows when that data point was last confirmed against the original source.
A credential that passes cryptographic checks but comes from an unrecognised issuer isn't trustworthy. A credential from a trusted issuer with outdated content isn't reliable. SOTRU evaluates all three pillars together so you don't have to assess each one manually.
Technical identifiers
Every credential carries three decentralised identifiers that allow its origin to be independently verified on the ledger. Click Show technical identifiers on any verification report to view them.
Issuer DID. The decentralised identifier of the organisation that issued the credential. This is the on-ledger identity of the issuer — not just a name, but a cryptographically verifiable address.
Schema DID. Identifies the structure the credential conforms to — the defined set of fields and their types. Two credentials of the same type will share the same Schema DID.
Credential Definition DID. Identifies the specific version of the schema used by this issuer. This allows the cryptographic signature to be traced back to the exact key the issuer used when creating credentials of this type.
