Add security considerations on signing presentation requests

[marcoscaceres]

Adds a short security considerations subsection strongly encouraging relying parties to sign their presentation requests, explains the in-page tampering it protects against, and is explicit that a signature the wallet cannot check against a recognized key does not help. Resolves the concern raised in #568 without mandating signed requests.

The following tasks have been completed:

• Modified Web platform tests (link)

Implementation commitment:

• WebKit (link to issue)
• Chromium (link to issue)
• Gecko (link to issue)

Documentation and checks:

• Affects privacy
• Affects security
• Pinged MDN
• Updated Explainer
• Updated digitalcredentials.dev

---

Preview | Diff

[TallTed]

Better to close a paragraph with the desired action and positive effect.

Suggested change

	the attacker is already inside one. A signed request gives the
	[=credential manager=] something to check, so the change can be
	detected instead of passing unnoticed. With an unsigned request, the
	[=credential manager=] has to trust that the verifier has kept its own
	page free of such scripts.
	the attacker is already inside one. With an unsigned request, the
	[=credential manager=] has to trust that the verifier has kept its own
	page free of such scripts. A signed request, on the other hand, gives
	the [=credential manager=] something to check, so the change can be
	detected instead of passing unnoticed.

[TallTed]

Suggested change

	Signing only helps if the [=credential manager=] can tell that the
	signature belongs to the verifier making the request. A script inside
	the page can re-sign an altered request with a key of its own, so a
	signature that cannot be checked against a signing key already
	recognized as the verifier's offers no protection against this
	attacker. Which signing keys to accept, and how they are established,
	is decided by the ecosystem a credential belongs to rather than by
	this specification, and the protection a signed request actually
	offers depends on that decision.
	Even at that, signing only helps if the [=credential manager=] can tell
	that the signature belongs to the verifier making the request. A script
	inside the page can re-sign an altered request with a key of its own,
	so a signature offers no protection against this attacker unless it can
	be checked against a signing key that is already recognized as the
	verifier's. Which signing keys to accept, and how they are established,
	is decided by the ecosystem a credential belongs to rather than by this
	specification, and the protection a signed request actually offers
	depends on that decision.