Credential Types

IBM Verify Credentials supports 3 types of credentials: Indy, JSON-LD, and BBS+. The purpose of this section is to help you determine which type of credential to use.

The table below compares the 3 types of credentials in terms of supported features. In order to choose a specific credential type, consideration should be given to the importance of these features for your use case.

Feature Indy JSON-LD BBS+
Selective disclosure Yes No Yes
Compound proofs Yes No Yes
Predicate proofs Yes No Not Yet
Signature blinding Yes No Yes
Private holder binding Yes No Yes
W3C Compliant Yes No Yes
NLS No Yes Yes
Small and fast No Yes Yes

Feature descriptions

This section describes the features which are supported by one or more credential types as referenced in the table above.

Selective disclosure

The credential holder can choose to reveal a subset of credential attributes to a verifier. For example, if Acme issues a credential to Alice with attributes A and B, then Alice can generate a cryotographic proof for Bob (the verifier) which reveals the value of attribute A but not of attribute B.

If selective disclosure is not supported for a credential type, it means that the holder must present the entire credential to the verifier.

Compound proofs

The holder can generate a single proof containing attributes from multiple credentials (e.g. showing both your driver’s license and your boarding pass at airport security).

Credential types which support

Predicate Proofs

A predicate proof allows a holder to prove to a verifier that a predicate is true (i.e. a boolean expression referencing an attribute value) without revealing the actual value of the attribute to be used in operations with a value provided by the verifier. For example, a predicate proof can be used to prove that a person is 18 years or older without revealing the actual age.

Signature Blinding

This allows the issuer’s signature, which is a unique value and therefore a correlating factor, to be randomized by the prover before it is shared with a verifier. This prevents one verifier (or multiple colluding verifiers) from being able to track the activity of a single prover. In other words, the issuer's signature can not be used as a "tracking beacon" by one or more verifier's to track a holder's activity.

Private Holder Binding

This allows a credential to be bound to a holder without creating a correlating factor for the holder that needs to be revealed upon presentation. Binding a credential to a particular holder is a requirement in order to prevent the credential from being forwarded by the holder to others, and doing this in a privacy-preserving manner prevents verifier's from being able to use this as a "tracking beacon" tp trackand holder's activity

W3C Compliant

W3C Verifiable Credentials is an important standard in order to be interoperable.


The JSON-LD format as is used by both JSON-LD and BBS+ credential types has built-in National Lang. See JSON-LD language indexing for more information.

Small and Fast

This section does not provide exact metrics pertaining to the size of the cryptographic keys and the speed of various cryptographic operations; however, in general, JSON-LD and BBS+ are smaller and faster than Indy-based credential types.

Cryptograpic curves and formats

Each credential type consists of two parts:

  1. the cryptographic curve (or signature scheme) which is used to perform primitive cryptographic operations such as creating or verifying a digital signature, creating derivation keys, etc;

  2. the format of the data such as the schema, credential, or proof.

The following table shows both the crytographic curve and the format associated with each type of credential. BBS

| Credential type | Cryptographic Curve | Format | | --------| -----| --------| ---- | | Indy | ed25519 | JSON | | JSON-LD | ed25519 | JSON-LD | | BBS+ | bls12381g2 | JSON-LD |