A server's URL-mode elicitation sends https://files.example.com/[email protected]&sig=abc123, which opens a pre-signed link to the user's private files. A reviewer objects. Which requirement does this URL violate?
Select an answer to reveal the explanation.
Short Explanation
That link is a house key with the owner's name written on it. Anyone who sees it — the client, a log, a forwarded chat — can walk right in. You keep personal data out of the URL and make the page check who's visiting rather than baking access into the link.
Full Explanation
The elicitation specification's safe URL handling rules say servers MUST NOT include sensitive information about the end user, including credentials and personally identifiable information, in the URL of a URL-mode elicitation, and MUST NOT provide a URL that is pre-authenticated to access a protected resource, because a malicious client could use it to impersonate the user. Servers SHOULD also use HTTPS outside development. This URL fails twice: the email address is personal data, and the signed parameter grants direct access to private files to whoever holds the link. Restricting URL mode to OAuth flows is incorrect; the specification describes it for auth flows, payment processing and other sensitive interactions, including entering an API key on a secure page. A custom URI scheme is not a requirement, and URLs are expected to open in a browser the client cannot inspect. Length is not the issue either; the client must show the full URL regardless of how long it is. Exam caveat: the safe pattern points the user at the server's own connect page, which verifies the user's identity before continuing. Operational check: inspect every URL the server places in an elicitation and confirm it holds no personal data, no tokens and no signature that grants access on its own.