Credentials showing as Not Verified in VerifierPlus, previously verified

[bmuramatsu]

I'm not sure if this is a VerifierPlus issue, a LCW issue or credential creation issue.

I think it may have something to do with the change to the security loader or other work related to Open edX's integration of DCC libraries. I suspect it's also similar to the issue Stuart reported to Dmitri in slack. But those are both only guesses.

Credentials created (baked) on April 14 or June 29 using James' test-signer show as verified in the LCW v2.0.0-Build 56 under iOS (aka the last version of LCW uploaded to the Apple App Store) but show as Not Verified on public links on https://verifierplus.org.

Credentials issued by CU (as a test, but they should be the same as the live BA digital diplomas CU issued to graduates) using sign-and-verify also return Not Verified via public links in VerifierPlus.

VC baked on 6/29/23 using test-signer:
validBadge-aseptic-technique.zip

VC baked on 4/14/23 using test-signer:
valid-dcc-demo.zip

VC issued from sign-and-verify by CU:
https://lcw.app/request.html?issuer=https://connect.collegeunbound.edu&vc_request_url=https://connect.collegeunbound.edu/request/credential&challenge=VOclS8ZiMs&auth_type=bearer

VerifierPlus used to verify the VC on 4/24/23:

VerifierPlus reports Not Verified and Invalid Signature of the same VC on 6/29/23:

[bmuramatsu]

It's possible that these same credentials will show as Not Verified in Android LCW as it's been updated since 4/24/23.

[dmitrizagidulin]

@bmuramatsu yes, that's likely

[dmitrizagidulin]

@bmuramatsu - ok, should be fixed for live VerifierPlus. (working on LCW)

[kayaelle]

@bmuramatsu - please test and let us know if it is working as expected. We should follow-up on whether any of the SJCC or CU credentials should get re-issued anyway.

[dmitrizagidulin]

Yeah, the reason I think we should recommend that the SJCC and CU credentials get re-issued, is that this fix is only for wallets and verifiers using our (DCC) libraries. Other implementations will show those VCs as not verified. (Due to 1EdTech OBv3 WG changing the contents of its context/schema without updating the context URL).

[bmuramatsu]

Previously created credentials verify as they had previously in VerifierPlus on 7/19/23 and iOS and Android LCW build 62.

[bmuramatsu]

Yeah, the reason I think we should recommend that the SJCC and CU credentials get re-issued, is that this fix is only for wallets and verifiers using our (DCC) libraries. Other implementations will show those VCs as not verified. (Due to 1EdTech OBv3 WG changing the contents of its context/schema without updating the context URL).

To @dmitrizagidulin's point about multiple contexts... we're at the start of OBv3 implementation so we might expect implementers to keep updating to the latest context, but as time proceeds wouldn't we expect multiple versions of the contexts we support to be in the wild?

Thus, shouldn't we:

• Need to recommend other implementers support multiple contexts, especially for OBv3, and presumably VC v2 when it is finalized?
• Continue to support multiple contexts?
• Consider whether we keep a copy of the contexts we support directly and do a diff on them with the one that's listed to check for stealth changes that might break something?

[kayaelle]

Will create follow-up issue on display based on contexts. There are two other badge display issues that reference similar issues:

#85
https://github.com/digitalcredentials/learner-credential-wallet/issues/460