-
Notifications
You must be signed in to change notification settings - Fork 24
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
Reconsider usage of AnonCredsPredicate
in an AnonCreds VP
#194
Comments
Interesting. The “ I think it would not be particularly limiting to allow only one predicate per attribute of a given name. In theory, multiple predicates could be referencing like-named attributes in different source credentials (which would be OK), but that’s really an edge case. |
@Artemkaaas During the WG call yesterday we landed on using |
Yes. I can update to use boolean value instead object.
|
Hmm now that you say this, I think maybe multiple predicates should even be possible without the mapping right? I can create the following DIF PD:
This will translate to two different predicates:
I think the only thing that is important here is that we need a consistent way to map from a PD to an AnonCreds proof request (mainly the group names are important here I think) |
For doing credential subProof verification, we have to pass predicate type and value as well. |
I've been re-reading the DIF PE specification to create test vectors for AnonCreds W3C credentials and exchange messages.
I now noticed in the spec the following sections:
This requires that the returned value is a boolean, only if a predicate is used. I think this is based on the assumption that each attribute will only have one predicate query associated with it (so not age > 10 and age < 50 as then you won't be able to use a boolean anymore).
Based on this I think it may be good for now to limit anoncreds w3c presentations to only a single predicate per attribute (I've never seen different), and use the approach as described in DIF PE.
Then we will be aligned with the spec, and this would actually make it a lot easier for us to get this working with e.g. the PEX implementation we use in JS which is not created by us (https://github.com/sphereon-Opensource/pex).
cc @swcurran @Artemkaaas @gvelez17 @2mau
The text was updated successfully, but these errors were encountered: