A client receives a URL-mode elicitation asking the user to connect a third-party account through an external web page. Which client behavior follows the specification's safe URL handling rules?
Select an answer to reveal the explanation.
Short Explanation
You're the bouncer for that link, not its tour guide. You show the user the whole URL with the domain lit up, you wait for a clear yes, and then you hand it to a real browser the client can't peek into. Prefetching or hiding the URL is exactly the trap.
Full Explanation
The elicitation specification lists strict client rules for URL mode. Clients MUST NOT automatically prefetch the URL or any of its metadata, MUST NOT open it without explicit user consent, MUST show the full URL for examination before consent, and MUST open it in a manner that does not let the client or the model inspect the page content or user inputs; a system browser view qualifies, an embedded web view the app controls does not. Clients SHOULD also highlight the domain to defeat subdomain spoofing and warn on suspicious forms such as Punycode. Prefetching to build a preview violates the no-prefetch rule and can leak to an attacker that the link was received, and a certificate check does not make an untrusted destination safe. Opening the link immediately in an embedded web view breaks both the consent rule and the no-inspection rule. Hiding the URL behind a friendly label removes the user's only means of spotting a lookalike domain. Exam caveat: an accept response means the user consented to open the link, not that the out-of-band interaction finished. Operational check: trigger a URL elicitation and confirm nothing is fetched before consent, the full URL is visible with its host emphasized, and the page opens in the system browser.