Error processing attestation code :: No issuer found for attestion code
See original GitHub issueExpected Behavior
Users able to complete verification
Current Behavior
One of the three text messages resulted in this error.
Info [2020-07-16T17:14:11.355Z] identity/verification@attestationCodeReceiver :: Error processing attestation code :: No issuer found for attestion code in index.android.bundle:1884:11497
Can provide more specific information if needed
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
Microsoft Azure Attestation troubleshooting guide
Error handling in Azure Attestation is implemented following Microsoft REST ... The requested item is not found Msg:[Unable to find issuer ...
Read more >Running sample code returns 400 when interacting with IAS #28
What I'm after is not necessary fixed code of sgx-ra-sample , but just being able to successfully finish attestation process manually.
Read more >Key and ID Attestation - Android Open Source Project
ID attestation allows the device to provide proof of its hardware identifiers, such as serial number or IMEI. Note: To support Keymaster 3's ......
Read more >Design Guide for Intel® SGX Provisioning Certificate Caching ...
Architecture Overview – ECDSA-Based Data Center Attestation . ... If caching fill mode is not 'LAZY', returns the 404 (No cache data) error...
Read more >PIV Attestation Verification Fails with OpenSSL 1.1.0 – Yubico
This is caused by an issue with the PIV Attestation Root Certificate. Starting with the YubiKey 5 series, an updated PIV Attestation Root ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@aslawson @i1skn Great work hunting this down so far.
I think Ivan’s assessment just above is probably right.
@i1skn that’s correct. Given that the interplay between UI + Saga for verification is quite complex, we need to be careful about any changes to state management and error handling.
We confirmed this is not a signature verification issue or anything related to the 64-bit geth client when calling
findMatchingIssuer
. Ivan tested on an android ARM64 bit device, and I did so with geth-linux-arm64 build running on docker. Both instances returned the expected message mapping to each of the attestation services.Issuer1: 0xDdbca691842FD452d8F53575FdFdC2314eb3AD57 Msg1: celo://wallet/v/5vuL14KNEbtiGJb0rMTxorAEvxoZ/s+FGNXJ+F/1pVF87CMLSlo68dFaC+NeIiLmEsA3U0yt8mjM66LT7NqeDBs=
Issuer2: 0x7b3859147B1C173FfF7182E58A4Ec81C1d287224 Msg2: celo://wallet/v/lNeEQhZ2lyq+5ltsLHAl/KvjTMubBrS7NMpPMFaTCsosDS1Q3KaJeL74kEFN4nXZBy4nIc/5E6qIapGKgzNxnRw=
Issuer3: 0x48aC52662CBF32f8FC0cd8c1122c7560b482c2AD Msg3: celo://wallet/v/g24qWPX2qL9Wyut2wX47EBh9Wa/7L+LvvpWaYbswZFEMOgN//GeCjnNBk3b15h+24bQLHka2bLyw+kF0Eg9lkxw=
I confirmed on-chain that Issuer1 is the issuer that is still in the INCOMPLETE state.
I dug further into Martin’s logs. Unfortunately, we do not have logs from the original verification flow, but we have logs from a re-attempt with just the missing attestation. In this attempt, it identifies that 2/3 attestations are complete and that Issuer1 is remaining.
Info [2020-07-16T17:14:00.517Z] ValoraAnalytics/Tracking event verification_fetch_status_complete with properties: {"timestamp":1594919640513,"sessionId":"65d5d1c0e8619ad2ce3be53e8323ffa245e72f07d960b31d5d0be3ee8955d8","userAddress":"0xe76313cd887929044a472e0cfa48c9e47d15b69a","**isVerified":false,"numAttestationsRemaining":1,"total":3,"completed":2}**
According to the slack discussion, the user was confident that he was sending Msg2 even though it corresponds to a COMPLETED issuer (Issuer2). Based on the slack conversation the other two messages return “Code already exists” errors.
This message in this logged attempt did not receive a “Code already exists” error and moved to the next line in the code where it called
findMatchingIssuer
passing in Issuer1 only – confirmed from the logs:verification_request_all_attestations_complete with properties: {"timestamp":1594919642821,"sessionId":"65d5d1c0e8619ad2ce3be53e8323ffa245e72f07d960b31d5d0be3ee8955d8","userAddress":"0xe76313cd887929044a472e0cfa48c9e47d15b69a","issuers":["**0xDdbca691842FD452d8F53575FdFdC2314eb3AD57**”]}
If this was indeed called with Msg2, that would explain why
findMatchingIssuer
returns “No issuer found for attestion code” error, since only Issuer1 was in the array to compare and that is not a match.I cannot explain how Msg1 was marked as an
acceptedAttestationCodes
in the user state and Msg2 was incorrectly unmarked. I’ve tried to dig into the mobile flow to see where there could have been a race condition that would allow them to be mixed up, but I can’t find anything. Any ideas from mobile folks @cmcewen @i1skn? I’ll can try to see if there are different logs/events I can dig into to understand what initially happened on the first verification attempt.