leifj · Oct 9, 2026 · Oct 9, 2026 · Oct 9, 2026
diff --git a/docs/howto/verifier-quickstart.md b/docs/howto/verifier-quickstart.md
diff --git a/docs/sirosid/operations/docker-images.md b/docs/sirosid/operations/docker-images.md
@@ -37,14 +37,14 @@ Images are tagged with multiple version identifiers:
 
 | Tag Pattern | Description | Example |
 |-------------|-------------|---------|
-| `{major}.{minor}.{patch}` | Semantic version release | `vc/verifier:0.7.23` |
+| `{major}.{minor}.{patch}` | Semantic version release | `vc/verifier:0.7.0` |
 | `{major}.{minor}`, `{major}` | Moving tags for the latest patch release | `vc/verifier:0.7` |
 | `latest` | Latest tagged release (not the head of `main`) | `vc/verifier:latest` |
 | `<git-sha>` | A specific commit | `vc/verifier:3f2c1a9...` |
 
-SIROS-built images are additionally published with a `-sirosid.N` suffix (for example `0.7.20-sirosid.4`) and `dev-<sha>` tags; some per-architecture builds carry an `-amd64` or `-arm64` suffix. The [Container Image Catalog](/opensource/container-images) lists the tags currently published.
+SIROS-built images are additionally published with a `-sirosid.N` suffix (for example `0.7.20-sirosid.4`) and `dev-<sha>` tags; some per-architecture builds carry an `-amd64` or `-arm64` suffix. The [Container Image Catalog](/opensource/container-images) lists the tags currently published. Not every release is published as an image: as last checked on GHCR, `vc/verifier` has `0.7.0`, `0.7.5-sirosid.0` and `0.7.20-sirosid.0` to `.4` (`-amd64` only), and `latest` points at `0.7.5-sirosid.0`.
 
-**Recommended for production:** Pin an exact version tag (e.g., `0.7.23` or `0.7.23-sirosid.0`) for reproducible deployments; do not track `latest`.
+**Recommended for production:** Pin an exact version tag (e.g., `0.7.5-sirosid.0`, or `0.7.20-sirosid.4-amd64` for amd64 hosts) for reproducible deployments; do not track `latest`.
 
 ## Trust Service Images
 

diff --git a/docs/sirosid/quickstart.md b/docs/sirosid/quickstart.md
@@ -149,6 +149,12 @@ sequenceDiagram
     App->>User: Welcome, Alice!
 ```
 
+:::caution Not enforced on the OIDC `/authorize` path
+The "Verify signature & trust" step above is intended behaviour. Currently, a presentation that answers an OIDC `/authorize` session (QR code or same-device link) is posted to `/verification/oidc-direct_post`, which does not verify the SD-JWT VC or mdoc signature and does not ask the PDP about the issuer. The checks run on `/verification/direct_post`, used by the verifier's own page at `/`.
+
+Known issue: https://github.com/SUNET/vc/issues/761
+:::
+
 Your application received verified identity claims directly from the user's credential:
 
 ```json
@@ -181,6 +187,7 @@ scope=openid pid ehic
 ## Next Steps
 
 - 📖 [Full Verifier Guide](/sirosid/verifiers/verifier) – Complete verification documentation
+- 🤝 [Verifier Quick Start: Trust an Issuer](/howto/verifier-quickstart) – Get a verifier accepting one issuer's credentials
 - 🎫 [Issuing Credentials](/sirosid/issuers/issuer) – Issue your own credentials
 - 🔐 [Trust Services](/sirosid/trust/) – Configure trust framework
 - 🔧 [Keycloak Integration](/sirosid/verifiers/keycloak_verifier) – Detailed Keycloak setup

diff --git a/docs/sirosid/trust/go-trust.md b/docs/sirosid/trust/go-trust.md
@@ -90,8 +90,9 @@ services:
       - ./trust-data:/data:ro  # For local TSL files
     command: ["--config", "/config.yaml"]   # config must set server.host: "0.0.0.0"
     healthcheck:
-      # The image ships wget, not curl
-      test: ["CMD", "wget", "--spider", "-q", "http://localhost:6001/healthz"]
+      # The image ships wget, not curl. /healthz does not answer HEAD requests,
+      # so do not use "wget --spider"
+      test: ["CMD", "wget", "-q", "-O", "/dev/null", "http://127.0.0.1:6001/healthz"]
       interval: 30s
       timeout: 10s
       retries: 3

diff --git a/docs/sirosid/verifiers/deployment.md b/docs/sirosid/verifiers/deployment.md
@@ -284,6 +284,10 @@ volumes:
   mongo-data:
 ```
 
+:::note Mounted keys and secrets must be readable by the container user
+The verifier image runs as an unprivileged user (uid 100 or 65532, depending on the image build), so a `0600` key or secrets file owned by you on the host is unreadable inside the container: the key fails to load (`PKI signing key not loaded ... permission denied`) or startup panics with `failed to load secrets file`. Either `chown` the files to the container's uid (keeping mode `0600` or `0400`) or run the service as your own user with `user: "<uid>:<gid>"` in the Compose file.
+:::
+
 This stack has no PDP and is suitable for development and testing only: remove
 `verifier.trust.pdp_url` from the configuration above or add the go-trust
 service below.

diff --git a/docs/sirosid/verifiers/verifier.md b/docs/sirosid/verifiers/verifier.md
@@ -91,6 +91,12 @@ sequenceDiagram
     App->>User: Access granted
 ```
 
+:::caution Not enforced on the OIDC `/authorize` path
+The "verify" step above is intended behaviour. Currently, a presentation that answers an OIDC `/authorize` session (QR code or same-device link) is posted to `/verification/oidc-direct_post`, which does not verify the SD-JWT VC or mdoc signature and does not ask the PDP about the issuer. The checks run on `/verification/direct_post`, used by the verifier's own page at `/`.
+
+Known issue: https://github.com/SUNET/vc/issues/761
+:::
+
 ## Integration Options
 
 ### Option 1: OIDC Identity Provider (Recommended)
@@ -595,7 +601,7 @@ verifier:
 
 ### Credential Verification
 
-For each presentation the verifier:
+For each presentation that reaches `/verification/direct_post` (the verifier's own page) the verifier:
 
 1. Validates the credential signature
 2. Checks issuer trust through the configured PDP (see below)
@@ -612,6 +618,8 @@ for some things but is not supported. Run without `pdp_url` only for
 development and testing, never in production.
 :::
 
+Presentations answering an OIDC `/authorize` session (`/verification/oidc-direct_post`) currently skip steps 1 and 2 for SD-JWT VC and mdoc (known issue: https://github.com/SUNET/vc/issues/761).
+
 ## API Endpoints
 
 ### OIDC Provider Endpoints
@@ -743,6 +751,10 @@ locally; that mode may work for some things but is not supported, so use it for
 development and testing only.
 :::
 
+:::note Mounted keys and secrets must be readable by the container user
+The verifier image runs as an unprivileged user (uid 100 or 65532, depending on the image build), so a `0600` key or secrets file owned by you on the host is unreadable inside the container: the key fails to load (`PKI signing key not loaded ... permission denied`) or startup panics with `failed to load secrets file`. Either `chown` the files to the container's uid (keeping mode `0600` or `0400`) or run the service as your own user with `user: "<uid>:<gid>"` in the Compose file.
+:::
+
 #### Verifier Configuration
 
 Create `config.yaml`. This configuration passes the verifier's startup
@@ -960,6 +972,7 @@ and `presentation_requests_dir` if you set it).
 
 ## Next Steps
 
+- [Verifier Quick Start: Trust an Issuer](/howto/verifier-quickstart)
 - [Keycloak Integration Guide](./keycloak_verifier)
 - [Trust Services Configuration](../trust/)
 - [Go-Trust AuthZEN Service](../trust/go-trust)