1
Issuer identity on your own domain
The issuer’s identity is a DID derived from the issuer service’s host:
did:web:<host of ISSUER_ORIGIN>. The issuer service publishes a DID document at /.well-known/did.json, which lists the public keys verifiers use to check signatures. AIR does not generate this identity; the issuer owns it.2
Signing keys
The issuer’s partner key pair (
RS256 or ES256) signs two things: the credentials themselves, and the short-lived Partner JWTs that authenticate the issuer to AIR. The public half is published in the DID document and in a JWKS URL registered with AIR.3
Credential type
A schema registered in the Developer Dashboard defines the credential type (
vct) and its fields. The issuer service decides which claims each schema contains and which of them the user can selectively disclose.4
Issuance program
An issuance program connects the schema to the credential format (
SD_JWT_VC) and to settings such as Allow data disclosure. Apps start issuance with the program ID.5
Registered endpoints
In Issuer → Settings, the issuer registers where AIR can reach it: the preview endpoint (
available-vc), the issue endpoint (issue-vc), and the revocation status endpoint. AIR authenticates to them with the issuer’s API key.What runs where
Sandbox and production are separate. Configuration created in sandbox must be registered again in production.
Iden3 issuers are set up differently. Their identity is a
did:air:… DID derived from a secret seed held by the Iden3 issuer service, and they sign with a BabyJubJub key. See Issue Iden3 credentials.