#Issuer Identifiers

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

#What's included

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

#DID-based Identifiers

Your issuer 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 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
• did:ebsi – EBSI-compliant DID for European ecosystem interoperability

#X.509 Certificate-based Identifiers

Your issuer 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 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.

#Key Management Integration

Regardless of which identifier method you choose, the underlying cryptographic keys used for signing are stored and managed through the Community Stack's key management system.

For proof-of-concepts and testing, local key storage is available. For production deployments, external key management systems keep key material secure (Hashicorp Vault, Azure Key Vault, AWS KMS, OCI Vault, 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.

What's the difference between a DID and a key?
A key is the cryptographic material used to sign credentials. A DID is a persistent identifier that resolves to a DID document containing keys (and other metadata). Keys can be rotated; the DID stays the same. A "direct key reference" uses the key itself as an identifier, which means rotating the key changes the identifier.

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

#Get Started

• Set up your issuer – Configure your first issuer.
• Key management – Learn how to securely store and manage the cryptographic keys backing your issuer identifier.
• Issue your first credential – See how your identifier appears in issued credentials and how wallets verify it.