Skip to content

Add guidance on how to handle multiple presentation request entries #249

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -482,6 +482,27 @@ <h3>
Details of how to actually get the [=digital credential=] are
forthcoming.
</aside>
<ol class="algorithm" >
<li>
<aside class="issue">
The following guidance on handling multiple requests will need to be relocated once
this entire section of the algorithm is defined.
</aside>
When multiple [=digital credential/presentation requests=] are present
in {{DigitalCredentialRequestOptions/requests}},
[=user agents=] MUST only return one
[=digital credential/presentation responses | presentation response=] for one
of these requests.
Comment on lines +508 to +510
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[=user agents=] MUST only return one
[=digital credential/presentation responses | presentation response=] for one
of these requests.
[=user agents=] MUST return a maximum of one
[=digital credential/presentation responses | presentation response=] for each
of these requests.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is slightly different behavior than what I'm trying to define here. I'm trying to capture the idea that, while a verifier may specify multiple requests using different protocols for each, the response the verifier gets back will only be for one of those requests.

The suggested wording sounds like it'd open the door to allowing multiple requests to get back one response each. Am I misunderstanding the intent of these proposed changes?

Multiple credentials MAY be present in this one response depending on the capabilities
of the corresponding [=digital credential/exchange protocol=].
Comment on lines +511 to +512
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs further refinement. I'm trying to capture the concept before getting the language just right. There will also need to be some language about what happens when a response that contains credentials A, B, and C is sent after receiving individual requests for credentials A, B, C, D and E, and then a new request for credential B is received. Does the first response cause the new request for B to be ignored? Or might a new response containing B, D, and E be sent? Or something else?

Suggested change
Multiple credentials MAY be present in this one response depending on the capabilities
of the corresponding [=digital credential/exchange protocol=].
Multiple credentials MAY be present in one such response depending on the capabilities
of the corresponding [=digital credential/exchange protocol=].
Each credential SHOULD be present in only one such response, such that a response
containing multiple credentials is considered to be a response to all individual
requests for one of the credentials it contains.

<aside class="note">
Copy link
Collaborator

@marcoscaceres marcoscaceres Jun 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Notes shouldn't include RFC2119 keywords (i.e., get rid of the SHOULD).

I don't think this even makes sense, to be honest. How they are presented is up to the user agent, not up to verifier.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we imagine a Verifier that is trying to handle a wallet ecosystem that's in between foo-proto-v1 and foo-proto-v2, how might they express a preference for getting a foo-proto-v2 response when a wallet supports it? I'm suggesting here that we approach it by allowing Verifiers to sorting the list of requests by protocol, from most preferred to least preferred.

Verifiers SHOULD order entries in {{DigitalCredentialRequestOptions/requests}}
by descending preference to help [=user agents=] determine
which [=digital credential/presentation responses | presentation response=]
to return.
</aside>
</li>
</ol>
</li>
<li>Return a {{DigitalCredential}}.
</li>
Expand Down