SD-JWT VC vs mdoc (ISO/IEC 18013-5): EUDI 월렛 포맷 비교

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

SD-JWT VC는 서명된 JSON Web Token으로 구성된 검증 가능한 자격증명으로, 각 클레임을 하나씩 공개할 수 있습니다. mdoc은 ISO/IEC 18013-5 형식의 모바일 문서이며, 이 표준은 원래 모바일 운전면허증을 위해 작성되었습니다. EUDI 지갑의 아키텍처 및 참조 프레임워크(ARF)는 두 형식을 지갑의 필수 형식으로 규정하고, 세 번째 형식인 W3C Verifiable Credentials Data Model 2.0은 선택 형식이며 "비적격 EAA 전용"이라고 명시합니다.^[1]

이 가이드는 검증자를 구축하는 개발자를 위해 ARF v3.0.0, OpenID for Verifiable Presentations(OpenID4VP) 1.0 본문, EU 관보를 바탕으로 두 형식을 비교합니다. PID는 개인 식별 데이터(person identification data)를 뜻합니다.

SD-JWT VC란 무엇인가

ARF는 "SD-JWT 기반 검증 가능한 자격증명"을 검증 가능한 자격증명을 표현하기 위한 데이터 형식 및 처리 규칙으로 설명하며, SD-JWT는 "'Selectively Disclosable JSON Web Token'의 약자"라고 밝힙니다.^[1] 여기에는 JSON 인코딩, 선택적 공개를 지원하는 증명 메커니즘, 선택 사항인 기기 바인딩이 포함됩니다.^[1]

OpenID4VP에서 형식 식별자는 dc+sd-jwt이며, 쿼리는 vct_values를 통해 자격증명 유형을 지정합니다.^[4] 다음은 사양에 수록된 발급 페이로드 예시로, 8개 다이제스트 중 2개만 남기고 줄인 것입니다.^[4]

{ "_sd": [ "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4", "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo" ], "vct": "https://credentials.example.com/identity_credential", "_sd_alg": "sha-256", "cnf": { "jwk": { "kty": "EC", "crv": "P-256" } } }

mdoc(ISO/IEC 18013-5)이란 무엇인가

ISO/IEC 18013-5는 면허 속성, CBOR(Concise Binary Object Representation) 인코딩, 식별자 충돌을 방지하는 네임스페이스, 선택적 공개를 지원하는 증명 메커니즘, 필수 기기 바인딩, 근거리 교환 방식을 정의합니다.^[1]

운전에 특화된 부분은 면허 데이터 모델뿐입니다. ARF는 그 밖의 모든 요소가 "범용적이며 PID를 포함한 다른 모든 증명 유형에 사용할 수 있다"고 설명합니다.^[1]

OpenID4VP는 이러한 자격증명을 "CBOR로 인코딩되고 COSE_Sign1으로 보호되는" 것으로 설명하며, 형식 식별자로 mso_mdoc을 부여합니다. 쿼리는 doctype_value를 통해 문서 유형을 지정합니다.^[4]

각 형식에서 선택적 공개가 작동하는 방식

선택적 공개를 통해 사용자는 일부 속성만 공유하고 나머지는 숨길 수 있으며, 검증자는 여전히 발급자의 서명을 확인할 수 있습니다. eIDAS 2는 지갑이 이를 가능하게 하도록 요구합니다.^[6] ARF는 SD-JWT 메커니즘을 "솔트 해시"라고 부르며, 이 메커니즘이 "[ISO/IEC 18013-5]에서 같은 목적으로 사용되는 메커니즘과 개념적으로 동일하다"고 설명합니다.^[1]

메커니즘은 하나, 인코딩은 두 가지입니다.^[1][4]

위 예시에서 _sd 배열에는 SHA-256 다이제스트가 들어 있습니다. 각 공개 항목(disclosure)은 랜덤 값, 클레임 이름, 클레임 값으로 이루어진 배열입니다. 이름(given name)의 경우 ["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]이며, 그 해시가 목록의 첫 번째 다이제스트입니다. 검증자는 수신한 각 공개 항목을 해시하고, 서명된 페이로드에서 해당 다이제스트를 찾습니다.^[4]

클레임을 지정하는 방식은 서로 다릅니다. JSON 크리덴셜의 경우 클레임 경로는 ["address", "street_address"]와 같은 키 목록입니다. mdoc의 경우 경로는 "string 타입의 요소 두 개를 포함"합니다. 바로 네임스페이스와 데이터 요소 식별자이며, 예를 들면 ["org.iso.18013.5.1", "first_name"]입니다.^[4]

키 바인딩과 디바이스 연결(device engagement)

디바이스 바인딩은 크리덴셜을 사용자 월렛에 보관된 키에 묶어 복제할 수 없게 합니다. 검증자는 크리덴셜에 포함된 공개키에 대응하는 개인키로 새로 생성한 랜덤 데이터에 서명하도록 월렛에 요청하여 이를 확인합니다.^[1] 명칭은 서로 다릅니다. "[ISO/IEC 18013-5]에서는 'mdoc 인증'이라고 한다. [SD-JWT VC]에서는 '키 바인딩'이라고 한다."^[1]

두 형식 모두 PID에 대해 디바이스 바인딩이 필수입니다.^[1][4]

SD-JWT VC의 경우 OpenID4VP의 규칙은 엄격합니다. 기본값인 require_cryptographic_holder_binding이 true이면, 지갑은 Key Binding JWT와 함께 "SD-JWT를 반환해야 합니다(MUST return an SD-JWT)". nonce 클레임은 요청의 nonce와 같아야 하고, aud는 귀사의 Client Identifier와 같아야 합니다. 단, Digital Credentials API를 통하는 경우에는 origin: 접두사를 붙인 귀사의 origin과 같아야 합니다.^[4]

디바이스 인게이지먼트(device engagement)는 mdoc에만 있습니다. 근접 흐름에서 사용자는 QR 코드를 보여주거나 NFC 태그를 제시합니다. 여기에는 리더가 NFC, Bluetooth Low Energy 또는 Wi-Fi Aware 연결을 열고 그 위에 인증되고 암호화된 채널을 구축하는 데 필요한 정보가 담겨 있습니다. 두 기기 사이에는 인터넷 연결이 없습니다.^[1]

mdoc(ISO/IEC 18013-5)를 이용한 근접 제시를 간략히 나타낸 흐름입니다.^[1]

사용자에게 보이는 화면:

제시 프로토콜: OpenID4VP, ISO/IEC 18013-7 및 근접 방식

ARF는 지갑이 처리하는 프로토콜을 명시합니다. 근접 방식에서는 ISO/IEC 18013-5, 원격 방식에서는 OpenID4VP 또는 ISO/IEC 18013-7입니다.^[1]

ARF에 따른 프로토콜별 전달 형식입니다.^[1]

SD-JWT VC 증명은 "근접 제시에 사용할 수 없습니다". ISO/IEC 18013-7은 "[ISO/IEC 18013-5] 준수 형식의 증명을 요청하고 제시하는 데에만 사용할 수 있습니다". OpenID4VP는 "원격 제시 거래 흐름에만 적합하며" 두 형식을 모두 전달합니다.^[1] OpenID4VP 1.0은 2025년 7월 10일 최종 사양(Final Specification)이 되었습니다.^[5]

ARF는 기기 간 흐름에서 사용자 지정 URI 스킴을 권장하지 않습니다. 이러한 흐름은 "피싱 및 릴레이 공격에 취약"하기 때문입니다. ARF는 대안으로 Digital Credentials API를 제시합니다.^[1] 이 API는 아직 W3C 초안이며, Chrome 141에서는 기본으로 활성화됩니다.^[9][10] ISO는 18013-7의 2024년 기술 사양을 철회 및 대체된 것으로 표시하고 있으며, 제3판이 개발 중입니다. 따라서 코드가 어느 판을 대상으로 하는지 확인하십시오.^[7][8] 요청 세부 사항은 OpenID4VP 검증자 가이드에서 확인할 수 있습니다.

시행규정 (EU) 2026/1731이 PID에 요구하는 사항

PID 형식에 관한 최초 규정인 시행규정 (EU) 2024/2977은 PID를 "두 가지 형식으로 발급해야 한다"고 규정했습니다. 그 두 형식은 ISO/IEC 18013-5:2021과 Verifiable Credentials Data Model 1.1입니다.^[2][3] 2026년 7월의 개정 법령이 이 문장을 대체했습니다. 이제 PID는 "시행규정 (EU) 2024/2979 부속서 II의 조항 5(SD-JWT VC 형식) 및 조항 6(ISO/IEC-mdoc 형식)에 명시된 표준에 따라 발급되어야 합니다".^[2]

1. 2024년 12월 4일최초 규정2024/2977: 18013-5 및 VCDM 1.1.
2. 2026년 7월 22일개정2026/1731: SD-JWT VC 및 mdoc.
3. 2026년 7월 23일ARF v3.0.0개정 법령에 맞춰 정비되었습니다.
4. 2026년 12월 24일지갑 제공 기한회원국당 하나의 지갑.
5. 2028년 8월 11일얼굴 사진해당되는 경우, 사용자가 명시적으로 거부하지 않는 한 얼굴 사진 요건이 적용됩니다.

PID 형식에 관한 법령의 변화 과정.^[1][2][3][6]

같은 법령은 이행규정(EU) 2024/2982의 부속서에서 두 가지 제시 프로필, 즉 "ISO/IEC-mdoc 프로필"과 "OpenID4VC-HAIP 프로필"을 정합니다.^[2]

• 등록 인증서를 전송하십시오. verifier_info의 한 요소는 "등록 인증서를 포함해야 한다"고 규정되어 있습니다.^[2]
• x509_hash Client Identifier Prefix와 함께 접근 인증서를 리프 인증서로 사용하십시오.^[2]
• Digital Credentials API를 통한 mdoc에는 "ISO/IEC 18013-7:2025 부속서 C"를 따르십시오.^[2]

등록 절차는 EUDI 지갑 신뢰 당사자 가이드에서, 일정은 2026년 및 2027년 EUDI 지갑 기한에서 다룹니다.

SD-JWT VC와 mdoc(ISO/IEC 18013-5) 비교표

ARF 기준. 단, PID 행(시행규정 2026/1731)과 마지막 두 행(OpenID4VP 1.0)은 제외.^[1][2][4]

미국의 모바일 운전면허증은 근접 방식에 ISO/IEC 18013-5를 기반으로 합니다.^[7][8] EU 연령 확인 솔루션은 영지식 증명을 필수 제시 방식으로 명시하며, "일반 mDoc 제시를 대체 수단으로" 둡니다.^[13] 몰도바의 EVO Wallet은 HAIP 1.0에 따라 프로파일링된 ISO/IEC 18013-5 mdoc과 OpenID4VP 1.0을 문서화하고 있습니다.^[11]

신뢰 당사자가 지원해야 하는 형식

지갑 유닛은 두 형식을 모두 처리하며, PID는 두 형식으로 모두 발급됩니다.^[1][2] 이 가이드를 위해 검토한 문서에는 신뢰 당사자에게 두 형식을 모두 요청하도록 의무화하는 조항이 없습니다. 실무적 해석은 다음과 같습니다. 원격 검증자는 둘 중 어느 형식이든 요청할 수 있고, 인터넷 연결이 없는 리더기는 근접 환경에서 작동하는 유일한 형식인 mdoc이 필요합니다.^[1]

OpenID4VP의 Digital Credentials Query Language(DCQL)를 사용하면 하나의 요청에 dc+sd-jwt 쿼리와 mso_mdoc 쿼리를 나란히 담을 수 있으며, 사양에 그러한 요청 예시가 나와 있습니다.^[4] ARF에 따르면 신뢰 당사자는 Trusted List 또는 List of Trusted Entities의 신뢰 앵커를 기준으로 발급자 서명을 검증하고, 상태 목록 또는 폐기 목록을 통해 폐기 여부를 확인하며, 기기 바인딩을 검증합니다.^[1]

eIDAS 2, 즉 Regulation (EU) 2024/1183에 따라 각 회원국은 2026년 12월 24일까지 최소 하나의 지갑을 제공해야 하며, 강력한 사용자 인증을 사용해야 하는 민간 신뢰 당사자는 2027년 12월 24일까지 사용자의 요청이 있으면 이를 수용해야 합니다. 영세기업과 소기업은 면제됩니다.^[6] 국가별 현황은 EUDI 지갑 출시 현황 트래커에서 확인할 수 있습니다.

라이브러리 및 테스트 도구

이 가이드가 참고한 출처는 오픈소스 라이브러리를 명시하지 않습니다. 따라서 이 섹션도 라이브러리를 명시하지 않습니다. 다만 출처는 어디에서 테스트해야 하는지, 선택한 라이브러리에서 무엇을 확인해야 하는지는 알려 줍니다.

• ARF v3.0.0 릴리스 노트에 명시된 conformance.eudi.dev에서 적합성 테스트를 실행하십시오.^[1]
• docs.eudi.dev에서 참조 구현 문서를 읽으십시오.^[1]
• 공개된 검증자를 살펴보십시오. 몰도바 국립은행은 금융기관을 위해 소스 코드와 함께 데모 검증자를 공개했습니다.^[12]
• 라이브러리가 기본 사양뿐 아니라 HAIP도 따르는지 확인하십시오.^[1]
• 라이브러리가 ISO/IEC 18013-7의 어느 판을 구현하는지 확인하십시오.^[2][8]

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

Didit의 EUDI 지갑 수용 기능은 곧 제공될 예정입니다. EUDI 지갑 일정에 맞춰 로드맵에 올라 있으며, 현재 사용하는 것과 같은 워크플로에서 제공됩니다. 지금은 원격으로 사람을 검증할 수 있습니다.

• 현재 Didit에서는 디지털 ID 지갑을 통해 5개 국가 eID가 운영됩니다. MitID, BankID Sweden, Finnish Trust Network, Smart-ID, Mobile-ID입니다. eID 검증을 참고하십시오.
• 그 밖의 모든 사용자는 신분증 검증과 NFC 칩 판독, 라이브니스 및 얼굴 대조를 사용합니다. 전체 KYC 확인 비용은 $0.33입니다.
• AML 스크리닝은 같은 흐름에서 $0.20에 실행됩니다.

지갑 문서에서 국가별로 eID를 활성화하는 방법을 확인할 수 있습니다.

자주 묻는 질문

출처

1. Architecture and Reference Framework v3.0.0, GitHub의 eu-digital-identity-wallet, 2026년 7월 23일 릴리스.
2. 집행위원회 시행규정 (EU) 2026/1731, EUR-Lex, 2026년 7월 22일자 관보.
3. 개인 식별 데이터에 관한 집행위원회 시행규정 (EU) 2024/2977, EUR-Lex, 2024년 12월 4일자 관보.
4. OpenID for Verifiable Presentations 1.0, OpenID Foundation, 최종 사양.
5. OpenID for Verifiable Presentations 1.0 최종 사양 승인, OpenID Foundation, 2025년 7월 10일.
6. 규정 (EU) 2024/1183 (eIDAS 2), EUR-Lex, 2024년 4월 30일자 관보.
7. ISO/IEC 18013 시리즈, 모바일 운전면허증, ISO 표준 페이지.
8. ISO/IEC 18013-7, ISO 표준 페이지.
9. Digital Credentials, W3C 초안.
10. Digital Credentials API 출시, Chrome for Developers.
11. EVO Wallet 개발자 가이드, 몰도바 정부, egov4dev.
12. BNM 데모 검증자, 몰도바 정부, egov4dev.
13. EU 연령 확인 솔루션, 기술 포털, ageverification.dev.

SD-JWT VC와 mdoc(ISO/IEC 18013-5)은 같은 약속을 담는 두 가지 인코딩입니다. 바로 사용자가 통제하는 서명된 속성입니다. Didit이 지갑 수용에 어떻게 접근하는지는 EUDI 지갑 솔루션 페이지에서, 모든 국가별 체계는 국가별 eID 체계에서 확인하세요.