FAQ

Common questions about issuing credentials with the Issuer Service, answered against the current API behavior.

Q: How can I restrict who is able to claim or use a credential I issue? A: There are two complementary mechanisms. First, you can bind a credential to a specific subject by setting subjectDid when signing directly through POST /issuers/:issuerDid/credentials/sign — for SD-JWT VC the value is written to the sub claim, and for JWT-VC-JSON it becomes credentialSubject.id. Second, you can require a PIN on a credential offer by setting requirePin: true when calling POST /issuers/:issuerDid/credential-offers; the issuance response then returns a userPin that the holder must enter to complete the pre-authorized flow, so only someone who received the PIN out of band can claim the credential. There is no offering mode that targets a recipient DID and forces the wallet to prove ownership of it before claiming.

Q: Will updating a schema affect previously issued credentials? A: No. Issued credentials are self-contained and remain valid regardless of later schema changes. When you create a schema whose name already has an active version, the previous version is marked superseded and the new one becomes active. Superseded versions are hidden from the default listings, and GET /schemas/:schemaId returns 410 Gone for them — but you can still retrieve them by passing includeInactive=true, or list every version with GET /schemas/:schemaName/versions.

Q: How do wallets retrieve credentials? A: Issuance uses the OpenID4VCI pre-authorized code flow. You create an offer with POST /issuers/:issuerDid/credential-offers (or the /qr-code variant), which returns an openid-credential-offer://... URI. The holder scans the QR code or opens the offer link, enters the PIN if one is required, and the wallet then completes the pre-authorized exchange and receives the credential automatically — there are no separate authorization or token endpoints for you to call.

Q: Which credential formats and DID methods are supported? A: The Issuer Service issues credentials as SD-JWT VC (vc+sd-jwt / sd-jwt-vc) and JWT-VC-JSON (jwt-vc-json / jwt_vc_json). Issuer DIDs use the did:web and did:key methods; did:web documents are hosted and served by the service itself over HTTPS.

Q: Does the Issuer Service support selective disclosure? A: Yes, today, via SD-JWT VC. Declare which claims are selectively disclosable with disclosureFrame when creating a schema, or pass a disclosureFrame of the form { "_sd": ["..."] } when signing directly through POST /issuers/:issuerDid/credentials/sign. For example, a schema named EmployeeBadge (version 1.0) could mark employee_id, full_name and department as disclosable so the holder can later reveal only the claims a verifier asks for during a presentation. Selective disclosure applies to SD-JWT VC only; it is not available for JWT-VC-JSON.

Q: Can I rotate signing keys? A: Not yet. Keys are managed automatically by the Issuer Service. Configurable key rotation is planned for a future release.

Q: Will the Issuer Service support additional privacy features? A: Selective disclosure is already available through SD-JWT VC (see above). Zero-knowledge proofs (ZKPs) are being evaluated as a future enhancement for privacy-preserving credential presentations.