Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

VP JWT format and verification inconsistencies

Đang mở
  • Có gì không ổn?
#4,197 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
go
Lĩnh vực
api, backend, security

Hướng nghiên cứu

Bắt đầu với vcr/holder/presenter.go:buildJWTPresentation và so sánh các claims của nó với auth/api/iam/validation.go:validatePresentationAudience. Sau đó, lần theo việc chấp nhận VP trong discovery/module.go, vcr/api/vcr/v2/api.go, discovery/client.go và auth/api/iam/openid4vp.go. Được xem là hoàn tất khi hành vi xác minh theo từng giai đoạn nhất quán mà không làm hỏng khả năng tương tác với các node cũ hơn.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

While working on #4191 (JWTProfile refactor) we surfaced a number of inconsistencies in how Verifiable Presentations are constructed and verified in this codebase. None are immediate vulnerabilities, but together they make it hard to reason about VP security and complicate consistent verification.

Findings

1. iss is not set on VP JWTs (spec deviation)

vcr/holder/presenter.go:buildJWTPresentation puts the holder DID in the sub claim and omits iss. Per W3C VC Data Model 1.1 §6.3.1, for a JWT VP iss MUST be the holder; sub is not specified.

Consequence: the signer identity has to be derived from the kid header, which means the standard iss-to-kid binding check we use for VCs (in crypto.IssuerKidValidator) cannot be applied to VPs.

2. aud is not consistently required on verification

VP builders set aud:

  • discovery: from service.ID (via Domain)
  • OpenID4VP: from ClientIDParam (via Audience)

But aud is only checked in the v2 OpenID4VP flow (validatePresentationAudience in auth/api/iam/validation.go). VerifyVP itself doesn't check it, so callers like discovery/module.go:269 and vcr/api/vcr/v2/api.go accept VPs regardless of audience. A VP intended for verifier A could be replayed against verifier B.

3. exp is not consistently required on verification

After #4191 the VP builder always sets exp (default 15 min), but the verifier still doesn't require it because other nodes may produce VPs without one. Caller-side max-age checks are inconsistent:

Caller Behavior when `exp` missing
`validateS2SPresentationMaxValidity` (s2s OpenID4VP) rejects ("missing creation or expiration date")
`discovery/module.go:247` silently passes (`time.Until(zeroTime)` is hugely negative)
`vcr/api/vcr/v2/api.go` (external API) no check
`discovery/client.go:372` no check
`auth/api/iam/openid4vp.go:539` no check
4. typ is "JWT" instead of "vp+jwt"

W3C VC Data Model 2.0 specifies typ: "vp+jwt" to prevent JWT type confusion. This was the root cause of GHSA-9hmg-827w-9rhj (VP replayed as access token). The fix for that advisory addressed the verifier side; updating the VP builder is out of scope for safety reasons (rolling-upgrade compatibility), but should be considered in a coordinated network upgrade.

Suggested actions

A consolidated fix would involve:

  1. Update buildJWTPresentation to set iss (in addition to sub, for backward compat) and typ: "vp+jwt".
  2. Fix discovery/module.go to properly reject VPs with missing exp (or use nbf + maxValidity as a fallback).
  3. Add audience checks to all VP-accepting endpoints, not just validatePresentationAudience.
  4. Once the network has been upgraded, tighten the vpJWTProfile to require exp, validate iss-to-kid binding, and reject typ != "vp+jwt".

Each step needs to be staged carefully to avoid breaking interop with older nodes.

Ngôn ngữ chính
Go
Star
29
Fork
24
Merge trung bình
2 ngày 5 giờ
Pull request đã merge (30 ngày)
37

Chuẩn bị môi trường

  • Có Dockerfile hoặc tệp Docker Compose
  • Không có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của nuts-foundation/nuts-node

Tất cả issue của nuts-foundation/nuts-node

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.