디지털 자격증명 API (2026): Chrome 및 Safari 정식 지원 현황

마지막 업데이트: 2026년 3월 26일

주요 브라우저의 디지털 자격증명 API(Digital Credentials API) 지원 현황을 빠르게 살펴보겠습니다.

디지털 자격증명 분야는 빠르게 변화하고 있습니다. 주요 개발 사항과 전망을 정리해 드립니다.

Want to experience digital credentials in action?

Try Digital Credentials

2025년 10월 이후 무엇이 바뀌었나요?

• 프로토콜 거버넌스 변화: W3C FedID WG는 TPAC(2025년 11월)에서 개방형 프로토콜 레지스트리를 폐지하고, 이제 스펙에 OpenID4VP, OpenID4VCI, ISO 18013-7 Annex C 등 지원 프로토콜을 직접 하드코딩합니다. 이 API는 더 이상 "단순 파이프(dumb pipe)"가 아닙니다.
• 발급 기능 도입: Chrome 143은 navigator.credentials.create()를 통한 자격증명 발급 오리진 트라이얼을 시작하여 API 영역을 제출 전용에서 확장했습니다.
• Firefox 구현: 부정적인 표준 입장에도 불구하고, Mozilla는 Firefox 149에 기본 DC API 코드를 탑재하고 UX 작업을 진행 중입니다.
• EU 조건부 의무화: EUDI 아키텍처 참조 프레임워크(Topic F)는 이제 모든 회원국 지갑에 DC API 지원을 조건부로 요구합니다.
• 실제 도입 사례: 캘리포니아 DMV가 OpenCred 플랫폼에 DC API 지원을 추가했습니다(2026년 2월).

디지털 자격증명(Digital Credentials)은 현재 신원 인증 분야에서 가장 뜨거운 주제입니다. 우리의 삶이 디지털 영역과 점점 더 긴밀하게 연결됨에 따라, 안전하고 사용자 중심적이며 개인정보를 보호하는 방식으로 온라인에서 신원과 자격을 증명하는 것이 그 어느 때보다 중요해졌습니다. 기존 방식들은 노후화되었고, 더 강력한 솔루션에 대한 요구가 뚜렷합니다.

이 글에서는 웹에서 신원 정보와 상호작용하는 방식을 재편할 중요한 발전인 디지털 자격증명 API의 현재 상태에 대해 이야기해 보겠습니다. 기본 메커니즘, 지원 프로토콜, 현재 브라우저 도입 현황을 살펴보고, 이 빠르게 진화하는 환경을 탐색하는 신뢰 당사자(Relying Party)와 지갑 발급자(Issuer)를 위한 권장 사항을 제안합니다.

신뢰할 수 있고 안전하게 신원을 증명하는 것은 오랫동안 웹 아키텍처의 끊임없는 과제였습니다. 인터넷은 전례 없는 연결성과 정보 교환을 촉진했지만, 동시에 허위 정보와 사기의 새로운 통로를 열기도 했습니다.

일부 국가에서는 기존의 신뢰 관계를 활용하여 온라인 식별 서비스를 개발한 초기 은행 컨소시엄 주도로 해결책이 등장했습니다. 정부 또한 국가 디지털 신원 지갑과 서비스를 의무화하거나 제공하며 개입했습니다. 그러나 이러한 솔루션은 종종 고립되어 있고, 지리적으로 제한적이며, 보편적으로 상호 운용되지 않는 경우가 많았습니다.

많은 지역에서 신원 검증을 위한 대안은 전통적으로 마찰이 큰 과정을 수반했습니다. 예를 들어 우체국을 통한 대면 확인은 상당한 지연과 불편을 초래합니다. 영상 통화와 문서 업로드의 결합이 더 디지털화된 대안이 되었고, 최근에는 자동화된 문서 스캔과 생체 감지(liveness check)가 부상했습니다. 이러한 발전에도 불구하고, 이 방법들은 여전히 단점이 큽니다. 시간이 많이 걸리고, 인적 오류나 편향에 취약하며, 정교한 위조에 뚫릴 수 있다는 점이 자주 노출되었습니다.

딥페이크, 고급 AI 기반 사칭 기술, 점점 더 정교해지는 피싱 공격의 등장으로 도전 과제는 극적으로 확대되고 있습니다. 이러한 기술은 매우 사실적이지만 완전히 조작된 영상, 음성, 문서 증거를 생성할 수 있어, 기존 시스템은 물론 AI 기반 검증 도구조차 진짜 사용자와 사기꾼을 구별하기 어렵게 만듭니다. 합성 신원을 생성하거나 생체 데이터를 조작하여 확인을 우회할 수 있는 가능성은 심각한 위협이며, 특히 금융 기관이나 강력한 고객 확인(KYC) 절차가 필요한 서비스에는 더욱 그렇습니다. 이러한 위협 환경의 고조는 더 안전하고 암호학적으로 검증 가능한 온라인 신원 및 확인 메커니즘의 시급성을 강조합니다.

Want to experience digital credentials in action?

Try Digital Credentials

디지털 자격증명의 작동 원리를 이해하려면 관련된 핵심 참여자와 기능을 가능하게 하는 기술 계층을 살펴봐야 합니다.

디지털 자격증명의 핵심 개념, 특히 새로운 웹 API의 맥락에서는 3자 모델을 중심으로 돌아갑니다.

1. 발급자 (Issuer): 주체에 대한 특정 정보에 대한 권한을 가지며 해당 정보를 증명하는 디지털 자격증명을 발급할 수 있는 개체(예: 정부, 대학, 고용주).
2. 보유자 (Holder): 발급자로부터 자격증명을 받아 디지털 지갑에 저장하는 정보의 주체(즉, 사용자). 보유자는 자격증명의 어떤 정보를 언제 공유할지 제어합니다.
3. 검증자 (Verifier) 또는 신뢰 당사자(Relying Party): 서비스나 리소스에 대한 접근 권한을 부여하기 위해 보유자에 대한 특정 정보를 확인해야 하는 개체(예: 웹사이트, 온라인 서비스). 검증자는 보유자에게 필요한 정보를 요청합니다.

이 3자 모델이 중요한 이유는 사용자(보유자)에게 자신의 데이터에 대한 통제권을 부여하기 때문입니다. 데이터가 중앙에 저장되거나 사용자 개입 없이 당사자 간에 공유되던 기존 신원 시스템과 달리, 이 모델은 사용자 동의와 **선택적 공개(Selective Disclosure)**를 강조합니다. 보유자는 전체 자격증명을 드러내는 대신 특정 거래에 필요한 정보 조각만 공유하기로 결정할 수 있습니다.

이 시스템의 근본적인 측면은 암호화 키 쌍의 개입입니다. 발급자는 자격증명에 디지털 서명을 하여 진본성과 무결성을 보장합니다. 보유자는 디지털 지갑(보통 기기 하드웨어로 보호됨) 내에 안전하게 보관된 개인 키를 사용하여 자격증명에 대한 제어 권한을 증명하고 검증자에게 제출을 승인합니다. 이 과정에는 일반적으로 검증자가 챌린지(임의의 데이터 조각)를 제시하고, 보유자의 지갑이 자격증명과 연관된 개인 키를 사용하여 이에 서명하는 방식이 포함됩니다. 검증자는 대응하는 공개 키를 사용하여 서명을 확인하고 제출을 인증할 수 있습니다.

이 설명은 프로토콜 중립적이며, 발급, 보유, 암호화 챌린지를 통한 검증의 핵심 원칙은 다양한 기반 기술 전반에 공통적으로 적용됩니다.

이 글에서는 디지털 자격증명의 검증과 선택적 공개 원칙에 집중합니다. 이를 통해 사용자는 전체 원본 문서를 공개하지 않고도 특정 속성(예: "만 18세 이상임", "유효한 운전면허증 보유")을 증명할 수 있습니다. 디지털 자격증명을 위한 기반 시스템은 적격 전자 서명(QES)이나 원격 서명 기능(법적 구속력이 있는 서명을 위한 EU 디지털 신원 지갑과 같은 포괄적인 솔루션에서 볼 수 있음)과 같은 기능을 지원할 수 있지만, 여기서는(특히 디지털 자격증명 API의 경우) 광범위한 서명 기능보다는 온라인 상호작용을 위한 신원 어설션(assertion) 및 속성 검증에 초점을 맞춥니다.

디지털 자격증명의 기능을 이해하려면 계층 모델을 시각화하는 것이 도움이 됩니다. 각 계층은 데이터 형식 자체에서부터 웹 브라우저에서 사용자에게 표시되는 방식까지 생태계의 서로 다른 측면을 다룹니다. 이 글은 주로 프레젠테이션 계층(Presentation Layer)에서 작동하는 디지털 자격증명 API에 초점을 맞춥니다.

핵심 용어:

• 디지털 자격증명 (Digital credential): 기계가 읽을 수 있는 모든 자격증명(바코드가 있는 PDF, ISO mDL, W3C VC, SD-JWT 등). "디지털"이라는 단어 자체는 암호학적 검증 가능성을 의미하지 않습니다.
• 검증 가능한 자격증명 (Verifiable Credential, VC): W3C VC 데이터 모델에 의해 정의된 디지털 자격증명의 한 종류입니다. 변조 방지 및 암호학적 증명을 추가하며, 항상 '발급자 → 보유자 → 검증자'의 3자 세계에 존재합니다.
• 검증 가능한 자격증명 API (VC API): 백엔드 시스템(발급자, 지갑, 검증자) 간에 VC를 발급, 저장, 제출 및 검증하기 위한 REST/HTTP 서비스 인터페이스입니다.
• 디지털 자격증명 API (DC API): 웹사이트가 사용자의 기기 측 지갑에 개인정보를 보호하는 방식으로 지원되는 디지털 자격증명(VC, ISO mDoc, SD-JWT 등) 제출을 요청할 수 있게 해주는 브라우저/운영체제 API(JavaScript + 네이티브 연동)입니다.

VC는 데이터 모델, VC API는 백엔드 스펙, DC API는 웹에 자격증명을 제시하는 프론트엔드 구현이라고 생각하면 됩니다. 1계층(데이터 모델 계층) 위의 모든 것은 형식에 구애받지 않지만(agnostic), 그 아래는 자격증명 형식에 따라 달라집니다.

End-to-end 흐름 (예: 온라인 연령 확인):

다음 다이어그램은 이러한 계층이 실제 시나리오에서 어떻게 함께 작동하는지 보여줍니다.

데이터는 VC이고, 웹상의 전송은 DC API, 그 아래의 교환 프로토콜은 OpenID4VP이며, 서버 측 확인은 VC API를 사용한다는 점에 주목하세요.

구분이 존재하는 이유:

• 상호 운용 가능한 데이터 모델 (암호화 증명, 선택적 공개): VC 데이터 모델(및 기타 형식)로 해결.
• 백엔드 시스템을 위한 표준 REST 엔드포인트: VC API로 해결.
• 개인정보를 보호하는 지갑 ↔ 웹사이트 핸드셰이크: DC API로 해결.
• 다양한 신뢰 수준 / 문서 유형 (정부 ID vs. 과정 수료증): DC API 하단에서 올바른 형식(고보증 ID를 위한 ISO mDoc, 일반 클레임을 위한 W3C VC)을 사용하여 해결.

핵심 요약:

1. "디지털 자격증명"은 포괄적인 용어입니다.
2. 검증 가능한 자격증명(VC)은 암호학적 검증 기능이 내장된 디지털 자격증명의 한 종류입니다.
3. VC API는 VC의 수명 주기 작업을 위한 서버 간 배관(plumbing)입니다.
4. 디지털 자격증명 API는 자격증명이 어떤 구체적인 형식이든 관계없이 웹 앱으로 원활하게 흐를 수 있게 해주는 브라우저-지갑 간의 다리입니다.
5. 이 세 가지 요소는 경쟁 관계가 아니라 상호 보완적입니다. 동일한 스택의 서로 다른 계층에 위치하며 함께 개방형 웹에서 안전한 사용자 중심 신원을 가능하게 합니다.

참여자와 디지털 자격증명의 전반적인 계층 구조를 살펴보았으니, 이제 프레젠테이션 계층, 특히 디지털 자격증명 API와 그 현재 상태에 대해 더 깊이 알아보겠습니다.

프레젠테이션 계층의 핵심 구성 요소인 디지털 자격증명 API는 웹사이트가 사용자의 디지털 지갑에서 디지털 신원 정보를 요청하고 수신할 수 있는 안전하고 표준화된 방법을 제공하기 위해 개발 중인 웹 표준입니다. 이 작업은 2025년 4월 FedID 커뮤니티 그룹에서 이관되어 현재 주로 W3C의 연합 신원 워킹 그룹(FedID WG) 내에서 진행되고 있습니다. 공식 초안 사양은 https://w3c-fedid.github.io/digital-credentials/에서 확인할 수 있습니다.

2025년 10월 현재, 이 API는 Chrome 141(2025년 9월 30일) 및 Safari 26(2025년 9월 15일)의 안정 버전에서 출시되었습니다. Chrome의 구현은 OpenID4VP와 ISO 18013-7 Annex C를 모두 지원하는 반면, Safari는 org-iso-mdoc 프로토콜만 독점적으로 지원합니다.

중요 (2026년 3월 업데이트): API와 프로토콜의 관계가 근본적으로 변경되었습니다. 2025년 11월 TPAC에서 W3C FedID WG는 개방형 프로토콜 레지스트리를 폐지하고 대신 스펙에 지원되는 프로토콜 목록을 직접 하드코딩하기로 합의했습니다. 목록은 다음과 같습니다: openid4vp-v1-unsigned, openid4vp-v1-signed, openid4vp-v1-multisigned, org-iso-mdoc (제출용), 그리고 openid4vci-v1 (발급용). 사용자 에이전트는 목록에 없는 프로토콜을 거부해야 합니다. 이는 워킹 그룹을 향후 프로토콜 추가에 대한 사실상의 문지기로 만듭니다. 이는 API를 통해 흐르는 모든 것에 대한 전체적인 보안 및 개인정보 보호 검토를 가능하게 하기 위한 의도적인 절충안입니다(현재 작업 초안 참조).

스펙은 이제 navigator.credentials.create()를 통한 자격증명 발급도 다룹니다. Chrome 143은 이를 위한 오리진 트라이얼을 시작하여 웹사이트가 OpenID4VCI를 사용하여 지갑 프로비저닝 흐름을 트리거할 수 있게 했습니다. 그러나 악의적인 지갑 앱이 발급 사전 승인 코드를 가로챌 수 있는 지갑 선택 바인딩 취약점은 여전히 해결되지 않은 우려 사항으로 남아 있습니다. 정부 발급자들은 이 문제가 해결될 때까지 브라우저 매개 발급을 채택하지 않겠다는 입장을 밝혔습니다.

Chrome은 자격증명 관리자(Credential Manager) 시스템을 통해 Android에서 기본적으로 제출을 지원하며, 데스크톱에서는 CTAP/BLE 기반 QR 핸드오프를 통해 크로스 디바이스 디지털 자격증명 API를 지원합니다.

이 API는 기존 자격증명 관리 API(Credential Management API)를 확장하여 navigator.credentials.get()을 통해 디지털 자격증명 요청을 가능하게 합니다. W3C FedID WG 디지털 자격증명 설명서(Explainer)에 따르면, API는 이전에 제안된 navigator.identity 대신 이 확립된 인터페이스를 사용하는 것으로 되돌아갔습니다. 웹사이트는 디지털 자격증명에 대한 특정 매개변수와 함께 navigator.credentials.get()을 호출하여 자격증명을 요청합니다.

다음은 웹사이트가 OpenID4VP를 사용하여 자격증명을 요청하기 위해 API를 호출하는 예시입니다.

async function requestCredential() {
    // 디지털 자격증명 API 지원 여부 확인
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // 이 매개변수들은 일반적으로 백엔드에서 가져옵니다.
            // 여기서는 프로토콜 확장성 설명을 위해 정적으로 정의했습니다.
            const oid4vp = {
                protocol: "oid4vp", // 지갑에 대한 OpenID4VP 요청 예시. // https://github.com/openid/OpenID4VP/issues/125 기반
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        // 프레젠테이션 교환(Presentation Exchange) 요청, 간결함을 위해 생략
                    },
                },
            };
 
            // Abort Controller 생성
            const controller = new AbortController();
 
            // 백엔드에서 받은 프레젠테이션 요청을 사용하여 디지털 자격증명 API 호출
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // 암호화된 응답을 복호화 및 검증하기 위해 백엔드로 전송
            // 간결함을 위해 생략
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // 폴백(fallback) 시나리오, 예시용
        alert("이 브라우저에서는 디지털 자격증명 API가 지원되지 않습니다.");
    }
}

이 예시는 여기에서 가져왔습니다.

디지털 자격증명 API는 본질적으로 안전한 래퍼(wrapper) 또는 중개자 역할을 합니다. 브라우저가 신원 정보 요청을 중재하고, 기본 운영 체제의 기능을 활용하여 요청과 일치하는 사용 가능한 지갑 및 자격증명을 검색할 수 있게 합니다. 그러면 브라우저와 OS는 자격증명 선택 및 릴리스 승인을 위한 일관된 사용자 인터페이스를 제공하여, 사용자 동의를 보장하고 웹사이트가 민감한 데이터에 몰래 접근하는 것을 방지함으로써 보안과 개인정보 보호를 강화합니다. 응답에 포함된 실제 자격증명 데이터는 브라우저 자체에 대해 불투명(암호화)하게 처리되며, 복호화 및 해석은 신뢰 당사자와 지갑/보유자가 처리합니다.

디지털 자격증명 API는 원래 모든 프로토콜이 등록할 수 있는 개방형 레지스트리를 갖춘 "단순 파이프(dumb pipe)"로서 완전히 프로토콜 중립적으로 설계되었습니다. 그러나 2026년 1월 기준으로 스펙은 지원하는 프로토콜을 명시적으로 지정하고 있으며, 사용자 에이전트는 목록에 없는 프로토콜을 거부할 것으로 예상됩니다. 현재 스펙에 하드코딩된 두 가지 주요 프로토콜 제품군은 org.iso.mdoc(ISO 18013-5 및 그 확장인 ISO 18013-7 "Annex C"에서 파생됨)과 OpenID Foundation의 OpenID4VP(OpenID for Verifiable Presentations) 및 OpenID4VCI(OpenID for Verifiable Credential Issuance) 사양입니다.

• 기원 및 표준화: org.iso.mdoc은 국제표준화기구(ISO)와 국제전기기술위원회(IEC)에서 표준화한 모바일 문서, 주로 모바일 운전면허증(mDL)의 데이터 형식 및 상호작용 모델을 말합니다. 기본 표준인 ISO/IEC 18013-5는 NFC, 블루투스, QR 코드와 같은 기술을 사용하는 대면(근거리) 제출을 위한 mDL 애플리케이션, 데이터 구조 및 프로토콜을 정의합니다. ISO/IEC 18013-7은 이를 확장하여 mDL의 온라인/원격 제출을 가능하게 합니다. 프로토콜 문자열 "org.iso.mdoc"은 디지털 자격증명 API와 같은 API와 함께 사용하기 위해 ISO/IEC TS 18013-7(Annex C)에 구체적으로 정의되어 있습니다.

• 데이터 모델: mdoc은 압축성과 효율성을 위해 CBOR(Concise Binary Object Representation)에 기반한 엄격하게 정의된 데이터 구조를 가집니다. 일반적인 운전면허 속성에 대한 네임스페이스와 데이터 요소를 지정하며 발급자 인증, 기기 바인딩, 보유자 인증(인물 사진 등), 세션 암호화, 선택적 공개를 포함한 강력한 암호화 보안 기능을 지원합니다.

• 주요 사용 사례: 주로 운전면허증 및 주민등록증과 같은 정부 발급 신분증입니다. 대면(예: 교통 단속, 제한된 물품에 대한 연령 확인) 및 온라인(예: 정부 서비스 접속, 은행 계좌 개설을 위한 원격 신원 확인) 모두에서 높은 보증 수준이 필요한 시나리오를 위해 설계되었습니다.

• 기원 및 표준화: OpenID4VP(제출용)와 OpenID4VCI(발급용)는 OpenID Foundation에서 개발한 사양입니다. 이들은 검증 가능한 자격증명의 교환을 지원하기 위해 OAuth 2.0을 확장합니다. 이는 정부뿐만 아니라 다양한 자격증명 유형에 대한 광범위한 상호 운용성을 목표로 하는 개방형 표준입니다. 2025년 초 기준으로 OpenID4VP는 고급 초안 단계(예: 4월 기준 draft 28)에 있습니다. OpenID4VCI 또한 성숙해지고 있습니다.
• 데이터 모델: OpenID4VP/VCI는 자격증명 형식에 구애받지 않도록 설계되었습니다. JSON/JSON-LD 또는 JWT 형식의 W3C 검증 가능한 자격증명(VC), mdoc, SD-JWT 및 기타 형식을 전송할 수 있습니다. 상호작용 모델은 검증자(RP)의 인증 요청(Authorization Request)과 vp_token(검증 가능한 프레젠테이션 토큰)을 포함하는 보유자 지갑의 응답을 포함합니다. 선택적 공개는 일반적으로 Presentation Exchange(DIF PE) 또는 DCQL(Digital Credentials Query Language)과 같은 쿼리 언어를 사용하여 관리됩니다.
• 주요 사용 사례: 신원 확인, 자격 증명 제공(예: 학위, 전문 자격증), 멤버십 증명(attestations) 등 광범위한 애플리케이션을 포함합니다. 신뢰 당사자가 다양한 발급자의 클레임을 검증해야 하는 온라인 상호작용에 매우 적합합니다.

이들이 항상 상호 배타적인 것은 아니라는 점을 인식하는 것이 중요합니다. 예를 들어 OpenID4VP는 [org.iso.mdoc]을 요청하고 전송하는 데 사용될 수 있습니다. 선택은 종종 특정 사용 사례, 자격증명 유형, 생태계 참여자에 따라 달라집니다.

유럽 연합 디지털 신원(EUDI) 지갑은 모든 EU 시민과 거주자에게 신분증 및 증명을 위한 안전한 디지털 지갑을 제공하는 것을 목표로 하는 주요 이니셔티브입니다. EUDI 지갑 아키텍처 및 참조 프레임워크는 제출 및 발급 흐름을 위해 OpenID4VP 및 OpenID4VCI를 활용하여 mdoc(특히 모바일 운전면허증용)과 W3C 검증 가능한 자격증명을 모두 지원할 계획을 명시적으로 밝히고 있습니다. 참조 구현에는 mDoc 전송을 위한 OpenID4VP 지원과 mDoc 및 SD-JWT-VC 형식의 PID 및 mDL 발급을 위한 OpenID4VCI 지원이 포함됩니다. 이러한 대규모 프로젝트의 이중 지원은 두 프로토콜 제품군의 중요성을 강조합니다.

2026년 3월 업데이트: 디지털 자격증명 API에 대한 EU의 약속이 더욱 구체화되었습니다. EUDI 아키텍처 참조 프레임워크(ARF) Topic F는 이제 EUDI 지갑 유닛 및 신뢰 당사자가 원격 제출 및 증명서 발급 흐름을 위해 DC API를 지원할 것을 조건부로 의무화합니다. 조건에는 DC API가 W3C 권고안(Recommendation) 상태에 도달하고 기능, 브라우저/OS 중립성, 개인정보 보호 및 서비스 거부 공격 보호에 대한 기대치를 충족하는 것이 포함됩니다. 유럽 지갑 컨소시엄(EWC)은 적합성 테스트 프로그램에 DC API 테스트 사례를 통합했으며, NOBID 컨소시엄은 OpenID4VP(DC API가 현재 전송하는 것과 동일한 프로토콜)를 사용하여 결제 파일럿을 완료했습니다.

그러나 이러한 방향에 비판이 없는 것은 아닙니다. 일부 관측통들은 "미국 빅테크" 기업의 영향을 많이 받은 디지털 자격증명 API가 최종 EUDI 지갑 사양에 깊이 통합될 수 있다고 지적합니다. 이 GitHub 토론과 같은 커뮤니티 포럼에서 논의된 바와 같이, 중요한 EU 인프라에 대한 비 EU 기업의 잠재적 영향력에 대한 우려가 제기되었습니다. 별도로, 스펙에 ISO 18013-7 참조를 하드코딩하기로 한 결정은 Ping Identity의 이의 제기를 불러왔습니다. 유료 사양을 규범적으로 참조하는 것은 개방형 웹 원칙과 상충된다는 주장이며, 이는 스펙이 후보 권고안(Candidate Recommendation)으로 전환될 때 공식적인 이의 제기로 표면화될 수 있습니다.

디지털 자격증명 API의 브라우저 환경은 이제 윤곽이 잡혔으며, Chrome 141과 Safari 26이 2025년 9월에 안정적인 지원을 시작했습니다. 브라우저마다 접근 방식과 지원 수준에 눈에 띄는 차이가 있습니다.

Chrome은 Chrome 141(2025년 9월 30일)에서 디지털 자격증명 API를 출시했습니다. Chrome의 구현은 프로토콜 중립적입니다. OpenID4VP와 ISO 18013-7 Annex C(mdoc 온라인)와 호환됩니다. 데스크톱은 CTAP/BLE 기반 채널(QR 핸드오프)을 통해 모바일 지갑의 크로스 디바이스 제출을 지원하며, 응답은 브라우저에 불투명(opaque)하게 처리됩니다. API 형태는 navigator.credentials.get()으로 이동했으며, 매개변수 이름이 변경되었습니다: providers → requests, request → data.

기능 감지:

if (typeof DigitalCredential !== "undefined") {
    // 디지털 자격증명 API 지원됨
}

Android의 자격증명 관리자(Credential Manager)는 기본적으로 제출을 위한 OpenID4VP와 발급을 위한 OpenID4VCI를 지원하여, Android 앱이 이러한 표준을 사용하여 자격증명 보유자 및 검증자 역할을 할 수 있게 합니다. Google은 지갑 지원이 확대되고 있다고 언급했습니다. Google Wallet이 초기 채택자이며, Samsung Wallet과 1Password도 발표되었습니다.

이전 기사에서 우리는 Apple의 접근 방식이 org.iso.mdoc 프로토콜에 집중함으로써 Google과 달라질 것이라고 예측했습니다. 역사적 맥락에서 우리의 추론은 다음과 같았습니다:

우리가 정확히 예상했듯이, WWDC25에서 이 전략이 확인되었습니다. Safari 26(iOS/iPadOS/macOS)은 2025년 9월 15일에 디지털 자격증명 API 지원과 함께 출시되었으며, 구현이 제출을 위해 org-iso-mdoc 프로토콜(하이픈 연결)을 독점적으로 지원함을 확인했습니다.

이는 WWDC25 세션 웹에서 신원 문서 확인하기(Verify identity documents on the web)에서 자세히 설명되었습니다. 이 API를 사용하면 웹사이트가 Apple 지갑이나 타사 문서 제공 앱에 저장된 운전면허증과 같은 신원 문서에서 검증 가능한 정보를 요청할 수 있습니다.

Apple 구현의 핵심 사항:

• MDOC 전용: API는 ISO/IEC 18013-7 Annex C 표준에 기반한 프로토콜 문자열 "org-iso-mdoc"만을 사용합니다. Safari의 디지털 자격증명 API 구현에는 OpenID4VP에 대한 지원이 없습니다.
• 제출 전용: API는 기존 자격증명의 제출(검증)을 위한 것입니다. Apple 지갑이나 다른 앱으로의 발급은 별도의 브라우저 외 프로세스로 남습니다.
• 사용자 중심 & 보안: 흐름은 사용자 제스처에 의해 시작되며 "부분 요청(partial request)" 메커니즘을 활용합니다. OS가 먼저 샌드박스에서 요청을 파싱하고 유효성을 검사한 후 지갑 애플리케이션으로 전달하여 보안을 강화합니다.
• 앱으로 확장 가능: Apple 지갑 외에도 타사 앱은 새로운 IdentityDocumentServices 프레임워크와 앱 확장을 구현하여 문서 제공자 역할을 할 수 있습니다.
• 크로스 디바이스 지원: Apple이 아닌 플랫폼에서의 크로스 디바이스 제출은 QR 코드 핸드오프 후 근접 통신을 위해 CTAP를 사용합니다. JS 응답은 브라우저에 대해 암호화/불투명 상태로 유지됩니다.

Apple은 신뢰 당사자가 API를 사용하는 방법에 대한 명확한 코드 예시를 제공했습니다.

async function verifyIdentity() {
    try {
        // 서버가 요청 데이터를 생성하고 암호화 서명합니다.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // 요청은 'org-iso-mdoc' 프로토콜을 지정합니다.
        const request = {
            protocol: "org-iso-mdoc",
            // data에는 암호화 서명된 mdoc 요청이 포함됩니다.
            data,
        };
 
        // API는 사용자 제스처 내에서 호출되어야 합니다.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // 지갑에서 받은 암호화된 응답을 복호화 및 검증을 위해 서버로 전송합니다.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // 검증된 세부 정보 표시...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // 오류 처리 (예: 사용자 취소)
    }
}

이 확인은 브라우저 시장의 엇갈린 전략을 확고히 합니다. Chrome이 유연한 OpenID4VP 전송 계층을 기반으로 구축하는 반면, Apple은 ISO mdoc 생태계에 대한 깊은 투자를 활용하여 공식 신분증 문서에 맞춘 고도로 통합되고 안전하지만 유연성은 덜한 솔루션을 제공하고 있습니다.

Mozilla는 원래 디지털 자격증명 API에 대해 부정적인 표준 입장을 표명했습니다. 상세히 문서화된 그들의 우려는 포괄적이며, 사용자 개인정보와 주체성을 보호하고 개방적이고 공정한 웹을 보장하려는 사명에 뿌리를 두고 있습니다.

Mozilla가 제기한 주요 우려 사항:

• 개인정보 위험: 사소한 상호 작용에서도 디지털 자격증명 요청이 일상화될 경우 개인 데이터 공유 증가 및 온라인 익명성 감소 가능성.
• 사용자 배제: 디지털 자격증명을 사용할 수 없거나 사용하지 않기로 선택한 개인이 온라인 서비스 및 커뮤니티에서 배제될 위험. 주요 사용 사례인 정부 발급 자격증명은 개인의 신원 제시 선택권과 일치하지 않을 수 있음.
• 상호 운용성 문제: 자격증명 형식의 난립으로 보편적으로 상호 운용 가능한 생태계 대신 파편화된 생태계가 초래될 우려.
• 선택적 공개: 선택적 공개의 개인정보 보호 이점이 강력한 연결 불가능성(unlinkability) 보장 없이 구현되거나 사용자가 무엇이 공유되는지 완전히 이해하지 못할 경우 약화될 수 있다는 우려.
• 신뢰의 중앙집중화 및 사용자 주체성: API가 신뢰의 중앙집중화를 심화시키고 사용자 주체성을 감소시켜 기존의 사회적 권력 불균형을 영구화할 수 있다는 두려움.

W3C 위원회(Council)가 이러한 우려와 관련된 공식적인 이의 제기를 기각했지만(잠재적으로 덜 투명한 장소가 아닌 W3C 내에서 작업이 진행되도록 허용하기 위함), 위원회는 워킹 그룹이 이러한 잠재적 피해를 완화하기 위해 적극적으로 노력할 것을 권고했습니다.

2026년 3월 업데이트 — 구현 진행 중: 공식적인 부정적 입장은 기술적으로 변함없지만, Mozilla는 디지털 자격증명 API를 적극적으로 구현하기 시작했습니다. 2026년 1분기에 Firefox 149에 기본 DC API 지원이 탑재되었으며(환경 설정 플래그 뒤에 숨겨짐), 메타 버그 2004828에서 추적되고 있습니다. DigitalCredential.cpp, WebIDL 바인딩, IPC 배관을 포함한 소스 코드는 mozilla-central에 있습니다. 데스크톱 및 Android 권한 프롬프트 작업(버그 2010091, 버그 2010093)이 진행 중입니다.

John Schanck, Martin Thomson, Benjamin VanderSloot 등 세 명의 Mozilla 엔지니어가 W3C FedID 워킹 그룹의 활성 회원이며, Schanck는 자격증명 제출 알고리즘 및 요청 준비 알고리즘을 포함한 주요 스펙 PR에 대해 구현에 입각한 실질적인 피드백을 제공해 왔습니다.

이는 중요한 발전입니다. Mozilla는 오남용 가능성에 대한 우려를 유지하면서도, 다른 브라우저 벤더들에게 설계를 넘겨주기보다는 스펙 작업과 구현을 통해 내부에서 API를 형성하는 쪽을 선택한 것이 분명합니다. 이는 디지털 자격증명 API가 3대 브라우저 지원의 길로 들어서고 있음을 알리는 신호입니다. 다만 Mozilla는 더 강력한 개인정보 보호 가드레일(자격증명 요청을 위한 투명성 로그 제안 포함)을 추진하고 있습니다.

표 1: 디지털 자격증명 API 및 프로토콜 브라우저 지원 (2026년 3월)