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.
|Predicate proofs||Yes||No||Not Yet|
|Private holder binding||Yes||No||Yes|
|Small and fast||No||Yes||Yes|
This section describes the features which are supported by one or more credential types as referenced in the table above.
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.
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
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.
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 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:
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;
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