-
Notifications
You must be signed in to change notification settings - Fork 18
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
@@ -497,6 +497,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. | ||||||||||||||||
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
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
|
||||||||||||||||
<aside class="note"> | ||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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> | ||||||||||||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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?