credo-ts
credo-ts copied to clipboard
openwallet-foundation
fix: query for qualified/unqualified forms in revocation notification
Now querying in both qualified and unqualified forms for revocation registry id. Didn't add any specific test for this yet.
@bryce-mcmath it would be great if by chance you can verify that this properly solves your issue with legacy indy credentals.
Fixes #1864
Still getting no records with the updated query. Here's what the query ends up looking like:
"$or": [
{
"anonCredsRevocationRegistryId": "M6dhuFj5UwbhWkSLmvYSPc:4:M6dhuFj5UwbhWkSLmvYSPc:3:CL:612088:student_card:CL_ACCUM:5f6b196c-2051-4c30-92e1-e22af703ba8f",
"anonCredsCredentialRevocationId": "14",
"connectionId": "c8b60a89-4849-4697-9d8b-326e1f1ddc5c"
},
{
"anonCredsRevocationRegistryId": "M6dhuFj5UwbhWkSLmvYSPc:4:M6dhuFj5UwbhWkSLmvYSPc:3:CL:612088:student_card:CL_ACCUM:5f6b196c-2051-4c30-92e1-e22af703ba8f",
"anonCredsUnqualifiedRevocationRegistryId": "14",
"connectionId": "c8b60a89-4849-4697-9d8b-326e1f1ddc5c"
}
]
I thought maybe the values passed were incorrect so I tried switching them, but still retrieved no records. Here's what that query looked like:
"$or": [
{
"anonCredsRevocationRegistryId": "M6dhuFj5UwbhWkSLmvYSPc:4:M6dhuFj5UwbhWkSLmvYSPc:3:CL:612088:student_card:CL_ACCUM:5f6b196c-2051-4c30-92e1-e22af703ba8f",
"anonCredsCredentialRevocationId": "13",
"connectionId": "90da9419-b550-4616-b087-0e48efd78b0d"
},
{
"anonCredsUnqualifiedRevocationRegistryId": "M6dhuFj5UwbhWkSLmvYSPc:4:M6dhuFj5UwbhWkSLmvYSPc:3:CL:612088:student_card:CL_ACCUM:5f6b196c-2051-4c30-92e1-e22af703ba8f",
"anonCredsCredentialRevocationId": "13",
"connectionId": "90da9419-b550-4616-b087-0e48efd78b0d"
}
]
Not sure if I mentioned this already but it appears to be using the 'V1' revocation notification process, if that's helpful. Let me know what further info I could provide that might help.
@TimoGlastra please let me know if you see anything odd about the above that could cause no records to be found
Still getting no records with the updated query. Here's what the query ends up looking like:
"$or": [ { "anonCredsRevocationRegistryId": "M6dhuFj5UwbhWkSLmvYSPc:4:M6dhuFj5UwbhWkSLmvYSPc:3:CL:612088:student_card:CL_ACCUM:5f6b196c-2051-4c30-92e1-e22af703ba8f", "anonCredsCredentialRevocationId": "14", "connectionId": "c8b60a89-4849-4697-9d8b-326e1f1ddc5c" }, { "anonCredsRevocationRegistryId": "M6dhuFj5UwbhWkSLmvYSPc:4:M6dhuFj5UwbhWkSLmvYSPc:3:CL:612088:student_card:CL_ACCUM:5f6b196c-2051-4c30-92e1-e22af703ba8f", "anonCredsUnqualifiedRevocationRegistryId": "14", "connectionId": "c8b60a89-4849-4697-9d8b-326e1f1ddc5c" } ]I thought maybe the values passed were incorrect so I tried switching them, but still retrieved no records. Here's what that query looked like:
"$or": [ { "anonCredsRevocationRegistryId": "M6dhuFj5UwbhWkSLmvYSPc:4:M6dhuFj5UwbhWkSLmvYSPc:3:CL:612088:student_card:CL_ACCUM:5f6b196c-2051-4c30-92e1-e22af703ba8f", "anonCredsCredentialRevocationId": "13", "connectionId": "90da9419-b550-4616-b087-0e48efd78b0d" }, { "anonCredsUnqualifiedRevocationRegistryId": "M6dhuFj5UwbhWkSLmvYSPc:4:M6dhuFj5UwbhWkSLmvYSPc:3:CL:612088:student_card:CL_ACCUM:5f6b196c-2051-4c30-92e1-e22af703ba8f", "anonCredsCredentialRevocationId": "13", "connectionId": "90da9419-b550-4616-b087-0e48efd78b0d" } ]Not sure if I mentioned this already but it appears to be using the 'V1' revocation notification process, if that's helpful. Let me know what further info I could provide that might help.
Yeah the query parameters were mixed up in previous commit. Sad that once you updated the query it is still not finding any record. Looking here, it seems that Credo is not storing legacy identifiers because the issuer is not a qualified did:indy. I think this should be done either if it is a qualified or an unqualified did:indy. @auer-martin can you confirm?
Still getting no records with the updated query. Here's what the query ends up looking like:
"$or": [ { "anonCredsRevocationRegistryId": "M6dhuFj5UwbhWkSLmvYSPc:4:M6dhuFj5UwbhWkSLmvYSPc:3:CL:612088:student_card:CL_ACCUM:5f6b196c-2051-4c30-92e1-e22af703ba8f", "anonCredsCredentialRevocationId": "14", "connectionId": "c8b60a89-4849-4697-9d8b-326e1f1ddc5c" }, { "anonCredsRevocationRegistryId": "M6dhuFj5UwbhWkSLmvYSPc:4:M6dhuFj5UwbhWkSLmvYSPc:3:CL:612088:student_card:CL_ACCUM:5f6b196c-2051-4c30-92e1-e22af703ba8f", "anonCredsUnqualifiedRevocationRegistryId": "14", "connectionId": "c8b60a89-4849-4697-9d8b-326e1f1ddc5c" } ]I thought maybe the values passed were incorrect so I tried switching them, but still retrieved no records. Here's what that query looked like:
"$or": [ { "anonCredsRevocationRegistryId": "M6dhuFj5UwbhWkSLmvYSPc:4:M6dhuFj5UwbhWkSLmvYSPc:3:CL:612088:student_card:CL_ACCUM:5f6b196c-2051-4c30-92e1-e22af703ba8f", "anonCredsCredentialRevocationId": "13", "connectionId": "90da9419-b550-4616-b087-0e48efd78b0d" }, { "anonCredsUnqualifiedRevocationRegistryId": "M6dhuFj5UwbhWkSLmvYSPc:4:M6dhuFj5UwbhWkSLmvYSPc:3:CL:612088:student_card:CL_ACCUM:5f6b196c-2051-4c30-92e1-e22af703ba8f", "anonCredsCredentialRevocationId": "13", "connectionId": "90da9419-b550-4616-b087-0e48efd78b0d" } ]Not sure if I mentioned this already but it appears to be using the 'V1' revocation notification process, if that's helpful. Let me know what further info I could provide that might help.
Yeah the query parameters were mixed up in previous commit. Sad that once you updated the query it is still not finding any record. Looking here, it seems that Credo is not storing legacy identifiers because the issuer is not a qualified did:indy. I think this should be done either if it is a qualified or an unqualified did:indy. @auer-martin can you confirm?
Yeah, I think that's a mistake. I'm wondering if we should do it for qualified and unqualified Indy Dids, as we want to get rid of the unqualified variants eventually. But I don't think it will hurt if we do it for qualified and unqualified atm.
Just tried one of the approaches suggested; removing the (isIndyDid(issuerId) from here, keeping the other change from this PR as well (or query).
It still unfortunately did not find the record, not sure why. Here's what my resulting w3cRecordAnonCredsTags looked like:
{
"anonCredsLinkSecretId": "790feabb-8054-41c9-8df5-197e3f646979",
"anonCredsCredentialDefinitionId": "did:indy:bcovrin:test:QEquAHkM35w4XVT3Ku5yat/anoncreds/v0/CLAIM_DEF/567943/student_card",
"anonCredsSchemaId": "did:indy:bcovrin:test:QEquAHkM35w4XVT3Ku5yat/anoncreds/v0/SCHEMA/student_card/1.4",
"anonCredsSchemaName": "student_card",
"anonCredsSchemaIssuerId": "did:indy:bcovrin:test:QEquAHkM35w4XVT3Ku5yat",
"anonCredsSchemaVersion": "1.4",
"anonCredsMethodName": "indy",
"anonCredsRevocationRegistryId": "did:indy:bcovrin:test:QEquAHkM35w4XVT3Ku5yat/anoncreds/v0/REV_REG_DEF/567943/student_card/ac6d918c-6532-45a8-b74c-4a2533e596a2",
"anonCredsCredentialRevocationId": "1",
"anonCredsUnqualifiedIssuerId": "QEquAHkM35w4XVT3Ku5yat",
"anonCredsUnqualifiedCredentialDefinitionId": "QEquAHkM35w4XVT3Ku5yat:3:CL:567943:student_card",
"anonCredsUnqualifiedSchemaId": "QEquAHkM35w4XVT3Ku5yat:2:student_card:1.4",
"anonCredsUnqualifiedSchemaIssuerId": "QEquAHkM35w4XVT3Ku5yat",
"anonCredsUnqualifiedRevocationRegistryId": "QEquAHkM35w4XVT3Ku5yat:4:QEquAHkM35w4XVT3Ku5yat:3:CL:567943:student_card:CL_ACCUM:ac6d918c-6532-45a8-b74c-4a2533e596a2"
}
and here's what my query looked like:
query: {
"$or": [
{
"anonCredsRevocationRegistryId": "QEquAHkM35w4XVT3Ku5yat:4:QEquAHkM35w4XVT3Ku5yat:3:CL:567943:student_card:CL_ACCUM:ac6d918c-6532-45a8-b74c-4a2533e596a2",
"anonCredsCredentialRevocationId": "1",
"connectionId": "985d47bb-a7e7-4b1b-8ac8-02e407b5e0a1"
},
{
"anonCredsUnqualifiedRevocationRegistryId": "QEquAHkM35w4XVT3Ku5yat:4:QEquAHkM35w4XVT3Ku5yat:3:CL:567943:student_card:CL_ACCUM:ac6d918c-6532-45a8-b74c-4a2533e596a2",
"anonCredsCredentialRevocationId": "1",
"connectionId": "985d47bb-a7e7-4b1b-8ac8-02e407b5e0a1"
}
]
}
Let me know if anything here stands out.
Just tried one of the approaches suggested; removing the
(isIndyDid(issuerId)from here, keeping the other change from this PR as well (or query).It still unfortunately did not find the record, not sure why. Here's what my resulting
w3cRecordAnonCredsTagslooked like:Let me know if anything here stands out.
The issue is that in RevocationNotificationService we are looking at the tag in the CredentialExchangeRecord (i.e. the record holding the credential issuance flow) while these new unqualified tags are being stored into the CredentialRecord itself.
So for the moment I've updated LegacyIndyCredentialFormatService to set the unqualified identifier as a tag of the CredentialExchangeRecord (in addition to the qualified one), which seems to be working fine for BC Wallet showcase demo credentials.
I have one comment above just asking if we need an extra addition but as it is currently revocation works! Thank you all for your help this far. Safe to create a patch with these changes?
Oh one other question. Will this only solve the problem for newly issued credentials, credentials issued with AFJ 0.4.2 will still fail revocation, no?
Oh one other question. Will this only solve the problem for newly issued credentials, credentials issued with AFJ 0.4.2 will still fail revocation, no?
From my understanding, credentials issued with 0.4.2 should work, since at the moment we are not touching any tag in CredentialExchangeRecord during record migration. So I guess it will have anonCredsRevocationRegistryId: "QEquAHkM35w4XVT3Ku5yat:4:QEquAHkM35w4XVT3Ku5yat:3:CL:567943:student_card:CL_ACCUM:ac6d918c-6532-45a8-b74c-4a2533e596a2" (i.e. the unqualified one, matching what you are sending to it).
BTW for consistency, I think if we follow this anonCredsUnqualifiedRevocationRegistryId approach, it will be nice to also create this tag in the migration scripts.
From my understanding, credentials issued with 0.4.2 should work, since at the moment we are not touching any tag in CredentialExchangeRecord during record migration
I can confirm that revocation in 0.5.2 for credentials issued in 0.4.2 work with these changes.
could we also do this for credentials and proofs?
@wadeking98 do you still want this? @genaris see any issue doing this?