> 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/references-and-standards.md).

# References and Standards

The Issuer Service is built on open, standards-based specifications so that the credentials it issues remain interoperable with third-party wallets and verifiers. The references below cover the credential data models, identifier methods, issuance and presentation protocols, and query languages the service implements.

## Credential data models and formats

* **W3C Verifiable Credentials Data Model**: <https://www.w3.org/TR/vc-data-model/> The underlying data model for verifiable credentials. The service issues **JWT-VC-JSON** credentials (`jwt-vc-json` / `jwt_vc_json`) that follow this model.
* **SD-JWT VC (Selective Disclosure JWT Verifiable Credentials)**: <https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/> The format used for **SD-JWT VC** credentials (`vc+sd-jwt` / `sd-jwt-vc`). Each SD-JWT VC carries a `vct` (Verifiable Credential Type) and supports selective disclosure of individual claims. For example, a schema named `EmployeeBadge` at version `1.0` yields the credential configuration `EmployeeBadge@1.0:sd-jwt`.
* **Selective Disclosure for JWTs (SD-JWT)**: <https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/> The underlying mechanism that lets a holder reveal only selected claims when presenting an SD-JWT VC. A schema's `disclosureFrame` declares which claims are selectively disclosable.

## Identifiers

* **DID Core Specification**: <https://www.w3.org/TR/did-core/> The base specification for Decentralized Identifiers and DID documents.
* **DID Method: `did:web`**: <https://w3c-ccg.github.io/did-method-web/> HTTPS-resolvable DIDs. The service hosts the DID document itself and serves it at `/{uuid}/did.json` (also at `/{uuid}/.well-known/did.json`).
* **DID Method: `did:key`**: <https://w3c-ccg.github.io/did-method-key/> Self-contained DIDs (Ed25519) that encode the public key directly in the identifier, requiring no network lookup.

## Issuance and presentation protocols

* **OpenID for Verifiable Credential Issuance (OpenID4VCI)**: <https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html> The protocol the Issuer Service uses to deliver credentials to wallets. The service implements the pre-authorized code flow with an optional PIN.
* **OpenID for Verifiable Presentations (OpenID4VP)**: <https://openid.net/specs/openid-4-verifiable-presentations-1_0.html> The protocol used to request and receive verifiable presentations from wallets when a credential is later presented to a verifier. Authorization requests can target versions `v1`, `v1.draft21`, or `v1.draft24`.

## Presentation query languages

* **DIF Presentation Exchange v2**: <https://identity.foundation/presentation-exchange/> Describes the credentials a verifier requires in a presentation request.
* **DCQL (Digital Credentials Query Language)**: <https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-digital-credentials-query-l> The OpenID4VP-native query language, supported as an alternative to DIF Presentation Exchange.

## Ecosystem context

For the `did:empe` method and the EMPE blockchain, see [Terminology and Concepts](/develop/issuer/terminology-and-concepts.md).


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.empe.io/develop/issuer/references-and-standards.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.