xChk: Bring Your Own Identity -- Heterogeneous Assurance with Verifier-Determined Sufficiency

Source: arXiv:2607.13369 · Published 2026-07-15 · By Sean MacGuire

TL;DR

xChk addresses a fundamental gap in identity provisioning for OAuth 2.0 / OpenID Connect ecosystems by enabling Bring Your Own Identity (BYOI) with multi-modality assurance portfolios rather than single-modality authentication tokens. Users enroll via multiple heterogeneous identity verification modalities—including government KYC, corporate SSO, WebAuthn/FIDO2, professional networks, live verification, and behavioral signals—resulting in a rich, typed assurance portfolio embedded in standard OIDC tokens. The relying party (RP) independently evaluates the sufficiency of provided claims according to its own policies, while the IdP transports claims and optionally aids in consent-time policy evaluation without deciding access.

Additionally, xChk supports hybrid human-in-the-loop attestation workflows integrating humans and AI agents within a unified verification graph, providing hash-chained approvals, delegation with scope and revocation control, and optional blockchain anchoring. The reference implementation at in.xchk.io demonstrates these features in production with an example RP, leveraging standard OAuth/OIDC flows extended with nested portfolio claims and a rich attestation gateway API. This approach enables fine-grained, verifiable, and portable identity assurance composable across organizational contexts and agent delegation hierarchies.

Key findings

• xChk aggregates 10 heterogeneous identity assurance modalities into typed portfolio artifacts embedded in OIDC tokens, including government KYC (Didit), corporate SSO (Entra ID, Google Workspace), WebAuthn/FIDO2, professional verification (LinkedIn), live helpdesk verification, and behavioral signals (§3.1, Table 3).
• RPs independently adjudicate access sufficiency by evaluating disclosed portfolio subsets against policies supplied to the IdP, which evaluates but does not decide access, preserving separation of concerns (§3.3).
• xChk attestation records form hash-chained, HMAC-signed append-only chains with optional Ravencoin blockchain anchoring; attestations support multi-step approval, progressive notifications, and are surfaced as portfolio artifacts on user logins and token refresh (§4.1-4.2).
• Delegation chains from human root principals through agents enforce scope monotonicity and support cascading revocation on agent deletion, with the chain and scope metadata embedded in access tokens for runtime enforcement (§4.4).
• Production deployment supports three usage surfaces: (A) RP OIDC ID tokens with portfolio claims and bilateral RP evaluation; (B) first-party xChk access tokens with trust scores, attestations, and delegation chains; (C) agent API for authorization, attestation, and revocation (§5.1 Table 1).
• Bilateral evaluation at consent simultaneously enforces RP evidence policies against the user's disclosed portfolio and enforces user-defined policies on the RP's institutional identity portfolio, blocking portfolio disclosure if the RP fails domain control and KYB requirements (§3.3).
• Production supports consent-time fresh verification via WebAuthn or PIN and per-app artifact selection by users, enhancing user control and trust (§5.3).
• Hermes guardrails integration enables end-to-end dangerous command pattern detection in attestation approvals; currently about 50 patterns shipped (§5.4).

Threat model

The adversary may attempt to impersonate users or delegate agent identities to perform actions without proper authorization or assurance. They do not have direct control of the identity provider or verification modalities but may try to circumvent enrollment processes or present forged claims. They cannot produce valid hash-chained attestations nor valid delegation chains rooted in a verified human operator without detection. The adversary cannot compromise the HMAC keys used for portfolio claim integrity or the RS256 signing keys for tokens. Attestation approvals must be signed with WebAuthn passkeys by authorized human approvers, limiting remote compromise.

Methodology — deep read

Threat Model & Assumptions: The primary adversary is an attacker impersonating a human principal or agent attempting unauthorized access or actions via OAuth/OIDC flows and delegated agent APIs. The IdP assumes trustworthy evidence providers for enrollments but does not adjudicate RP access. Adversaries cannot forge valid portfolio claims without completing enrollment modalities or compromising human attestations. Agents operate under scoped delegation chains rooted in verifiable human principals.

Data: The system aggregates heterogeneous identity evidence streams including government KYC (Didit), corporate SSO (Entra ID, Google Workspace), professional network verification (LinkedIn), WebAuthn/FIDO2 passkey registrations, live helpdesk or interview verifications, longitudinal platform activity (GitHub, LinkedIn), behavioral signals (e.g., device/location/time consistency), and prior human attestations. Each modality emits typed assurance artifacts with timestamp and provider metadata. The dataset/verification portfolio size is not explicitly quantified but production supports at least ten artifact types (§3.1, Table 3).

Architecture/Algorithm: xChk extends standard OAuth 2.0 / OIDC flows by embedding a nested xchk.portfolio claim in ID tokens and access tokens, containing typed assurance artifacts, verified with an HMAC-SHA256 signature over the portfolio, RP policy, and institutional data—ensuring integrity beyond the RS256 JWT signature. Human entities receive tokens with these assurance portfolios; agent entities carry delegation chains encoding scope-restricted authorizations cryptographically linked to human principals (§3.2).

The IdP evaluates RP-submitted evidence policies against the user's portfolio at consent to provide xchk.policy claims indicating satisfied or missing evidence but leaves final access adjudication to the RP. xChk supports bilateral portfolio evaluation by assessing the RP's institutional verification portfolio against a subject-defined policy, gating portfolio disclosure when requirements like DNS domain control or KYB are unmet (§3.3).

The attestation protocol supports both human-initiated and AI-agent-initiated attestations, with hash-chained, HMAC-signed attestation records containing metadata (action, approver, outcome, timestamp). The attestation gateway enforces OAuth 2.0 scopes, progressively notifies approvers, enforces WebAuthn passkey verification, and optionally anchors attestations to Ravencoin OP_RETURN transactions (§4).

Delegation chains encode ordered scopes in strictly monotonic subsets down the chain, enabling runtime authorization checks via API calls. Cascading revocation invalidates all descendant agents and their keys when a root human entity or intermediate agent is revoked. Multi-entity session tokens aggregate delegation chains and scopes for complex workflows (§4.4-4.5).

Training & Evaluation: Not applicable as this work is a system design and reference implementation rather than a machine learning model.

Evaluation Protocol: The paper describes production usage at in.xchk.io and a documented relying party crabbyed.com exercising Login with xChk using full OAuth 2.0 / OIDC authorization code flows with PKCE. The effectiveness of the portfolio claims embedding, bilateral consent, and attestation flows are demonstrated in this production deployment, but no formal security proofs or quantitative user studies are reported. Appendix C contains a microbenchmark of the public endpoints.

Reproducibility: The reference implementation is publicly deployed at https://in.xchk.io; however, source code release status is unclear in the text. The dataset includes real-world identity verification providers such as Didit, Entra ID, LinkedIn, suggesting closed-proprietary provenance. No frozen model weights or artifacts apply as this is an architectural system paper.

Concrete example end-to-end: A user enrolls via government KYC (Didit), corporate SSO, and FIDO2 passkey. These artifact claims form a typed portfolio embedded into an OIDC ID token with an HMAC-protected xchk.portfolio claim. The user authenticates via Login with xChk at an RP implementing bilateral consent, where the RP policy is evaluated against the disclosed portfolio subset. High-risk actions require an attestation initiated by a human approver via the xChk attestation gateway, which emits a hash-chained approval record surfaced in the next token refresh. Delegated agents operate under scoped authorization chains rooted in human principals, and cascading revocation enables invalidation of compromised delegations.

Technical innovations

• Portfolio claims embedding heterogeneous multi-modality identity assurance artifacts as typed nested claims within standard OAuth 2.0 / OIDC tokens with HMAC portfolio integrity protection.
• Verifier-determined sufficiency semantics separating the roles of the IdP (enrollment, claim transport, policy assistance) and Relying Party (access adjudication) over rich assurance portfolios.
• Unified human and AI agent identity governance on a single verification graph with hash-chained, human-rooted delegation chains enforcing monotonic scopes and cascading revocation.
• Human-in-the-loop attestation gateway supporting progressive notifications, multi-approver escalation, WebAuthn passkey verification, and optional blockchain anchoring integrated into OAuth/OIDC flows.
• Bilateral consent model evaluating RP institutional portfolio against subject-defined policies, gating portfolio disclosure before user consent.

Datasets

• Didit KYC — proprietary government ID and liveness verification
• Corporate SSO logs — Entra ID and Google Workspace internal authentication records
• LinkedIn verification API data — professional network attestations
• GitHub OAuth activity — longitudinal platform identity signal
• WebAuthn/FIDO2 credential registrations — cryptographic authenticator events
• xChk internal attestation records — hash-chained approval records from deployment

Baselines vs proposed

• Traditional single-modality OAuth/OIDC providers (e.g., Okta, Auth0): identity tokens assert only authentication event without multi-modality assurance portfolio or verifier-determined sufficiency. xChk extends the paradigm with typed portfolio claims and bilateral evaluation of RP and subject policies.
• KYC platforms like Persona, Jumio: provide identity proof flags or verifiable credentials but require separate integration; xChk uniquely aggregates heterogeneous proofs into standardized OAuth/OIDC tokens.
• Decentralized identity solutions (W3C VCs, Microsoft Entra Verified ID): require relying parties to implement credential verification infra outside OAuth; xChk integrates diverse modalities within OAuth/OIDC with RP policy evaluation.
• Agent governance frameworks (AgentBound, OIDC-A): govern behavior or support agent identity but lack BYOI multi-modality portfolio tokens and human-rooted delegation chains; xChk complements these by providing the identity assurance layer.

Figures from the paper

Figures are reproduced from the source paper for academic discussion. Original copyright: the paper authors. See arXiv:2607.13369.

Fig 1: xChk System Architecture—Three-domain architecture showing the User Domain (modalities,

Fig 2: xChk Identity Token Structure—Standard OIDC claims, entity type, human assur-

Fig 3: Attestation Protocol Sequence—Production attestation sequence (agent-triggered variant shown;

Fig 4: Delegation Chains and Cascading Revocation—Left: Normal delegation chain from human root u

Limitations

• The system currently has limited third-party RP adoption beyond a single documented relying party (crabbyed.com); broader ecosystem impact remains to be demonstrated.
• Blockchain anchoring of attestations via Ravencoin OP_RETURN is optional and partially supported, requiring a running Ravencoin node, limiting decentralization guarantees for attestation immutability.
• No formal security proofs or quantitative evaluations of attacker resistance or usability are presented, focusing primarily on architectural design and production implementation.
• Agent entities do not yet appear in RP OIDC tokens; management of non-human entity types currently requires separate agent API surfaces, limiting unified RP token acceptance.
• Dependence on trusted external KYC and professional verification providers may limit assurance portability and introduce trust assumptions external to xChk.
• Fresh verification enforcement relies on WebAuthn passkeys or PIN re-verification but may be bypassed if RPs do not enforce policies strictly.

Open questions / follow-ons

• How does the system perform under adversarial enrollment attempts that try to game or spoof individual modalities, e.g., synthetic behavior signals or compromised SSO?
• What are the scaling properties of hash-chained attestations and delegation chains as agent counts and approval workloads grow in large organizations?
• How might zero-knowledge proofs or other cryptographic techniques be integrated to improve privacy while preserving verifier sufficiency evaluation in portfolio claims?
• To what extent can the attestation gateway and delegation constructs be expanded to interoperate with emerging agent identity standards such as OpenID Connect for Agents (OIDC-A)?

Why it matters for bot defense

For bot-defense and CAPTCHA practitioners, xChk represents a significant advancement in identity assurance frameworks underpinning strong and granular user verification beyond simple authentication assertions. Incorporating heterogeneous assurance evidence into tokens allows relying parties to tailor sufficiency policies for varying security and risk profiles—an essential capability in high-risk environments requiring differentiated access controls.

Moreover, xChk’s ability to unify human and AI agent identity governance with human-in-the-loop attestation and scoped delegation enriched with cryptographic audit trails offers a powerful means to mitigate automated abuse by ensuring that bot or agent actions are always anchored to verifiable human approvals and constrained permissions. The architecture aligns well with multi-factor CAPTCHA challenges needing risk-based adaptive triggers and consent flows, enabling next-generation bot-defense systems to integrate identity assurance portfolios directly into session and authorization tokens. However, practical adoption requires careful integration into existing OAuth/OIDC ecosystems and attestation workflows.

Cite

@article{arxiv2607_13369,
  title={ xChk: Bring Your Own Identity -- Heterogeneous Assurance with Verifier-Determined Sufficiency },
  author={ Sean MacGuire },
  journal={arXiv preprint arXiv:2607.13369},
  year={ 2026 },
  url={https://arxiv.org/abs/2607.13369}
}

Read the full paper

• arXiv:2607.13369 (abstract)
• arXiv:2607.13369 (PDF)