Pith. sign in

REVIEW 3 major objections 5 minor 21 references

Next Generation Authentication for Data Spaces: An Authentication Flow Based On Grant Negotiation And Authorization Protocol For Verifiable Presentations (GNAP4VP)

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

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

Pith's one-line read 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.

desk verdict 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. read the letter →

arxiv 2505.24698 v1 pith:IKBQ4XNT submitted 2025-05-30 cs.CR cs.ET

Rodrigo Menéndez , Andres Munoz-Arcentales , Joaquín Salvachúa , Carlos Aparicio , Irene Plaza , Gabriel Huecas This is my paper
classification cs.CRcs.ET
keywords DataSpacesGNAPOIDC4VPSelf-SovereignIdentityAuthenticationAccessControlLinkedVerifiablePresentationsCredentials
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

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

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

  • 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.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

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.

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 (3)
  1. [Section 3, first paragraph; Section 4.1; Section 4.2] 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.
  2. [Section 3.2, steps 4-6; Section 4.2] 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.
  3. [Abstract; Section 4; Section 5] 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.
minor comments (5)
  1. [Section 2.1] The bullet list separates 'Regulatory' and 'Compliance' across lines, making the item read as two fragments; this should be fixed in the final formatting.
  2. [Section 3.1, steps 1-2 and later] 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.
  3. [Section 3.1, step 11] 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.
  4. [Section 4.2] 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.
  5. [Section 5] 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.'

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity found: GNAP4VP is an explicit composition of independent external standards, and the paper's trust-anchor and did:web gaps are correctness/security-analysis concerns rather than input/output equivalences.

full rationale

The paper contains no fitted parameters, no numeric predictions, and no derivation chain whose conclusion is equivalent to its premises by construction. Its central contribution is the design of a protocol that composes GNAP with OIDC4VP and Linked Verifiable Presentations, and it states this explicitly: 'we introduce GNAP4VP, an extension of GNAP that preserves its flexibility while adding native support for Verifiable Credential-based identity verification.' The two flows are also explicitly positioned as extensions of existing GNAP interaction models ('conceptually aligned with GNAP's Redirect-Based Interaction' and 'conceptually resemble GNAP's Software-Only Authorization'). There is no self-citation chain: the load-bearing references, such as the GNAP RFC, the OIDC4VP draft, the DIF Linked Verifiable Presentation spec, and the Gaia-X technical overview, are external standards and specifications, not prior work by the same authors. The security section explicitly inherits properties rather than deriving them from a new model: 'As this flow closely mirrors GNAP's redirect-based interaction model, it inherits its core security mechanisms' and refers the reader to the GNAP and OIDC4VP specifications. This is a compositional design argument, not circular reasoning, though it is not a formal security proof of the composed protocol. The skeptical concern about an undefined 'globally trusted authority' and the reliance on did:web DNS/TLS security is a substantive correctness and trust-model gap: the paper does not define how a verifier obtains a trust list, what 'globally trusted' means in a decentralized SSI setting, or how key rotation and revocation are handled. However, an unstated or fragile premise is not the same as a conclusion that reduces to its own input. The VCs are asserted to come from an external trusted authority, and the did:web document is used to authenticate the Consumer's signing key; the failure mode is an incomplete threat model, not a circular derivation. The paper also candidly states that the wallet flow 'requires further refinement' and that the LVP flow is 'under active development,' and it defers empirical evaluation to future work, which weakens the abstract's claim to 'guarantee' security but does not constitute circularity under the provided rubric.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The protocol introduces no free parameters or new physical/formal entities. Its central claims rest on domain assumptions about trust anchors, DID resolution, and the composability of security properties from GNAP and OIDC4VP.

assumptions (4)
  • domain assumption Verifiable Credentials can be validated against 'globally trusted authorities'.
    Invoked in Section 3 ('validating that Credentials are issued by a globally trusted authority') and Section 4.1/4.2 ('ensuring that they were issued by trusted authorities'). No definition of the trust root or revocation mechanism is given.
  • domain assumption did:web DID Documents are trustworthy and correctly resolvable via DNS/TLS.
    Section 3.2, steps 4-6: the Authorization Server queries the URL from the did:web identifier and uses the public keys and LVP endpoint from the DID Document without further trust bootstrapping.
  • domain assumption GNAP and OIDC4VP security properties carry over unchanged to GNAP4VP.
    Section 4.1 says the flow 'inherits its core security mechanisms' from GNAP and OIDC4VP; the paper provides no composition analysis.
  • domain assumption Signed metadata with validFrom/validUntil and duplicate rejection is sufficient to prevent replay attacks.
    Section 4.2 claims replay protection solely from timestamps and duplicate detection, without a formal threat model.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Next Generation Authentication for Data Spaces: An Authentication Flow Based On Grant Negotiation And Authorization Protocol For Verifiable Presentations (GNAP4VP)." pith.science (2026). https://pith.science/paper/IKBQ4XNT

@misc{pith2026250524698,
  author       = {Pith},
  title        = {Pith review of: Next Generation Authentication for Data Spaces: An Authentication Flow Based On Grant Negotiation And Authorization Protocol For Verifiable Presentations (GNAP4VP)},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IKBQ4XNT}},
  note         = {Machine review of arXiv:2505.24698}
}
read the original abstract

Identity verification in Data Spaces is a fundamental aspect of ensuring security and privacy in digital environments. This paper presents an identity verification protocol tailored for shared data environments within Data Spaces. This protocol extends the Grant Negotiation and Authorization Protocol (GNAP) and integrates OpenID Connect for Verifiable Presentations (OIDC4VP) along with support for Linked Verifiable Presentations (LVP), providing a robust foundation for secure and privacy-preserving interactions. The proposed solution adheres to the principles of Self-Sovereign Identity (SSI) to facilitate decentralized, user-centric identity management while maintaining flexibility through protocol negotiation. Two alternative interaction flows are introduced: a "Wallet-Driven Interaction" utilizing OIDC4VP, and a "LVP Authorization" model for fully automated machine-to-machine communication. These flows address critical challenges encountered in Data Spaces, including privacy, interoperability, and regulatory compliance while simultaneously ensuring scalability and minimizing trust assumptions. The paper provides a detailed technical design, outlining the implementation considerations, and demonstrating how the proposed flows guarantee verifiable, secure, and efficient interactions between participants. This work contributes towards the establishment of a more trustworthy and sovereign digital infrastructure, in alignment with emerging European data governance initiatives.

Figures

Figures reproduced from arXiv: 2505.24698 by the authors.

Figure 1
Figure 1. Wallet-Driven Interaction Flow. 6. The Wallet extracts the necessary endpoints from the VP Exchange URI and accesses them following the OIDC4VP protocol. 7. The Authorization Server responds with the Presentation Definition required to access its protected API. 8. Depending on how the VP Exchange URI was transferred to the Wallet, the next steps vary: • If the URI was shared manually (e.g., via QR code scan or copy-… view at source ↗
Figure 2
Figure 2. LVP Authorization Flow [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

21 extracted references · 21 canonical work pages

  1. [1]

    Challenges to enforce data quality in data spaces

    Ayala, C.P., Bilalli, B., G ´omez, C., Maz´on, J.N., Romero, O., et al., 2025. Challenges to enforce data quality in data spaces. CEUR Workshop Proceedings . 10Rodrigo Men´ endez et al./Procedia Computer Science 00 (2019) 000–000

    work page 2019

  2. [2]

    Regulating data intermediaries: The impact of the data governance act on the eu’s data economy

    Carovano, G., Finck, M., 2023. Regulating data intermediaries: The impact of the data governance act on the eu’s data economy. Computer Law & Security Review 50, 105830

    work page 2023

  3. [3]

    Linked Verifiable Presentation.https://identity.foundation/linked-vp/

    Foundation, D.I., 2023. Linked Verifiable Presentation.https://identity.foundation/linked-vp/. [Accessed 10-04-2025]

    work page 2023

  4. [4]

    Digital identity infrastructures: A critical approach of self-sovereign identity

    Giannopoulou, A., 2023. Digital identity infrastructures: A critical approach of self-sovereign identity. Digital Society 2, 18

    work page 2023

  5. [5]

    Rfc 6749: The oauth 2.0 authorization framework

    Hardt, D., 2012. Rfc 6749: The oauth 2.0 authorization framework

    work page 2012

  6. [6]

    OpenID for Verifiable Credentials: formal security analysis using the Web Infrastructure Model

    Hauck, F., 2023. OpenID for Verifiable Credentials: formal security analysis using the Web Infrastructure Model. Master’s thesis. University of Stuttgart

    work page 2023

  7. [7]

    The grant negotiation and authorization protocol: attacking, fixing, and verifying an emerging standard, in: European Symposium on Research in Computer Security, Springer

    Helmschmidt, F., Hosseyni, P., K ¨usters, R., Pruiksma, K., Waldmann, C., W¨urtele, T., 2023. The grant negotiation and authorization protocol: attacking, fixing, and verifying an emerging standard, in: European Symposium on Research in Computer Security, Springer. pp. 222–242

    work page 2023

  8. [8]

    Hoops, F., Matthes, F., 2024. A universal system for openid connect sign-ins with verifiable credentials and cross-device flow, in: 2024 IEEE International Conference on Blockchain and Cryptocurrency (ICBC), IEEE. pp. 296–298

    work page 2024

Show all 21 references
  1. [9]

    RFC 9635: Grant Negotiation and Authorization Protocol (GNAP) — rfc-editor.org.https://www.rfc-editor.org/rfc/ rfc9635.html

    Imbault, F., . RFC 9635: Grant Negotiation and Authorization Protocol (GNAP) — rfc-editor.org.https://www.rfc-editor.org/rfc/ rfc9635.html. [Accessed 29-05-2025]

    2025

  2. [10]

    Integration of self-sovereign identity into conventional software using established iam protocols: A survey, in: Open Identity Summit 2022

    Kuperberg, M., Klemens, R., 2022. Integration of self-sovereign identity into conventional software using established iam protocols: A survey, in: Open Identity Summit 2022. Gesellschaft f¨ur Informatik e.V ., Bonn, pp. 51–62. doi:10.18420/OID2022_04

    2022 doi

  3. [11]

    Data space functionality, in: Designing Data Spaces: The Ecosystem Approach to Competitive Advantage

    Lycklama, D., 2022. Data space functionality, in: Designing Data Spaces: The Ecosystem Approach to Competitive Advantage. Springer International Publishing Cham, pp. 521–534

    2022

  4. [12]

    Self-sovereign identity

    Preukschat, A., Reed, D., 2021. Self-sovereign identity. Manning Publications

    2021

  5. [13]

    Grant negotiation and authorization protocol (gnap)

    Richer, F., Parecki, A., 2020. Grant negotiation and authorization protocol (gnap)

    2020

  6. [14]

    Digital identity: an approach to its nature, concept, and functionalities

    Robles-Carrillo, M., 2024. Digital identity: an approach to its nature, concept, and functionalities. International Journal of Law and Information Technology 32, eaae019

    2024

  7. [15]

    Web technologies for decentralised identity

    Rodr ´ıguez-Doncel, V ., 2025. Web technologies for decentralised identity. Governance and Control of Data and Digital Economy in the European Single Market , 111

    2025

  8. [16]

    Common european data spaces: Challenges and opportunities

    Scerri, S., Tuikka, T., de Vallejo, I.L., Curry, E., 2022. Common european data spaces: Challenges and opportunities. Data Spaces: Design, Deployment and Future Directions , 337–357

    2022

  9. [17]

    On the compliance of self-sovereign identity with gdpr principles: A critical review

    Shehu, A.S., 2024. On the compliance of self-sovereign identity with gdpr principles: A critical review. arXiv preprint arXiv:2409.03624

    2024 arXiv

  10. [18]

    Building a dataspace: Technical overview

    Siska, V ., Karagiannis, V ., Drobics, M., et al., 2023. Building a dataspace: Technical overview. Gaia-X Hub Austria

    2023

  11. [19]

    Data security governance in the era of big data: status, challenges, and prospects

    Sun, L., Zhang, H., Fang, C., 2021. Data security governance in the era of big data: status, challenges, and prospects. Data Science and Management 2, 41–44

    2021

  12. [20]

    Openid for verifiable presentations-draft 18

    Terbu, O., Lodderstedt, T., Yasuda, K., Looker, T., 2023. Openid for verifiable presentations-draft 18. Internet draft

    2023

  13. [21]

    A tutorial on the interoperability of self-sovereign identities

    Yildiz, H., K ¨upper, A., Thatmann, D., G¨ond¨or, S., Herbke, P., 2022. A tutorial on the interoperability of self-sovereign identities. arXiv preprint arXiv:2208.04692

    2022 arXiv

Pith tools

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