@@ -1913,6 +1913,11 @@ $config = [
      *  - DidJwk: `kid` is the issuer's `did:jwk:...#0` and `iss` is the same
      *    `did:jwk:...`. The token carries the key with it, so it verifies without
      *    any external lookup. This is the default.
+     *  - DidWeb: `iss` is the did:web set under
+     *    OPTION_VCI_ISSUER_DID_IDENTIFIER and `kid` names the key in the DID
+     *    document this module publishes for it, matching how credentials are
+     *    identified under the same issuer identity. Requires that option to be
+     *    set, and requires the published document to stay reachable.
      *  - Jwks: `iss` is this module's issuer URL and `kid` is the JWKS key ID,
      *    so the key is resolved through the published JWKS. Use this for Relying
      *    Parties which will not accept a `did:jwk` key identifier.
@@ -1922,6 +1927,19 @@ $config = [
      * lists keep being served under the profile their holders already resolved
      * them by. Changing it therefore never invalidates credentials which are
      * already in wallets.
+     *
+     * A list created under DidWeb also records the identifier itself, for the
+     * same reason it records its signing key: changing or clearing
+     * OPTION_VCI_ISSUER_DID_IDENTIFIER routes new credentials to new lists
+     * rather than changing the issuer of tokens already being verified. Keep the
+     * DID document published for every identifier any unretired list still
+     * names. The administration screen lists the identities credentials were
+     * issued under, which covers these too unless credentials are issued under
+     * some other identity than the Status Lists are.
+     *
+     * Note that a deployment which creates a DidWeb list can not be rolled back
+     * to a release without this profile: an older process reading such a row
+     * fails rather than guessing an identity for it.
      */
     ModuleConfig::OPTION_VCI_STATUS_LIST_KEY_PROFILE => \SimpleSAML\Module\oidc\Codebooks\StatusListKeyProfileEnum::DidJwk,
 
 
@@ -860,13 +860,39 @@ key it was signed with is a deployment choice:
 
 - `did_jwk` (default): `kid` is the issuer's `did:jwk:...#0` and `iss` is the same `did:jwk:...`. The
   token carries the key with it and verifies without any external lookup.
+- `did_web`: `iss` is the `did:web` set under `OPTION_VCI_ISSUER_DID_IDENTIFIER` and `kid` names the
+  signing key in the DID document this module publishes for it. This is the profile which makes a
+  credential and the Status List Token it points at name the same issuer under the same resolvable
+  identity. It requires that option to be set — a pool on this profile without one is a configuration
+  error rather than something discovered when a token is signed.
 - `jwks`: `iss` is this module's issuer URL and `kid` is a JWKS key ID, so the key is resolved through
   the published JWKS. Use this for Relying Parties which will not accept a `did:jwk` key identifier.
 
 Each list records the profile it was created under. Changing the setting therefore routes newly issued
 credentials to newly created lists, while existing lists keep being served under the profile their
 holders already resolved them by — so changing it never invalidates anything already in a wallet.
 
+**A `did_web` list also records the identifier, not just the profile.** It has to: unlike the other two,
+that identifier is a setting of its own which can be changed or cleared while lists created under it are
+still being served. Reading it afresh at signing time would silently rewrite the `iss` of every token
+those lists emit, leaving a wallet holding a credential naming one issuer and a status token naming
+another. Because the identifier is recorded, changing it behaves like every other policy change: new
+credentials go to new lists, and the old lists go on naming the issuer they were created under.
+
+The obligation that follows is the same one credentials carry. **Keep the DID document published for
+every identifier an unretired list still names**, not only for the one currently configured — a Relying
+Party checking a credential's status has to resolve the token's issuer, and a `404` there is
+indistinguishable from a revoked deployment. The Verifiable Credential configuration screen lists the
+identities **credentials** were issued under, which answers this too whenever credentials are issued
+under the same `did:web`. It does not cover the case where they are not — a deployment naming its
+credentials some other way while its Status Lists use `did:web` has to track the identifiers of its
+unretired lists itself.
+
+**Selecting `did_web` is a one-way upgrade.** Once a list has been created under it, the deployment can
+no longer be rolled back to a release that predates the profile: an older process reading that row
+refuses it rather than guessing an identity, which takes that list's endpoint down. Roll the code
+forward everywhere before switching a pool onto it.
+
 **A signing key has to outlive every list signed with it.** Each list records the key it was created
 with and is re-signed from that key alone, never from whichever key is current. Rotating keys is
 therefore safe in itself: new lists take the new key, existing lists keep theirs. Removing the old key
@@ -883,7 +909,9 @@ when the list matters most.
 Whether credentials stay verifiable in the meantime depends on the profile. A `did_jwk` token carries
 its own key, so tokens already published keep verifying. Under `jwks` the key is resolved through this
 module's published JWKS, which the same removal empties, so already published tokens stop verifying too
-once Relying Parties refetch it. A key is only safe to discard once every list it signed has been
+once Relying Parties refetch it. `did_web` behaves the same way as `jwks` here: the key is named in the
+published DID document, which is built from the configured keys, so removing one withdraws it there
+too. A key is only safe to discard once every list it signed has been
 retired, which the lifecycle below does only after the last credential in those lists has expired.
 
 ### Credential expiry
 
@@ -27,6 +27,19 @@ enum StatusListKeyProfileEnum: string
      */
     case DidJwk = 'did_jwk';
 
+    /**
+     * `iss` is the deployment's configured `did:web`, and `kid` the verification method that DID's
+     * published document names for the signing key, matching how Verifiable Credentials are identified
+     * under the same issuer identity. Unlike `did_jwk`, the token does not carry its key: a Relying
+     * Party resolves the document over HTTPS, which is what lets the same issuer name outlive any one
+     * key. Requires a configured issuer `did:web` identifier, whose document this module publishes.
+     *
+     * The identifier is recorded on each list at creation, so a list keeps naming the issuer it was
+     * created under even after the configured one changes -- and that document therefore has to stay
+     * resolvable for as long as any credential pointing at the list is still being verified.
+     */
+    case DidWeb = 'did_web';
+
     /**
      * `iss` is the module's issuer URL and `kid` is the JWKS key ID, so a Relying Party resolves the
      * key through the issuer's published JWKS. Use this for Relying Parties which will not accept a
 
@@ -70,6 +70,12 @@ public function __invoke(): JsonResponse
      * the database did, taking down verification of every ID token and access token this issuer has
      * ever signed. That is a far larger failure than the one it would prevent.
      *
+     * Asked of the raw configured values rather than of the built pools, which matters for the same
+     * reason. Building them is all or nothing: one pool misconfigured in any way -- a bad bit count, or
+     * an issuer `did:web` which only another pool's profile even reads -- would make the whole bag
+     * unreadable, this question answer "no", and the key that a perfectly good `jwks` pool's already
+     * published tokens are verified through be withdrawn over a setting those tokens never used.
+     *
      * The gap this leaves is an operator removing a pool, or switching it to the other key profile,
      * while lists created under the old one are still being served. That is the same class of change as
      * removing the signing key itself, and it is caught where it can be acted on: publication resolves
@@ -78,19 +84,14 @@ public function __invoke(): JsonResponse
     protected function isAnyStatusListKeyPublished(): bool
     {
         try {
-            foreach ($this->moduleConfig->getVciStatusListPoolBag()->getAll() as $pool) {
-                if ($pool->getKeyProfile() === StatusListKeyProfileEnum::Jwks) {
-                    return true;
-                }
-            }
+            return $this->moduleConfig->isAnyStatusListPoolOnKeyProfile(StatusListKeyProfileEnum::Jwks);
         } catch (Throwable) {
-            // A pool which can not be resolved is reported on the configuration overview screen, which
-            // owns that error. Here the conservative reading is that no pool needs its key published,
-            // which leaves the key set exactly as it was before Status Lists existed.
+            // Only a pool list or a default key profile which can not be read at all reaches here, and
+            // both are reported on the configuration overview screen, which owns that error. The
+            // conservative reading is that no pool needs its key published, which leaves the key set
+            // exactly as it was before Status Lists existed.
             return false;
         }
-
-        return false;
     }
 
 
 
@@ -1829,6 +1829,67 @@ public function getVciStatusListKeyProfile(): StatusListKeyProfileEnum
     }
 
 
+    /**
+     * Whether any configured Status List pool signs under the given key profile.
+     *
+     * Answered from the raw configured values rather than by building the pools, and that is the point
+     * of it. The JWKS endpoint asks this to decide whether the credential signing key still has to be
+     * published, and a pool misconfigured in any way at all would otherwise make the whole bag
+     * unreadable and the answer "no" - withdrawing the key that a different, perfectly good pool's
+     * already published tokens are verified through. A question about one pool must not be answerable
+     * only while every pool is valid.
+     *
+     * The pool bag asks it too, before resolving the issuer `did:web`, so that an option only the
+     * `did_web` profile reads is not consulted for a deployment which has no pool on it.
+     *
+     * A value which is not a valid profile at all counts as "no": the pool is about to be refused by
+     * name, which is a better error than one about whichever profile was being asked about.
+     *
+     * @param array<array-key,mixed> $pools
+     */
+    protected function isAnyStatusListPoolOnKeyProfileIn(
+        array $pools,
+        StatusListKeyProfileEnum $keyProfile,
+        StatusListKeyProfileEnum $defaultKeyProfile,
+    ): bool {
+        /** @var mixed $poolConfig */
+        foreach ($pools as $poolConfig) {
+            if (!is_array($poolConfig) || !array_key_exists(StatusListPool::KEY_KEY_PROFILE, $poolConfig)) {
+                if ($defaultKeyProfile === $keyProfile) {
+                    return true;
+                }
+
+                continue;
+            }
+
+            /** @var mixed $configured */
+            $configured = $poolConfig[StatusListPool::KEY_KEY_PROFILE];
+
+            if ($configured === $keyProfile || $configured === $keyProfile->value) {
+                return true;
+            }
+        }
+
+        return false;
+    }
+
+
+    /**
+     * Whether any configured Status List pool signs under the given key profile.
+     *
+     * @throws \SimpleSAML\Error\ConfigurationError On a malformed default key profile, which is the one
+     *         value this cannot be answered without.
+     */
+    public function isAnyStatusListPoolOnKeyProfile(StatusListKeyProfileEnum $keyProfile): bool
+    {
+        return $this->isAnyStatusListPoolOnKeyProfileIn(
+            $this->config()->getOptionalArray(self::OPTION_VCI_STATUS_LIST_POOLS, []),
+            $keyProfile,
+            $this->getVciStatusListKeyProfile(),
+        );
+    }
+
+
     /**
      * The configured Status List pools.
      *
@@ -1844,9 +1905,27 @@ public function getVciStatusListPoolBag(): StatusListPoolBag
             return $this->vciStatusListPoolBag;
         }
 
+        $pools = $this->config()->getOptionalArray(self::OPTION_VCI_STATUS_LIST_POOLS, []);
+        $defaultKeyProfile = $this->getVciStatusListKeyProfile();
+
         $poolBag = StatusListPoolBag::fromConfig(
-            $this->config()->getOptionalArray(self::OPTION_VCI_STATUS_LIST_POOLS, []),
-            $this->getVciStatusListKeyProfile(),
+            $pools,
+            $defaultKeyProfile,
+            // The module wide issuer identity, which the `did_web` key profile stamps onto every list
+            // it creates. Taken from here rather than configured per pool, so that a deployment cannot
+            // end up with two issuer identities of which only one has a published DID document.
+            //
+            // Resolved only when some pool is actually on that profile. Reading it unconditionally
+            // would mean a malformed did:web identifier -- an option no other profile looks at -- also
+            // stopping the pools from being read, and the JWKS endpoint answers "does any pool need its
+            // key published?" by reading them. A pool on the `jwks` profile would then have the key its
+            // already published tokens are verified through quietly withdrawn, over a setting it does
+            // not use.
+            $this->isAnyStatusListPoolOnKeyProfileIn(
+                $pools,
+                StatusListKeyProfileEnum::DidWeb,
+                $defaultKeyProfile,
+            ) ? $this->getVciIssuerDidIdentifier() : null,
         );
 
         $supportedIds = $this->getVciCredentialConfigurationIdsSupported();
 
@@ -323,19 +323,20 @@ public function create(
         int $refreshIntervalSeconds,
         string $signingKeyId,
         StatusListKeyProfileEnum $keyProfile,
+        ?string $issuerIdentifier = null,
     ): void {
         $this->database->write(
             sprintf(
                 'INSERT INTO %s (
                     id, uri, pool_id, policy_fingerprint, expiry_lane, generation, bits, capacity,
                     allowed_statuses, ttl_seconds, token_validity_seconds, refresh_interval_seconds,
-                    signing_key_id, key_profile, allocated_count, is_active,
+                    signing_key_id, key_profile, issuer_identifier, allocated_count, is_active,
                     signed_token_content_hash, created_at
                 ) VALUES (
                     :id, :uri, :pool_id, :policy_fingerprint, :expiry_lane, :generation, :bits,
                     :capacity, :allowed_statuses, :ttl_seconds, :token_validity_seconds,
-                    :refresh_interval_seconds, :signing_key_id, :key_profile, :allocated_count,
-                    :is_active, :signed_token_content_hash, :created_at
+                    :refresh_interval_seconds, :signing_key_id, :key_profile, :issuer_identifier,
+                    :allocated_count, :is_active, :signed_token_content_hash, :created_at
                 )',
                 $this->getTableName(),
             ),
@@ -354,6 +355,9 @@ public function create(
                 'refresh_interval_seconds' => [$refreshIntervalSeconds, PDO::PARAM_INT],
                 'signing_key_id' => $signingKeyId,
                 'key_profile' => $keyProfile->value,
+                // Null under every profile but `did_web`, which is the only one naming the issuer by
+                // something a list has to remember rather than derive.
+                'issuer_identifier' => $issuerIdentifier,
                 'allocated_count' => [0, PDO::PARAM_INT],
                 // Created inactive, and activated only once every index has been seeded. Otherwise a
                 // concurrent request could select this list and probe indices which do not exist yet,
 
@@ -272,6 +272,11 @@ public function migrate(): void
             $this->version20260902000001();
             $this->database->write("INSERT INTO $versionsTablename (version) VALUES ('20260902000001')");
         }
+
+        if (!in_array('20260903000001', $versions, true)) {
+            $this->version20260903000001();
+            $this->database->write("INSERT INTO $versionsTablename (version) VALUES ('20260903000001')");
+        }
     }
 
 
@@ -1157,6 +1162,36 @@ private function version20260902000001(): void
     }
 
 
+    /**
+     * The issuer identifier a Status List was created under.
+     *
+     * Only the `did_web` key profile fills it in, and only that profile needs it: a `did:jwk` is
+     * derived from the signing key the row already records, and the `jwks` profile names the issuer by
+     * a URL which cannot move without the key set moving with it. A `did:web` identifier is neither --
+     * it is a setting of its own, which an operator can change or clear while lists created under it
+     * are still being served. Recording it is what keeps such a change from rewriting the `iss` of
+     * every token those lists emit, which would leave a wallet holding a credential naming one issuer
+     * and a Status List Token naming another.
+     *
+     * Nullable, so it can be added to a table which already has rows: every existing list is on a
+     * profile which does not use it.
+     */
+    private function version20260903000001(): void
+    {
+        $statusListTableName = $this->database->applyPrefix(StatusListRepository::TABLE_NAME);
+
+        if ($this->hasColumn($statusListTableName, 'issuer_identifier')) {
+            return;
+        }
+
+        $this->database->write(<<< EOT
+        ALTER TABLE {$statusListTableName}
+            ADD issuer_identifier TEXT NULL
+EOT
+            ,);
+    }
+
+
     /**
      * Whether a table already has a column.
      *
 
@@ -477,6 +477,7 @@ protected function createList(
                 $pool->getRefreshIntervalInSeconds(),
                 $signingKeyId,
                 $pool->getKeyProfile(),
+                $pool->getIssuerIdentifier(),
             );
         } catch (Throwable $throwable) {
             $this->loggerService->info(