{"id":"3d29f7aa-5884-45bc-976f-9a5b4d7375a9","arxiv_id":"2502.09253","paper_version":1,"verdict":"UNVERDICTED","confidence":"HIGH","novelty_score":4.0,"correctness_risk":"low","formal_verification":"none","parameter_count":0,"one_line_summary":"The International Lattice Data Grid is being modernized with extended XML schemas, token-based authentication, and reimplemented REST catalogue services.","lead":"This paper reports the status of ILDG 2.0, a modernized international data grid for sharing lattice QCD gauge configurations. It describes extended metadata schemas, token-based authentication, and reimplemented file and metadata catalogues.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Token-based access is reported as if federation-wide, but the paper only confirms it for LDG storage elements; uniform ILDG-wide enforcement is untested.","rationale":"The reader's weakest assumption was that token-based authorization can be correctly and securely enforced by all participating storage elements. My concern overlaps with that, but it is more specifically about deployment coverage and lack of demonstrated enforcement rather than about an inherent security flaw in the OAuth2 scope/path model. The paper is a proceedings status report, and the evidence it does provide — the ILDG IAM instance, re-factored catalogues, revised schemata, and LDG storage elements configured for tokens — supports 'major progress' as a directional claim. The gap is that 'token-based (meta-)data access' is presented as a completed component of ILDG 2.0 in the conclusion, while the body text limits full token enablement to LDG and reports JLDG as still in progress, with other regions unmentioned. That is a caveat on the strength of the conclusion, not a reason to reject the paper or to change the UNVERDICTED classification. A federation-wide interoperability test would settle whether the claim is accurate as stated or needs qualification. I therefore leave the verdict unchanged and mark partial agreement with the reader's weakest-assumption analysis.","tokens_in":7928,"tokens_out":3057,"duration_ms":34804,"concrete_test":"Run a federation-wide interoperability test: place a small test file under a protected path on one storage element in each regional grid (LDG, JLDG, USQCD, UKLFT, CSSM). Obtain an OAuth2 token with scope storage.read:/protected/test from the ILDG IAM instance, and also an expired token and a token with a non-matching issuer. Attempt a read of the test file and of a file outside the path. Record whether each storage element accepts the valid in-scope read and rejects the out-of-scope, expired, and wrong-issuer reads. If only LDG passes, the claim should be explicitly qualified as LDG-only deployment.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is a status claim: major progress towards ILDG 2.0, including 'token-based (meta-)data access'. The most load-bearing condition for that claim is that the token-based authorization model actually works across the federation, not merely in one region. Section 3.3 states that all four LDG storage elements using dCache or StoRM are 'meanwhile fully enabled' and that JLDG Gfarm token work is 'in progress'. No statement is made about CSSM, UKLFT, or USQCD storage elements. The paper also provides no end-to-end test results showing that a token with scope storage.read:/x/y is accepted for files under x/y and rejected for files outside that path, nor that tokens are validated for issuer, audience, and expiry by each storage element. If any participating storage element fails to enforce the scope/path comparison, the 'uniform, safe, and controlled data access' described in Section 3 does not hold ILDG-wide. This does not invalidate the paper as a status report, but it means the conclusion's phrase 'token-based (meta-)data access' should be read as 'deployed on LDG, under development elsewhere' unless additional evidence is supplied.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper is a proceedings contribution reporting the status and recent progress of the International Lattice Data Grid (ILDG) towards a modernised 'ILDG 2.0'. It describes extensions to the QCDml ensemble and configuration XML schemata (licenses, funding references, ORCID identification, new gauge groups and lattice actions, multi-configuration files), a revision of the ILDG file format to version 1.2, migration from grid certificates to an INDIGO IAM-based registration and single-sign-on service, re-implementation of metadata and file catalogues with REST APIs, and deployment of token-based, capability-style authorisation for storage elements following the WLCG profile. The conclusions summarise this as 'major progress' on metadata schemata, user registration, catalogue services, and token-based (meta-)data access, and list next steps such as reactivating missing regional services and migrating legacy metadata.","tokens_in":8119,"tokens_out":2219,"duration_ms":24437,"significance":"If the reported claims hold, ILDG 2.0 would provide a working FAIR-aligned infrastructure for sharing lattice gauge configurations across regional grids, with modern authentication and authorisation mechanisms. The paper is valuable as a status report because it documents concrete design decisions, points to specifications and repositories, and makes falsifiable claims (e.g., that LDG storage elements are fully token-enabled and that certain action types are supported by the schemata). Its limitations as an unrefereed proceedings report are the absence of test data, endpoint measurements, or external validation; the word 'progress' is appropriate, but the strength of the cross-federation 'token-based data access' claim is not yet supported by the evidence presented.","major_comments":[{"comment":"The conclusion in Section 4 claims 'token-based (meta-)data access' as a general ILDG 2.0 achievement, but the evidence in Section 3.3 only demonstrates token-based access for the four LDG storage elements. For JLDG the text explicitly says the Gfarm token development 'is in progress', and no statement is made about CSSM, UKLFT, or USQCD storage elements. This overstates the deployment status. Please qualify the conclusion, e.g., 'token-based data access deployed on LDG, under development elsewhere', or add evidence for the remaining regional grids.","section":"Section 3.3 and Section 4"},{"comment":"The claim that storage elements 'fully enabled for token-based access' is not supported by any reported end-to-end verification. The paper states that dCache and StoRM 'can be configured to work with capability-based authorisation', but provides no test results showing that a token with scope storage.read:/x/y is accepted for paths under /x/y and rejected for other paths, nor that issuer, audience, and expiry claims are validated by all four LDG elements. Without such evidence the uniform, safe, controlled access described in Section 3 is an assumption rather than a demonstrated property. Please add a reference to test reports, or explicitly describe the configuration checks that were performed.","section":"Section 3.3"},{"comment":"Token-based authorisation for the metadata and file catalogues is described as 'implemented in an analogous way', but the deployment status is unclear. Is this feature already active in the production MDC and FC instances, or only in the re-factored code base? If it is active, which registry or federation instances use it? Please make the status explicit, since this is one of the four headline claims in the conclusions.","section":"Section 3.2"}],"minor_comments":[{"comment":"The text says 'web-DaV/http' in Section 3.3; this should read 'WebDAV/http'.","section":"Section 2.3"},{"comment":"Reference [24] contains a typo: 'INGIGO' should be 'INDIGO'.","section":"References"},{"comment":"The reference list appears garbled in the version I reviewed (e.g., 'hep-lat//zero.alt32/zero.alt39121' in [1], '25/zero.alt32./zero.alt33593' in [22]). If these are author-introduced artifacts, they need correcting; if they are extraction artifacts, please ensure the published PDF has complete citation data.","section":"References"},{"comment":"The list of new action specifiers is compact and useful, but a short explanation of at least one representative new element (e.g., the C* boundary-condition photon actions) would help readers who are not members of the Metadata Working Group.","section":"Section 2.1"},{"comment":"The outlook mentions 'massive uploads of new data' as a next step; since no ensemble has yet been uploaded under ILDG 2.0, consider stating explicitly whether any ensemble has been registered to date, as this would calibrate how much of the infrastructure is now in live use.","section":"Section 4"}],"recommendation":"major_revision","confidential_remarks":null},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Honestly, this is a proceedings status report, not a research paper, and it should be read that way. The authors have made concrete progress on the ILDG 2.0 stack: the XML schema extensions look sensible (multiple configurations per file, ORCID for participants, license/embargo elements, funding references, expanded gauge groups and actions), the catalogue services have been re-factored behind REST APIs and containerized, and user registration has moved to an INDIGO IAM instance that issues OAuth2 tokens. The paper is also unusually candid about what is not done: JLDG Gfarm token access is 'in progress,' the next steps mention 're-activation of still missing services,' and they explicitly note that some regional services degraded. That honesty is worth crediting.\n\nThe soft spot is exactly where the stress-test lands. The conclusion states that ILDG 2.0 includes 'token-based (meta-)data access' as if it were a federation-wide property. But in Section 3.3 the only concrete statement is that the four LDG storage elements (dCache and StoRM) are 'fully enabled.' JLDG is in progress, and CSSM, UKLFT, and USQCD are not mentioned at all. There are also no end-to-end test results showing that the OAuth2 scope-to-path comparison is enforced correctly and rejected outside the path. So the conclusion overstates the current state. This is a minor flaw for a status report, but it is worth flagging because the whole point of the report is to tell the community where things stand. If I were the editor, I'd ask them to add one sentence: 'token-based access is deployed on LDG, under development elsewhere.'\n\nThe paper has no equations or data, and the citation pattern is appropriate. It is a project update for the lattice QCD community and for anyone building FAIR data grids. It wouldn't merit a full journal review; as a proceedings contribution it is fine. I'd desk-reject it as a research article, but I wouldn't object to it appearing in PoS LATTICE as a report.","headline":"A candid, useful status report on the ILDG 2.0 overhaul; the one real flaw is that the token-based access claim in the conclusions is broader than what the body actually reports.","tokens_in":8593,"tokens_out":3878,"would_cite":false,"duration_ms":35241,"reading_group":"no","serious_thinker":"yes","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The International Lattice Data Grid is being rebuilt around token-based access, richer metadata, and containerised catalogues, to make lattice QCD gauge configurations shareable and FAIR-compliant.","keywords":["International Lattice Data Grid","lattice QCD","gauge configurations","metadata schemata","FAIR data","token-based authentication","OAuth2","data sharing"],"falsifier":"Take a token with scope storage.read:/x/y and try, on each storage system enrolled in the grid, to read a file addressed as /x/y/../z or /x/z, or to list the parent directory; any successful read or listing would show that the capability boundary is not enforced. A second check is to request a file from each regional grid in turn with a valid token; the first grid that cannot honour the token would falsify the claim of a single uniform access mechanism.","tokens_in":7772,"feed_emoji":"🔑","tokens_out":8270,"duration_ms":76677,"temperature":0.7,"pith_summary":"This paper reports on ILDG 2.0, the modernised version of the International Lattice Data Grid through which lattice QCD groups share gauge-configuration ensembles. It aims to establish that the federation has made major progress: new ensemble and configuration metadata schemata, an extended file format, a new user registration and single-sign-on service, re-implemented metadata and file catalogues with REST APIs, and storage access controlled by OAuth2 tokens instead of grid certificates. The point of the modernisation is to make shared data findable, accessible, interoperable, and reusable in the FAIR sense, while supporting embargoes and controlled access for collaborations. If the claims hold, the ILDG would again be a working infrastructure rather than the degraded service of the past decade.","feed_headline":"Lattice QCD data grid rebuilt for token-based sharing","feed_subtitle":"New metadata schemata and containerised catalogues aim to make gauge configurations FAIR and shareable.","key_machinery":"The mechanism that carries the modernisation is capability-based authorisation via OAuth2 access tokens. A token carries a scope such as storage.read:/x/y, and every storage element or catalogue service is supposed to grant access only when the path-like scope encompasses the path of the requested data object, with issuer and audience claims also checked. Around this sit the XML/XSD metadata schemata (QCDmlEnsemble and QCDmlConfig) and the LIME-packed binary file format; together they let a configuration file link to its ensemble and to the physical file via logical file names, while the token layer decides who may read or write it.","core_discovery":"The central claim is that ILDG 2.0 has moved from design to deployment: the QCDml ensemble and configuration schemata now include licences with embargo dates, funding references, ORCID-based participant identification, a wider set of gauge groups and actions, and annotation elements; the file format has been extended from single SU(3) configurations to multiple configurations, other gauge groups, and reduced storage forms; and the core services have been re-implemented around token-based authentication, with a new federated user registration, containerised REST catalogue services, and storage elements that base access decisions on the scope claim of an OAuth2 token compared with the path of the requested data object. The paper states that the European regional grid's storage elements are already token-enabled, while one regional storage system is still being adapted.","pith_inferences":["A testable extension not pursued in the paper: measure the query latency of the re-factored catalogue for realistic ensemble sizes, since the paper itself notes that XPath searches can be slow; if quick-search keys cover the common access patterns, the service will be practical at scale.","If the scoped-token model proves robust, ILDG-style federations could adopt standard cloud object-store semantics, where short-lived tokens are passed to analysis jobs; this would make the grid look like a normal remote file system to modern compute workflows.","The same architectural pattern — XML schemata plus token-protected storage and REST catalogues — could be applied to other disciplines that share large numerical ensembles, since none of the core services depend on the physics content of the data."],"forward_implications":["A user authenticated once through a home institution can in principle reach data on any participating regional grid with a single token, without maintaining separate grid certificates.","Data producers can publish configurations immediately while restricting read access through scoped tokens, so embargoes no longer require delaying the upload.","The richer metadata, including licences and funding references, makes it possible for downstream users to know how to legally reuse an ensemble and how to acknowledge it.","Because the metadata catalogue supports multiple XML document collections with separate schemata, the same infrastructure can later be extended to other data types, such as correlation functions or analysis workflows.","Storage elements can enforce access control at directory or even individual-file granularity, which is finer than the previous certificate-based all-or-nothing model."],"supporting_citations":[{"why":"Defines the FAIR principles that motivate the required licences, embargo dates, and rich metadata in the new schema.","marker":"[11]"},{"why":"Earlier ILDG status paper that frames the modernisation as a move toward FAIR data sharing.","marker":"[14]"},{"why":"Supplies the identity-and-access-management service used for the new user registration and for issuing the OAuth2 tokens.","marker":"[15]"},{"why":"Defines the common token profile that the storage elements follow for capability-based authorisation.","marker":"[26]"},{"why":"Is the file-format specification whose new version supports multiple configurations, non-SU(3) gauge groups, and reduced storage.","marker":"[17]"},{"why":"Is the QCDml schema repository from which the revised ensemble and configuration XML schemata are implemented.","marker":"[18]"},{"why":"Provides the metadata model followed for the new funding-reference elements in the ensemble schema.","marker":"[20]"},{"why":"Specifies the LIME packing format used to combine binary link variables, format information, and identifiers in ILDG files.","marker":"[21]"}],"fun_headline_variants":["Lattice data grid 2.0 goes live with token auth","ILDG 2.0: token-based sharing for lattice QCD","FAIR gauge configurations via token-enabled ILDG grid","Token-based access arrives for Lattice QCD data grid"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The modernisation rests on the assumption that every participating storage element can correctly and securely enforce the rule that a token allowing access to one directory cannot reach data outside that directory, and that all regional grids will actually deploy and maintain that enforcement. If any storage system bypasses or misreads the scope claim, the claimed ILDG-wide uniform token-based access would not hold.","fun_headline_variants_meta":{"raw":{"variants":["Lattice data grid 2.0 goes live with token auth","ILDG 2.0: token-based sharing for lattice QCD","FAIR gauge configurations via token-enabled ILDG grid","Token-based access arrives for Lattice QCD data grid"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000505,"raw_usage":{"total_tokens":2368,"prompt_tokens":752,"completion_tokens":1616,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":368,"completion_tokens_details":{"reasoning_tokens":1545}},"tokens_in":368,"tokens_out":1616,"duration_ms":10368,"temperature":1.0,"reasoning_tokens":1545,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T22:06:56.376450+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take a token with scope storage.read:/x/y and try, on each storage system enrolled in the grid, to read a file addressed as /x/y/../z or /x/z, or to list the parent directory; any successful read or listing would show that the capability boundary is not enforced. A second check is to request a file from each regional grid in turn with a valid token; the first grid that cannot honour the token would falsify the claim of a single uniform access mechanism.","supporting_citations":[{"cited_title":"Wilkinson et al., The FAIR Guiding Principles for scientific data management a nd stewardship, Sci","cited_arxiv_id":null,"evidence_quote":"Defines the FAIR principles that motivate the required licences, embargo dates, and rich metadata in the new schema."},{"cited_title":"Karsch, H","cited_arxiv_id":null,"evidence_quote":"Earlier ILDG status paper that frames the modernisation as a move toward FAIR data sharing."},{"cited_title":"Indigo Identity Access Management","cited_arxiv_id":null,"evidence_quote":"Supplies the identity-and-access-management service used for the new user registration and for issuing the OAuth2 tokens."},{"cited_title":"WLCG common JWT profiles","cited_arxiv_id":null,"evidence_quote":"Defines the common token profile that the storage elements follow for capability-based authorisation."},{"cited_title":"gitlab repository of file format specification","cited_arxiv_id":null,"evidence_quote":"Is the file-format specification whose new version supports multiple configurations, non-SU(3) gauge groups, and reduced storage."},{"cited_title":"gitlab repository of QCD ml schema and examples","cited_arxiv_id":null,"evidence_quote":"Is the QCDml schema repository from which the revised ensemble and configuration XML schemata are implemented."},{"cited_title":"DataCite Metadata Schema","cited_arxiv_id":null,"evidence_quote":"Provides the metadata model followed for the new funding-reference elements in the ensemble schema."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Specifies the LIME packing format used to combine binary link variables, format information, and identifiers in ILDG files."}],"review_version":1}