This verifier is registered with the German EUDI Wallet sandbox registrar under go.eIDAS e.V. The registrar issued two certificates: an access certificate that signs our wallet requests, and a registration certificate that tells the wallet what we are allowed to ask for and why. Both are shown below, read live from this server, together with checks you can repeat yourself.
Our registration on the EU reference registry is unchanged: see EU reference registry.
Issued by the sandbox registrar from a key generated on our side; the private key never left our infrastructure. Every request started with registrar=de is signed with it and carries it in the x5c header. Wallets identify us by its SHA-256 hash (x509_hash client identifier).
An rc-wrp+jwt signed by the registrar (ETSI TS 119 475). It travels inside each registrar=de request as verifier_info, so the wallet can compare the attributes we request with the attributes we are registered for.
Start a sign-in request signed with the German access certificate and scan the QR code with a wallet that trusts the German sandbox registrar. The verifier test page shows a per-check report once the wallet answers.
Attestation types from the registrar’s catalogue that this verifier accepts in German-registrar requests:
Issuers are trusted from the trust anchors the catalogue publishes for each type, and only in German-registrar requests. The demo attestations show their attributes; they never sign anyone in to an account.
Developers: add registrar=de to /oidc.ashx?action=vp-start. registrar=eu forces the EU reference registry certificate; without the parameter the tenant default applies.
Two registrars, two trust anchors. A Wallet Relying Party can register with more than one registrar. Each registrar runs its own certificate authority, and a wallet trusts a request only if its signing certificate chains to a registrar the wallet knows. Wallets anchored on the EU reference registry see our EU certificate; wallets anchored on the German sandbox registrar see the certificate on this page. We pick the certificate per request, so one never breaks the other.
Why go.eIDAS e.V. The sandbox registrar takes the organisation name from the account used to register; it cannot be typed in. That account belongs to go.eIDAS e.V., so both certificates name go.eIDAS e.V. (NTRDE-56A4B75B725F11F4). The registration certificate's purpose text names the service it covers: sign-in to CodeB Sovereign Communications on phone.codeb.io.
Nothing here is a claim. The cards above are read from the certificate files this server actually uses. The registration certificate's signature is verified against the registrar certificate it carries, and its subject is compared with the access certificate's organisation identifier. Download the access certificate and the registrar CA and check the chain with any X.509 tool.
Sandbox, not production. This registration exists for interoperability testing with wallets that use the German sandbox registrar.
The German sandbox registrar derives the organisation name from the login used to register, and that login belongs to go.eIDAS e.V. Both certificates therefore name go.eIDAS e.V. (NTRDE-56A4B75B725F11F4). The service behind them is this CodeB verifier, as the purpose text in the registration certificate states.
Requests started with registrar=de. All other requests keep using the certificate from the EU reference registry, so wallets that only know the EU anchor are unaffected.
Which credential types and attributes this verifier is registered to request, for what purpose, and where its privacy policy is. The wallet receives it inside the signed request (verifier_info) and can compare it with what is actually asked for.
No. It is a sandbox registration for interoperability testing with wallets anchored on the German sandbox registrar.