> For the complete documentation index, see [llms.txt](https://docs.empe.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.empe.io/develop/issuer/faq.md).

# 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.empe.io/develop/issuer/faq.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.