One connector, a hostname per relying party
This is the ConnectID connector, on a hostname that names the relying party. It is the same service, the same code and the same reader keys as every other ConnectID hostname — only the name the browser asserts is different. That name is the one thing every wallet displays, and on iPhone it is the only thing.
Why the hostname is a lever at all
When this page calls the Digital Credentials API, the browser — not the page — tells the wallet which origin asked. The page cannot influence that value, which is exactly why a wallet can trust it. But ConnectID chooses the hostname, so the origin the browser asserts can be one that names the relying party.
Nothing else in the request changes. The response is still bound, cryptographically, to a ConnectID origin.
What each platform will actually show
iPhone · Safari origin only
ISO 18013-7 Annex C — org-iso-mdoc
The protocol carries the verifier's identity as a reader certificate and has no field for a second party, so the wallet leads with the origin. On this hostname that origin names the relying party — the only lever that reaches this screen.
Android · Chrome signed request
OpenID4VP — openid4vp-v1-signed
ConnectID, as Trust Controller, signs the request for the relying party. A wallet that walks the trust chain names the shop and where the vouching came from. A wallet that ignores the signature falls back to the origin — which, here, still names it.
What this is. A statement by ConnectID, made through its DNS rather than through a signature. It reaches the user on every platform and every wallet, with no wallet cooperation and no protocol change.
What it is not. A verified claim. A wallet can check that the request came from ConnectID's domain, because the browser vouches for the origin. It cannot check that the label inside that domain means anything — a domain owner can name a subdomain whatever it likes. The user is trusting ConnectID's word about who is asking.
See the experience end to end
The journey a ConnectID user would actually take: the shop sends them here over an ordinary OpenID Connect flow, this connector runs the wallet ceremony on this origin, and the shop gets back an ID token. The shop never speaks to the wallet and holds no reader keys.
Issuer for this hostname:
…
The same ceremony, the other hostname
The contrast is the finding. Run the identical request from ConnectID's generic hostname and the iPhone sheet names the connector instead of the shop.