What is an issuer-signed credential?

An issuer-signed credential has three parts: a statement, the issuer’s signature over it, and enough information for a verifier to find the right public key. The issuer does its checking while it has the facts at hand, signs the result, and hands the credential to its holder. Later, a verifier who already trusts the issuer’s public key checks the digital signature locally.

The X.509 certificate is one example. RFC 5280 describes certificates as data structures that bind public key values to subjects, with the binding asserted by a trusted certification authority signing each certificate. It also notes the property that matters offline: because a certificate’s signature and validity period can be checked independently, certificates can travel over untrusted channels and be cached on the device that uses them.

Other formats follow the same pattern. A JSON Web Token carries an iss claim naming its issuer and an exp claim after which it must not be accepted. A verifiable credential in the W3C data model carries its issuer, validity dates and an optional status entry.

Offline Protocol’s OfflineID API issues a credential of this kind. Its documented fields bind an account ID, a username and an off1 device address, with issue and expiry times, the identifier of the issuer key, and an Ed25519 signature. A separate endpoint publishes the issuer’s public key, and the docs say to cache trusted issuer keys for offline verification and to handle rotation and expiry explicitly.

A valid signature is necessary but not sufficient. Before accepting an issuer-signed credential, a verifier should check:

1. The signature, against a public key it already trusts for this issuer, selected by the key identifier in the credential.
2. The issuer key itself, that it is one the verifier was given and has not been retired.
3. The validity window, that the current time is inside it. This depends on the verifier’s clock being right.
4. The subject, that the credential is about the party actually in front of it, and not a copy someone else is presenting.
5. The intended use, that the credential was issued for this application or audience.
6. Status, against the most recent revocation information the verifier holds.

Steps 1 to 3 and 5 are local calculations. Step 4 needs the holder’s participation, and step 6 needs information from the issuer.

A credential is data, and data can be copied. The W3C data model notes that it does not prevent replay on its own, giving the example of an event ticket presented by several people.

One fix is to make the credential name a public key and ask the presenter to prove they hold the matching private key. The verifier sends a fresh random value and the holder signs it, which is challenge-response authentication. RFC 5280 mentions the same idea on the issuing side: a certification authority can base its assertion on proof of possession through a challenge-response protocol before it signs.

The difficult part of issuer-signed credentials is learning that one is no longer good. RFC 5280 lists reasons a certificate may need revoking before it expires, including a change of name, the end of the relationship with the issuer, and compromise of the private key.

There are two classic ways to publish that information:

• Revocation lists. The issuer periodically signs a list of revoked serial numbers. RFC 5280 points out that lists can travel over the same untrusted channels as certificates, which suits offline use, but that a revocation only reliably reaches relying parties when the next list is issued, which it says may be up to one hour, one day or one week, depending on how often lists are published.
• Online status checks. OCSP, specified in RFC 6960, lets a client ask a responder about one certificate’s current status without needing lists. It needs a connection at the moment of checking, so it does not help a verifier that is offline.

RFC 5280 is direct about the consequence: if revocation information is untimely or unavailable, the assurance of the binding is reduced. Offline designs manage that with short validity windows, refreshing status lists whenever a connection appears, and deciding in advance how old status information may be for each kind of decision.

Everything rests on the issuer’s private key. If it leaks, anyone can sign credentials that verify. RFC 5280 also notes that a certification authority that loses its signing key cannot produce revocation lists. Publishing keys with identifiers makes key rotation possible: the issuer signs new credentials with a new key while verifiers keep the old public key until the credentials signed with it expire. Offline verifiers learn about a new or withdrawn key only when they next sync, so plan key changes well ahead of when they are needed.