발급기관 귀환 호출 없는 인증: 미래의 디지털 국제운전면허증이 매 사용 시마다 발급기관에 연락해서는 안 되는 이유

폐기(Revocation)는 미래의 디지털 국제운전면허증(IDP)에서 가장 해결하기 어려운 문제입니다. 이를 해결하는 가장 쉬운 방법은 동시에 가장 위험하기도 합니다. 바로 발급기관을 매번 제시 과정에 참여시키는 것입니다. 현대적인 국경 간 운전 자격증명은 기본적으로 이 편법을 거부해야 합니다.

거의 모든 디지털 신원 제안서에는 다음과 같은 안심시키는 문구가 포함되어 있습니다:

“자격증명을 즉시 검증할 수 있습니다.”

때로 이 문구는 진정한 기술 발전을 의미합니다. 하지만 때로는 더 친숙한 사용자 인터페이스를 갖춘 감시 체계를 의미하기도 합니다.

현재 공개된 표준들은 이미 자격증명 제시 시마다 검증기가 발급기관에 연락할 필요가 없다는 점을 명확히 하고 있습니다:

• NIST의 현행 mDL 아키텍처에 따르면, 검증기는 발급기관과 직접 접촉하지 않고 발급기관의 서명과 공개 키를 신뢰함으로써 진위성과 무결성을 검증할 수 있습니다.
• AAMVA는 ISO/IEC 18013-5가 기기 검색(device retrieval)을 지원하도록 요구하며, 서버 검색(server retrieval)은 선택적으로만 허용한다고 확인합니다.
• AAMVA는 또한 경고합니다 — 서버 검색 방식에서는 발급기관이 매 사용 시마다 실시간으로 관여하게 되므로, 기술적으로 자격증명 사용 시점, 공유된 데이터, 심지어 IP 분석을 통한 위치 추론까지 기록할 수 있게 됩니다.

이것은 사소한 각주가 아닙니다. 차세대 국경 간 운전 자격증명의 핵심 설계 과제입니다.

위험한 편법: 네 가지 질문을 하나의 네트워크 호출로 압축하기

잘못된 아키텍처는 네 가지 전혀 다른 질문을 발급기관에 대한 단일 실시간 호출로 묶어버립니다:

1. 이 자격증명은 진본인가?
2. 제시하는 사람이 정당한 소지자인가?
3. 자격증명 자체가 여전히 유효한가?
4. 기초가 되는 국내 운전 자격이 여전히 유효한가?

잘못 설계된 시스템은 이 네 가지 모두를 실시간 발급기관 호출로 해결합니다. 반면 잘 설계된 시스템은 이를 분리합니다. 이는 동일한 문제가 아니며, 동일한 메커니즘을 공유해서도 안 됩니다.

진위성은 네트워크가 아닌 로컬에서 검증되어야 한다

자격증명은 발급기관이 거래를 전혀 관찰하지 않아도 암호학적으로 진본임을 증명할 수 있습니다.

• NIST의 mDL 신뢰 모델은 진위성과 무결성이 발급기관의 서명과 공개 키로 검증되며 — 실시간 발급기관 접촉이 필요하지 않다고 명시합니다.
• AAMVA의 디지털 신뢰 서비스(Digital Trust Service)는 거래별 콜백 없이 검증기가 유효한 발급기관 공개 키에 접근할 수 있도록 하기 위해 존재합니다.

설계 원칙 1: 서명이 이미 해결하는 문제에 실시간 연결을 사용하지 말 것.

검증기가 신뢰할 수 있는 발급기관 키를 보유하고 표준 준수 제시를 수신하면, 진위성 확인은 네트워크 의존 없이 로컬 암호학적 검사로 충분합니다.

소지자 바인딩은 로컬에서 증명되어야 하며, 전 세계에 보고되어서는 안 된다

두 번째 질문 — 이 사람이 정당한 소지자인가? — 역시 네트워크 없이 답할 수 있습니다.

현행 EUDI 아키텍처는 PID 및 ISO/IEC 18013-5 증명에 대해 기기 바인딩을 의무화합니다. 검증기는 지갑에게 자격증명에 내장된 공개 키에 대응하는 개인 키를 사용해 새로운 챌린지에 서명하도록 요청합니다:

• ISO/IEC 18013-5에서는 이를 mdoc 인증(mdoc authentication)이라고 합니다.
• SD-JWT VC에서는 이를 키 바인딩(key binding)이라고 합니다.

두 경우 모두, 소지 증명은 로컬에서 암호학적으로 이루어집니다. 발급기관에 개인 데이터가 전달될 필요가 전혀 없습니다.

설계 원칙 2: 소지는 로컬에서 증명할 것. 신원을 전 세계에 공표하지 말 것.

미래의 IDP는 발급기관 측 메커니즘을 고려하기 전에 기기 바인딩, 로컬 소지자 인증, 검증기 챌린지-응답을 모두 활용해야 합니다.

자격증명 상태와 운전 자격 상태는 서로 다른 개념이다

많은 디지털 신원 설계들이 이 구분을 흐리며, 바로 그것이 문제의 시작입니다.

W3C의 비트스트링 상태 목록(Bitstring Status List) 사양은 이 점을 명확히 합니다: 검증 가능한 자격증명에 첨부된 상태 정보는 검증 가능한 자격증명 자체에 적용되며 — 반드시 기초가 되는 실세계 권한에 적용되는 것은 아닙니다. 디지털 자격증명은 서명 메커니즘이 침해되어 폐기될 수 있지만, 기초가 되는 운전 자격은 완전히 유효한 상태로 남아 있을 수 있습니다.

따라서 미래의 IDP는 두 가지 별도의 상태 계층이 필요합니다:

• 자격증명 상태 계층 — 디지털 자격증명 또는 제시 채널 자체에 대한 것.
• 운전 자격 계층 — 운전을 허용하는 기초가 되는 국내 권한에 대한 것.

때로는 이 두 가지가 함께 변경됩니다. 그러나 자주 그렇지 않습니다. 이를 혼동하는 시스템은 과잉 반응하거나 필요 이상의 데이터를 노출시키거나, 혹은 두 가지 모두 발생합니다.

지갑 침해는 상태를 통해 전파되어야 하며 — 검증기 콜백을 촉발해서는 안 된다

미래의 IDP는 또한 지갑이 침해되었을 때 어떻게 처리할지에 대한 명확한 답변이 필요합니다.

EUDI 아키텍처는 이에 대한 해답을 제공합니다:

• 지갑 제공자는 폐기 정보가 포함된 지갑 단위 증명(Wallet Unit Attestations)을 발급합니다.
• 지갑 무결성은 시간이 지남에 따라 재검증되며, 지갑이 더 이상 안전하지 않으면 증명이 폐기됩니다.
• PID 제공자는 지갑이 폐기되었는지 정기적으로 확인해야 합니다. 폐기된 경우 PID도 함께 폐기합니다.
• 신뢰 당사자(relying party)는 PID 상태를 검증함으로써 암묵적으로 지갑 상태를 검증하게 됩니다.

이것이 미래의 IDP가 채택해야 할 계층화 방식입니다. 모든 검증기가 독립적으로 지갑 제공자를 확인하도록 요구하지 마십시오. 지갑 침해가 기존의 자격증명 상태 파이프라인을 통해 전파되도록 하고, 검증기들이 단일한 프라이버시 보호 채널을 참조하도록 하십시오.

실현 가능한 세 가지 폐기 패턴 (콜백 불필요)

EUDI는 제공자가 다음 세 가지 폐기 방법 중 하나를 사용하도록 요구합니다:

• 단기 증명(Short-lived attestations) — 24시간 이하로 유효하여 폐기가 불필요해집니다.
• 증명 상태 목록(Attestation Status List) — 검증기가 참조할 수 있는 공개 목록.
• 증명 폐기 목록(Attestation Revocation List) — 폐기된 자격증명의 명시적 목록.

24시간 이상 유효한 증명의 경우, EUDI는 다음을 포함하는 폐기 정보를 내장하도록 요구합니다:

• 신뢰 당사자가 상태 목록을 가져올 수 있는 URL.
• 해당 목록 내에서 자격증명을 식별하는 식별자.

신뢰할 수 있는 폐기 정보를 이용할 수 없는 경우 — 예를 들어 신뢰 당사자가 오프라인 상태일 때 — EUDI는 자격증명의 수락 또는 거부 전에 위험 분석을 수행하도록 신뢰 당사자에게 안내합니다.

핵심 시사점: 폐기는 단일한 메커니즘이 아니며, 발급기관 콜백을 의무화하는 근거도 될 수 없습니다.

기본적으로 단기 유효, 필요한 경우에만 장기 유효

전체 스택에서 가장 효과적인 프라이버시 보호 조치 중 하나는 또한 가장 단순합니다: 제시되는 내용을 단기 유효로 유지하는 것입니다.

• EUDI에 따르면 24시간 이하로 유효한 증명은 폐기 인프라가 필요하지 않습니다 — 폐기가 중요해지기 전에 만료됩니다.
• W3C는 검증 가능한 제시가 일반적으로 단기 유효이며 장기 보관을 위해 설계되지 않았다고 명시합니다.
• NIST는 일상적인 사용에서 재사용 가능한 식별자를 반복적으로 전송하는 것을 명시적으로 경고합니다. 일상적인 인증은 신원이 풍부한 자격증명을 반복 제시하는 것이 아니라 패스키(passkeys)와 같은 그 목적에 맞게 설계된 기술에 의존해야 합니다.
• NIST는 또한 프라이버시 보호와 운영 효율성을 이유로 서버 측 생체인식 매칭 대신 로컬 기기 인증을 선택했습니다.

설계 원칙 3: 기본 자격증명은 중간 유효 기간을 가질 수 있지만, 제시 자체는 단기 유효, 검증기 특정, 비재사용 가능해야 한다.

상태 목록이 올바른 기본 메커니즘이다

모든 것을 단기 유효로 만들 수 없을 때는 상태 인프라가 필요하며 — 상태 목록이 올바른 기본값입니다.

W3C의 비트스트링 상태 목록 v1.0(Bitstring Status List v1.0)은 정지 또는 폐기와 같은 상태 데이터를 게시하기 위한 프라이버시 보호, 공간 효율적, 고성능 메커니즘을 설명합니다. 주요 특성은 다음과 같습니다:

• 각 발급기관은 자신이 발급한 자격증명에 대한 목록을 관리합니다.
• 대부분의 자격증명이 폐기되지 않은 상태로 유지되므로 형식은 압축이 잘 됩니다.
• 기본 목록 크기는 131,072개 항목이며, W3C는 이것이 일반적인 경우에 적절한 그룹 프라이버시를 제공한다고 밝힙니다.
• 더 강력한 그룹 프라이버시가 필요한 경우 더 큰 목록을 사용할 수 있습니다.

이는 질문의 방향을 다음에서:

“지금 이 사용자에 대해 발급기관에 물어볼 수 있을까?”

다음으로 전환합니다:

“이미 로컬에서 결정을 내릴 수 있을 만큼 충분히 최신의 프라이버시 보호 상태 목록을 보유하고 있는가?”

이것이 훨씬 더 나은 질문입니다 — 기술적으로도, 정치적으로도.

“발급기관 귀환 호출 없음”은 다운로드 패턴이지, 슬로건이 아니다

EUDI 프라이버시 지침에서 가장 중요한 규칙은 철학적이 아니라 절차적입니다.

신뢰 당사자는 자격증명이 제시될 때마다 상태 목록을 요청해서는 안 됩니다. 대신 다음을 따라야 합니다:

• 목록의 각 새 버전을 한 번만 다운로드합니다.
• 사용자 제시와 무관한 시간과 장소에서 다운로드합니다.
• 신뢰 당사자 조직 내부적으로 목록을 배포합니다.
• 신뢰 당사자 인증 없이 목록을 가져옵니다.

이것이 발급기관 귀환 호출 없는 인증의 운영 핵심입니다: 상태를 사용자 제시와 별도로 갱신하고 — 개인별로도, 거래별로도 갱신하지 말 것.

이 단일한 설계 선택이 발급기관 또는 상태 제공자가 어떤 검증기가 어떤 자격증명을 언제 확인했는지 알 수 없도록 합니다.

그룹 프라이버시: 대부분의 설계가 잊어버리는 요건

많은 시스템이 제시 내부의 선택적 공개는 크게 홍보하면서 상태 조회의 프라이버시는 조용히 무시합니다. 이것은 심각한 결함입니다.

EUDI의 프라이버시 요건은 다음을 명시합니다:

• 상태 목록의 인덱스는 무작위로 할당되어야 하므로 인덱스 자체가 추적 신호가 되어서는 안 됩니다.
• 각 목록은 그룹 프라이버시를 보장하기 위해 충분히 많은 수의 자격증명을 포함해야 합니다.
• 목록이 너무 작아질 경우, 제공자는 실제 자격증명 수를 숨기기 위해 미사용 항목을 추가해야 합니다.

미래의 IDP는 선택적 공개만으로 프라이버시 보호를 주장할 수 없습니다. 폐기 메커니즘이 제시 이벤트를 누출한다면, 프라이버시 설계는 불완전한 것입니다.

오프라인 운영은 예외적 상황이 아니라 핵심 요건이다

완벽한 연결성을 가정하는 여행 시스템은 잘못 설계된 것입니다.

• AAMVA는 기기 검색이 소지자 기기와 리더기 모두에서 외부 연결 없이 작동하며, ISO/IEC 18013-5가 mDL의 기기 검색 지원을 요구한다고 확인합니다.
• EUDI는 신뢰 당사자가 오프라인 상태이거나 캐시된 상태 목록이 없을 수 있음을 인정하며, 이 경우 결정 전에 위험 분석을 권장합니다.

이 트레이드오프를 일찍 받아들이십시오:

완벽한 오프라인 운영과 완벽한 실시간 최신성을 동시에 가질 수는 없습니다.

타협 없이 두 가지 모두를 약속하는 아키텍처는 부정확하거나 조용히 감시를 재도입하는 것입니다. 올바른 대응은 최신성을 보편적인 네트워크 의존성이 아닌 정책 입력값으로 만드는 것입니다.

로그는 프라이버시가 조용히 실패하는 곳이다

훌륭한 상태 아키텍처도 부주의한 로깅에 의해 무너질 수 있습니다.

• EUDI는 신뢰 당사자 인스턴스가 더 이상 필요하지 않은 즉시 고유 요소와 타임스탬프를 폐기하고, 이를 전달하는 것을 금지하도록 요구합니다.
• AAMVA는 이해관계자들이 법적으로 요구되는 경우를 제외하고 mDL 소지자 또는 mDL 사용을 추적하는 것을 금지하며, 발급기관이 정적 또는 장기 메타데이터 공유를 최소화할 것을 요구하고, 활동 로그 접근을 소지자로 제한합니다.
• AAMVA는 또한 기기 내 삭제가 사용 이력을 드러낼 수 있는 로그 정보와 메타데이터를 제거해야 하며 — 이 삭제가 오프라인에서도 가능해야 한다고 요구합니다.

이것은 행정적 정리 작업이 아닌 프로토콜 동작입니다. 미래의 IDP는 명시적으로 달리 증명되지 않는 한 장기 식별자, 타임스탬프, 로그를 잠재적 추적 도구로 취급해야 합니다.

미래 IDP를 위한 구체적인 발급기관 귀환 호출 없는 아키텍처

이 원칙들을 종합하면, 시스템이 실제로 해야 할 일은 다음과 같습니다:

1. 기기 바인딩 기본 자격증명을 발급합니다. 자격증명을 지갑의 보안 환경에서 보호되는 키에 바인딩합니다 — EUDI에서 PID 및 ISO/IEC 18013-5 증명에 대해 의무사항입니다.
2. 새로운 챌린지와 함께 필요한 것만 요청합니다. OpenID4VP 거래에서 DCQL 쿼리를 통해 지갑이 소지자에게 어떤 속성이 요청되는지 보여주고, 검증기는 재전송 공격을 방지하기 위해 챌린지를 발급합니다(NIST의 현행 mDL 아키텍처 기준).
3. 재사용 가능한 식별자가 아닌 단기 유효 제시를 생성합니다. 각 제시는 검증기, 요청, 순간에 특정되어야 합니다.
4. 진위성을 로컬에서 검증합니다. 발급기관 서명과 공개 키를 오프라인으로 검증합니다; AAMVA의 신뢰 서비스는 바로 이 목적을 위해 만들어졌습니다.
5. 캐시된, 별도로 갱신된 목록에서 상태를 확인합니다. 폐기를 건너뛸 수 없을 만큼 장기 유효한 자격증명의 경우, 사용자 제시와 무관한 일정에 따라 갱신된 로컬 캐시 상태 목록을 사용합니다.
6. 최신성이 없을 때 위험 정책을 적용합니다. 오프라인 결정을 비체계적인 추측이 아닌 명시적인 검증기 정책으로 만들어야 합니다.
7. 추적 데이터를 적극적으로 삭제합니다. 더 이상 필요하지 않은 경우 거래별 고유 요소와 타임스탬프를 폐기합니다; 이동 이력을 재구성할 수 있는 로그를 보관하지 마십시오.

이것이 진지한 발급기관 귀환 호출 없는 아키텍처의 모습입니다 — 계층화되고, 프라이버시 보호적이며, 암호학적으로 로컬이고, 오프라인 현실에 대해 운영적으로 솔직합니다.

설계 단계에서 금지되어야 할 세 가지 패턴

성숙한 미래의 IDP 생태계는 이것들을 최적화 선택이 아닌 아키텍처 실패로 취급해야 합니다:

• 매 제시마다 발급기관 콜백 의무화. AAMVA의 자체 프라이버시 지침이 이것이 왜 해로운지 설명합니다.
• 운전 자격증명을 일상적인 로그인으로 사용. NIST는 일상적인 인증에 신원 정보가 담긴 자격증명을 반복 제시하는 것에 대해 명시적으로 경고합니다.
• 제시 이력을 재구성할 수 있는 식별자, 타임스탬프, 로그 보존. EUDI와 AAMVA 모두 그 반대를 요구합니다.

핵심 논거를 한 문장으로

즉각적인 검증이 발급기관 측 감시를 위한 허가가 되어서는 안 됩니다.

미래의 IDP는 다음을 수행할 수 있어야 합니다:

• 진위성을 로컬에서 증명.
• 소지를 로컬에서 증명.
• 최신성을 프라이버시 보호 방식으로 확인.
• 오프라인 현실을 수용.
• 완벽한 정보가 없을 때도 원활하게 기능.

이것이 시스템을 약하게 만들지 않습니다. 오히려 대규모로 배포할 가치 있게 만듭니다.

운전 자격증명이 누가, 무엇을, 어디서, 언제 제시했는지 기록하는 도구가 되는 순간, 그것은 종이 문서의 더 안전한 버전이기를 멈춥니다. 관찰을 위한 인프라가 됩니다.

그것이 바로 미래의 IDP가 되기를 거부해야 하는 것입니다.

자주 묻는 질문

“발급기관 귀환 호출 인증”이란 무엇입니까?
검증기가 자격증명을 검증하기 위해 발급기관에 실시간으로 연락하는 모든 설계를 말합니다. 진위성과 폐기 문제를 동시에 해결하지만, 발급기관이 모든 제시 이벤트를 관찰할 수 있게 됩니다.

ISO/IEC 18013-5는 온라인 발급기관 연락을 요구합니까?
아닙니다. AAMVA는 ISO/IEC 18013-5가 기기 검색 지원을 요구하며 서버 검색은 선택적으로만 허용한다고 확인합니다.

발급기관에 연락하지 않고 폐기가 어떻게 작동할 수 있습니까?
단기 유효 자격증명, 증명 상태 목록, 또는 증명 폐기 목록을 통해 가능합니다 — 이상적으로는 신뢰 당사자가 사용자 제시와 별도로 상태 데이터를 다운로드하는 방식으로.

상태 목록에서 “그룹 프라이버시”가 중요한 이유는 무엇입니까?
상태 목록이 너무 작거나 인덱스가 예측 가능하면, 상태 요청이 방금 제시된 특정 자격증명을 노출할 수 있습니다. 무작위 인덱스와 큰 목록이 이를 방지합니다.

오프라인 검증이 실제로 실용적입니까?
그렇습니다 — AAMVA와 EUDI를 포함한 표준 기구들이 명시적으로 이를 요구합니다. 트레이드오프는 완벽한 실시간 최신성이 완벽한 오프라인 운영과 양립할 수 없다는 것이므로, 최신성은 하드 의존성이 아닌 정책 결정이 되어야 합니다.