improve(internet-identity): add derivationOrigin anti-pattern pitfall (#146)

Add mistake `#7`: icp0.io and ic0.app produce the same principal (II
auto-rewrites). Adding derivationOrigin or ii-alternative-origins for
this breaks auth. Different principal = different passkey/device.

Add eval for the domain equivalence diagnostic scenario.

Addresses #136 (F3).

Author: marc0olo

evaluations/internet-identity.json

@@ -59,6 +59,15 @@
         "Explains that top-level await requires ES2022+ and Vite defaults to es2020",
         "Shows a concrete example of wrapping the auth initialization in an async function"
       ]
+    },
+    {
+      "name": "Different principal after login on icp0.io vs ic0.app",
+      "prompt": "A user reports getting a different principal when accessing my app via icp0.io compared to ic0.app. Should I add derivationOrigin to fix this?",
+      "expected_behaviors": [
+        "Explains that icp0.io and ic0.app produce the same principal — II auto-rewrites icp0.io to ic0.app during delegation",
+        "Advises NOT to add derivationOrigin or ii-alternative-origins for this",
+        "Suggests the different principal is likely caused by a different passkey or device"
+      ]
     }
   ],
 

skills/internet-identity/SKILL.md

@@ -39,6 +39,8 @@ Internet Identity (II) is the Internet Computer's native authentication system.
 
 6. **Passing principal as string to backend.** The `AuthClient` gives you an `Identity` object. Backend canister methods receive the caller principal automatically via the IC protocol -- you do not pass it as a function argument. The caller principal is available on the backend via `shared(msg) { msg.caller }` in Motoko or `ic_cdk::api::msg_caller()` in Rust. For backend access control patterns, see the **canister-security** skill.
 
+7. **Adding `derivationOrigin` or `ii-alternative-origins` to handle `icp0.io` vs `ic0.app`.** Internet Identity automatically rewrites `icp0.io` to `ic0.app` during delegation, so both domains produce the same principal. Do not add `derivationOrigin` or `ii-alternative-origins` configuration to handle this — it will break authentication. If a user reports getting a different principal, the cause is almost certainly a different passkey or device, not the domain.
+
 ## Using II during local development
 
 ### icp.yaml Configuration