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

마지막 업데이트: 2025년 10월 30일

주요 브라우저의 디지털 자격증명 API 지원 현황을 간략히 살펴봅니다.

디지털 자격증명의 세계는 빠르게 움직이고 있습니다. 주요 개발 사항과 전망을 간략히 정리했습니다.

Want to experience digital credentials in action?

Try Digital Credentials

2025년 7월 이후 변경된 점은?

• 정식 출시: Chrome 141 (2025년 9월 30일) 및 Safari 26 (2025년 9월 15일).
• Chrome: 프로토콜에 구애받지 않음(OpenID4VP 및 ISO 18013-7 부록 C), CTAP을 통한 데스크톱 크로스 디바이스 지원.
• Safari: mdoc 전용 (org-iso-mdoc), CTAP을 통한 크로스 디바이스 흐름.
• API 형태: navigator.credentials.get(), requests/data 네이밍, DigitalCredential 기능 감지.

디지털 자격증명은 현재 ID 분야에서 뜨거운 주제입니다. 우리 삶이 디지털 영역과 점점 더 연결되면서, 온라인에서 우리의 신원과 자격을 안전하고, 사용자 중심적이며, 개인 정보를 보호하는 방식으로 주장할 필요성이 그 어느 때보다 중요해졌습니다. 기존 방식은 낡아가고 있으며, 더 강력한 해결책에 대한 요구가 뚜렷합니다.

이 글에서는 웹에서 ID 정보를 상호 작용하는 방식을 재편할 중요한 발전인 디지털 자격증명 API의 현황을 논의하고자 합니다. 우리는 이 API의 기본 메커니즘, 지원하는 프로토콜, 현재 브라우저 채택 현황을 살펴보고, 이 빠르게 진화하는 환경을 탐색하는 신뢰 당사자(relying party)와 Wallet 발급 기관(issuer) 모두를 위한 권장 사항을 제공할 것입니다.

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

일부 국가에서는 주로 초기 은행 컨소시엄이 주도하여 기존의 신뢰 관계를 온라인 신원 확인에 활용하는 서비스를 개발하면서 해결책이 등장했습니다. 정부도 개입하여 국가 디지털 신원 Wallet 및 서비스를 시행하거나 제공했습니다. 그러나 이러한 해결책은 종종 분리되어 있고 지리적으로 제한적이며 보편적으로 상호 운용되지 않았습니다.

많은 지역에서 신원 확인을 위한 차선책은 전통적으로 마찰이 많은 프로세스를 포함했습니다. 예를 들어, 우체국에서의 물리적 확인은 상당한 지연과 불편을 초래합니다. 문서 업로드와 결합된 화상 통화가 더 디지털적인 대안이 되었고, 최근에는 자동화된 문서 스캔 및 실시간 확인(liveness check)이 부상했습니다. 이러한 발전에도 불구하고, 이 방법들에는 상당한 단점이 있습니다. 시간이 많이 걸리고, 사람의 실수나 편견에 취약하며, 정교한 위조에 취약하다는 점이 자주 노출되었습니다.

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

Want to experience digital credentials in action?

Try Digital Credentials

디지털 자격증명이 어떻게 작동하는지 이해하려면 관련된 주요 참여자들과 그 기능을 가능하게 하는 다양한 기술 계층을 살펴보아야 합니다.

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

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

이 3자 모델은 사용자(소유자)가 자신의 데이터를 제어할 수 있도록 하는 것을 목표로 하기에 중요합니다. 데이터가 중앙에 저장되거나 사용자의 직접적인 중개 없이 당사자 간에 공유될 수 있는 기존의 신원 시스템과 달리, 이 모델은 사용자 동의와 선택적 공개를 강조합니다. 소유자는 전체 자격증명을 공개하는 대신, 특정 거래를 위해 자격증명에서 어떤 정보를 공유할지 결정합니다.

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

이 설명은 프로토콜 중립적입니다. 발급, 소유, 그리고 암호화 챌린지를 통한 검증이라는 핵심 원칙은 다양한 기반 기술에서 공통적이기 때문입니다.

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

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

핵심 용어:

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

VC를 데이터 모델로, VC API를 백엔드 사양으로, DC API를 웹에 자격증명을 제시하는 프론트엔드 구현으로 생각할 수 있습니다. 1계층(데이터 모델 계층) 위의 모든 것은 형식에 구애받지 않으며, 그 아래의 모든 것은 자격증명 형식에 따라 달라집니다.

종단 간 흐름 (예: 온라인 연령 확인):

1. 발급 (VC API - 발급 기관 ↔ Wallet): 주 정부 DMV가 '소유자는 18세 이상'이라는 검증 가능한 자격증명(Verifiable Credential)을 발급합니다.
2. 저장 (Wallet 앱 - OS): 자격증명이 암호 증명과 함께 사용자의 Wallet에 저장됩니다.
3. 요청 (DC API를 통한 navigator.credentials.get() - 웹사이트 → 브라우저): 맥주 판매 웹사이트가 '사용자가 18세 이상임을 증명해 주세요'라고 요청합니다.
4. 제시 (DC API가 Wallet으로 전달 → OpenID4VP (프로토콜) → VC 페이로드): Wallet이 동의 UI를 표시하고, 사용자가 승인하면 Wallet은 검증 가능한 제시(verifiable presentation)를 다시 보냅니다.
5. 검증 (VC API - 맥주 판매점 백엔드): 사이트의 백엔드가 서명과 발급 기관의 DID/공개 키를 확인하고 접근을 허용합니다.

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

왜 이렇게 분리되어 있는가:

• 상호 운용 가능한 데이터 모델 (암호학적 증명, 선택적 공개): VC 데이터 모델(& 다른 형식)로 해결됩니다.
• 백엔드 시스템을 위한 표준 REST 엔드포인트: VC API로 해결됩니다.
• 개인 정보를 보호하는 Wallet ↔ 웹사이트 핸드셰이크: DC API로 해결됩니다.
• 다른 신뢰 수준 / 문서 유형 (정부 ID 대 과정 수료증): DC API 아래에서 올바른 형식(고신뢰도 ID의 경우 ISO mDoc, 일반적인 주장의 경우 W3C VC)을 사용하여 해결됩니다.

핵심 요점:

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

참여자들과 디지털 자격증명의 전반적인 계층 구조를 살펴본 후, 이 글에서는 이제 표시 계층, 특히 디지털 자격증명 API와 그 현황에 대해 더 깊이 파고들 것입니다.

표시 계층의 핵심 구성 요소인 디지털 자격증명 API는 웹사이트가 사용자의 디지털 Wallet에서 디지털 신원 정보를 요청하고 수신하는 안전하고 표준화된 방법을 제공하기 위해 현재 개발 중인 웹 표준입니다. 이 작업은 2025년 4월 FedID Community Group에서 이전되어 주로 W3C의 Federated Identity Working Group(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 부록 C를 모두 지원하여 프로토콜에 구애받지 않는 반면, Safari는 org-iso-mdoc 프로토콜만 독점적으로 지원합니다. Chrome은 Credential Manager 시스템을 통해 Android에서 이를 네이티브로 지원하며, 데스크톱에서는 CTAP/BLE 기반 QR 핸드오프를 통해 크로스 디바이스 디지털 자격증명 API도 지원합니다.

이 API는 navigator.credentials.get()을 통해 디지털 자격증명 요청을 활성화하여 기존의 Credential Management API를 확장합니다. W3C FedID WG 디지털 자격증명 설명서(https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md)에 따르면, API는 이전에 제안되었던 navigator.identity 대신 이 확립된 인터페이스를 사용하는 것으로 되돌아갔습니다. 웹사이트는 디지털 자격증명에 대한 특정 매개변수와 함께 navigator.credentials.get()을 호출하여 디지털 자격증명을 요청합니다.

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

async function requestCredential() {
    // 디지털 자격증명 API 지원 여부 확인
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // 이 매개변수들은 일반적으로 백엔드에서 가져옵니다.
            // 프로토콜 확장성 설명을 위해 여기서는 정적으로 정의합니다.
            const oid4vp = {
                protocol: "oid4vp", // Wallet에 대한 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);
        }
    } else {
        // 대체 시나리오, 설명용
        alert("이 브라우저에서는 디지털 자격증명 API가 지원되지 않습니다.");
    }
}

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

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

디지털 자격증명 API는 프로토콜에 구애받지 않도록 설계되었습니다. 즉, 자격증명 교환을 위한 다양한 기본 프로토콜을 지원할 수 있습니다. 그러나 현재 구현 및 논의의 중심에는 두 가지 주요 프로토콜군이 있습니다: org.iso.mdoc (ISO 18013-5 및 그 확장인 ISO 18013-7 '부록 C'에서 파생)과 OpenID Foundation의 OpenID for Verifiable Presentations (OpenID4VP) 및 OpenID for Verifiable Credential Issuance (OpenID4VCI) 사양입니다.

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

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

• 일반적인 사용 사례: 주로 운전면허증 및 주민등록증과 같은 정부 발행 신분증입니다. 교통 단속, 제한된 상품에 대한 연령 확인과 같은 대면 시나리오와 정부 서비스 접근, 은행 계좌 개설을 위한 원격 신원 확인과 같은 온라인 시나리오 모두에서 높은 보증 수준을 요구하는 경우에 설계되었습니다.

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

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

유럽 연합 디지털 신원(EUDI) Wallet은 모든 EU 시민과 거주자에게 신분증과 증명(attestation)을 위한 안전한 디지털 Wallet을 제공하는 것을 목표로 하는 주요 이니셔티브입니다. EUDI Wallet 아키텍처 및 참조 프레임워크는 mdoc(특히 모바일 운전면허증용)과 W3C 검증 가능한 자격증명(Verifiable Credentials)을 모두 지원할 계획이며, 제시 및 발급 흐름에 OpenID4VP와 OpenID4VCI를 활용합니다. 참조 구현에는 OpenID4VP를 통해 mDocs를 전송하고, OpenID4VCI를 통해 mDoc 및 SD-JWT-VC 형식으로 PID 및 mDL을 발급하는 지원이 포함됩니다. 이러한 대규모 프로젝트에 의한 이중 지원은 두 프로토콜군의 중요성을 강조합니다. 그러나 이 방향은 비판 없이 받아들여지지는 않습니다. 일부 관찰자들은 '미국 빅테크' 기업의 큰 영향을 받은 디지털 자격증명 API가 최종 EUDI Wallet 사양에 깊숙이 통합될 수 있다고 지적합니다. 이 GitHub 토론과 같은 커뮤니티 포럼에서 논의된 바와 같이, EU의 중요한 인프라에 비 EU 기관이 미칠 잠재적 영향에 대한 우려가 제기되었습니다.

디지털 자격증명 API에 대한 브라우저 환경은 2025년 9월 Chrome 141과 Safari 26이 안정적인 지원을 시작하면서 구체화되었습니다. 브라우저마다 접근 방식과 지원 수준에 주목할 만한 차이가 있습니다.

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

기능 감지:

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

Android의 Credential Manager는 제시를 위한 OpenID4VP와 발급을 위한 OpenID4VCI를 네이티브로 지원하여, Android 앱이 이러한 표준을 사용하여 자격증명 소유자 및 검증자 역할을 할 수 있도록 합니다. Google은 Wallet 지원이 증가하고 있다고 언급했으며, Google Wallet이 초기 채택자이고 Samsung Wallet과 1Password도 발표되었습니다.

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

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

이는 WWDC25 세션 웹에서 신분증 확인하기에서 자세히 설명되었습니다. 이 API를 통해 웹사이트는 Apple Wallet이나 타사 문서 제공 앱에 저장된 운전면허증과 같은 신분증에서 검증 가능한 정보를 요청할 수 있습니다.

Apple 구현의 핵심 사항:

• MDOC 전용: API는 ISO/IEC 18013-7 부록 C 표준을 기반으로 하는 프로토콜 문자열 "org-iso-mdoc"을 독점적으로 사용합니다. Safari의 디지털 자격증명 API 구현에는 OpenID4VP에 대한 지원이 없습니다.
• 제시 전용: API는 기존 자격증명의 제시(검증)를 위한 것입니다. Apple Wallet이나 다른 앱으로의 발급은 별도의 비브라우저 프로세스로 남아 있습니다.
• 사용자 중심 및 보안: 흐름은 사용자 제스처에 의해 시작되며, OS가 샌드박스에서 요청을 먼저 구문 분석하고 유효성을 검사한 후 Wallet 애플리케이션에 전달하는 '부분 요청' 메커니즘을 활용하여 보안을 강화합니다.
• 앱으로 확장 가능: Apple Wallet 외에도 타사 앱은 새로운 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],
            },
        });
 
        // Wallet에서 받은 암호화된 응답을 서버로 보내 복호화 및 유효성 검사를 합니다.
        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가 제기한 주요 우려 사항은 다음과 같습니다:

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

Mozilla는 이러한 API가 기존의 임시방편적인 자격증명 제시 방법보다 유용성을 제공할 수 있음을 인정하지만, 새로운 웹 플랫폼 기능은 웹을 전반적으로 더 좋게 만들고 사용자의 이익을 우선시해야 함을 명백히 입증해야 한다고 강조합니다. W3C 위원회가 이러한 우려와 관련된 공식적인 이의 제기를 기각했지만(덜 투명할 수 있는 장소 대신 W3C 내에서 작업이 진행되도록 허용하기 위해), 위원회는 워킹 그룹이 이러한 잠재적 피해를 완화하기 위해 적극적으로 노력할 것을 권고했습니다.

표 1: 디지털 자격증명 API 및 프로토콜에 대한 브라우저 지원 현황 (2025년 10월)

사용자로부터 디지털 자격증명을 요청하고 검증하려는 조직(신뢰 당사자 또는 RP)에게 현재 상황은 신중한 전략 계획을 요구합니다.

Safari(2025년 9월 15일 출시)는 디지털 자격증명 API를 통해 직접적인 org-iso-mdoc 상호 작용(ISO 18013-7 부록 C)만 독점적으로 지원하고, Chrome(2025년 9월 30일 출시)은 OpenID4VP와 ISO 18013-7 부록 C(mdoc)를 모두 지원하는 프로토콜에 구애받지 않으므로, 가능한 가장 넓은 도달 범위를 목표로 하는 RP는 두 접근 방식에 기반한 상호 작용을 모두 지원할 준비를 해야 합니다.

이는 다음과 같은 시스템을 설계해야 함을 의미합니다:

1. 브라우저 감지 또는 사용자 에이전트 기능에 따라 다른 프로토콜 매개변수("org-iso-mdoc"는 Safari용, "openid4vp"는 Chrome/OID4VP 흐름용)를 지정하여 navigator.credentials.get() API를 통해 자격증명 요청을 시작합니다.
2. 직접 mdoc 형식(ISO 18013-7 부록 C)으로 오거나 OpenID4VP를 통해 vp_token으로 올 수 있는 응답을 처리합니다. 후자의 경우, 기본 자격증명(이 또한 mdoc이나 다른 VC 형식일 수 있음)을 추출하기 위해 구문 분석이 필요합니다.

이는 복잡성을 더하지만, 모든 사용자를 단일 프로토콜 경로로 강제하려는 시도는 선택한 경로에 따라 iOS 사용자나 Chrome/Android 사용자 중 상당 부분을 배제할 가능성이 높습니다. 개발 집약적이지만 실용적인 접근 방식은 둘 다 처리할 수 있는 유연성을 구축하는 것입니다.

신뢰 당사자는 동일한 논리적 정보(예: '사용자가 21세 이상인가?')를 요청하더라도, 이것이 요청에서 어떻게 정의되고 응답에서 어떻게 반환되는지가 직접적인 mdoc 쿼리와 OpenID4VP 쿼리(Presentation Exchange나 DCQL을 사용할 수 있음) 간에 크게 다를 수 있다는 점을 명확히 인지해야 합니다.

• mdoc 선택적 공개: org.iso.mdoc은 선택적 공개를 위한 자체 메커니즘을 가지고 있으며, 일반적으로 발급 기관이 개별 데이터 요소의 솔트 해시를 생성하는 것을 포함합니다. 그러면 소유자의 Wallet은 요청된 요소와 그 솔트만 공개하여, 검증자가 다른 데이터를 보지 않고도 해시와 비교하여 확인할 수 있게 합니다. 특정 요소에 대한 요청은 mdoc 표준 내의 미리 정의된 네임스페이스 및 데이터 요소 식별자와 연결됩니다.
• OpenID4VP 선택적 공개: OpenID4VP는 일반적으로 요청의 presentation_definition 내에 포함된 Presentation Exchange(DIF PE)나 새로운 Digital Credentials Query Language(DCQL)와 같은 쿼리 언어를 사용합니다. 이를 통해 RP는 필요한 자격증명 유형과 개별 클레임을 지정할 수 있습니다. 그러면 Wallet은 자격증명 형식과 Wallet이 지원하는 경우 요청된 정보만 포함하는 검증 가능한 제시(Verifiable Presentation)를 구성합니다.

RP는 특정 데이터 요구 사항을 이러한 다양한 프로토콜 구조에 매핑해야 합니다. 개인 정보 보호 모범 사례와 데이터 최소화 원칙을 준수하기 위해 각 프로토콜에서 선택적 공개가 어떻게 구현되고 요청되는지에 대한 미묘한 차이를 이해하는 것이 중요합니다. Wallet에서 반환된 공개된 데이터의 형식과 구조도 다를 수 있으므로 RP의 백엔드에서 별도의 구문 분석 및 유효성 검사 로직이 필요합니다.

디지털 자격증명을 발급하고 소유자를 위한 Wallet 애플리케이션을 제공하려는 기관에게는 운영 체제 환경이 중요한 역할을 합니다.

Wallet 발급 기관(issuer)은 Wallet 생성, 시스템 통합 및 디지털 자격증명 API와의 상호 작용과 관련하여 iOS와 Android에서 뚜렷하게 다른 환경에 직면합니다.

• Android: 일반적으로 더 개방적인 생태계를 제공합니다. Android Credential Manager에는 타사 네이티브 애플리케이션이 자격증명 소유자로 등록할 수 있도록 하는 Holder API가 포함되어 있습니다. 이 등록된 소유자 앱은 시스템이 중재하는 자격증명 제시 흐름에 참여하여 디지털 자격증명 API(Chrome을 통해) 또는 네이티브 앱 검증자의 요청에 응답할 수 있습니다. Android는 또한 자격증명 발급을 위해 OpenID4VCI를 명시적으로 지원하여 사용자가 새로 발급된 자격증명을 수신할 호환되는 타사 Wallet을 선택할 수 있도록 합니다. 완전한 자격증명 소유자 기능을 위해서는 네이티브 앱이 주요 초점이지만, 시스템은 더 넓은 참여를 위해 설계되었습니다.

• iOS: Apple은 자사 생태계에 대해 더 엄격한 통제를 유지합니다. 타사 Wallet 앱이 App Store에 존재할 수는 있지만, Apple Wallet을 위한 mDL과 같은 고신뢰도 자격증명을 위한 시스템 수준의 자격증명 소유자로서 깊이 통합하는 능력은 종종 Apple의 특정 프로세스와 권한에 따라 달라집니다. 예를 들어, Apple Wallet에 ID를 추가하는 것은 주 발급 당국과 Apple의 확인을 포함하는 통제된 흐름입니다. Safari의 디지털 자격증명 API의 경우, 상호 작용은 면밀히 관리될 가능성이 높으며, 주로 Apple Wallet 자체와 등록된 타사 문서 제공 앱에서 제시되는 org.iso.mdoc에 초점을 맞출 것입니다.

Apple의 '폐쇄적인 생태계(walled garden)' 접근 방식은 잘 확립되어 있으며, 디지털 자격증명 구현도 예외는 아닙니다. 그러나 WWDC25는 타사 참여 경로를 명확히 했습니다.

Apple Wallet이 주 mDL과 같은 자격증명의 주요 내장 제공자이지만, Apple은 네이티브 iOS 앱을 위해 IdentityDocumentServices 프레임워크를 도입했습니다. 이를 통해 타사 개발자는 자체 신분증을 프로비저닝하고 제시할 수 있는 애플리케이션을 구축할 수 있습니다.

웹 흐름에 참여하려면 네이티브 앱은 다음을 수행해야 합니다:

1. 문서 등록: IdentityDocumentProviderRegistrationStore를 사용하여 앱이 관리하는 mdoc을 운영 체제에 등록합니다. 이 등록에는 문서 유형과 요청 서명을 위한 신뢰할 수 있는 인증 기관이 포함됩니다.
2. 앱 확장 구현: 프로젝트에 'Identity Document Provider' UI 앱 확장을 추가합니다. 이 확장은 웹 기반 확인 흐름 중에 앱이 선택될 때 사용자에게 승인 UI를 표시하는 역할을 합니다.

이는 iOS에서 완전히 통합된 Wallet을 만들려면 네이티브 애플리케이션을 구축하고 Apple의 특정 프레임워크를 사용해야 한다는 것을 의미합니다(PWA와 같은 웹 기술이 아님). 그러나 타사 앱이 Apple Wallet과 함께 문서 제공자 역할을 할 수 있는 명확하지만 엄격하게 통제되는 메커니즘이 있습니다. 이는 Safari의 디지털 자격증명 API와의 상호 작용이 OS에 의해 관리되며, OS는 요청을 Apple Wallet이나 다른 등록되고 승인된 문서 제공 앱으로 전달한다는 것을 확인시켜 줍니다.

디지털 자격증명 API는 디지털 신원 분야에서 상당한 발전을 의미하며, 신원 확인 및 자격증명 제시에 대해 더 안전하고 사용자 중심적이며 개인 정보를 보호하는 접근 방식을 제공합니다. Chrome 141(2025년 9월 30일)과 Safari 26(2025년 9월 15일)이 이제 안정적인 지원을 시작함에 따라, 이 API는 실험 단계에서 프로덕션 준비 단계로 이동했습니다. 생태계가 계속 발전함에 따라 신뢰 당사자와 Wallet 발급 기관 모두가 이 새로운 기술의 잠재력을 수용하고 적응하는 것이 중요합니다. 우리는 환경이 변화함에 따라 이 글을 계속 업데이트할 것입니다.

그러나 도전 과제는 남아 있습니다. 다양한 자격증명 형식, 프로토콜 및 Wallet 구현 간에 진정한 글로벌 상호 운용성을 달성하는 것은 중요한 과제입니다. 개인 정보 보호, 배제 및 사용자 주체성에 관해 Mozilla와 같은 조직이 제기한 타당한 우려를 해결하는 것은 이러한 기술이 인류에게 봉사하도록 보장하는 데 가장 중요합니다. Chrome의 프로토콜에 구애받지 않는 구현과 Safari의 mdoc 전용 초점이라는 상이한 접근 방식은 신뢰 당사자와 Wallet 발급 기관이 당분간 이중 프로토콜 환경을 탐색해야 함을 의미합니다.