EUDI Wallet 연동 경로 선택 방법: 2026 가이드
EUDI Wallet 연동 비교: 네 가지 경로, 제5b조(10)에 따라 중개자가 할 수 있는 것과 할 수 없는 것, 2026/1730 이후의 인증서 모델, 벤더에게 물어볼 질문, 그리고 귀사에 남는 부분.
요약
EUDI Wallet 연동은 기술 프로젝트이기 전에 하나의 결정입니다. 지갑 앞에 신뢰당사자로 서는 주체가 귀사인지, 귀사를 대리하는 중개자인지를 정해야 합니다.[1][6]
- 등록은 항상 자국 회원국에서 하며, 등록한 범위를 넘어 요청할 수 없습니다.[1]
- 중개자는 신뢰당사자로 간주되며 거래 내용에 관한 데이터를 저장할 수 없습니다. 따라서 그 역할을 맡은 벤더가 귀사를 위해 보관할 수 있는 정보는 제한됩니다.[1]
- 강력한 인증 의무가 있는 민간 기업은 2027년 12월 24일까지 지갑을 수용해야 합니다(당사 계산). 초소기업 및 소기업은 면제됩니다.[1]
유럽 디지털 신원(EUDI) Wallet은 이번 겨울 실제 기한을 맞습니다. 모든 회원국은 2026년 12월 24일까지 지갑을 제공해야 하며, 지갑을 수용하는 기업에 대한 등록 규칙도 같은 날 적용됩니다.[1][2] 대부분의 팀에게 질문은 "그것이 무엇인가"에서 "어떻게 연결하는가"로 바뀌었습니다.
이 가이드는 EUDI Wallet 연동의 네 가지 경로를 비교하고, 위임할 수 있는 것과 귀사에 남는 것을 구분하며, 각 기능을 그 근거 규칙에 대응시킵니다. 현행 법령과 기술 청사진인 Architecture and Reference Framework(ARF) 버전 3.0.0을 바탕으로 하며, 중개자에 관한 2026년 7월 변경 사항을 포함합니다.[3][6]
기본 사항부터 필요하다면 EUDI Wallet 신뢰당사자: 등록, 인증서 및 의무와 OpenID4VP 검증자 가이드를 읽어 보십시오. 법령은 eIDAS 2 해설을 참고하십시오.
결정하는 동안에도 사용자 인증을 계속하십시오
Didit은 현재 국가 eID와 신분증 검사를 하나의 워크플로에서 실행하며, EUDI Wallet 수용 기능은 곧 제공될 예정입니다. 무료로 시작하거나 귀사의 유럽 사용자 기반에 대해 문의하십시오.
EUDI Wallet 연동이 실제로 해야 하는 일
작업은 다섯 가지입니다. 누군가 서비스를 등록합니다. 누군가 요청자가 누구인지 증명하는 키를 보유합니다. 누군가 서명된 요청을 보냅니다. 누군가 돌아온 응답을 검증합니다. 누군가 기록을 보관합니다. 경로마다 이 작업을 나누는 방식이 다릅니다.
ARF는 지갑과 통신하는 시스템을 Relying Party Instance라고 부릅니다. ARF에서 이 시스템은 접근 인증서로 인증하며, 그 개인 키는 "Relying Party Instance의 하드웨어에 안전하게 저장"됩니다.[6] 두 번째 객체인 등록 인증서는 하나의 의도된 용도와 그 용도로 등록된 속성을 명시합니다.[1][6] 신뢰당사자는 모든 제시 요청에 이 중 하나를 값으로 포함합니다.[7]
생태계에서 신뢰당사자의 위치. 출처: EUDI Wallet Architecture and Reference Framework, European Commission, CC BY 4.0.
2026년의 두 가지 변경이 구매 결정을 바꿉니다. 2026년 7월 15일 이행규정(EU) 2026/1730은 등록 규칙을 개정했습니다. 이제 회원국은 등록 인증서를 발급할 인증기관을 최소 하나 이상 승인해야 하며, 발급은 자동화되어야 합니다.[3] 또한 부속서 I 제16호를 추가했습니다. 이는 중개자가 서비스하는 신뢰당사자와의 연결 정보로, 부속서 II에 따라 접근 인증서에 포함되어야 합니다.[3]
계획을 정하는 날짜
- 2026년 8월 11일규칙 개정2026/1730 발효. 당사 계산: 7월 22일 공포 후 20일.
- 2026년 12월 24일지갑 제공 기한2025/848의 등록 규칙 적용.
- 2027년 7월 10일AMLR 적용대부분의 의무기관에 아웃소싱 및 기록 규칙 적용.
- 2027년 12월 24일수용제5f조(2) 민간 신뢰당사자(당사 계산).
- 2028년 8월 11일인증서 확인지갑은 등록 인증서를 인증하고 유효성을 검증해야 합니다.
날짜 출처: 규정(EU) No 910/2014, 2025/848, 2026/1730, 2026/1731 및 AMLR. 2027년 12월 24일은 당사 계산입니다. 이행법령 발효 후 36개월입니다(2024년 12월 4일 공포, 20일 후 발효).[1][2][3][4][5][9]
법적 요건은 제5f조(2)에 있습니다. 이 조항은 법령이나 계약에 따라 온라인 신원 확인에 강력한 사용자 인증을 사용해야 하는 민간 신뢰당사자에 적용되며, 대상 분야에는 은행, 에너지, 보건이 포함됩니다. 또한 "사용자의 자발적 요청이 있는 경우에만" 적용됩니다.[1] 초대형 온라인 플랫폼은 제5f조(3)에 따른 별도 의무가 있으며, 조문에 별도 날짜는 없습니다.[1] 전체 일정은 모든 EUDI Wallet 기한을 참고하십시오.
EUDI Wallet 연동의 네 가지 경로
이 표는 누가 지갑과 통신하는지, 어떤 법적 역할로 하는지에 따라 경로를 분류합니다. 노력과 통제 수준은 당사의 평가이며 법적 기준이 아닙니다.
| 경로 | 지갑을 상대하는 주체 | 인증서 | 통제 | 작업 부담 | 주로 적합한 대상 |
|---|---|---|---|---|---|
| 자체 검증기 구축 | 귀사(신뢰당사자) | 귀사가 접근 인증서와 등록 인증서를 보유 | 가장 높음 | 가장 높음: 키, 신뢰 목록, 지갑 테스트 | 보안 엔지니어링 역량을 갖춘 은행과 대형 플랫폼 |
| 신뢰당사자 중개자 | 귀사를 대신하여 중개자가 수행 | 중개자가 접근 인증서를 보유하며, 등록 인증서는 귀사 명의 | 중간: 계약으로 정함 | 프로토콜 부담은 낮으나 새로운 공급업체 관리가 필요 | 지갑만 필요한 기업 |
| 신원 확인 또는 오케스트레이션 플랫폼 | 제품에 따라 다름: 어떤 역할이 적용되는지 확인 필요 | 지갑 구간에서는 대체로 중개자와 동일 | 중간, 여러 방식에 걸쳐 발생 | 도입 부담은 가장 낮으나 의존도는 가장 깊음 | 하나의 흐름에서 지갑, eID, 신분증 경로가 모두 필요한 기업 |
| 지갑 제공자 또는 신뢰 서비스 도구 | 경우에 따라 다름: 도구는 역할이 아니라 제품임 | 다양함 | 용도에 따라 다름 | 사용 사례에 따라 다름 | 전자서명, 증명 발급 등 검증과 병행되는 별도 수요 |
경로 1: 자체 검증기 구축
귀사가 Relying Party Instance를 운영합니다. 유럽연합 집행위원회는 원격 검증기와 근접 검증기 구축 가이드가 포함된 참조 구현을 공개하며, 그 검증기 엔드포인트는 Apache 2.0 라이선스로 제공됩니다.[14][15] 그래도 하드웨어에 보관되는 키, 인스턴스와 서비스별 인증서, 신뢰 목록 다운로드, 사양 변경 시 업그레이드는 여전히 귀사의 책임입니다.[6][7]
지갑 처리량이 많거나, 제출된 속성을 제3자가 보는 것을 리스크 팀이 허용하지 않는 경우에 적합합니다.
경로 2: 신뢰당사자 중개자
제5b조(10)는 이 모델의 법적 틀을 정합니다. 나머지는 ARF가 구체화합니다. 중개자는 신뢰당사자를 대신해 신뢰당사자의 업무를 수행하는 "특수한 유형의 신뢰당사자"이며, 고객은 "접근 인증서가 필요하지 않습니다".[6] 그래도 등록은 해야 합니다. 중개자는 각 고객이 그 고객이 설립된 회원국에 등록되어 있도록 보장해야 하기 때문입니다.[7]
경로 3: 신원 확인 또는 오케스트레이션 플랫폼
"플랫폼"은 상업적 용어이며 제5b조(10)에는 나오지 않습니다. 월렛 구간에서 플랫폼은 중개자이거나, 귀사 자체 인스턴스의 호스트입니다. 중개자라면 그에 따르는 모든 제한이 적용됩니다. 플랫폼의 가치는 여러 인증 수단을 하나의 연동으로 연결하는 데 있습니다. 위험은 플랫폼이 신분증 문서에 대해 하는 일, 예를 들어 증빙을 수년간 보관하는 일이 월렛에도 그대로 적용된다고 가정하는 것입니다. 그렇지 않을 수 있습니다.
미해결 쟁점
귀사 자체 접근 인증서로 귀사 인스턴스를 호스팅만 하는 벤더도 중개자에 해당하는가. ARF의 정의인 "그들을 대신해 Wallet Unit과 상호작용하는" 자는 넓게 읽히며, 이 문제를 정리하는 문언은 찾지 못했습니다.[6] 계약 체결 전에 법률 자문과 등록기관에 이 질문을 확인하십시오.
경로 4: 월렛 제공자 또는 신뢰 서비스 도구
월렛 제공자와 신뢰 서비스 제공자도 소프트웨어를 판매합니다. 적격 서명이 필요하거나 증명을 발급하려는 경우에 유용합니다. 등록 규칙은 이러한 활동을 별도의 권한으로 규정합니다. 예를 들어 QEAA_Provider와 QCert_for_ESig_Provider가 있으며, 일반 사업자에게는 Service_Provider가 있습니다.[2] 해당 도구가 귀사를 대신해 월렛과 통신한다면 중개자 규칙에 비추어 검토하십시오.
귀사에 남는 것과 위임할 수 있는 것
제5b조(10)Regulation (EU) No 910/2014
"신뢰당사자를 대신해 행위하는 중개자는 신뢰당사자로 간주되며, 거래 내용에 관한 데이터를 저장해서는 안 된다."
출처: EUR-Lex, 통합본[1]
신뢰당사자로 "간주"된다고 해서 귀사 자신의 의무가 사라지지는 않습니다. 제5b(9)조는 신뢰당사자가 요청한 개인 식별 데이터와 증명을 인증하고 검증하는 절차를 수행할 책임을 신뢰당사자에게 부과합니다.[1] ARF는 역할 분담을 계약에 맡깁니다. "중개자와 그 서비스를 이용하는 신뢰 당사자는 중개자가 수행할 검증 항목에 대해 합의해야 한다".[6] 등록기관은 서명된 계약서나 위임장 등 관계를 입증하는 자료를 요구할 수 있습니다.[6]
| 업무 | 벤더가 수행할 수 있는가 | 근거 규정 |
|---|---|---|
| 이용 목적과 데이터 결정 | 불가: 귀사의 결정 | 제5b(2)(c)조, 제5b(3)조[1] |
| 귀사 회원국에 등록 | 등록기관이 허용하면 서류 작업은 가능. 등록 항목은 귀사 명의로 유지 | 제5b(1)조[1], RPI_03[7] |
| 등록 항목을 정확하게 유지 | 지원 가능. 의무는 귀사에 남음 | 제5b(6)조[1] |
| 접근 인증서 보유 및 요청 전송 | 가능, 중개자로서 | ARF §6.6.5[6] |
| 진위, 폐지 여부, 기기 및 사용자 결합 검증 | 합의한 경우 가능 | RPI_09[7] |
| 요청마다 등록 인증서를 선택 | 귀사가 지정 | RPI_05[7] |
| 이용자 삭제 요청에 응답 | 지원만 함. 귀사의 연락처는 귀사의 등록 인증서에 기재되며, 지갑은 삭제 요청을 귀사로 보냄 | RPRC_11[7], 2024/2982 제6조[4] |
| 위험 프로필과 업무관계를 결정 | AMLR 의무기관은 불가. 펀드 관련 예외 1건만 있음 | AMLR 제18조(3), 제18조(7)[9] |
규제 대상 기업에는 세 가지 층위가 더 있습니다. 자금세탁방지규정(AMLR)은 의무기관이 업무를 아웃소싱하도록 허용하지만, 의무기관은 먼저 감독기관에 통지해야 하며 "전적인 책임"을 계속 집니다.[9] 디지털운영복원력법은 ICT 계약에서도 금융기관이 "전적으로 책임"을 지도록 합니다.[11] 일반개인정보보호규정(GDPR)은 충분한 보증을 제공하는 처리자를 요구합니다.[10] 저희가 검토한 어떤 문서도 중개자가 처리자인지 관리자인지 밝히지 않으므로, 귀사의 분석을 계약서에 기록하십시오.
중개자의 작동 방식과 인증서 수가 중요한 이유
두 식별자를 대조
이용자에게 귀사의 이름을 표시
합의된 점검을 수행
제시 내용을 삭제
중개된 제시. ARF §6.6.5 및 Topic 52를 단순화함.[6][7]
첫째, 이용자에게는 공급업체의 이름이 아니라 귀사의 상호가 표시됩니다. 다만 지갑은 중개자를 기록하므로 이용자는 나중에 이를 확인할 수 있습니다.[6] 둘째, 지갑은 등록 인증서의 식별자와 접근 인증서의 식별자를 대조하며, 불일치 경로에서는 거래가 중단될 수 있습니다.[6] 셋째, 귀사와 중개자 사이의 인터페이스는 ARF의 적용 범위 밖이며, ARF는 속성의 종단간 암호화를 요구하지 않습니다. 따라서 공급업체가 모든 속성을 볼 수도 있습니다.[6]
핵심은 ARF의 계산입니다. 시행규정 2026/1730은 서비스를 받는 신뢰당사자와의 연결을 등록 데이터에 추가하며, ARF v3.0.0에서는 접근 인증서가 그 연관 관계를 담습니다. 따라서 서비스를 받는 신뢰당사자 기준으로, 중개자는 "중개하는 신뢰당사자마다 별도의 접근 인증서 세트를 받습니다".[3][6] 2026년 7월 이전에 공유 인증서 모델을 설명한 공급업체라면 새 설계를 귀사에 보여 주어야 합니다. 규모는 위험을 집중시킵니다. 귀사 중개자의 접근 인증기관(Access Certificate Authority)이 정지되면 그 인증서는 폐지되며, 귀사는 "등록이 여전히 유효하더라도" 속성을 요청할 수 없습니다.[7] 다른 중개자로 옮기거나 기다려야 하므로, 이탈 계획은 운영상 통제 수단입니다.
모든 경로가 수행해야 하는 단계인 신뢰당사자 인증. 출처: EUDI Wallet Architecture and Reference Framework, European Commission, CC BY 4.0.
증거 문제: 삭제 대 보존
삭제를 요구하는 규정
중개자와 검증자
- 거래 내용에 관한 데이터는 저장하지 않음(제5b조(10))
- 전달 후 "완전히 그리고 즉시" 삭제(RPI_10)
- 더 이상 필요하지 않게 되면 서명 값, salt, 해시, 타임스탬프를 폐기(OIA_16)
규정 및 ARF 부속서 2[1][7]
보관을 요구하는 규칙
의무기관
- 전자식별수단을 통해 취득한 정보를 보관(제77조(1)(a))
- 5년간 보관
- 아웃소싱한 업무가 귀사의 위험을 완화한다는 점을 감독기관에 입증(제18조(2))
AMLR, 2027년 7월 10일부터[9]
OIA_16은 Relying Party Instance에 모든 고유 요소를 폐기하고 이를 "Relying Party 또는 다른 어떤 당사자에게도" 전달하지 말도록 요구합니다. 이 목록에는 증명 제공자의 서명이 포함됩니다.[7] 따라서 서명된 지갑 응답을 감사 추적 기록으로 보관하겠다는 약속은 어느 벤더가 하든 검증이 필요합니다. ARF는 프레임워크이지 법적 행위가 아니며, 5년 보관 의무와 관련하여 "더 이상 필요하지 않게 되면"이 무엇을 의미하는지 정의하지 않습니다. 법률 자문가에게, 그리고 규제 대상이라면 감독기관에도 문의하십시오.
아래는 규칙이 아니라 검증이 필요한 당사의 제안 설계입니다.
| 기록 | 보유 주체 | 근거 |
|---|---|---|
| 고객확인에 필요한 속성 | 귀사, 귀사 시스템 내 | AMLR 제77조[9] |
| 확인 로그: 시각, 방법, 수행한 확인, 결과, 사용된 인증서 | 귀사, 고유 요소 제외 | AMLR 제18조(2), 당사 제안[9] |
| 얼굴 사진(요청하는 경우에 한함) | 필요하거나 법률에 규정된 경우가 아니면 보관하지 않음 | ARF 부속서 2[7] |
| 서명, salt, 해시 | 귀사가 검토해야 할 미해결 법적 쟁점 | OIA_16[7] |
| 중개자에서의 거래 내용 | 없음: 즉시 삭제 | 제5b조(10)[1], RPI_10[7] |
벤더가 입증해야 할 기능과 각 기능의 근거 규정
이 표를 제안요청서(RFP)의 기술 부속서로 쓰거나 자체 구축에 활용하십시오.
| 단계 | 기능 | 규정 또는 표준 |
|---|---|---|
| 설정 | 중개자 연결 정보를 포함한 등록 데이터 | 2025/848 부속서 I 제14호부터 제16호[2][3]; TS5 usesIntermediaries[8] |
| 설정 | 인스턴스, 서비스, 고객별 접근 인증서, 하드웨어 보관 키 | ARF §3.11.3[6]; 2026/1730을 통한 ETSI TS 119 411-8[3] |
| 설정 | Trusted Lists 및 Lists of Trusted Entities에서 가져와 갱신하는 신뢰 앵커 | OIA_12, OIA_15a[7] |
| 요청 | 등록된 용도를 벗어난 속성은 모두 강제 차단 | 제5b조(3)[1]; 2025/848 제9조(2)(c)[2] |
| 요청 | 각 요청에 현재 용도에 대한 등록 인증서를 값으로 포함 | RPRC_19[7] |
| 요청 | 권장: 두 프로토콜 프로파일 모두, OpenID4VC-HAIP 및 ISO/IEC mdoc | 2024/2982에 대한 2026/1731 부속서[5] |
| 검증 | 증명 유형별 발급자 서명 | OIA_12부터 OIA_15까지[7] |
| 검증 | 폐기 여부 확인, 그리고 상태를 알 수 없을 때 적용할 서면 정책 | VCR_13, VCR_14[7] |
| 검증 | 기기 바인딩 및 선택한 사용자 바인딩 방식 | OIA_17, ARF §6.6.3.9[6][7] |
| 이후 | 고유 요소의 폐기 | OIA_16[7] |
| 이후 | 삭제 요청 및 해당 개인정보 보호 감독기관 연락처 | RPRC_11, RPRC_12[7]; 2024/2982 제6조, 제7조[4] |
| 보증 | 공개된 테스트 결과 | OpenID Foundation 자체 인증[12] |
OpenID Foundation은 2026년 8월 7일 OpenID for Verifiable Presentations(OpenID4VP) 적합성 테스트를 자체 인증용으로 공개했습니다. 검증자는 이 테스트를 무료로 실행할 수 있습니다. 자체 인증 결과를 공개하려면 수수료가 듭니다.[12] 집행위원회의 Functional Conformance Assessment Framework는 아직 "활발히 개발 중"이며, 최초 테스트 대상 시스템은 Wallet Solution입니다. 따라서 아직 이 프레임워크에서 신뢰당사자용 인증 배지를 기대하지 마십시오.[13] 형식의 경우, 개인 식별 데이터(PID) 증명서는 mdoc과 SD-JWT VC 두 형식으로 모두 발급되어야 합니다. 다른 증명은 하나씩 확인하십시오. 차이점은 Didit의 형식 비교에서 설명합니다.[7]
국가 지갑이 아닌 디자인 가이드 예시 화면입니다. 사용자가 공유하기 전에 검토하는 내용을 보여 줍니다. EUDI Wallet Architecture and Reference Framework, Annex 5, European Commission, CC BY 4.0에서 각색(일부 잘라냄)했습니다.[16]
지갑 경로와 비지갑 경로
제5a조(15)는 지갑 사용은 "자발적이어야 한다"고 하고, "다른 기존 신원확인 및 인증 수단으로 공공 및 민간 서비스에 접근하는 것이 계속 가능해야 한다"고 규정합니다.[1] 따라서 지갑이 유일한 통로가 되어서는 안 됩니다. AMLR 제22조(6)도 마찬가지로 신분증명서 또는 보증 수준 상당(substantial) 또는 높음(high)의 전자신원확인을 허용합니다.[9]
1해당 국가에 맞는 방식 제시
사용자가 선택합니다. 지갑 요청은 사용자가 요청할 때에만 시작됩니다.
지갑 제시가 성공하고 자체 점검을 통과함
계속 진행
지갑이 제공하지 않는 항목을 추가합니다.
자체 정책 적용
서면 위험 분석에 따라 수락 또는 거절을 결정합니다.
다른 경로로 전환
국가 eID, 그다음 생체 활성 감지를 동반한 신분증명서.
2스크리닝, 위험 평가, 결정
어떤 방식을 사용했든 동일한 기록.
모든 통로를 열어 두는 경로 설계입니다. 상태 불명 경로는 VCR_14가 규율합니다.[1][7]
초상 사진은 2028년 8월 11일부터만 필수 PID 데이터가 될 수 있으며, 회원국은 이용자가 이를 거부하도록 허용할 수 있습니다. 따라서 지갑과의 얼굴 대조에 의존하는 설계는 항상 작동하지는 않습니다.[5] holder binding에 관한 글에서 지갑만으로 충분한 경우와 라이브니스 검사를 추가해야 하는 경우를 다룹니다. 항목과 식별자의 국가별 차이는 27개 이상의 국가 지갑 수용에서, 도입 현황은 국가별 현황 추적에서 확인할 수 있습니다. 규제 대상 온보딩에 대해서는 AMLR과 EUDI Wallet을 읽어 보십시오.
지갑이 도입되기 전에 라우터를 설계하십시오
현재 존재하는 방법으로 지금 이 경로를 구축할 수 있습니다. Didit을 통한 신원 확인은 신분증 촬영, NFC 칩 판독, 라이브니스 검사와 얼굴 대조를 포함하며, 국가와 결과에 따라 분기합니다.[18][19]
기업 유형별 경로 선택
제5f조(2): 강력한 이용자 인증을 사용해야 하며 초소기업 또는 소기업이 아닌 경우
수용 의무
2027년 12월 24일까지 가동을 계획하십시오.
선택 사항
초대형 온라인 플랫폼으로서 제5f조(3)이 적용되는 경우는 예외입니다. 수용하는 경우 등록이 적용됩니다.
키 보관, 신뢰 목록, 지갑 테스트를 자체적으로 운영할 수 있는 경우
자체 구축
또는 자체 구축을 벤더로부터의 출구 전략으로 유지합니다.
벤더 이용
중개자 단독, 또는 다른 방법도 필요한 경우 플랫폼.
출발점일 뿐입니다. 법률 자문과 처리 물량에 따라 결정됩니다.[1]
| 귀사 유형 | 출발 경로 | 유의 사항 |
|---|---|---|
| 은행 또는 결제 기업 | 자체 구축, 또는 자체 구축 옵션이 있는 중개자 | AMLR 제18조 및 Digital Operational Resilience Act[9][11] |
| 핀테크 또는 암호자산 기업 | 플랫폼 또는 중개자 | 제5f조(2) 적용 여부 확인, 보존[1][9] |
| 초대형 온라인 플랫폼 | 자체 구축 또는 중개자 | 제5f조(3), 최소한의 데이터[1] |
| 연령 제한 서비스 또는 소규모 기업 | 수용하기로 선택한 경우 공급업체 | 필요한 정보만 요청해야 하며, 신원 확인이 요구되지 않는 경우 가명 사용을 거부할 수 없습니다[1] |
| 여러 회원국에 걸친 그룹 | 하나의 설계, 여러 건의 등록 | 각 법인은 설립된 곳에서 등록합니다[1] |
| EU 내 설립지가 없는 기업 | 먼저 자문을 받으십시오 | 검토한 문서에는 경로가 규정되어 있지 않습니다. 제5b조(1)은 설립지를 기준으로 합니다[1] |
공급업체에 서면으로 요구할 사항
등록부 규정은 2026년 12월 24일부터 적용됩니다. 따라서 등록된 서비스라는 주장이 있으면 그 근거가 되는 등록부 항목을 요구하십시오.[2]
| 항목 | 서면으로 받을 내용 | 경고 신호 |
|---|---|---|
| 법적 역할 | 지갑 구간에서의 역할, 어느 등록기관에 언제 신고하는지 | "저희는 플랫폼이라 해당되지 않습니다" |
| 귀사의 등록 | 누가 어떤 권한으로 신고하고, 누가 갱신하는지 | 등록 항목이 공급업체 명의로 되어 있음 |
| 인증서 | 2026/1730 이후 고객별 모델 | 모든 고객이 공유하는 단일 인증서 |
| 인증기관 | 어느 기관을 이용하는지, 한 곳이 정지될 경우의 계획 | 대체 공급원도 출구도 없음 |
| 수행하는 검증 | 목록: 진위, 폐지 여부, 기기 및 사용자 결합 | "저희가 지갑을 검증합니다" |
| 데이터 가시성 | 속성을 평문으로 볼 수 있는지 여부 | 답변 없음 |
| 삭제 | 전달 후 삭제 방식과 삭제 증빙 방식 | "귀사의 감사"를 위해 보관하는 프레젠테이션 |
| 귀사의 기록 | 귀사 시스템에 어떤 데이터가 어떤 형태로 들어오는지 | 자사 포털 안에서만 제공되는 증거 |
| 범위 제한 | 등록되지 않은 속성에 대한 기술적 차단 | 신중하게 설정하겠다는 약속 |
| 테스트 | 공개된 결과, 그리고 이름과 버전을 명시해 테스트한 월렛 | "모든 월렛과 호환" |
| 이전 | 사용자에게 새로운 영향 없이 다른 중개자로 이전 | 벤더에 묶인 등록 |
이번 달에 할 일
- 각 법인에 제5f조(2)와 제5f조(3) 중 어느 조항이 적용되는지 서면으로 확인하십시오.[1]
- 각 사용 사례와 그에 필요한 최소 속성을 목록으로 정리하십시오.
- 등록 기관과 해당 국가의 등록 정책을 확인하십시오.[2]
- OIA_16과 귀사의 보존 의무의 관계를 법률 자문에게 문의하십시오.[7][9]
- 폐지 상태를 알 수 없는 경우에 대한 정책을 작성하십시오.[7]
- 의무기관이 아웃소싱할 예정이라면 감독기관 통지서 초안을 작성하십시오.[9]
- 현재 보유한 방법으로 대체 경로를 구축하십시오.
관련 글 EUDI Wallet 정책과 통제에서는 이 단계들을 담당자와 증거가 포함된 통제 매트릭스로 정리합니다.
Didit이 EUDI Wallet 연동을 지원하는 방법
EUDI Wallet 수용 기능은 곧 제공될 예정이며, 날짜나 가격은 아직 정해지지 않았습니다.[17] 접근 방식은 EUDI Wallet 솔루션 페이지에서 확인하십시오. 해당 페이지의 문구는 "Integrate today, and keep it when the wallet arrives"입니다.
현재 제공되는 것은 이 가이드에서 설명한 흐름의 나머지 부분입니다. Didit은 MitID, BankID Sweden, Finnish Trust Network, Smart-ID, Mobile-ID를 문서 촬영과 함께 운영하며, 설정된 문서 대체 경로를 제공합니다.[18] eID 인증을 참조하십시오. 워크플로는 국가와 결과에 따라 분기되고, 웹훅에는 서명이 적용되며, 보존 기간은 1개월부터 10년까지 설정할 수 있습니다.[19][20][21] Didit은 데이터 처리자로 기능하며 귀사는 계속 컨트롤러로 남습니다.[22] Didit은 SOC 2 Type 1 및 Type 2 보고서, ISO/IEC 27001:2022 인증, iBeta Level 1 프레젠테이션 공격 탐지 테스트를 보유하고 있습니다.[23] 가격은 가격을 참조하십시오.
Didit이 제공하는 것
- 하나의 워크플로 안에서 국가 eID와 신분증 확인
- 라우팅 분기와 신분증 대체 경로
- 서명된 webhook과 설정 가능한 보존 기간
귀사에 남는 것
- 귀사의 신뢰당사자 등록과 의도된 용도
- 위험평가, 정책 및 고객에 대한 결정
- 귀사의 보존 결정과 법률 분석
핵심 요약
- 실제 선택은 누가 신뢰당사자로서 지갑을 상대하느냐입니다. 귀사 또는 중개자입니다.
- 제5b조(10)에 따라 중개자는 신뢰당사자로 간주되며 거래 내용에 관한 데이터를 저장할 수 없습니다.
- 2026/1730은 서비스를 받는 고객을 접근 인증서에 기재하도록 합니다. ARF v3.0.0은 중개자에게 고객별로 별도의 인증서 세트를 부여합니다.
- 삭제 규칙과 보존 의무가 충돌합니다. OIA_16과 AMLR 제77조의 관계는 법률 자문과 함께 정리하십시오.
- 제5a조(15)는 다른 수단을 열어 두므로 라우팅을 먼저 설계하십시오.
자주 묻는 질문
EUDI Wallet 통합 플랫폼이란 무엇입니까?
애플리케이션을 EUDI Wallet에 연결하는 서비스로, 다른 신원 확인 수단과 함께 제공되는 경우가 많습니다. 이 용어에는 법적 의미가 없습니다. 지갑 구간에서 벤더는 중개자이거나 귀사 자체 인스턴스의 호스트입니다. 어느 역할에 해당하는지 확인하십시오.[1][6]
EUDI Wallet을 서비스에 어떻게 통합합니까?
귀사가 속한 회원국에 등록하고, 각 의도된 용도와 해당 속성을 정의한 뒤 경로를 선택하십시오. 자체 검증자, 중개자, 플랫폼 또는 전문 도구 중에서 선택합니다. 요청은 접근 인증서로 서명되며 등록 인증서를 포함합니다.[2][7]
신뢰당사자 중개자란 무엇입니까?
신뢰당사자를 대신하여 지갑과 상호작용하는 개인 또는 회사입니다. 제5b조(10)는 이를 신뢰당사자로 간주하며 거래 내용에 관한 데이터의 저장을 금지합니다.[1][6]
중개자를 이용해도 등록해야 합니까?
그렇습니다. ARF는 중개자가 각 고객이 설립된 회원국에 해당 고객이 등록되도록 보장할 것을 요구합니다. 등록 방식은 등록기관이 결정하며, 관계를 증명하면 중개자가 등록 신청을 처리하도록 허용할 수 있습니다.[6][7]
벤더가 서명된 지갑 응답을 증거로 보관할 수 있습니까?
이는 미해결 문제로 보아야 합니다. 중개자는 거래 내용을 저장할 수 없으며, ARF 요건 OIA_16은 검증자에게 더 이상 필요하지 않은 서명 값을 폐기하도록 합니다. 규제 대상 기업은 AMLR 제77조와의 관계를 법률 자문과 함께 정리해야 합니다.[1][7][9]
민간 기업은 언제부터 EUDI Wallet을 수용해야 합니까?
법률이나 계약에 따라 온라인 신원확인에 강력한 사용자 인증을 사용해야 하는 경우, 기한은 2027년 12월 24일입니다. 이 날짜는 36개월을 저희가 직접 계산한 결과입니다. 초소기업 및 소기업은 면제되며, 수용 의무는 이용자가 자발적으로 요청하는 경우에만 적용됩니다.[1]
EUDI Wallet이 신분증 검증을 대체할 수 있나요?
개별 고객에 대해서는 요건을 갖춘 지갑이 신분증 확인을 대신할 수 있지만, 유일한 수단이 될 수는 없습니다. 지갑 사용은 자발적이며, 제5a조(15)에 따라 다른 수단도 계속 제공해야 합니다. AMLR은 전자신원확인과 함께 신분증도 허용하므로 두 경로를 모두 준비하십시오.[1][9]
Didit은 현재 EUDI Wallet을 수용하나요?
아니요. EUDI Wallet 수용 기능은 곧 제공될 예정이며, 아직 일정이나 가격은 정해지지 않았습니다. 현재 Didit은 국가 eID와 신분증 확인을 하나의 워크플로에서 실행합니다.[17][18]
출처
- Regulation (EU) No 910/2014, 2024년 10월 18일 통합본, EUR-Lex.
- Commission Implementing Regulation (EU) 2025/848, 지갑 신뢰당사자 등록, EUR-Lex.
- Commission Implementing Regulation (EU) 2026/1730, 2026년 7월 15일, EUR-Lex.
- Commission Implementing Regulation (EU) 2024/2982, 프로토콜 및 인터페이스, EUR-Lex.
- Commission Implementing Regulation (EU) 2026/1731, 2026년 7월 15일, EUR-Lex.
- Architecture and Reference Framework v3.0.0, European Commission, 2026년 7월.
- ARF v3.0.0, 부속서 2, 주제별 상위 요구사항, European Commission.
- Technical Specification 5, 신뢰당사자 등록 형식 및 API, European Commission.
- Regulation (EU) 2024/1624 (AMLR), EUR-Lex.
- Regulation (EU) 2016/679 (GDPR), EUR-Lex.
- Regulation (EU) 2022/2554 (Digital Operational Resilience Act), EUR-Lex.
- OpenID4VP 및 OpenID4VCI 적합성 테스트 완료, 자체 인증 개시, OpenID Foundation, 2026년 8월 7일.
- Functional Conformance Assessment Framework, EUDI Wallet 프로젝트.
- EUDI Wallet Reference Implementation 문서, European Commission.
- EUDI 검증자 엔드포인트 저장소, Apache License 2.0.
- ARF v3.0.0, 부속서 5, 데이터 공유 시나리오 설계 가이드, European Commission.
- EUDI Wallet, Didit 솔루션 페이지.
- 디지털 ID 지갑, Didit 문서.
- 워크플로 빌더, Didit 문서.
- 웹훅, Didit 문서.
- 데이터 보존, Didit 문서.
- 보안 및 컴플라이언스, Didit 문서.
- 인증, Didit 문서.
지금 선택하는 경로는 공급업체 변경, 국가 지갑의 출시 지연, 보존 감사에도 유지될 수 있어야 합니다. 출시 진행 상황과 Didit의 수용 방식은 EUDI Wallet 솔루션 페이지에서 확인하십시오.