身份证实名认证。验证姓名与身份证号是否一致，支持全国居民身份证。使用场景：用户说"身份证认证"、"实名认证"、"验证身份证"、"姓名和身份证是否匹配"、"身份证二要素核验"等。通过聚合数据（juhe.cn）API 实时核验，免费注册每天免费调用。

This skill appears to implement what it claims (ID two-factor checks via juhe.cn) and only requires one API key, but there are concrete security and correctness issues you should address before using it with real user data: - Use HTTPS: change API_URL to https://op.juhe.cn/idcard/query so the API key and PII are transmitted over TLS. Sending the key over plain HTTP can expose it to network observers. - Stop printing raw API responses: remove or redact the final print(json.dumps(result,...)) so the unmasked idcard/realname and any returned fields aren’t leaked to logs or stdout. - Fix result semantics: confirm the API's `res` values (SKILL.md and script disagree about whether non-match is 0 or 2) and make the code and documentation consistent so users see correct results. - Protect the API key: prefer environment variables or a secure secret store; if you use a .env file, ensure it is not committed to source control (.gitignore it). Rotate the key if it may have been exposed during testing. - Be mindful of privacy/regulatory issues: handling real ID numbers has legal and privacy implications in many jurisdictions; only collect/verify IDs with explicit consent and secure storage. If you cannot or will not modify the script, do not use it with real PII because of the HTTP/plaintext and logging issues. After the above fixes and a short security review (confirm HTTPS, remove raw dumps, and test behavior), the skill would be reasonable to use. If you want, I can produce a small patch showing the exact code changes (switch to HTTPS, remove JSON dump, and fix the res mapping) you should apply.

Type: OpenClaw Skill Name: juhe-idcard-verify Version: 1.0.0 The skill is designed to verify Chinese identity cards using a third-party API (juhe.cn). While the behavior aligns with the stated purpose, the script `scripts/idcard_verify.py` transmits highly sensitive PII (names and ID numbers) over an unencrypted `http://` connection (API_URL), despite the documentation in `SKILL.md` suggesting HTTPS. There is no evidence of intentional malice or hidden data exfiltration, but the insecure handling of PII constitutes a significant security vulnerability.