-
Notifications
You must be signed in to change notification settings - Fork 204
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
Add new changes from AnonCreds RS to AFJ #1371
Comments
@genaris are we missing any changes here? You already had some local code for the fromJson / toJson right? Can you also pick up the prover_did / entropy and revocation override changes or do you want one of us to pick that up? |
Otherwise @Vickysomtee could pick up the revocation override and prover_did / entropy changes, but it would be good if you can pick up the fromJson / toJson stuff |
I can pick up the revocation override and prover_did/entropy changes |
Don't worry, I'll do both |
In regards to this, I'm struggling a bit because anoncreds-rs is always requiring me to provide an entropy, even if i use identifiers like I mean, in current If that's the case, according to current anoncreds-rs behaviour (which requires entropy for new identifiers) I think we should check the issuerId in
Am I missing something? |
also makes sense
We shouldn't support non-legacy identifiers in the legacy indy format services (and should probably add a check for this) |
Makes sense and I'm now adding checks in Legacy Indy Format Services in #1374, I think before (or soon after it's merged) it would be nice to have the new AnonCreds format services in #1168 and #1169. This way, folks using Cardano, Cheqd or other methods can use AnonCreds without any limitation. Are any of you working on this? Otherwise I think I can pick them up (AFAIK they should be nearly the same as Legacy with a few tweaks aligned to the new AnonCreds Aries RFC). |
No one from our side working on this currentlt |
I'm not sure how to properly check if I need to provide overrides. My initial understanding is that in Is this reasoning correct? If it is, how should I deal with local |
My suggestion was slightly different from that. If the provided timestamp is between If the provided timestamp is outside the This is logic outside of AnonCreds and it’s possible AnonCreds is never called, if the range check fails. It is more interesting if the provided timestamp is after the |
Thanks @swcurran , I think your explanation clarified me the use case from a high-level perspective. Here I was trying to figure out how to use a new parameter that has been added to anoncreds-rs verifier that asks the library to accept some overrides (which will be used when the logic you said determines that it is good to continue the flow regardless of a difference between timestamp and the from in proof request's non_revoked). Something that came up during today's AFJ call was: why the verifier does not always put an accurate For example: user wants to have a non_revoked interval between Monday and Wednesday. But it happens that there are revocation entries only Sunday and Tuesday. So why don't just use 'from Monday' and 'to Tuesday' in the generated Proof Request? Following that practice should solve the inconsistency in current libraries like indy-sdk, shouldn't it? |
My $0.02CDN. I think the reason for not doing it is speed. Why make two (relatively expensive) calls to the ledger just to ask for something that the verifier probably doesn’t care about? In most cases, the verifier wants to know if the credential is revoked |
entropy
added, interface has changed.AnonCredsHolderService
interface to adduseLegacyProverDid
boolean.IndySdkHolderService
we need to throw an error whenuseLegacyProverDid
is false/undefined.AnonCredsRsHolderService
we need generate either the legacy prover did or entropy. (need to think about randomness). optionally generate public key, derive the prover_did based on it (but don't store the private key)The text was updated successfully, but these errors were encountered: