Add guidance on how to handle multiple presentation request entries

[MasterKale]

This PR adds initial text on A) how user agents MUST handle the presence of multiple presentation requests in options.digital.requests, and B) how verifiers SHOULD populate options.digital.requests to handle getting back a corresponding presentation response.

Closes #220.

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

[wseltzer]

Discussed 11 June minutes

[npdoty]

I think we should indicate to the verifier that the multiple requests (and similarly for the request language) should be semantically compatible/equivalent, or the user/user agent/wallet are easily going to be confused, or might be seen as abuse. Browsers can try to catch really extreme cases that violate that, but it probably wouldn't be easy to test.

[MasterKale]

From WG meeting:

• Add a note to Verifiers that request options within requests should be semantically similar
• Review text to see how it might clarify that we're talking about multiple requests within a single invocation of DC API

[wseltzer]

Discussed 9 July.

[TallTed]

Might I suggest that this be reworked/rewritten a bit, to more closely mimic the HTTP content negotiation accept: header, such that each entry pairs a protocol (with associated priority) with one or more credentials (each with their own associated priority)?

A single artificially complicated request (with syntactically invisible line break, here just to make comprehension easier) might then look something like —
foo-proto-v1(ex-cred-1;cp=1.0, ex-cred-2;cp=0.5);pp=1.0, foo-proto-v2(ex-cred-1;cp=0.7, ex-cred-2;cp=0.3);pp=0.5

I would multiply the internal credential priority, cp, values by the wrapping protocol priority, pp, to make a net priority, p.

This could be made less visibly complicated by having two multi-valued parameters instead of one, such that the protocol priorities are in one parameter and the credential priorities are in another, or by having one slightly-more complex multi-valued parameter for which each value includes both protocol and credential (basically containing the permutations of the above), maybe something like —
(foo-proto-v1;ex-cred-1;p=1.0), (foo-proto-v2;ex-cred-1;p=0.35), (foo-proto-v1;ex-cred-2;p=0.5), (foo-proto-v2;ex-cred-2;p=0.15)

Note that the ordering of these is not important. It's the p value that dictates preference/priority of receiving that combination.

[wseltzer]

Discussed 3 September minutes.

[MasterKale]

Just an update, this PR is effectively blocked by #372 which defines the presentation algorithm for the user agent. Once that lands I can then update this PR to slot in this PR's guidance to wherever is appropriate.

[hlflanagan]

Discussed as part of AOB: https://github.com/w3c-fedid/meetings/blob/main/2025/2025-12-02-DCAPI-A-notes.md#aob

[MasterKale]

Abandoning this because I just found out @marcoscaceres decided instead to do this in #420.

[marcoscaceres]

There might be some text we can bring over from here to #420. There’s still something to be said, even if non-normatively, about not expecting multiple credentials (unless the format allows for it).