{"id":"6ed6b1b3-b14e-4a70-9b1f-b4df08c69bd3","arxiv_id":"2505.24698","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"GNAP4VP extends GNAP with OIDC4VP and Linked Verifiable Presentations to enable SSI-based authentication in Data Spaces.","lead":"This paper proposes GNAP4VP, a protocol that extends GNAP with OpenID Connect for Verifiable Presentations and Linked Verifiable Presentations, to bring self-sovereign identity to European Data Spaces. It defines two authentication flows, one for users with digital wallets and one for automated machine-to-machine communication, and reports partial implementation in the EUNOMIA project.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Trust-anchor gap is load-bearing: undefined 'globally trusted authority' and did:web DNS/TLS compromise undermine both flows, so the §4 security guarantees are unsupported until a trust framework and DID-resolution threat model are specified.","rationale":"The reader's weakest_assumption is the same trust-model gap I would flag. The paper is a design blueprint, not an evaluated system: the LVP flow is 'under active development' (§3.2), the wallet flow is implemented but 'further refinement is needed' (§3.1), and Section 5 defers testing and standardization. The central claim, however, is stated in the abstract as fact: the flows 'guarantee verifiable, secure, and efficient interactions.' The mismatch between asserted guarantees and the absence of any trust-framework definition or DID-resolution threat analysis is the main correctness risk. I do not see an internal logical contradiction in the flow descriptions; the issue is that the protocol's security is conditional on an unstated trust anchor. That is fixable, so the appropriate disposition remains CONDITIONAL rather than REJECT. The reader's verdict is sound; no adjustment is needed.","tokens_in":8485,"tokens_out":3991,"duration_ms":49703,"concrete_test":"Symbolically model the LVP flow (e.g., in Tamarin) with two adversarial capabilities: (1) the attacker controls DNS/TLS for the did:web domain and can substitute DID Documents and LVP endpoints, and (2) the VC issuance trust list is left as an uninterpreted predicate. If the model cannot prove authentication unless the trust list is instantiated with concrete trusted issuers and did:web resolution is assumed secure, then the missing trust-anchor specification is load-bearing; conversely, a proof under these assumptions would show the protocol's guarantees are conditional on exactly the undefined trust model.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Both flows reduce to an unstated trust anchor. Section 3 says VC/VP validation follows 'established standards for Data Spaces, including validating that Credentials are issued by a globally trusted authority' [18], but the paper never defines who that authority is, how it is governed, or how a verifier obtains or updates its trust list. This is not cosmetic: in the decentralized SSI setting the paper advocates, 'globally trusted authority' is exactly the centralized dependency the abstract claims to minimize. For the LVP flow (Section 3.2, steps 4–6), the Provider binds the Consumer's key and Linked Verifiable Presentation to a did:web DID Document. did:web security rests on DNS and TLS only: an attacker who can poison DNS or obtain a mis-issued TLS certificate for the Consumer's domain can substitute a DID Document with an attacker-controlled verification key and LVP endpoint, and the Provider has no cryptographic or governance mechanism to detect the substitution. Key rotation and revocation are not discussed. Because Section 4's replay and token-binding protections all presuppose that the VC issuer and the DID Document are genuine, a failure of either assumption compromises the whole flow; hence the central claim that the flows 'guarantee verifiable, secure, and efficient interactions' is not established.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes GNAP4VP, an extension of the Grant Negotiation and Authorization Protocol (GNAP) that integrates OpenID Connect for Verifiable Presentations (OIDC4VP) and Linked Verifiable Presentations (LVP) for identity verification in Data Spaces. It defines two interaction flows: a Wallet-Driven Interaction based on OIDC4VP and an LVP Authorization flow for machine-to-machine scenarios. The paper describes the protocol steps, states that security properties are inherited from GNAP, OIDC4VP, and Verifiable Credential standards, and concludes that the flows guarantee verifiable, secure, and efficient interactions. No formal security analysis, threat model, or performance evaluation is provided.","tokens_in":8673,"tokens_out":2900,"duration_ms":37161,"significance":"If the design were validated, the work would address a real gap: combining dynamic GNAP-based authorization with Verifiable Credential-based identity verification in Data Spaces without a centralized identity provider. The protocol composition is clearly described and follows the cited specifications, and the authors are explicit about which components are implemented and which are not. However, because the paper does not provide a threat model, security proof, trust framework specification, or empirical evaluation, the central claim that the flows 'guarantee' security and efficiency is not currently established. The main value of the paper at this stage is as a design proposal and standardization input.","major_comments":[{"comment":"The manuscript repeatedly states that Verifiable Presentation validation includes 'validating that Credentials are issued by a globally trusted authority' and calls this a 'critical security step,' but it never defines who that authority is, how it is governed, how verifiers obtain or update a trust list, or how revocation is handled. This is load-bearing because Section 4's security guarantees all presuppose that the VC issuer is genuine. In the decentralized SSI setting the paper advocates, an undefined 'globally trusted authority' reintroduces a centralized trust anchor that the abstract claims to minimize. The authors should specify a concrete trust framework (e.g., a federation, a trust list, or a governance document) and analyze the effect of issuer compromise or trust-list manipulation on both flows.","section":"Section 3, first paragraph; Section 4.1; Section 4.2"},{"comment":"The LVP Authorization flow authenticates the Consumer by resolving a did:web DID Document and using the verification methods inside it. The paper does not analyze the trust assumptions of did:web resolution: an attacker who can poison DNS or obtain a mis-issued TLS certificate for the Consumer's domain can substitute a DID Document containing an attacker-controlled verification key and LVP endpoint. The Provider has no cryptographic mechanism to detect this substitution, and key rotation and revocation are not discussed. Because the access token in Section 4.2 is cryptographically bound to the public key from that DID Document, this attack compromises the entire LVP flow. The authors should add a did:web threat model and either propose mitigations (e.g., additional anchoring, certificate pinning, trust-on-first-use, or a governance mechanism) or explicitly state the assumptions under which the flow is secure.","section":"Section 3.2, steps 4-6; Section 4.2"},{"comment":"The abstract and Section 4 claim that the proposed flows 'guarantee verifiable, secure, and efficient interactions,' but no formal analysis, threat model, security proof, or performance evaluation is presented. Section 5 states that the LVP flow is still under development, that the Wallet-Driven flow will need further refinement, and that performance evaluation is future work. As a result, the strong guarantee claim is not supported by the evidence in the paper. The authors should either soften the claims to describe design goals or add a security argument and at least a preliminary performance evaluation before making the guarantee claim.","section":"Abstract; Section 4; Section 5"}],"minor_comments":[{"comment":"The bullet list separates 'Regulatory' and 'Compliance' across lines, making the item read as two fragments; this should be fixed in the final formatting.","section":"Section 2.1"},{"comment":"The terms 'Consumer,' 'Consumer Machine,' and 'consumer global instance' are used with inconsistent capitalization and sometimes without a clear definition of which entity performs which action; this could confuse readers of the protocol steps.","section":"Section 3.1, steps 1-2 and later"},{"comment":"The sentence 'The Wallet redirects or pushes back to the Consumer URI the Provider transferred' is grammatically ambiguous and should be rephrased to clarify that the Provider transfers the Consumer's callback URI to the Wallet.","section":"Section 3.1, step 11"},{"comment":"The replay-prevention rule rejects a second request with 'identical metadata' within the validity window. It should clarify whether the metadata includes the signature and any nonce, and should discuss the denial-of-service possibility where a legitimate request is rejected because an attacker replayed an earlier identical request.","section":"Section 4.2"},{"comment":"The claim in the conclusion that the protocol 'underscores the use of verifiable credentials issued by trusted authorities' should be supported by a reference to a specific trust list or governance specification, rather than an unspecified 'globally trusted authority.'","section":"Section 5"}],"recommendation":"major_revision","confidential_remarks":"The paper is a design proposal with no security proof or evaluation. The trust-anchor gap is real and load-bearing, but it is fixable within the manuscript's scope if the authors specify a trust framework and add a did:web threat model. The conference format may not require a full proof, but the abstract's 'guarantee' claim should be aligned with the actual evidence."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Read the GNAP4VP paper. Short version: it's a useful, honest design blueprint, not a validated protocol. The specific composition of GNAP with OIDC4VP and Linked Verifiable Presentations for Data Spaces is genuinely new, and the two flows are clearly described. The Wallet-Driven flow mirrors GNAP redirect with a wallet instead of an external AS; the LVP flow is a software-only variant with signed metadata and a DID-embedded VP endpoint. The authors know the difference between these and the GNAP base patterns, and they're upfront that only the first flow is implemented and the second is in development. That transparency earns credit.\n\nThe paper reads well as a standards-oriented design note. The flow diagrams and step-by-step descriptions are implementable. The state of the art is accurate enough. And the conclusion correctly lists the missing pieces: reference implementation, performance evaluation, wallet interoperability, standardization work.\n\nThe soft belly is the security section. Section 4 says the flows inherit GNAP's interaction references, key-bound tokens, and replay protection, plus OIDC4VP's nonces and audience restrictions. That is plausible for the parts that hold. But the trust anchor is where it all rests. The paper says credentials must be issued by a 'globally trusted authority' and never defines who that is, how trust lists are distributed or updated, or what a verifier does when an issuer revokes or rotates keys. For the LVP flow, the Provider binds the Consumer's request to a did:web DID document. did:web resolves over DNS and TLS, so an attacker who can poison DNS or get a mis-issued cert for the Consumer's domain can substitute the DID document and the LVP endpoint. The paper doesn't model that. Key rotation and revocation are not discussed. So the abstract's 'guarantee verifiable, secure, and efficient interactions' is not supported. The 'efficient' part is also unmeasured.\n\nThis doesn't kill the proposal. A design paper is allowed to defer the threat model and the implementation. But the authors should either add a trust framework section with explicit governance and DID-resolution threat model, or tone down the guarantees. Given that the LVP flow is under development, I'd treat the security claims as aspirations, not results.\n\nWho should read it: people designing identity for Data Spaces, GNAP extension work, SSI practitioners looking for concrete flow patterns. It's a worthwhile cite for the protocol composition. I'd send it to review, with major revision expected.","headline":"A clear, honest design blueprint for GNAP+OIDC4VP/LVP in Data Spaces; the security guarantees are asserted rather than shown, and the undefined 'globally trusted authority' plus did:web trust model need a serious referee's attention.","tokens_in":9265,"tokens_out":2259,"would_cite":true,"duration_ms":25089,"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":"The paper claims that GNAP4VP, an extension of GNAP using OIDC4VP and Linked Verifiable Presentations, lets Data Space participants verify identity through a user wallet or a fully automated machine flow.","keywords":["Data Spaces","GNAP","OIDC4VP","Self-Sovereign Identity","Authentication","Access Control","Linked Verifiable Presentations","Verifiable Credentials"],"falsifier":"Run the LVP Authorization flow against a Provider configured with a trust list, using a Verifiable Credential issued by an entity outside that list, or with a did:web identifier whose domain is controlled by an attacker; if the Provider issues an access token rather than rejecting the request, the claimed verification guarantee is shown to fail.","tokens_in":8266,"feed_emoji":"🔐","tokens_out":6488,"duration_ms":72086,"temperature":0.7,"pith_summary":"This paper argues that identity verification in Data Spaces can be built on an extension of the Grant Negotiation and Authorization Protocol (GNAP) rather than on OAuth-style centralized providers. The proposal, GNAP4VP, fuses GNAP's negotiable authorization flows with OpenID Connect for Verifiable Presentations (OIDC4VP) and Linked Verifiable Presentations (LVP), giving participants two ways to authenticate: a wallet-driven flow where a user approves credential presentation, and a fully automated machine-to-machine flow. A sympathetic reader would care because the design aims to keep the privacy and user-control promises of Self-Sovereign Identity while staying flexible enough for providers to pick or reject flows during negotiation. If the protocol works as described, Data Space consumers and providers can establish identity and authorization without a central identity provider.","feed_headline":"Data spaces verify identity with no central provider","feed_subtitle":"GNAP plus verifiable credentials gives data spaces wallet-driven and fully automated identity checks.","key_machinery":"The load-bearing object is GNAP4VP itself, an extension of GNAP whose interaction model is parameterized by a negotiated interaction mechanism. It defines two concrete instantiations: Wallet-Driven Interaction, which transfers control to a digital wallet via an OIDC4VP VP Exchange URI and Presentation Definition, and LVP Authorization, which uses a did:web DID Document as the source of a verification public key and a Linked Verifiable Presentation endpoint. The same GNAP continuation and access-token mechanics carry both flows, so the protocol inherits GNAP's dynamic negotiation while adding credential-based identity verification.","core_discovery":"The central claim is that GNAP's existing interaction models can be repurposed for Verifiable Credentials: the redirect-based interaction becomes a transfer of control to the user's wallet, and the software-only authorization becomes an exchange of Linked Verifiable Presentations. In the wallet flow, the Consumer sends a GNAP Grant Request asking for Wallet-Driven Interaction; the Authorization Server returns a VP Exchange URI; the wallet retrieves a Presentation Definition, the user selects credentials, and the wallet returns a VP token that the Provider validates before issuing access tokens. In the LVP flow, the Consumer includes signed metadata with a did:web identifier; the Provider resolves the DID Document to obtain the verification key and the LVP endpoint, retrieves the Linked Verifiable Presentation, validates it, and issues an access token bound to the Consumer's public key. The paper claims these flows guarantee verifiable, secure, and efficient interactions, and reports that the wallet-driven flow is implemented while the LVP flow is under active development.","pith_inferences":["Beyond the paper's explicit claims, the security of the LVP flow reduces to the security of did:web resolution; if an attacker can compromise DNS or TLS for the DID domain, they can substitute both the verification key and the Linked Verifiable Presentation, so the flow needs key-rotation and resolution-hardening measures to meet its stated guarantees.","The same negotiation mechanism could be reused outside Data Spaces, for example in public-administration or private-service login, wherever SSI-based verification is wanted; the paper itself notes that the architecture is general-purpose.","A natural next experiment is to measure latency, token size, and resource consumption in both flows against OAuth/OIDC baselines; the paper announces this performance evaluation as future work.","Selective disclosure in the wallet flow depends on the wallet's ability to map a Presentation Definition to locally held credentials; comparing this behavior across custodial and non-custodial wallets would test the claimed interoperability."],"forward_implications":["Data Space consumers can authenticate through their own digital wallets, reviewing and approving which verifiable credentials to present without a centralized identity provider.","Machine-to-machine scenarios can be fully automated: signed metadata and a Linked Verifiable Presentation give the Provider everything needed to validate identity without human involvement.","Providers keep the GNAP negotiation advantage: a Consumer can declare support for several flows and the Provider can select, accept, or reject them according to its policies.","Credentials are checked against trusted authorities and presentations are validated for authenticity and integrity, with replay protection and access tokens bound to the Consumer's public key in the LVP flow.","The wallet-driven flow is already implemented, while the LVP flow is under active development, so the protocol's practical feasibility is demonstrated for the interactive case and pending for the automated case."],"supporting_citations":[{"why":"Supplies the base GNAP protocol, including redirect-based interaction, continuation data, and access-token issuance that GNAP4VP extends.","marker":"[9]"},{"why":"Supplies the OIDC4VP verifiable-presentation request and response mechanics, and the VP token format, used in the Wallet-Driven Interaction flow.","marker":"[20]"},{"why":"Defines Linked Verifiable Presentations and how a VP is referenced from a DID Document, which the LVP Authorization flow relies on.","marker":"[3]"},{"why":"Cited as the source for the Data Space requirement that credentials be issued by a globally trusted authority during VP validation.","marker":"[18]"},{"why":"Supports the claim that OIDC4VP can bridge self-sovereign identity and existing identity infrastructure for wallet-based presentation.","marker":"[8]"}],"fun_headline_variants":["GNAP4VP: verifiable credentials without a central ID in data spaces","GNAP repurposed for verifiable credentials in data spaces","Wallet or machine: GNAP flows give data spaces verifiable credentials","No central identity provider: GNAP-based verifiable credentials for data spaces"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The protocol assumes that a globally trusted authority issues credentials and that the web-hosted DID document that carries verification keys and linked presentations can be trusted; if either trust anchor gives way, identity verification can be defeated.","fun_headline_variants_meta":{"raw":{"variants":["GNAP4VP: verifiable credentials without a central ID in data spaces","GNAP repurposed for verifiable credentials in data spaces","Wallet or machine: GNAP flows give data spaces verifiable credentials","No central identity provider: GNAP-based verifiable credentials for data spaces"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000617,"raw_usage":{"total_tokens":2870,"prompt_tokens":956,"completion_tokens":1914,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":572,"completion_tokens_details":{"reasoning_tokens":1837}},"tokens_in":572,"tokens_out":1914,"duration_ms":19589,"temperature":1.0,"reasoning_tokens":1837,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T12:14:44.496299+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the LVP Authorization flow against a Provider configured with a trust list, using a Verifiable Credential issued by an entity outside that list, or with a did:web identifier whose domain is controlled by an attacker; if the Provider issues an access token rather than rejecting the request, the claimed verification guarantee is shown to fail.","supporting_citations":[{"cited_title":"RFC 9635: Grant Negotiation and Authorization Protocol (GNAP) — rfc-editor.org.https://www.rfc-editor.org/rfc/ rfc9635.html","cited_arxiv_id":null,"evidence_quote":"Supplies the base GNAP protocol, including redirect-based interaction, continuation data, and access-token issuance that GNAP4VP extends."},{"cited_title":"Openid for verifiable presentations-draft 18","cited_arxiv_id":null,"evidence_quote":"Supplies the OIDC4VP verifiable-presentation request and response mechanics, and the VP token format, used in the Wallet-Driven Interaction flow."},{"cited_title":"Linked Verifiable Presentation.https://identity.foundation/linked-vp/","cited_arxiv_id":null,"evidence_quote":"Defines Linked Verifiable Presentations and how a VP is referenced from a DID Document, which the LVP Authorization flow relies on."},{"cited_title":"Building a dataspace: Technical overview","cited_arxiv_id":null,"evidence_quote":"Cited as the source for the Data Space requirement that credentials be issued by a globally trusted authority during VP validation."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supports the claim that OIDC4VP can bridge self-sovereign identity and existing identity infrastructure for wallet-based presentation."}],"review_version":1}