디지털 자격증명 API (2025): Chrome 및 Safari (WWDC25)

마지막 업데이트: 2025년 7월 15일 (WWDC25 이후)

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

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

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

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

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

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

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

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

Want to try digital credentials yourself in a demo?

Try Digital Credentials

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

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

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

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

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

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

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

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

핵심 용어:

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

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

엔드투엔드 흐름 (예: 온라인 연령 확인):

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

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

분할이 존재하는 이유:

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

핵심 요약:

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

참여자들과 디지털 자격증명의 전반적인 계층 구조를 살펴본 후, 이 글은 이제 프레젠테이션 계층, 특히 디지털 자격증명 API와 그 현재 상태에 대해 더 깊이 파고들 것입니다.

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

2025년 현재, 이 API는 여전히 상당한 변경이 진행 중인 것으로 설명됩니다. 이는 활발한 개발 단계를 강조합니다. 그럼에도 불구하고 그 잠재력은 상당합니다. Chrome은 Origin Trial을 통해 개발자들이 그 기능을 실험할 수 있도록 하면서 공개적으로 무언가를 출시한 첫 번째 브라우저였습니다. Chrome은 또한 Android의 Credential Manager 시스템을 통해 이를 기본적으로 지원하며, 최근에는 데스크톱에서의 Cross-Device 디지털 자격증명 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() {
    // Check for Digital Credentials API support
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // These parameters are typically fetched from the backend.
            // Statically defined here for protocol extensibility illustration purposes.
            const oid4vp = {
                protocol: "oid4vp", // An example of an OpenID4VP request to wallets. // Based on https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Presentation Exchange request, omitted for brevity
                    },
                },
            };
 
            // create an Abort Controller
            const controller = new AbortController();
 
            // Call the Digital Credentials API using the presentation request from the backend
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Send the encrypted response to the backend for decryption and verification
            // Ommitted for brevity
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // fallback scenario, illustrative only
        alert("The Digital Credentials API is not supported in this browser.");
    }
}

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

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

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

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

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

디지털 자격증명 API에 대한 브라우저 환경은 여전히 형성 중이며, 접근 방식과 지원 수준에서 주목할 만한 차이가 있습니다.

Google Chrome, 특히 Android에서는 디지털 자격증명 API의 초기 채택자이자 구현자였습니다. 그들은 Origin Trial을 실행하고 이를 Android의 기본 Credential Manager와 통합했습니다. Chrome의 구현은 주로 navigator.credentials.get() API 호출을 통해 자격증명을 요청하는 프로토콜로 OpenID4VP를 활용합니다. OpenID4VP 자체는 형식에 구애받지 않으며 org.iso.mdoc 또는 W3C 검증 가능한 자격증명을 페이로드로 전달할 수 있지만, Google의 실질적인 강조점은 전송 메커니즘으로서의 OpenID4VP 흐름에 있는 것으로 보입니다. Android의 Credential Manager는 또한 제시를 위한 OpenID4VP와 발급을 위한 OpenID4VCI를 기본적으로 지원합니다. 이를 통해 Android 앱은 이러한 표준을 사용하여 자격증명 소유자 및 검증자 역할을 할 수 있습니다.

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

우리가 정확하게 예상했듯이, WWDC25는 이 전략을 확인했습니다. 컨퍼런스에서 Apple은 Safari 26(2025년 가을에 iOS 26 및 기타 OS 업데이트와 함께 출시)에서 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는 먼저 샌드박스에서 요청을 구문 분석하고 유효성을 검사한 후 지갑 애플리케이션에 전달하여 보안을 강화합니다.
• 앱으로 확장 가능: Apple Wallet 외에도 타사 앱은 새로운 IdentityDocumentServices 프레임워크와 앱 확장을 구현하여 문서 제공자 역할을 할 수 있습니다.

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

async function verifyIdentity() {
    try {
        // Server generates and cryptographically signs the request data.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // The request specifies the 'org-iso-mdoc' protocol.
        const request = {
            protocol: "org-iso-mdoc",
            // data contains the cryptographically signed mdoc request.
            data,
        };
 
        // The API must be called from within a user gesture.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Send the encrypted response from the wallet to the server for decryption and validation.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Display the verified details...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Handle errors, e.g., user cancellation.
    }
}

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

Mozilla는 현재 상태의 디지털 자격증명 API 제안에 대해 공식적으로 "부정적인" 입장을 표명했습니다. 그들의 우려는 포괄적이며, 사용자 개인정보 보호, 주체성, 그리고 개방적이고 공평한 웹을 보장하려는 그들의 사명에 뿌리를 두고 있습니다.

Mozilla가 제기한 주요 우려 사항은 다음과 같습니다.

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

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

표 1: 디지털 자격증명 API 및 프로토콜에 대한 브라우저 지원

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

상당한 시장 점유율을 가진 Safari가 디지털 자격증명 API를 통해 직접적인 org.iso.mdoc 상호작용을 우선시할 가능성이 높고, Chrome/Android는 OpenID4VP(mdoc 또는 다른 검증 가능한 자격증명 형식을 전달할 수 있음)를 강조하고 있다는 점을 고려할 때, 가능한 가장 넓은 도달 범위를 목표로 하는 RP는 두 가지 접근 방식을 모두 지원할 준비를 해야 합니다.

이는 다음과 같은 시스템을 설계하는 것을 의미합니다.

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

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

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

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

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

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

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

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

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

디지털 자격증명 API는 디지털 신원 분야에서 상당한 발전을 나타내며, 신원 확인 및 자격증명 제시에 대해 더 안전하고, 사용자 중심적이며, 개인정보를 보호하는 접근 방식을 제공합니다. 생태계가 진화함에 따라 신뢰 당사자와 지갑 발급자 모두가 이 새로운 기술의 잠재력에 적응하고 이를 수용하는 것이 중요합니다. 우리는 환경이 변화함에 따라 이 글을 계속 업데이트할 것입니다.

그러나 도전 과제는 여전히 남아 있습니다. 다양한 자격증명 형식, 프로토콜 및 지갑 구현 간에 진정한 글로벌 상호 운용성을 달성하는 것은 중요한 과제입니다. 개인정보 보호, 배제 및 사용자 주체성에 대해 Mozilla와 같은 조직이 제기한 타당한 우려를 해결하는 것은 이러한 기술이 인류에게 봉사하도록 보장하는 데 가장 중요합니다. 브라우저 지원 및 프로토콜 강조의 현재 파편화는 신뢰 당사자와 지갑 발급자가 당분간 복잡한 환경을 탐색해야 함을 의미합니다.