Issuing a SD-JWT Credential
Learn about issuing SD-JWT credentials which includes hashing, creating disclosures and adding decoy hashes
Last updated
Learn about issuing SD-JWT credentials which includes hashing, creating disclosures and adding decoy hashes
Last updated
Credential Creation: The issuer first creates the credential, as usual.
Conversion to SD-JWT Credential: The issuer then transforms the credential into an SD-JWT. This is done by hashing all or only a subset of claims, adding decoy hashes, and preparing disclosures. At the end, the SD-JWT credential can contain plain-text claims next to disclosable ones.
Claim Hashing: The claim is transformed into a disclosure, which is a plain-text representations of the claim, by concatenating the attribute name and value, then prefixing it with a salt. The salt prevents attackers from guessing plain-text values via dictionary attacks. This is then converted to a base64 string, which will represent the disclosure. For example, the disclosure may look like this (salt + attribute name + value): [ “dC12Y2xpYi9tYXN0ZXI”, “given_name”, “John” ]. The disclosure is then put into a hash function, and the result gets included in the SD-JWT.
Adding Decoy Hashes: At this point, decoy hashes are also added to the SD-JWT. These decoy hashes are essentially dummy values that help conceal the actual number of claims a credential holds. By using decoy hashes, the issuer can prevent potential observers from determining how many claims are contained within the credential based on the number of hashes.
SD-JWT Credential Transfer to Holder: The issuer sends the SD-JWT and all disclosures to the holder. Because the holder now has the SD-JWT credential as well as all the disclosures, he can read the entire content of the credential. This allows the holder to decide which disclosures to send alongside the SD-JWT in a transaction with a verifier.
Transfer Format: On transfer, the SD-JWT is shared with the concatenated disclosures using the ~ sign. An example of this format would be:
Using either the CLI, Kotlin or REST option, you can start issuing your SD-JWT credential.
Setup section, if you never used the SSi-Kit before.
I will be using ssikit as an alias for ./ssikit.sh in this section.
Creating a did:key for our SD-JWT credential. Please refer to DIDs section for all options.
Example Response
We will be using the VerifiableId credential template for this example, but you can use whatever template you want. When issuing we specify the format of the VC as SD-JWT, the fields which we want to make selectily discloable and the number of decoy digests we want to include (optiona).
Options:
-s, --subject-did: DID of the subject
-i, --issuer-did: DID of the issuer
-y, --proof-type: Either JWT, LD_PROOF or SD_JWT
-t, --template: VC template, e.g VerifiableId
--sd, --selective-disclosure: Path to selectively disclosable fields (if supported by chosen proof type), in a simplified JsonPath format, can be specified multiple times, e.g credentialSubject.dataOfBirth
--num-decoys: Number of SD-JWT decoy digests to add (fixed mode), or max num of decoy digests (random mode)
--interactive: Interactively prompt for VC data to fill in
vc.txt: Path to output the generated VC
Example Response
Receiving a JWT token with disclosures appended via '~'.
Viewing body of SD-JWT in JSON format
Options:
-c: credential content or file path
Example Responsen