경찰, 렌터카 데스크, 고용주, 보험사: 왜 그들은 동일한 데이터를 봐서는 안 되는가

미래의 국제운전면허증(IDP) 설계에서 가장 큰 실수는 모든 검증자를 동일한 검증자로 취급하는 것이다. 경찰관, 렌터카 데스크, 고용주, 보험사는 각각 다른 질문을 한다 — 따라서 동일한 답변을 받아서는 안 된다.

한 명의 운전자. 하나의 근본적인 운전 권리. 하나의 전자지갑. 그러나 네 가지 매우 다른 검증자:

도로변의 경찰관
차량 인수 시의 렌터카 데스크
차량 운행 자격을 확인하는 고용주
보험금 청구를 검토하는 보험사

미래의 IDP가 네 곳 모두에 동일한 데이터를 보여준다면, 그 시스템은 이미 실패한 것이다. 자격증명이 안전하지 않기 때문이 아니라, 정보 공개 모델이 지나치게 단순하기 때문이다.

표준화 커뮤니티는 이미 그 단순한 모델에서 벗어나는 방향으로 나아가고 있다. W3C의 검증 가능한 자격증명 연구는 발행자, 보유자, 검증자를 둘러싼 생태계를 기술하며, 고용주와 웹사이트를 검증자의 예시로 들고 있다. EU의 모바일 운전면허증 연구는 이미 도로변 확인과 렌터카를 별개의 검증 시나리오로 취급하며, 렌터카를 위한 원격 사전 공유와 경찰을 위한 대면 확인을 포함한다. 아키텍처는 이미 여러 검증자 유형을 위해 설계되어 있다. 실수는 마치 한 가지 유형만 존재하는 것처럼 사용자 경험을 설계하는 것이다.

물리적 카드가 우리를 잘못된 사고방식으로 훈련시킨 이유

물리적 면허증은 우리를 ‘모든 것을 보여주는’ 방식으로 훈련시켰다. 카드를 건네주면 상대방은 카드에 적힌 내용을 본다. 그것이 상호작용의 전부다.

그 방식은 종이 세계에서는 허용 가능하다. 대안이 없기 때문이다. 하지만 디지털 세계에서는 허용될 수 없다.

W3C VC 데이터 모델 2.0은 직접적으로 명시한다: 운전면허증에는 신분증 번호, 키, 몸무게, 생년월일, 집 주소가 포함될 수 있지만, 특정 거래에 필요한 정보보다 훨씬 많을 수 있다. 현행 표준의 핵심 사항:

W3C 모범 사례: 선택적 공개를 지원하고, 꼭 필요한 정보만 요청할 것
EU 데이터 보호 지침: 처리는 명시된 목적으로 제한되어야 하며, 처리되는 데이터는 필요하고 비례적이어야 함
미래 IDP의 첫 번째 원칙: 동일한 자격증명이 동일한 열람 권리를 의미하지 않는다

올바른 모델은 정책 기반 공개다

진지한 아키텍처를 원한다면, 올바른 모델은 디지털 카드 제시보다는 속성 기반 접근 제어에 가깝다.

NIST SP 800-205는 접근 제어 결정을 주체, 객체, 요청된 작업, 환경 조건과 관련된 속성을 정책에 따라 평가하는 것으로 정의한다. 이것이 바로 미래의 IDP에 적합한 구조다:

주체: 운전자
객체: 요청된 데이터 필드
행위: 추상적으로 “면허증을 보는 것”이 아니라, “도로변에서 B종 운전 자격 확인” 또는 “예약에 대한 렌터카 자격 확인”과 같이 구체적인 것
환경: 도로변, 렌터카 데스크, 원격 사전 확인, 차량 운행 등록, 사고 후 보험금 청구 검토는 서로 다른 환경이며, 서로 다른 결정으로 이어져야 한다

NIST는 또한 속성 시스템에는 세분성, 거버넌스, 속성의 축소·그룹화·최소화를 위한 메커니즘이 필요하다고 지적한다.

따라서 미래의 IDP는 이렇게 묻지 않아야 한다: 이 검증자가 면허증을 열람할 수 있는가? 대신 이렇게 물어야 한다: 이 검증자는 어떤 의도된 용도로, 어떤 환경에서, 어떤 보유 규칙 하에 어떤 항목을 수신할 수 있는가?

검증자는 무언가를 요청하기 전에 자신의 신원을 밝혀야 한다

미래의 IDP는 전자지갑이 데이터를 보여주는 것으로 시작해서는 안 된다. 검증자가 자신이 누구인지를 증명하는 것으로 시작해야 한다.

EUDI 아키텍처는 이 점을 명확히 한다. 신뢰 당사자는 반드시:

요청하려는 속성과 그 목적을 등록해야 한다
접근 인증서를 발급받아야 한다
공개 전에 전자지갑에 인증해야 한다
등록 정보가 있는 경우, 등록된 범위에 따라 검토를 받아야 한다

그러면 사용자는 누가 요청하는지, 무엇을 요청하는지, 해당 요청이 등록된 범위 내에 있는지를 확인할 수 있다.

ETSI의 현행 전자지갑-신뢰 당사자 인증서 연구는 이를 더욱 구체화한다. 전자지갑 신뢰 당사자 등록 인증서는 신뢰 당사자의 의도된 용도와 요청 등록 속성을 기술할 수 있다. 관련 접근 인증서는 요청이 합법적이고 권한 있는 당사자로부터 온 것임을 보장하기 위해 존재한다. ETSI는 또한 다음과 같은 신뢰 당사자 메타데이터를 포함한다:

상호명
지원 URI
의도된 용도
자격 부여 사항
등록부 URI
감독 기관 정보

미래 IDP의 두 번째 원칙: 검증자 신원 확인 없이는 정보 공개 없다.

동의 화면만으로는 충분하지 않은 이유

여기에는 또 다른 실수가 있다: 사용자 승인을 법적 정당성과 동일시하는 것이다.

EUDI 아키텍처는 속성 제시에 대한 사용자 승인이 신뢰 당사자의 개인정보 처리에 대한 합법적 근거로 취급되어서는 안 된다고 명시적으로 밝힌다. 신뢰 당사자는 여전히 자체적인 합법적 근거를 가져야 한다. EUDI는 또한 신뢰 당사자가 법 집행기관이나 다른 정부 기관인 경우를 포함한 모든 사용 사례에서 사용자 승인을 요구한다.

좋은 전자지갑 인터페이스는 도움이 될 수 있지만, 그 자체만으로는 검증자의 과도한 요구를 해결할 수 없다. 규칙은 인터페이스보다 먼저 존재해야 한다.

따라서 미래의 IDP는 다음 두 가지를 모두 필요로 한다:

암호화 기반 검증자 인증으로 요청자 확인
해당 검증자 범주가 요청할 수 있는 사항에 대한 정책 제약

두 가지 모두 없으면 “사용자 선택”은 정책 실패를 개인에게 전가하는 수단이 된다.

검증자 분류 매트릭스

1. 경찰: 사람 전체가 아닌 운전 권리를 확인하라

경찰의 도로변 시나리오는 가장 집중적인 경우다.

EU mDL 매뉴얼은 이를 직접적으로 기술한다: 경찰 또는 기타 당국은 면허 유효성과 차량 운전 자격을 포함하여 필요한 경우 면허증을 확인한다. 사용자 여정에서 담당 경찰관은 QR 코드 기반 절차, 블루투스, Wi-Fi Aware, 또는 NFC를 통해 면허증을 검증한다. 이는 집중된 검증 작업이다:

이 사람이 면허증 보유자인가?
자격증명이 유효한가?
어떤 차량 운전 자격과 제한이 적용되는가?

기본적으로 허용되는 항목:

성명
사진
면허 상태
발급일 및 만료일
면허 종별
운전 관련 제한 사항
발급 기관 및 관할 지역
유효성/상태 결과

기본적으로 허용되지 않는 항목:

자택 주소
도로변 용도에 불필요한 내부 식별자
다른 증명서의 관련 없는 속성
과거 제시 기록
상업적 메타데이터

AAMVA의 구현 지침은 사진에 관한 사항을 강조한다: 사진이 요청되고 다른 정보가 공개되는 경우, 검증자가 데이터를 제시자와 연결할 수 있도록 사진도 공유되어야 한다. 동일한 지침은 또한 이해관계자들이 법률에서 요구하는 경우를 제외하고 mDL 보유자나 mDL 사용을 추적해서는 안 된다고 명시한다.

경찰의 경우는 국가가 모든 것을 수신하는 것이 아니다. 도로변 단속에 필요한 운전 관련 데이터를 국가가 수신하는 것이다. 이는 중요한 차이다.

2. 렌터카 데스크: 자격 확인, 본인 일치 확인, 그리고 불필요한 정보는 배제

렌터카의 경우는 더 복잡하다. 실제로 두 가지 순간이 있기 때문이다: 도착 전 원격 사전 확인, 그리고 직원이나 키오스크가 열쇠를 건네줄 때의 픽업.

EU mDL 매뉴얼은 이미 두 가지를 모두 모델링하고 있다. 렌터카 서비스는 예약 중에 신원 증명과 함께 mDL을 요청하고, 증명을 검증한 후, 나중에 차량 인도 전 픽업 시 대면으로 고객을 확인할 수 있다. 사용자는 대면 또는 원격으로 사전에 렌터카 업체와 mDL을 공유할 수 있다.

렌터카 데스크는 사고를 조사할 필요가 없다. 판단해야 할 것은: 이 예약 및 정책 하에 이 고객에게 차량을 대여할 수 있는가?

원격 사전 확인에 포함되어야 할 항목:

신원 연결
사진 또는 동등한 신원 확인 요소
관련 차량 종별
발급일 및 만료일
현재 유효성
경우에 따라 연령 기준 또는 연령대

픽업 시 확인해야 할 항목:

보유자가 사전 확인을 완료한 동일인인지 여부
현재 유효성
관련 운전 자격

기본적으로 불필요한 항목:

예약 프로필에 이미 연락처 정보가 있는 경우의 전체 자택 주소
연령 초과 여부 또는 연령대로 충분한 경우의 전체 생년월일
관련 없는 신원 속성
예약 증명이 이미 존재하는 경우의 전체 자격증명 반복 재제시

NIST의 현행 mDL 아키텍처는 신뢰 당사자가 DCQL을 사용하여 필요한 속성만 요청하도록 하며, 이것이 자격증명을 단일 단위로 취급하는 것이 아니라 요청을 구조화함으로써 데이터 최소화와 보유자 동의를 지원한다고 명시적으로 밝힌다. AAMVA는 또한 애플리케이션이 요청된 데이터와 검증자가 정보를 보유할 의도가 있는지를 명확하게 보여주어야 한다고 덧붙인다.

3. 고용주: 검증자 범주이지, 완전한 신원 정보로 통하는 입구가 아니다

W3C의 개요는 대학 학위를 확인하는 고용주의 디지털 시스템을 검증자 사례로 사용한다. 이는 고용주 검증이 이미 자격증명 생태계에서 인정된 패턴임을 상기시켜 준다.

고용주 또는 차량 운행 관리자가 합법적으로 알아야 할 사항:

근로자가 현재 특정 차종을 운전할 자격이 있는지 여부
주요 제한 사항이 있는지 여부
운전 자격이 유효한지 여부

이는 실질적인 업무상 필요다. 그러나 그것이 전체 운전 자격증명, 완전한 신원 데이터, 또는 반복적인 제시의 지속적 스트림에 대한 영구적 접근을 자동으로 정당화하지는 않는다.

NIST는 재사용 가능한 식별자를 자주 전송하고 사용자에게 신원 확인 자격증명을 반복적으로 제시하도록 조건화하는 것은 바람직하지 않다고 경고하며, 일상적인 인증은 패스키와 같이 인증 목적으로 설계된 기술에 의존해야 한다고 말한다. NIST는 프라이버시를 더 잘 보호하기 때문에 서버 측 생체 인식 대조보다 로컬 기기 인증을 선호한다.

미래의 IDP는 직장 출입증이 되어서는 안 된다.

고용주 및 차량 운행 관련 사용의 경우, 올바른 패턴은 일반적으로 다음과 같다:

직무 관련 자격 확인
경우에 따라 정기적인 준수 증명
경우에 따라 보유자가 지정된 종별에 대해 유효함을 나타내는 항목
단, 직원이 시스템에 로그인하거나 근무를 시작할 때마다 모든 면허 데이터를 기본적으로 이전하는 것은 안 됨

차량 운행 준수 관리는 별도의 신뢰 당사자 범주이며, 별도의 의도된 용도와 별도의 공개 프로필을 가진다.

4. 보험사: 보험금 청구는 지속적 열람 권한이 아니다

보험 사례는 종종 현실적이다. EU mDL 사용 사례 자료에서 보험사는 렌터카 시나리오에 간접적으로 등장한다: 보험사는 렌터카 업체에게 차를 빌리는 사람이 운전 권리가 있는지 확인하도록 요구한다. 보험은 이미 운전 확인 절차에 영향을 미친다.

그러나 그것이 보험사가 경찰과 동일한 데이터를 수신해야 하거나, 자격증명에 대한 영구적인 접근 권한을 가져야 한다는 의미는 아니다.

미래의 IDP는 보험사를 별도의 의도된 용도를 가진 별도의 검증자 범주로 취급해야 한다:

언더라이팅
렌터카 위험 검증
사고 후 보험금 청구 처리
사기 검토

이것들은 동일한 목적이 아니다. EU 데이터 보호 원칙 하에서, 개인정보는 명시된 목적을 위해 수집되어야 하며 해당 목적에 필요하고 비례적인 것으로 제한되어야 한다. W3C의 VC 지침도 기술적으로 동일한 결론에 도달한다: 검증자는 꼭 필요한 것만 요청해야 한다.

합법적이고 사건별 공개의 예시:

해당 시점에 면허가 유효했다는 증명
관련 차량 운전 자격 증명
청구에 필요한 경우의 신원 연결 증명
청구별 공개

기본적으로 허용되지 않는 항목:

기반 자격증명에 대한 지속적 접근
고객이 보험사와 상호작용할 때마다 반복되는 일반 검증
운전 자격증명을 로그인 토큰으로 사용
관련 없는 속성 수집

운전 자격증명은 모니터링 구독이 아니다. 그리고 조용히 그렇게 되어서도 안 된다.

중간 매개자가 가시적이어야 하는 이유

실제 시장에는 중간 매개자가 존재한다. 렌터카 플랫폼, 차량 관리 업체, 고용주 인사 시스템, 보험금 청구 처리 업체는 종종 제3자를 통해 운영된다.

EUDI 아키텍처는 다음을 통해 이 문제를 처리한다:

중간 매개자를 신뢰 당사자로 취급
등록 의무화
중개된 신뢰 당사자를 위해 요청되는 속성의 등록 의무화
중간 매개자와 최종 신뢰 당사자 모두를 사용자에게 표시
중간 매개자가 거래 내용에 관한 데이터를 저장하는 것 금지

미래의 IDP는 사용자가 렌터카 업체에 공개한다고 믿지만, 실제로는 보이지 않는 검증 브로커, 분석 처리업체, 보험금 청구 공급업체 체인에 공개되는 패턴을 절대 허용해서는 안 된다.

ETSI가 여기서 도움이 된다. 전자지갑 신뢰 당사자 인증서 모델은 지원 URI, 의도된 용도, 등록부 URI, 감독 기관 메타데이터를 포함한다. 이것이 바로 사용자가 요청의 실제 상대방이 누구인지, 삭제나 정정을 원할 때 어디로 가야 하는지를 이해하는 데 필요한 기계 가독성 인프라의 유형이다.

보유는 접근 제어의 일부다

선택적 공개에 관한 대부분의 논의는 너무 일찍 끝난다. 무엇이 공개되는지에 집중한다. 그 후 얼마나 오래 남아있는지에는 충분히 집중하지 않는다.

현행 지침은 이미 수렴하고 있다:

AAMVA: 전자지갑은 보유자에게 어떤 데이터가 요청되었는지, 검증자가 정보를 보유할 의도가 있는지를 명확히 알려야 한다; 이해관계자들은 법률에서 요구하는 경우를 제외하고 보유자나 mDL 사용을 추적해서는 안 된다
W3C: 보유자 소프트웨어는 과도한 요청을 식별할 수 있도록 검증자와 공유된 정보의 로그를 제공해야 한다
EUDI: 사용자는 거래 로그에 접근하고, 의심스러운 요청을 신고하고, 삭제를 요청할 수 있어야 한다

보유 등급은 공개 정책 자체의 일부여야 한다: