Open mahtovivekUBT opened 2 months ago
I'm seeing a similar issue but on the offer side, seems to be related to this PR.
The browser isn't reaching the the issuer-container as the host of the vc-request sting is a internal docker URL reference.
@niwim in the etc/hosts
file you can add those lines to resolve the issue :
127.0.0.1 host.docker.internal 127.0.0.1 gateway.docker.internal
Thanks @SuperBatata, noticed that the issues were not related.
Managed to reproduce @mahtovivekUBT issue. It looks like its ebsi-related, idk much about the ebsi resolver but managed to extract this error at least.
docker-compose-verifier-api-1 | [DefaultDispatcher-worker-8] TRACE id.walt.credentials.schemes.JwsSignatureScheme - Verifying with issuer did: did:ebsi:zf39qHTXaLrr6iy3tQhT3UZ
docker-compose-verifier-api-1 | [DefaultDispatcher-worker-8] TRACE id.walt.credentials.schemes.JwsSignatureScheme - Imported key: Failure(io.ktor.network.tls.TLSException: Received alert during handshake. Level: FATAL, code: ProtocolVersion) from did: did:ebsi:zf39qHTXaLrr6iy3tQhT3UZ, public is: null
@niwim Could you please update the VERSION_TAG
in docker-compose/.env
to latest
? The fix was not included in version 0.3.1.
@mahtovivekUBT Could you kindly provide additional details to help us diagnose the issue? Specifically, the logs from the verifier-api, the setup you are using, and any steps to reproduce the problem would be very helpful. Thank you!
Thanks @SuperBatata, noticed that the issues were not related.
Managed to reproduce @mahtovivekUBT issue. It looks like its ebsi-related, idk much about the ebsi resolver but managed to extract this error at least.
docker-compose-verifier-api-1 | [DefaultDispatcher-worker-8] TRACE id.walt.credentials.schemes.JwsSignatureScheme - Verifying with issuer did: did:ebsi:zf39qHTXaLrr6iy3tQhT3UZ docker-compose-verifier-api-1 | [DefaultDispatcher-worker-8] TRACE id.walt.credentials.schemes.JwsSignatureScheme - Imported key: Failure(io.ktor.network.tls.TLSException: Received alert during handshake. Level: FATAL, code: ProtocolVersion) from did: did:ebsi:zf39qHTXaLrr6iy3tQhT3UZ, public is: null
This TLS exception sounds like the one with the missing TLS 1.3 support in the CIO client, this was changed when switching to okhttp in one of the last updates (EBSI DID Registry does not have support for TLS1.2/TLS1.1, only TLS1.3).
Thanks @SuperBatata and @niwim
These are the logs from the verifier_api (After clicking on accept presentation) verifier_api.log
I have Windows 11 OS with Docker-desktop, and I'm running the demo on Chrome browser although the behavior is same on other browsers. Please let me know if you need any more info.
@laserguy Thank you for providing the logs from the verifier-api. Could you please also provide the steps to reproduce the issue? For example, how are you running the project, and how do you issue the VC? etc.. This information will help us better understand and address the problem. Thank you!
Additionally, could you try using did:jwk
instead of did:cheqd
and let us know if the problem persists?
@SuperBatata I tried with did:jwk
, and the verification works with it. I tried with other did methods as well.
Except did:key
and did:cheqd
, other methods are working fine.
I have made a video that shows how issue can be reproduced, but it is more than 10 MB so I have uploaded it to the discord Failed Verification
@SuperBatata I had one small question, I was able to resolve the did:cheqd
using Uniresolver, but I couldn't resolve the did:ebsi
. Is did:ebsi
not stored on the ebsi
blockchain?
did:ebsi:zf39qHTXaLrr6iy3tQhT3UZ
I took the checkout of the latest walt.id repo and built the images locally and ran the setup with local built images. But whenever I try verifying the credentials, it fails
This is the last log I see in the wallet-api docker (Attached log.txt)
Is there an issue with the presentation?