Security and responsible disclosure
Report vulnerabilities privately to security@emabled.com.
Scope
Reports may cover the XCIM protocol design, public web properties, reference-network components when released, proof verification, recipient privacy, issuer impersonation, key lifecycle and implementation behavior that could produce an incorrect positive result.
Identity Evidence security boundary
XCIM does not blindly trust identity claims provided by the application. The XCIM Consent Issuer must independently validate the configured Identity Evidence profile before presenting or completing the consent decision.
For EVP this includes, according to the active external specification: recipient match, successful provider assertion, verifier audience/origin binding, per-session nonce, freshness, browser key binding, provider/issuer discovery, issuer signature verification and replay prevention. For OIDC this includes the profile-defined issuer, audience, nonce, signature, time and claim checks.
Identity success is a prerequisite to the high-assurance consent flow. It is never equivalent to consent.
Threats to track
- Identity evidence replay
- Vendor-provided fake identity evidence
- EVP issuer discovery abuse
- OIDC token replay
- Identity/consent session mismatch
- Experimental protocol behavior change
Reporting expectations
- Include the affected component, impact and reproducible steps.
- Do not include live recipient data or access data beyond what is necessary to demonstrate impact.
- Allow reasonable time for coordinated remediation before public disclosure.
- English and Spanish reports are supported.
Response and encryption
Target acknowledgement is five business days. A dedicated PGP key and counsel-reviewed safe-harbor statement are not yet published; this is an explicit publication limitation. Sensitive reports should request an encrypted follow-up channel before sending secrets.
Machine-readable policy: /.well-known/security.txt.