#Issuer Identifiers

The Enterprise Stack supports multiple identifier methods for your issuer services—from decentralized identifiers (DIDs) with built-in hosting to traditional X.509 certificates. This gives you flexibility to align with your ecosystem's trust model, regulatory requirements, and operational constraints.

Each issuer service can use a different identifier method, and you can operate multiple issuers with distinct identity strategies within a single deployment.

#What's included

The Enterprise Stack supports three main approaches to issuer identification, each with different operational characteristics.

#DID-based Identifiers

Your issuer service uses a Decentralized Identifier (DID) as its identity. The DID resolves to a DID document containing the issuer's public keys, service endpoints, and metadata. When a verifier checks a credential, they resolve the issuer DID and verify the signature against the published keys.

Supported DID methods (via the DID Service) include, but are not limited to:

• did:key – Self-contained DID where the key is embedded in the identifier itself
• did:jwk – DID based on JSON Web Key format
• did:web – Web-based DID that resolves via HTTPS, with built-in hosting through the DID Registry Service

The DID Service creates DIDs on-demand (stateless). DIDs can be persisted using the DID Store Service for reuse across issuance operations.

#X.509 Certificate-based Identifiers

Your issuer service uses an X.509 certificate issued by a trusted Certificate Authority (CA). The certificate contains the issuer's public key and identity information. Verifiers validate credentials by checking the certificate chain back to a trusted root CA.

#Direct Key References

Your issuer service uses a direct cryptographic key reference (such as a JWK – JSON Web Key) without a broader identity framework. The key itself serves as the identifier, and trust is established through out-of-band mechanisms (pre-shared key lists, trust registries, or direct configuration).

#Trust & Verification

Identifier methods tell you who the issuer is. But verifiers also need to determine whether to trust that issuer for a given credential type.

Ecosystems establish trust through mechanisms like:

• Trust registries and trust lists (e.g., EBSI TAO, eIDAS2 trust lists)
• Certificate Authority hierarchies (traditional PKI trust chains)
• Direct trust relationships (pre-configured trusted issuers)

These trust mechanisms work independently of the identifier method you choose. A DID, certificate, or direct key can all be registered in a trust registry or validated against ecosystem policies.

#Multi-Tenant Identifier Support

Each tenant (or sub-tenant) in the Enterprise Stack can operate multiple issuer services, and each issuer service can use a different identifier method:

• Tenant A might operate one issuer service using did:web (hosted by the DID Registry), and another using X.509 certificates.
• Tenant B might use did:key for all its issuer services.

This means you can:

• Host multiple customers (organizations) in one deployment, each with distinct identity strategies
• Support different trust models within a single organization (e.g., decentralized DIDs for open credentials, PKI certificates for regulated credentials)

#Key Management Integration

Regardless of which issuer identifier method you choose, the underlying cryptographic keys used for signing are stored and managed through the Enterprise Stack's Key Management Service (KMS).

For proof-of-concepts and testing, local key storage (using the Enterprise Stack database) is available. For production deployments, external key management systems keep key material secure (Hashicorp Vault, Azure Key Vault, AWS KMS, etc.). Learn more here.

#FAQs

Do I need a DID to issue credentials?
No. You can use X.509 certificates or direct key references. The choice depends on your ecosystem's trust model and regulatory requirements.

Can different issuer services in my tenant use different identifier methods?
Yes. Each issuer service has its own identifier configuration. One service can use did:web, another X.509 certificates, and a third did:key – all within the same tenant.

Can I switch identifier methods later?
Yes, but previously issued credentials will still reference the old identifier. Switching is effectively creating a new issuer identity. Plan your identifier strategy early; changes require ecosystem coordination (updating trust registries, verifier configurations, etc.).

Can I share a DID across multiple issuer services?
Yes. You can use organization-level DIDs to share an identifier across multiple tenants (e.g., departments within a company), or tenant-level DIDs to share across multiple issuer services within the same tenant.

#Get Started

• Set up a Key Management Service – Create a KMS service to manage keys for your issuer identifiers.
• Create DIDs – Learn how to create DIDs using the DID Service.
• Set up DID Web hosting – Configure the DID Registry Service to host did:web identifiers.
• Set up an issuer service – Create an issuer service.
• Issue your first credential – See how to configure the identifier in a credential.