Trust digital-credentials.dev as a verifier on gdc

environments/gdc.yaml

@@ -58,6 +58,35 @@ trusted_verifiers:
   - https://verifier.multipaz.org
   - https://siros-multipaz-verifier.fly.dev
   - https://geneva2026.mdoc.online
+  # Google's public DC API test site, for browser-initiated presentation
+  # testing. Written as the plain origin because that is what a whitelist
+  # match actually compares against: an unsigned DC API request carries no
+  # signing certificate, so the subject is the origin Chrome verified, and a
+  # signed one using the x509_san_dns scheme is normalized to
+  # https://<host> before the match runs. Only x509_hash: subjects are
+  # compared un-normalized, and if the site's signed requests turn out to use
+  # that scheme it needs its hash added verbatim alongside this - the PDP's
+  # denial message quotes the exact string to paste.
+  #
+  # No reader-CA root below: the site's request-signing certificate is
+  # self-signed rather than chained (see values-fly.yaml's 0.12.1 -> 0.13.0
+  # note), so it is trusted by hash-pinning rather than by chain validation,
+  # which is the one scheme go-trust deliberately skips chain validation for.
+  - https://digital-credentials.dev
+  # And its signed requests, which do use the x509_hash scheme - confirmed
+  # from the PDP's own denial on 2026-09-07:
+  #
+  #   whitelist denied request subject=x509_hash:f1drGLOIT4kDBlJVsD-_33igSf5uwRnq3yO2NvcXEW0
+  #     reason="subject not in whitelist for action 'credential-verifier'"
+  #
+  # Pasted verbatim because x509_hash: subjects are compared un-normalized,
+  # unlike x509_san_dns:/x509_san_uri: which are reduced to https://<host>
+  # first. The origin entry above therefore cannot match a signed request, and
+  # this entry cannot match an unsigned one - both are needed.
+  #
+  # Hash-pinning is itself the trust decision for this scheme, so go-trust
+  # skips chain validation and no reader-CA root is required.
+  - x509_hash:f1drGLOIT4kDBlJVsD-_33igSf5uwRnq3yO2NvcXEW0
 trusted_verifier_roots:
   - fixtures/trusted-roots/multipaz-reader-ca.pem
   - fixtures/trusted-roots/siros-multipaz-verifier-reader-ca.pem
@@ -68,6 +97,30 @@ trusted_verifier_roots:
 zk_circuits_sources:
   - https://zk-circuits-test.fly.dev
 
+# The sample app's signing keys, so wallet-backend's rp_origins (the
+# server-side WebAuthn accept-list) contains the apk-key-hash the app
+# actually presents. Without a matching entry, /auth/passkey/register/finish
+# fails with "Error validating origin" and signup returns 400 - while login
+# with an already-registered passkey keeps working, which makes it look like
+# a server regression rather than a missing accept-list entry.
+#
+# Persisted here on purpose. These previously lived only in `.android-apps`,
+# which is gitignored and per-checkout, so a `make fly-up ENV=gdc` from any
+# working copy that happened not to have that file silently deployed an
+# rp_origins with the app's keys missing - which is exactly what happened on
+# 2026-09-07. Environment state that the environment needs belongs in the
+# environment file, where anyone's next deploy reproduces it.
+#
+# Three keys, all for org.siros.sdk.sample: the repo's committed debug
+# keystore (sample-app/debug.keystore - what CI and a clean checkout build
+# with), a local per-developer debug keystore, and an older one kept so
+# devices still carrying that build can log in. `.android-apps` is still read
+# and still adds to this; nothing here replaces it.
+android_apps:
+  - org.siros.sdk.sample=A4:DF:EC:00:09:BF:CA:CD:A4:67:F7:D4:6D:A0:AD:96:1C:4E:38:D2:4F:42:5C:6A:21:7F:98:69:9C:C5:82:14
+  - org.siros.sdk.sample=C4:07:F2:6D:C3:B4:C8:F9:54:03:F1:A4:A3:6B:47:EA:82:11:6F:D6:3E:A9:AD:EE:56:D9:B4:9B:FA:96:D3:B4
+  - org.siros.sdk.sample=46:56:F0:24:08:55:32:F0:94:0F:53:60:A2:0E:6A:31:9A:0B:57:5B:38:C6:BD:F8:48:B6:95:09:39:CB:B0:2F
+
 wallet_attestation: true
 
 # Geneva 2026 interop event's RICAL (ISO 18013-5 2nd ed. Annex F reader-trust