{"id":"f8b20ad9-64fa-4894-8791-30275464040b","arxiv_id":"2607.13369","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A production OAuth/OpenID Connect identity provider that ships multi-modality \"bring your own identity\" portfolio claims to relying parties and leaves access sufficiency to each relying party.","lead":"xChk is a running identity service that lets people sign in with a mix of proofs — government ID, corporate login, passkeys, professional profiles, and behavior signals — and sends those proofs to apps as standard login tokens. Each app decides its own bar for what counts as \"good enough\", and the same system lets humans approve high-risk AI agent actions through a hash-chained audit trail.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Cascading revocation is driven by parentAgentId while delegation chains are integrator-supplied metadata; the paper never shows these graphs coincide, so human-rooted revocation may not reach agents that actually act under that root.","rationale":"The reader's weakest assumption identifies the most load-bearing concern: cascading revocation and delegation chains are defined on potentially different graphs. This is not merely an external validation issue; it is a structural mismatch inside the paper's own architecture. Eq. (6) formally defines revocation over delegation-chain descendants, but production revocation walks parentAgentId, and the paper explicitly says the platform does not auto-walk parentAgentId to mint chains. Without an enforced invariant, an agent can present a delegation chain rooted at a human while not being a descendant in the revocation tree, so revoking the human would not disable that agent. This directly threatens the central claim of human-rooted delegation with cascading revocation. The paper's self-reported production status and single RP are also weaknesses, but they are acknowledged in the text (Appendix B, §6.4) and affect confidence rather than internal coherence. The graph-consistency gap is a concrete, technically specified flaw that warrants a conditional rather than full accept, matching the reader's verdict. A targeted test—checking whether revocation reaches an agent whose delegationChain and parentAgentId disagree—would settle the issue, and the paper offers enough API detail to run it.","tokens_in":13584,"tokens_out":5262,"duration_ms":58746,"concrete_test":"Inspect the production code path for agent deletion (or run a controlled test on in.xchk.io): create human H, agent A with parentAgentId=H and delegationChain=[H], and agent B with parentAgentId=null but delegationChain=[H,B] at attestation create. Delete H. Then call POST /api/agents/authorize with B's API key. If B still gets allow/attest, the revocation guarantee fails. Also review the code for any validation that parentAgentId equals the corresponding parent_id in delegationChain at attestation create or token assembly; if no such check exists, the two graphs are not guaranteed to coincide.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim (2.8 item 5) is 'human-rooted delegation with cascading revocation.' Formal definition Eq. (6) states revocation propagates to Descendants(e), defined as entities whose delegation chain contains e as an ancestor. But the production mapping in §4.4/§5.2 says revocation is a BFS walk on parentAgentId that revokes descendant agents and their API keys. Meanwhile §3.2 and §4.4 state that delegation chains are integrator-supplied metadata on attestation create, and 'the platform does not auto-walk the parentAgentId agent tree to mint chains.' These are two different graph relations. The paper never states an invariant that an agent's parentAgentId matches the parent_id in its delegationChain, nor does it describe any validation at attestation create or token mint that enforces consistency. If an integrator supplies delegationChain metadata that names a human root but sets parentAgentId differently (or leaves it unset), then revoking that human—or an intermediate agent—will not invalidate the agent's API key, even though the agent's xchk_delegation_chains claims to act under that root. The paper explicitly flags the asymmetry with 'By contrast,' but does not resolve it. Thus the shipped 'cascading revocation' guarantee is only as strong as integrator discipline, and the formal model does not match the implementation.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":13955,"tokens_out":9267,"duration_ms":99829,"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":[{"comment":"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.","section":"§3.2 / §4.4 / Eq. (6)"},{"comment":"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.","section":"§5.2 / §8 / Appendix B"},{"comment":"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.","section":"§5.6 / §4.2"}],"minor_comments":[{"comment":"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.","section":"§3.2"},{"comment":"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.","section":"Figures 1-4"},{"comment":"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.","section":"Appendix A / C"},{"comment":"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.","section":"§4.2 / §4.4"},{"comment":"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.","section":"§5.6"}],"recommendation":"major_revision","confidential_remarks":"The primary technical issue is the mismatch between the formal revocation semantics and the production parentAgentId-based implementation; that is the main reason for major revision. The self-attested production status and the single co-owned RP are also significant, but they could be addressed by reframing the paper as an architecture/reference-implementation report rather than a claim of independent production adoption. If the authors can supply an invariant or validation for the delegation/revocation graphs (or explicitly weaken the claim), the paper would be close to acceptable for a systems venue."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Sean, quick read on arXiv:2607.13369.\n\nThe 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.\n\nCredit 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.\n\nThe 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.\n\nFor 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.","headline":"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.","tokens_in":14391,"tokens_out":2115,"would_cite":true,"duration_ms":23369,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["Bring Your Own Identity","identity assurance portfolio","OAuth 2.0","OpenID Connect","verifier-determined sufficiency","agent delegation","human-in-the-loop attestation","cascading revocation"],"falsifier":"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.","tokens_in":13500,"feed_emoji":"🪪","tokens_out":7447,"duration_ms":73939,"temperature":0.7,"pith_summary":"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.","feed_headline":"A new identity provider packs your proof portfolio into OIDC tokens","feed_subtitle":"Government ID, corporate SSO, passkeys, and human approvals ride in one token; each app decides what suffices.","key_machinery":"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","core_discovery":"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","pith_inferences":["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."],"forward_implications":["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."],"fun_headline_variants":["One token, many proofs: apps decide what's enough","xChk: Your identity portfolio, app decides what counts","From KYC to passkeys: one token, app-set assurance","RP determines sufficiency: xChk delivers the evidence","Human and agent attestations in one OIDC token"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["One token, many proofs: apps decide what's enough","xChk: Your identity portfolio, app decides what counts","From KYC to passkeys: one token, app-set assurance","RP determines sufficiency: xChk delivers the evidence","Human and agent attestations in one OIDC token"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000299,"raw_usage":{"total_tokens":1578,"prompt_tokens":770,"completion_tokens":808,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":514,"completion_tokens_details":{"reasoning_tokens":738}},"tokens_in":514,"tokens_out":808,"duration_ms":7929,"temperature":1.0,"reasoning_tokens":738,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-02T05:22:01.340299+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[],"review_version":1}