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

Sean MacGuire

REVIEW 3 major objections 5 minor 22 references

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

T0 review · 3 major / 5 minor · reviewed 2026-08-02 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read xChk is a production OAuth/OIDC identity provider that packs varied identity proofs into portable portfolio claims and leaves access decisions to each relying party.

desk verdict A clearly written architecture for a BYOI OIDC IdP with portfolio claims and human/agent attestation — novel synthesis, honest about its limits, but the formal model and production revocation tree don't provably match. read the letter →

arxiv 2607.13369 v1 pith:OA5AQNSU submitted 2026-07-15 cs.CR cs.CY

Sean MacGuire This is my paper · ORCID

classification cs.CRcs.CY

keywords BringYourOwnIdentityassuranceportfolioOAuth2.0OpenIDConnectverifier-determinedsufficiencyagentdelegationhuman-in-the-loopattestationcascadingrevocation

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

xChk is a production identity provider built around a transfer of authority: users enroll through many independent channels (government ID, corporate SSO, passkeys, professional networks, interviews, behavioral signals), and each enrolled proof becomes a typed artifact in a portable portfolio carried inside ordinary OAuth 2.0 / OpenID Connect (OIDC) tokens, the standard protocols for web login. The identity provider verifies enrollments and transports the user-selected subset of artifacts, but it does not decide who gets access; each relying party—the application being logged into—runs its own policy over the disclosed portfolio. The same verification graph also governs non-human entities: agents inherit scopes from a human principal through a delegation chain, and human approvals are recorded in a hash-chained attestation stream that can optionally be anchored to a blockchain. The paper argues this combination is missing from existing production providers and reports a live implementation with one documented relying party, plus micro-benchmarks of public endpoints. It presents xChk as an architectural model and shipped reference, not a formal security proof.

What carries the argument

The load-bearing mechanism is the typed portfolio claim carried inside standard OAuth/OIDC tokens. Each verification modality yields an assurance artifact (type, value, timestamp, issuer tier), the user consents to a per-app subset, and the IdP's token additionally carries an evidence-policy evaluation and a portfolio HMAC over the disclosed snapshot so an RP can verify integrity without a second lookup. For non-human entities, the matching mechanism is the delegation chain: each link records an entity, a scope, a parent, and an attestation, scopes are monotonically non-expanding down the chain, and deletion of a parent triggers a breadth-first revocation walk over descendants. The attestati

What would settle it

On the live system, register two agents under one human root via the attestation API, have the human approve an action, then delete the root; if the descendant agent can still call the authorize endpoint or obtain an elevation grant, the cascading revocation claim is falsified. Alternatively, produce any production OAuth/OIDC identity provider that already combines all seven listed capabilities, which would falsify the gap claim.

Watch

Extended reading notes

Core claim

The central claim is that identity assurance need not be a single level-of-assurance number issued by one login method. xChk defines an identity assurance profile over a finite set of verification modalities, each with its own assurance space, and emits a token whose payload is the user-chosen subset of (modality, assurance) pairs. Relying parties receive standard OIDC ID tokens with nested portfolio claims, an evidence-policy evaluation for display, and an HMAC over the consent-time snapshot; the relying party's own policy function maps the disclosed portfolio to Accept or Reject, while the IdP neither grants nor denies access. On the same graph, agents authenticate with API keys and can pr

Load-bearing premise

The load-bearing assumption is that the delegation chains attached by integrators at attestation time match the parent-agent tree the system walks on deletion, so cascading revocation actually reaches every agent that acts under a revoked human; the paper shows the two mechanisms side by side but does not prove they coincide.

Editorial extensions

If this is right

Relying parties can require a combination of artifact types (say, KYC plus passkey plus a prior helpdesk pass) instead of trusting a single login method or an ordinal assurance level.
Users keep the same portable assurance portfolio across relying parties; pairwise subject identifiers and per-app artifact selection limit cross-RP correlation.
AI agents can act on behalf of a verified human root, and approval history travels with the identity via refreshed tokens and attestation portfolio artifacts.
Deleting a parent agent or human root invalidates descendant agents' API keys through cascading revocation, giving operators a single revocation point for a whole agent tree.
Because everything rides standard OIDC flows, existing applications can adopt the mechanism by parsing nested claims and applying their own policy, without building verifiable-credential infrastructure.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

If the portfolio-HMAC pattern were standardized, any identity provider could emit consent-time integrity snapshots, and relying parties could audit token contents without trusting the IdP's read path; the open problem is key distribution, which the paper handles by out-of-band secret sharing.
The verifier-determined sufficiency split is a general evidence-evaluation model that could be lifted out of identity and applied to any domain where a subject holds typed evidence and each verifier sets its own bar.
The paper's revocation guarantee is only as strong as the correspondence between the deletion tree and the integrator-supplied delegation metadata; an independent deployment could test that correspondence by deleting a root and probing descendant agents.
If full non-human OIDC entity types ship on the RP token path as the status table lists as future, third-party applications could eventually apply the same portfolio-policy engine to agents, not just humans.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Sean, quick read on arXiv:2607.13369.

The real news is the combination. I know of no production OAuth/OIDC provider that does BYOI multi-modality enrollment, portable portfolio claims with RP-side sufficiency, unified human/agent governance, and hash-chained human-in-the-loop attestation on one graph. The paper's three-way separation — user controls disclosure, IdP transports, RP adjudicates — is clean, and the typed portfolio of artifacts is a genuine improvement over a single LoA integer. It also does the field a service by being explicit about what it doesn't do.

Credit where due: the system is concrete. There's a live endpoint, a public HMAC verifier, a documented RP, and a small latency benchmark. The paper explicitly flags that the one RP shares operational ownership, that source is private, and that there's no formal user study. That's honest, and it means the architecture is assessable even when the production claims aren't independently verifiable.

The soft spots are real but not fatal. The stress-test gets the main one right: §4.4's Eq. (6) defines revocation over delegation-chain descendants, but the production implementation revokes by BFS on parentAgentId, and §3.2 says the platform doesn't auto-walk that tree to mint chains. Nothing in the paper shows the two relations coincide. So 'human-rooted delegation with cascading revocation' is only as strong as integrators' consistency. That's a load-bearing gap between the model and the implementation, and the paper's own 'By contrast' highlights it without resolving it. The other weakness is the self-reported 'shipped' statuses — verification weakness, not fabrication.

For a systems paper, the architecture is coherent and the writing is clear. The proof burden isn't met, but the paper doesn't claim a security proof. I'd send it to a serious referee: the revocation/delegation consistency needs to be sorted, and the author should either publish code or get an independent RP. I'd read it again when that happens. It's a worthwhile contribution to the agent-identity conversation.

Referee Report

3 major / 5 minor

Summary. The paper presents xChk, a reference identity provider for Bring Your Own Identity (BYOI). Users enroll via a heterogeneous set of verification modalities (KYC, corporate SSO, WebAuthn, professional networks, live checks, longitudinal activity, behavioral signals) and disclose these as typed portfolio claims in standard OAuth 2.0 / OIDC ID tokens, while each relying party (RP) applies its own sufficiency policy. The IdP transports claims and optionally evaluates an RP-supplied evidence policy for consent, but does not adjudicate access. xChk also supports human-in-the-loop attestation for high-risk actions: humans can initiate attestations directly, and AI agents can trigger the same gateway via a scope-gated authorize/attest API. Attestation records are hash-chained, HMAC-signed, and optionally anchored on Ravencoin. The paper claims a production deployment at https://in.xchk.io with one documented RP (crabbyed.com) exercising the surface-A OIDC flow, three delivery surfaces (RP ID token, first-party access token, agent API), and a status table asserting that constructs (1)-(6) are shipped and (7) is available when Ravencoin anchoring is enabled.

Significance. If the described architecture is faithfully implemented, xChk fills a real gap: existing IdPs are single-modality, KYC vendors do not issue OIDC tokens, verifiable-credential systems require separate RP infrastructure, and agent-identity systems generally do not carry human assurance portfolios. The three-way separation of user control, IdP transport, and RP adjudication is a useful design pattern, and the bilateral evaluation of the RP's institutional portfolio is a novel production twist. The paper also ships concrete public artifacts: an OIDC discovery endpoint, an OAuth playground, and a runnable portfolio-HMAC verifier. These are genuine strengths. The significance is diminished, however, because the strongest claims are self-attested: source code is private, the single documented RP shares operational ownership, and no independent audit or end-to-end transcript is provided.

major comments (3)

[§3.2 / §4.4 / Eq. (6)] The formal revocation guarantee is defined over delegation-chain ancestry, but the production implementation revokes by a BFS walk over parentAgentId. §3.2 says delegationChain is integrator-supplied metadata and the platform does not auto-walk the parentAgentId tree to mint chains; no invariant or validation is described that an agent's parentAgentId equals the parent_id of its delegationChain. If those graphs diverge, an agent whose xchk_delegation_chains claims a human root may keep its API key after that root (or an intermediate) is revoked. Additionally, Eq. (6) invalidates only tokens with entity_id in Descendants(e); if Descendants is the transitive closure excluding e itself, the revoked entity's own tokens are not invalidated. Please either enforce/stated the consistency invariant or weaken the claim to revocation of the parentAgentId tree.
[§5.2 / §8 / Appendix B] The central 'ships (1)-(6) in production' claim rests entirely on the author's implementation status table. Source code is explicitly private (§8), and the sole documented RP explicitly shares operational ownership with the xChk deployment (Appendix B). A reader cannot independently verify that the documented flows exist, that the table is complete, or that the described security-relevant behaviors (e.g., cascading revocation, WebAuthn-only approval) are enforced. For a paper whose contribution is a working production system, this is a load-bearing verification gap. Consider releasing the relevant code/configuration, supplying an independent audit or deployment report, or recasting the claims as author-operated demonstration rather than production readiness.
[§5.6 / §4.2] The only reported measurement is a micro-benchmark of public endpoints, and the sampled operations are the 'invalid client' and 'no API key' reject paths, plus a local HMAC verify. No successful end-to-end OIDC code exchange or agent attestation lifecycle (capture -> authorize -> WebAuthn approval -> hash-chained record -> xchk_attestations refresh) is demonstrated with a reproducible transcript or script. Since surface C is claimed shipped, an executable integration test or captured trace is needed to substantiate the §4.2 protocol description; otherwise the production claim for HITL attestation is unverified.

minor comments (5)

[§3.2] The wire-encoding notes (nested dotted names versus flat snake_case claims) are hard to follow. The table helps, but the rule for when a field is duplicated at the top level (xchk_signature, xchk_signing_key_id, xchk_entity_type) could be stated more explicitly in prose.
[Figures 1-4] The manuscript contains only figure captions; the diagrams are not embedded. Since the paper refers to an external PDF for the figures, please embed them directly in the submission.
[Appendix A / C] The key derivation is described as 'the first 32 hex characters of SHA256(...)', which is ambiguous. Appendix C implements this as the ASCII encoding of those hex characters. Please state this explicitly in Appendix A.
[§4.2 / §4.4] In the attestation lifecycle, delegationChain metadata is 'optional' at record creation, but §4.4 treats it as the carrier of delegation and says xchk_delegation_chains is assembled from portfolio artifacts. It would help to state whether delegationChain is required for agent attestations and what happens if it is omitted.
[§5.6] The note that successful authorize/attest and full OIDC code exchange latencies are not reported is buried in the benchmark discussion. Consider moving it to the Limitations section so the reader is not left with the impression that the reported latencies characterize the full flow.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: xChk's claims are architectural/shipped-status assertions; no fitted parameter is relabeled as a prediction and no load-bearing self-citation chain exists.

full rationale

Walked the claimed derivation chain: §3 defines IAP(u), §3.2 defines token T, §3.3 defines RP policy P_rp, §3.4 defines trust score S as a monotone function of enrolled modalities, §4 defines attestation records, and §4.4 defines cascading revocation via Descendants(e). Each is a direct definition of intended system behavior, not a quantity derived from fitted data. Nothing is 'predicted' from an input that already contains it; the portfolio HMAC (Appendix A/C) is a self-contained integrity check, not an empirical prediction. The 'gap' claim in §2.8 is an explicit 'To our knowledge' empirical assertion, not a theorem derived from xChk's own definitions; it is self-attested, but self-attestation is a verification weakness, not circular reasoning. The reference list contains no self-citations by the author, and no prior-work 'uniqueness theorem' is imported to force a choice. The nearest concern is the revocation model: Eq. (6) defines revocation via delegation-chain ancestry, while §4.4/§5.2 say production revocation is a BFS walk on parentAgentId, and §3.2 states the platform 'does not auto-walk the parentAgentId agent tree to mint chains.' If the integrator-supplied delegationChain graph and the parentAgentId tree diverge, the 'cascading revocation' guarantee may fail; the paper never states an invariant tying the two relations. That is a specification/implementation consistency gap and a correctness risk, not a case where the conclusion reduces to its input by construction. Similarly, Appendix B explicitly says Crabby Editor 'shares operational ownership' and should be read as 'a reference integration, not independent ecosystem adoption,' and §6.4/§8 concede one documented RP and private source code; these limit external validation but do not make any derivation circular. Therefore no circular step is exhibited, and the honest finding is no significant circularity.

Assumptions & free parameters 0 free parameters · 5 assumptions · 3 invented entities

The paper introduces several new data and governance constructs — portfolio HMAC, plateState, plate identifiers, attestation_completed artifacts — but none has independent evidence outside the paper/live service; they are part of the claimed system, not independently verifiable entities. No physical entities are posited. The core axioms are standard OAuth/OIDC, WebAuthn, external issuer trust, organizational trust, and cryptographic hash/HMAC assumptions.

assumptions (5)

domain assumption Standard OAuth 2.0 / OIDC flows and RS256 JWT signatures provide baseline integrity and replay protection.
Invoked throughout §5.3 and §6.1; no proof or formal verification is supplied for the protocol-level security.
domain assumption WebAuthn passkey verification on attestation reply authenticates the human approver.
§4.2 step 5 and §5.4 require passkey; the paper assumes this binds approval to a human.
domain assumption External enrollment providers (Didit, Entra ID, Google Workspace, LinkedIn, GitHub) return truthful signals and can be linked to the enrolling user.
Table 3 treats each source's output as an assurance artifact; no mechanism is described for detecting enrollment fraud or account takeover at the source.
domain assumption Domain control, KYB, and officer binding establish a reliable institutional portfolio for OAuth client trust.
§3.3 bilateral evaluation and production OAuth gates rely on DNS/KYB/officer-bound status; no independent test is given.
standard math SHA-256 hash chaining and HMAC signing with a server-held secret produce an append-only, tamper-evident attestation log.
§4.1 defines chain_hash and HMAC; relies on standard cryptographic assumptions.

invented entities (3)

xchk portfolio HMAC scheme (xchk-portfolio-v1)
purpose: Integrity check for consented portfolio snapshot in OIDC tokens
Appears only in this paper and hosted service; Appendix A requires sharing the secret with integrators, so it is not a public-key signature.
plateState registration venue for agents (FL/CA/CO)
purpose: Jurisdictional attribution of non-human principals at attestation time
A governance construct with no formal backing; default venue is platform-chosen.
agent plate identifier (TYP-BODY)
purpose: Stable human-readable agent identity for approvers and auditors
Introduced by the system; no external registry confirms the identifier scheme.

how reviews work

0 comments

Cite this review

Pith. "Pith review of xChk: Bring Your Own Identity -- Heterogeneous Assurance with Verifier-Determined Sufficiency." pith.science (2026). https://pith.science/paper/OA5AQNSU

@misc{pith2026260713369,
  author       = {Pith},
  title        = {Pith review of: xChk: Bring Your Own Identity -- Heterogeneous Assurance with Verifier-Determined Sufficiency},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/OA5AQNSU}},
  note         = {Machine review of arXiv:2607.13369}
}

read the original abstract

We present xChk, a reference identity provider for Bring Your Own Identity (BYOI): users enroll via heterogeneous proofs (government KYC, corporate SSO, WebAuthn/FIDO2, professional networks, live verification, longitudinal activity, behavioral signals) and disclose them as portfolio claims in standard OAuth 2.0 / OpenID Connect (OIDC) tokens, while each relying party applies its own sufficiency policy - the IdP transports claims and may evaluate an RP-supplied evidence policy for consent, but does not adjudicate access. Enrollment depth varies by modality (some paths are user-initiated; org KYB and officer binding are operator-assisted). xChk also supports human-in-the-loop attestation for high-risk actions: humans can initiate attestations directly (browser UI / POST /api/attestations), and AI agents acting under those principals can trigger the same gateway via scope-gated authorize/attest - hash-chained human approvals on a shared verification graph (humans via OIDC; agents via API keys). A production deployment at https://in.xchk.io ships both initiation paths with bilateral RP evaluation at consent; one documented relying party (https://crabbyed.com, Appendix B) exercises Login with xChk.

Figures

Figures reproduced from arXiv: 2607.13369 by the authors.

**Figure 1.** xChk System Architecture—Three-domain architecture showing the User Domain (modalities, agent), xChk Identity Provider (enrollment, IAP storage, portfolio assembly, token issuer, attestation gateway), and Relying Party Domain (policy engine, services, blockchain anchor). This section and §4 give descriptive tuples and production mappings—an architectural model, not a security proof. The strongest structural properti… view at source ↗

**Figure 2.** xChk Identity Token Structure—Standard OIDC claims, entity type, human assurance claims, agent delegation chain, attestation history, and advisory score. Production tokens include nested xchk.portfolio claims; xchk_entity_type is top-level; the access-token path adds xchk_trust_score, xchk_portfolio_summary, xchk_delegation_chains, and xchk_attestations. 5 [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗

**Figure 3.** Attestation Protocol Sequence—Production attestation sequence (agent-triggered variant shown; humans may initiate via browser UI / POST /api/attestations): agent proposes action α; gateway evaluates scope via POST /api/agents/authorize; progressive notification of approver pool; human approves/declines via WebAuthn passkey (required); attestation record R created (hash-chained, HMAC-signed); optional Ravencoin OP_R… view at source ↗

Figures from the paper (1 more)

**Figure 4.** Figure 4: Delegation Chains and Cascading Revocation [PITH_FULL_IMAGE:figures/full_fig_p010_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

22 extracted references · 3 linked inside Pith

[1]

D. Hardt. The oauth 2.0 authorization framework. RFC 6749, IETF, 2012

2012
[2]

Sakimura et al

N. Sakimura et al. Openid connect core 1.0. OpenID Foundation, 2014

2014
[3]

Verifiable credentials data model v1.1

W3C. Verifiable credentials data model v1.1. W3C Recommendation, 2022

2022
[4]

Spiffe standard

SPIFFE. Spiffe standard. CNCF,https://github.com/spiffe/spiffe, 2020

2020
[5]

Kampik et al

T. Kampik et al. Governance of autonomous agents on the web: Challenges and opportunities.ACM Trans. Internet Technol., 22(4):1–31, 2022

2022
[6]

Schultze et al

S. Schultze et al. Building the web for agents: A declarative framework for agent-web interaction. arXiv:2511.11287, 2025

arXiv 2025
[7]

H. Wang, C. M. Poskitt, and J. Sun. AgentSpec: Customizable runtime enforcement for safe and reliable LLM agents, 2026

2026
[8]

A. Kaul, Q. Lan, and P. Gupta. Behavioral governance for autonomous AI agents: The AgentBound framework. arXiv:2606.30970, 2026

arXiv 2026

Show all 22 references

[9]

A. O. Osho et al. Risk-based authentication: A survey. arXiv:2108.07890, 2021

2021 arXiv
[10]

Decentralized identifiers (dids) v1.0

W3C. Decentralized identifiers (dids) v1.0. W3C Recommendation, 2022

2022
[11]

OpenID Connect for Agents (OIDC-A) 1.0

OpenID Foundation. OpenID Connect for Agents (OIDC-A) 1.0. arXiv:2509.25974, 2025

2025
[12]

Systems and methods for implementing automated agent authentication protocols

Forter Ltd. Systems and methods for implementing automated agent authentication protocols. WO2026039510A1, 2024

2024
[13]

System for federated compliance-token inheritance

Onesource Solutions International Inc. System for federated compliance-token inheritance. US20250373432A1, 2024

2024
[14]

Agent governance toolkit (AGT)

Microsoft Corporation. Agent governance toolkit (AGT). https://github.com/microsoft/age nt-governance-toolkit, 2026. 18

2026
[15]

Singh et al

A. Singh et al. Context lineage assurance for non-human identities in critical multi-agent systems. arXiv:2509.18415, 2025

2025
[16]

Dutta and A

S. Dutta and A. K. Moharir. AgentRiskBOM: A risk-scoping security bill of materials for agentic AI systems. arXiv:2606.21877, 2026

2026 arXiv
[17]

Singh et al

A. Singh et al. Evolution of AI agent registry solutions. arXiv:2508.03095, 2025

2025
[18]

US AI law tracker

Orrick AI Law Center. US AI law tracker. https://ai-law-center.orrick.com/us-ai-law -tracker-see-all-states/, 2026. Accessed 2026

2026
[19]

Digital identity guidelines

NIST. Digital identity guidelines. Technical Report NIST SP 800-63-3, National Institute of Standards and Technology, 2017

2017
[20]

eIDAS regulation (EU) no 910/2014, 2014

European Parliament and Council. eIDAS regulation (EU) no 910/2014, 2014

2014
[21]

Lodderstedt et al

T. Lodderstedt et al. OAuth 2.0 rich authorization requests. RFC 9396, IETF, 2023

2023
[22]

Richer and F

J. Richer and F. Imbault. Grant negotiation and authorization protocol. RFC 9635, IETF, 2024. 19

2024

Pith tools

Reviewed August 2, 2026 · model on record in the stance chip above.

[1] [1]

D. Hardt. The oauth 2.0 authorization framework. RFC 6749, IETF, 2012

2012

[2] [2]

Sakimura et al

N. Sakimura et al. Openid connect core 1.0. OpenID Foundation, 2014

2014

[3] [3]

Verifiable credentials data model v1.1

W3C. Verifiable credentials data model v1.1. W3C Recommendation, 2022

2022

[4] [4]

Spiffe standard

SPIFFE. Spiffe standard. CNCF,https://github.com/spiffe/spiffe, 2020

2020

[5] [5]

Kampik et al

T. Kampik et al. Governance of autonomous agents on the web: Challenges and opportunities.ACM Trans. Internet Technol., 22(4):1–31, 2022

2022

[6] [6]

Schultze et al

S. Schultze et al. Building the web for agents: A declarative framework for agent-web interaction. arXiv:2511.11287, 2025

arXiv 2025

[7] [7]

H. Wang, C. M. Poskitt, and J. Sun. AgentSpec: Customizable runtime enforcement for safe and reliable LLM agents, 2026

2026

[8] [8]

A. Kaul, Q. Lan, and P. Gupta. Behavioral governance for autonomous AI agents: The AgentBound framework. arXiv:2606.30970, 2026

arXiv 2026