Can this login map to a DSCVR user?

What this test is for

This page is not trying to restore DSCVR's normal production login flow. It is only checking whether a login method can produce a principal that can be used in the airdrop proof flow. The observed 500 / get_self() issue appears to happen when DSCVR's API asks the edge canister verifier to validate IC delegation or canister-signature data that uses the newer IC certificate/state-tree shape.

Two login families

1. DSCVR-hosted login: Google, wallet, username, and Worldcoin. These buttons open provider-specific routes under id.dscvr.one. After the provider authenticates the user, the page still receives a standard auth-client identity through authClient.getIdentity(), plus the derived principal.
2. IC-native login: Internet Identity and NFID legacy. These principals are strongly tied to the application origin and, when provided, the derivation origin. A localhost build or a new subdomain may produce a different principal, or may be rejected by Internet Identity. To test whether the result maps to old DSCVR data, the claim page should be tested under an authorized origin path such as https://social.dscvr.one/..., not an arbitrary new subdomain.

Core idea

An airdrop claim needs to prove two things: the user controls a DSCVR principal, and the user controls the EVM address that will receive the tokens. This lab makes the IC identity and the EVM wallet sign the same canonical payload. If both proofs verify, the payload's principal, wallet address, campaign, nonce, and origin can be treated as bound together.

Six-step flow

1. Read authClient.getIdentity().getPrincipal(). The principal is not manually entered.
2. Connect an EVM wallet and read its address and chainId.
3. Build the shared payload: type, version, campaignId, principal, evmAddress, chainId, nonce, issuedAt, expiresAt, and origin.
4. Build the IC proof: put the canonical payload into the IC request arg, then use the current IC identity to sign that request.
5. Build the EVM signature: use the connected wallet to personal_sign the same canonical payload.
6. Read the IC proof and EVM signature from editable text areas, then verify both. This makes it easy to tamper with fields and confirm that verification fails.

What the IC proof verifies

content.argUtf8 is the payload. content.sender is the principal. sender_pubkey_b64 can derive the self-authenticating principal. sender_sig_b64 is the session key signature over the IC request. sender_delegation is the authorization chain from the principal to the session key. Verification checks that the principal matches, the payload matches, the delegation is not expired, the scope is acceptable, and the request signature is valid.

What the EVM signature verifies

The EVM proof contains address, message, and signature. Verification checks that the address equals payload.evmAddress, the message equals the canonical payload, and verifyMessage(address, message, signature) succeeds.

Tamper tests and nonce

Tamper IC proof changes the payload nonce inside the IC proof without regenerating the IC signature, so payload matching and request-signature verification should fail. Tamper EVM sign changes the final hex character of the EVM signature, so EVM verification should fail. In a production claim flow, the nonce should be backend-issued, short-lived, and single-use. Its main job is to stop old proof/signature pairs from being replayed or submitted by someone else first.

-

-

-