-
Notifications
You must be signed in to change notification settings - Fork 36
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
Clarify wording All Input Descriptors MUST be satisfied
#479
Comments
I believe this is the crux of the confusion. All input descriptors MUST be satisfied, yes, but it does not say by all credentials. Since input descriptors themselves can specify multiple formats of VCs (like in this example) it would be impossible to satisfy all input descriptors with a single credential. So ... yes the correct reading is each input descriptor must be satisfied by at least one credential. I agree there is room to improve the language here -- do you have a suggestion for how the correct behavior can be made more clear? |
The input descriptors are conditions based on the rule set the spec sets forth, and all conditions must be satisfied. If there's a better way to say that, then we'd accept a modification to the text. |
For the list of descriptors provided, your set of N credentials must fulfill both descriptors (satisfying all present based on their conditions). If you had 3 credentials and a single one fulfilled both, you could submit that single one against both, if two different credentials in your set fulfilled one each, you could submit those two, according to the descriptor they fulfilled. If you tried all the creds in your set against the descriptors and could not fulfill all of the descriptors, per their conditions, you would not be able to proceed. |
I think better wording here might be:
I drew a diagram to help illustrate the example above a little more. In the below diagram, 3 claims are evaluated against 5 Input Descriptors. Credential A alone satisfies all 5 Input Descriptor requirements. Combination of Credential B and C satisfies all 5 Input Descriptor requirements as well. Here's another example. In the below diagram, 2 claims are evaluated against 5 Input Descriptors. In this scenario, Input Descriptor 1 is not satisfied by either Credential B or Credential C, so the Presentation Definition is not satisfied. |
I'd like to propose that we clarify this part of the spec describing the purpose of input descriptors:
In my current implementation to select credentials given a list of VC JWT and a Presentation Definition, this wording is rather confusing.
Test cases
Let's say I have a list of input descriptors like this
And I have a list of VC JWTs:
doge123
in$.dogeAddress
btc123
in$.btcAddress
When I call
selectCredentials(vcJwts, presentationDefinition)
, I initially thought that function would return[]
- meaning, there is no single VC JWT that matches ALL input descriptors. But after much discussion @diehuxx, @mistermoe and @nitro-neal, I realized that the wordingAll Input Descriptors MUST be satisfied
means that some combination of a given list of VC JWTs must satisfy all input descriptors. Even this wording is somewhat confusing.As someone that's new to the VC / PEX space but implementing credential selection methods, I would like to see more context included in the spec around what
All Input Descriptors MUST be satisifed
means.For example, the fact that input descriptors are usually evaluated against a list of VCs, or the fact that
All
does not mean that each VC must satisfy all input descriptors. It may be useful to include examples demonstrating expected input and output for this particular scenario.I work at a company where quite a few people are knowledgeable in this space, and have also implemented it in multiple languages. Even those experienced individuals have had to reference existing implementations to determine the correct interpretation of this spec. Without their expertise, I would have implemented this incorrectly, even after careful reading.
Clarifying the language would ensure other implementers can understand and correctly implement their credential selection methods.
The text was updated successfully, but these errors were encountered: