OpenID4VP 검증자 가이드: EUDI 지갑 수용하기

최종 검토: 2026년 10월 5일 · 법률 자문이 아님

OpenID4VP는 웹사이트나 앱이 지갑에 이름이나 생년월일 같은 개인에 관한 사항을 증명하도록 요청하는 방식입니다. 검증자는 원하는 크리덴셜과 클레임을 지정하고, 사용자는 지갑에서 승인하며, 지갑은 검증자가 암호학적으로 확인하는 프레젠테이션을 반환합니다. 사양 자체의 표현으로는 이 프로토콜은 "크리덴셜을 요청하고 제시하기 위한 프로토콜을 정의"합니다.^[1]

이 가이드는 EUDI 지갑용 OpenID4VP 검증자를 구축하는 개발자를 위한 것입니다. 요청 객체, DCQL, 응답 모드, 디바이스 흐름, SD-JWT VC 및 mdoc 검증, EU 법률상의 HAIP 규칙, 흔한 실수, 테스트 환경을 다룹니다.

OpenID4VP 쉽게 이해하기

OpenID4VP는 OAuth 2.0 인가 요청의 형태를 재사용합니다. 검증자는 응답 유형 vp_token을 요청하며, 성공한 응답에는 프레젠테이션을 담은 vp_token 파라미터가 반드시 포함되어야 합니다.^[1] 교환할 코드나 액세스 토큰은 없습니다. 데이터는 응답으로 바로 도착합니다.

지갑은 신뢰 당사자(relying party)를 인증하고, 등록한 범위를 넘는 요청이 없는지 확인하고, 사용자의 승인을 받은 뒤 프레젠테이션에 서명합니다. 그다음 신뢰 당사자가 발급자 서명, 폐기 상태, 디바이스 바인딩을 검증합니다.^[3] 개인 식별 데이터(PID)는 SD-JWT VC와 ISO/IEC mdoc 두 가지 형식으로 발급되며, 두 형식 모두 솔트 해시를 사용하므로 사용자는 일부 속성만 공유하고 나머지는 숨길 수 있습니다.^[5][3]

1. 2025년 7월 10일최종 사양OpenID4VP 1.0 승인.
2. 2026년 7월 22일게재CIR 2026/1731(2026년 7월 15일 채택) 관보(Official Journal) 게재.
3. 2026년 7월 23일ARF v3.0.0현행 아키텍처 릴리스.
4. 2026년 12월 24일지갑회원국당 최소 1개.
5. 2027년 12월 24일수용규제 대상 민간 신뢰 당사자.

최종 사양부터 민간 부문 수용 기한까지.^[2][3][4][5]

OpenID4VP 검증자 교환은 어떻게 작동하나

OpenID4VP는 응답 모드 direct_post에 대한 참조 설계를 제시합니다. 이 모드에서는 지갑이 브라우저를 거치지 않고 서버 엔드포인트로 응답을 POST합니다.^[1]

OpenID4VP 1.0 13.3절의 direct_post 참조 설계(간략화).^[1]

• 요청마다 "최소 16바이트의 새로운 암호학적 난수 바이트"로 된 논스를 생성합니다.
• 응답 엔드포인트에서 받은 request-id를 state로 지갑에 보냅니다.
• 지갑이 전송(post)하면 새로운 response_code가 포함된 리디렉션 URI를 반환합니다.
• transaction-id와 해당 코드로 VP Token을 가져온 뒤 논스를 확인합니다.

response_code는 세션 고정 공격을 차단합니다. 세션 고정은 공격자가 귀사의 요청을 피해자의 지갑으로 중계하는 공격입니다. 명세는 이 방식이 기기 간 흐름에서는 도움이 되지 않는다고 밝히고, 그 경우 추가 메커니즘을 권장합니다.^[1]

OpenID4VP 요청 객체와 클라이언트 식별자

client_id는 클라이언트 식별자 접두사(Client Identifier Prefix)로 시작합니다. 이 접두사는 지갑이 검증자를 인증하는 방식을 알려줍니다.^[1] 큰 요청은 참조 방식으로 전달됩니다. 지갑은 request_uri에서 서명된 요청 객체를 가져옵니다. QR 코드의 경우 요청이 "QR 코드에 들어가지 않을 수 있으므로" 명세는 request_uri와 함께 direct_post를 사용할 것을 권장합니다.^[1]

Client Identifier Prefix, OpenID4VP 1.0 5.9절.^[1]

EUDI 검증자의 경우 접두사는 EU 법이 정합니다. 리프 인증서는 "x509_hash Client Identifier Prefix와 함께 사용하는 경우 ETSI TS 119 475에 명시된 RP 접근 인증서여야 하며", verifier_info의 한 요소는 "등록 인증서를 포함해야 합니다".^[5]

DCQL 쿼리: 등록한 항목만 요청하십시오

Digital Credentials Query Language(DCQL)는 요청할 자격증명과 클레임을 지정하는 JSON 쿼리입니다. 필수 credentials 배열과 선택 credential_sets 배열로 구성됩니다. 각 자격증명 쿼리에는 id, format, meta 객체가 필요합니다.^[1] 사양의 SD-JWT VC 예시는 다음과 같습니다.^[1]

{ "credentials": [ { "id": "my_credential", "format": "dc+sd-jwt", "meta": { "vct_values": [ "https://credentials.example.com/identity_credential" ] }, "claims": [ {"path": ["last_name"]}, {"path": ["first_name"]}, {"path": ["address", "street_address"]} ] } ] }

mdoc의 경우 format은 mso_mdoc이고 meta에는 doctype_value가 들어갑니다.^[1] PID의 경우 해당 유형과 클레임 이름으로 바꾸면 됩니다. PID 필수 속성은 성, 이름, 생년월일, 출생지, 국적입니다.^[7]

• require_cryptographic_holder_binding의 기본값은 true입니다. 이 값을 유지하십시오. 이 설정으로 지갑이 키 바인딩 증명을 반환합니다.^[1]
• trusted_authorities는 지갑이 제시하는 항목을 필터링할 뿐입니다. 검증자는 "수신한 프레젠테이션의 발급자가 신뢰할 수 있는지 스스로 검증해야 합니다".^[1]
• 신뢰 당사자는 등록한 데이터 "외의 어떠한 데이터도 이용자에게 제공하도록 요청해서는 안 되며", 지갑이 이를 확인합니다.^[4][3]

OpenID4VP 응답 모드

응답 모드는 VP Token이 반환되는 방식을 결정합니다. vp_token의 기본값은 fragment이며, 리디렉션 URI의 프래그먼트로 전달됩니다.^[1]

OpenID4VP 1.0의 응답 모드.^[1]

direct_post를 사용하면 response_uri가 필수이고 redirect_uri는 없어야 합니다. 그렇지 않으면 지갑이 invalid_request를 반환합니다.^[1] 예를 들어 몰도바의 EVO Wallet은 동일 기기 흐름에서 direct_post.jwt를 사용하는 OpenID4VP 1.0, OpenID4VC HAIP 1.0에 따라 프로파일된 ISO/IEC 18013-5 mdoc, 그리고 폐기 확인용 IETF Token Status List를 문서화하고 있습니다.^[11]

동일 기기, 교차 기기, Digital Credentials API

ARF는 지원되는 원격 조합을 다음과 같이 열거합니다. 리디렉션과 사용자 지정 URI 스킴 기반 전송 메커니즘을 결합한 OpenID4VP, W3C Digital Credentials API와 결합한 OpenID4VP 또는 ISO/IEC 18013-7, 그리고 선택 사항으로 리디렉션과 사용자 지정 URI 스킴을 사용하는 ISO/IEC 18013-7입니다.^[3]

지갑이 OpenID4VP 요청을 받는 세 가지 방식.^[3][1][10]

ARF는 사용자 지정 URI 스킴이 "교차 기기 흐름에는 권장되지 않는다"고 밝히고, 대안으로 Digital Credentials API를 제시합니다.^[3] 이 API를 통하면 지갑은 브라우저가 인증한 검증자의 출처(origin)를 알 수 있으며, 이는 "피싱 저항성에 중요"합니다.^[1] W3C 규격은 아직 초안 단계입니다.^[9] 휴대폰에서 사용자에게 보이는 화면:

SD-JWT VC 프레젠테이션 단계별 검증

SD-JWT VC 프레젠테이션에는 발급자가 서명한 JWT, 사용자가 공개한 항목(disclosure), Key Binding JWT가 포함됩니다. 검증자는 "모든 개별 검증 가능한 프레젠테이션(Verifiable Presentation)을 검증해야 한다(MUST)". nonce가 잘못된 프레젠테이션은 거부해야 합니다.^[1]

SD-JWT VC 프레젠테이션 1건에 대해 검증자가 수행하는 검사.^[1][3]

발급자 서명. ARF는 신뢰 당사자(relying party)의 검사 항목 중 이를 가장 먼저 나열합니다. 신뢰 앵커는 신뢰 목록(Trusted Lists, ETSI TS 119 612)과 신뢰 기관 목록(Lists of Trusted Entities, ETSI TS 119 602)에서 가져옵니다.^[3]

공개 항목. 서명된 페이로드에는 다이제스트로 구성된 _sd 배열이 있습니다. 각 공개 항목은 솔트, 클레임 이름, 값으로 이루어집니다. 예를 들면 ["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"]와 같습니다.^[1] 각 항목을 해시하고 해당 다이제스트를 찾습니다. 일치하는 값이 없으면 발급자가 서명하지 않은 항목입니다.

Key Binding JWT. 보유자 바인딩(holder binding)이 요구되는 경우, 지갑은 "Key Binding JWT가 포함된 SD-JWT를 반환해야 한다(MUST)". 그 nonce는 요청의 nonce와 같아야 하고, aud는 귀사의 Client Identifier와 같아야 합니다. Digital Credentials API를 통하는 경우에는 origin: 접두사를 붙인 귀사의 origin과 같아야 합니다.^[1] 사양에 나온 예시는 다음과 같습니다.

{ "nonce": "n-0S6_WzA2Mj", "aud": "x509_san_dns:client.example.org", "iat": 1709838604, "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4" }

폐지 여부. 신뢰 당사자는 제공자가 "PID 또는 속성 증명을 폐지하지 않았음"을 확인합니다.^[3] 예를 들어 몰도바의 EVO Wallet은 이를 위해 IETF Token Status List를 사용한다고 문서에 명시하고 있습니다.^[11]

ISO/IEC 18013-7을 통한 mdoc 제시 요약

mdoc의 경우 VP Token에는 ISO/IEC 18013-5에 따른 base64url 인코딩 DeviceResponse가 담깁니다. 이 응답은 "SessionTranscript에 대한 서명 또는 MAC을 포함"하며, OpenID4VP 핸드오버 구조도 포함합니다.^[1] 이 핸드오버는 nonce와 audience가 SD-JWT VC를 요청에 묶는 것과 같은 방식으로 mdoc를 귀사의 요청에 묶습니다.

각 형식이 어떤 경우에 적합한지는 SD-JWT VC와 mdoc 비교에서 다룹니다.

HAIP 프로필이 EUDI 검증자에게 추가하는 요건

HAIP(High Assurance Interoperability Profile)는 OpenID4VP의 선택지를 좁힙니다. ARF는 이미 발급 단계에서 이를 요구하며, 그 사용이 "상호운용성을 보장하기 위해 필요하다"고 명시합니다.^[3] 제시 단계에 대해서는 CIR 2026/1731이 "OpenID4VC-HAIP 프로필"과 "ISO/IEC-mdoc 프로필"을 정합니다.^[5]

등록 인증서는 "신뢰 당사자의 의도된 용도를 기술하고" 등록한 "속성을 표시"합니다. 등록 규정은 2026년 12월 24일부터 적용됩니다.^[6] 2028년 8월 11일이라는 날짜는 해당 인증서에 대한 지갑 측 검사에만 해당하며, 등록에는 해당하지 않습니다.^[5] 독일은 이를 이렇게 요약합니다. 조직은 "조직과 사용 사례에 대한 접근 인증서와 등록 인증서를 받는다".^[12] 등록에 관한 전체 내용은 EUDI 지갑 신뢰 당사자 가이드에서 다룹니다.

OpenID4VP 검증자 구축 시 흔한 실수

지갑 사용도 자발적입니다. 지갑을 사용하지 않는 사람의 접근은 "어떠한 방식으로도 제한되거나 불리하게 되어서는 안 됩니다". 따라서 검증자는 다른 경로와 함께 운영됩니다.^[4]

테스트 리소스

국가 지갑을 대상으로 테스트하기 전에 참조 소프트웨어와 적합성 테스트부터 시작합니다.

• conformance.eudi.dev에서 적합성 테스트를 실행합니다.^[3]
• docs.eudi.dev의 참조 구현 문서를 읽습니다. 이 문서는 테스트가 아니라 문서입니다.^[3]
• 몰도바 국립은행(National Bank of Moldova)의 데모 검증자와 소스 코드를 살펴봅니다.^[13]
• 브라우저 경로에 의존하기 전에 Digital Credentials API 초안을 확인합니다.^[9]

테스트 계획의 기준이 되는 날짜는 2026년 및 2027년 EUDI 지갑 기한을 참조하십시오.

Didit이 EUDI 지갑 검증을 지원하는 방법

Didit의 EUDI 지갑 수락 기능은 곧 제공될 예정입니다. 이 기능은 EUDI 지갑 일정에 맞춘 로드맵에 포함되어 있으며, 현재 사용 중인 것과 동일한 워크플로에 추가될 예정입니다. 그동안에도 지금 바로 원격으로 사람을 인증할 수 있습니다.

• 현재 Didit에서는 디지털 ID 지갑을 통해 5개 국가 eID가 운영됩니다: MitID, BankID Sweden, Finnish Trust Network, Smart-ID, Mobile-ID. eID 인증을 참조하십시오.
• eID가 없는 사람의 경우, 흐름은 국가별로 설정된 신분증 인증으로 대체되며, 여기에는 NFC 칩 판독, 라이브니스, 얼굴 대조가 포함됩니다. 전체 KYC 확인 비용은 $0.33입니다.
• AML 스크리닝도 같은 흐름에서 $0.20에 실행됩니다.

신뢰 당사자(relying party)로서의 의무는 귀사에 그대로 남습니다. 지갑 문서에서 국가별로 eID를 활성화하는 방법을 확인할 수 있습니다.

자주 묻는 질문

출처

1. OpenID for Verifiable Presentations 1.0, OpenID Foundation, 최종 사양.
2. OpenID for Verifiable Presentations 1.0 최종 사양 승인, OpenID Foundation, 2025년 7월 10일.
3. 아키텍처 및 참조 프레임워크(Architecture and Reference Framework) v3.0.0, GitHub의 eu-digital-identity-wallet, 2026년 7월 23일 릴리스.
4. 규정 (EU) 2024/1183 (eIDAS 2), EUR-Lex, 2024년 4월 30일 관보.
5. 집행위원회 시행규정 (EU) 2026/1731, EUR-Lex, 2026년 7월 22일 관보.
6. 지갑 신뢰 당사자 등록에 관한 집행위원회 시행규정 (EU) 2025/848, EUR-Lex, 2025년 5월 7일 관보.
7. 개인 식별 데이터에 관한 집행위원회 시행규정 (EU) 2024/2977, EUR-Lex, 2024년 12월 4일 관보.
8. ISO/IEC 18013-7, ISO 표준 페이지.
9. Digital Credentials, W3C 초안.
10. Digital Credentials API 출시, Chrome for Developers.
11. EVO Wallet 개발자 가이드, 몰도바 정부, egov4dev.
12. EUDI 지갑 FAQ, eudi-wallet.gov.de.
13. BNM 데모 검증기, 몰도바 정부, egov4dev.

OpenID4VP는 EUDI 지갑에서 개발자가 가장 많이 다루는 부분이며, 이를 기반으로 개발할 수 있을 만큼 안정적입니다. Didit이 지갑 수용에 어떻게 접근하는지는 EUDI 지갑 솔루션 페이지에서, 전체적인 그림은 eIDAS 2 개요에서 확인하세요.