디지털 자격 증명

W3C 작업 초안

이 문서에 대한 자세한 정보
이 버전:
https://www.w3.org/TR/2026/WD-digital-credentials-20260904/
최신 공개 버전:
https://www.w3.org/TR/digital-credentials/
최신 편집자 초안:
https://w3c-fedid.github.io/digital-credentials/
이력:
https://www.w3.org/standards/history/digital-credentials/
커밋 이력
편집자:
Marcos Caceres (Apple Inc.)
Tim Cappalli (Okta)
Mohamed Amir Yosef (Google Inc.)
이전 편집자:
Sam Goto (Google Inc.) - 까지
피드백:
GitHub w3c-fedid/digital-credentials (풀 리퀘스트, 새 이슈, 열린 이슈)

Copyright © 2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

초록

이 문서는 사용자 에이전트가 제시 및 발급을 중개할 수 있도록 하는 API를 명세하며, 대상은 디지털 자격 증명으로, 예를 들면 운전면허증, 정부 발급 신분증 또는 기타 유형의 디지털 자격 증명이 있다. 이 API는 자격 증명 관리 레벨 1을 기반으로 하며 특정 자격 증명 형식에 종속되지 않도록 설계되었다.

이 문서의 상태

이 절에서는 이 문서가 발행된 시점의 상태를 설명한다. 현재 W3C 발행물 목록과 이 기술 보고서의 최신 개정판은 W3C 표준 및 초안 색인에서 확인할 수 있다.

이 문서는 연합 신원 작업 그룹이 권고안 트랙을 사용하여 작업 초안으로 발행했다.

작업 초안으로 발행되었다고 해서 W3C 및 그 회원이 이를 승인한다는 의미는 아니다.

이 문서는 초안이며 언제든 다른 문서에 의해 갱신, 대체 또는 폐기될 수 있다. 이 문서를 진행 중인 작업 이외의 것으로 인용하는 것은 적절하지 않다.

이 문서는 W3C 특허 정책에 따라 운영되는 그룹이 작성했다. W3C는 이 그룹의 산출물과 관련하여 이루어진 모든 특허 공개의 공개 목록을 유지하며, 해당 페이지에는 특허를 공개하기 위한 지침도 포함되어 있다. 자신이 알고 있는 특허에 필수 청구항이 포함되어 있다고 판단하는 개인은 W3C 특허 정책의 제6절에 따라 해당 정보를 공개해야 한다.

이 문서는 2025년 8월 18일 W3C 프로세스 문서의 적용을 받는다.

1. 소개

이 절은 비규범적이다.

이 문서는 웹사이트가 디지털 자격 증명의 제시 및 발급을 요청할 수 있도록 하는 API를 정의한다.

이 API는 자격 증명 형식에 종속되지 않으며 여러 제시 프로토콜 및 발급 프로토콜로 확장할 수 있도록 설계되었다. 5. 프로토콜을 참조하라.

이 API는 다음 목표를 지원하도록 설계되었다:

여러 유형의 디지털 자격 증명을 이 API를 사용하여 제시하고 발급할 수 있다. 이러한 유형의 예에는 다음이 포함된다:

2. 사용 예

이 절은 비규범적이다.

다음 예는 API를 사용하여 디지털 자격 증명을 요청하고 발급하는 방법을 보여준다.

2.1 기능 감지

API를 사용하기 전에 사용자 에이전트가 필요한 기능을 지원하는지 확인하는 것이 중요하다. 이는 다음 코드를 사용하여 수행할 수 있다:

예 1: API 지원 확인 
if (typeof DigitalCredential !== "undefined") {
  // API가 지원된다
} else {
  // API가 지원되지 않는다
}

2.2 프로토콜이 허용되는지 확인

userAgentAllowsProtocol() 정적 메서드는 사용자 에이전트가 디지털 자격 증명의 발급 또는 제시에 대해 특정 프로토콜을 허용하는지 확인하는 데 사용할 수 있다. 이는 API 호출을 수행하기 전에 사용자의 브라우저에서 어떤 프로토콜이 허용되는지 확인하는 데 유용하다. DigitalCredential을 구현하는 브라우저에서는 (위에 표시된 typeof 검사로 감지할 수 있음), 프로토콜 식별자가 DigitalCredentialProtocol에 사용자 에이전트가 이에 대한 지원을 채택함에 따라 점진적으로 추가되므로, 알 수 없는 프로토콜 식별자로 이 메서드를 호출하면 예외를 던지지 않고 안전하게 false를 반환한다. 예외. 단, DigitalCredential이 정의되지 않은 브라우저에서 이 메서드를 호출하면 ReferenceError가 발생하므로, 위에 표시된 typeof DigitalCredential !== "undefined" 가드는 이 메서드를 사용하기 전에 여전히 필요하다.

예 2: userAgentAllowsProtocol() 정적 메서드 사용 
if (DigitalCredential.userAgentAllowsProtocol("example-protocol")) {
  // DC API가 지원된다. 발급 또는 제시를 계속 진행한다.
} else {
  // DC API가 지원되지 않는다. 예를 들어
  // 기존 HTML 폼 기반 방식으로 대체한다.
  showHTMLForm();
}

또는 여러 프로토콜에 대한 지원을 확인하면서 지원되지 않는 프로토콜을 걸러낼 수 있다:

예 3: userAgentAllowsProtocol()으로 여러 프로토콜 확인 
const protocols = [
  "example-issuance-protocol",
  "another-issuance-protocol"
];
const supportedProtocols = protocols.filter(DigitalCredential.userAgentAllowsProtocol);
if (supportedProtocols.length > 0) {
  // 하나 이상의 프로토콜이 지원된다. 발급을 계속 진행한다.
} else {
  // 지원되는 프로토콜이 없다. 다른 발급 방법으로 대체한다.
}

프로토콜 식별자는 DigitalCredentialProtocol에 점진적으로 추가되므로, 이 메서드를 사용하여 최신 프로토콜을 우선하면서 레거시 브라우저에서는 이전 프로토콜로 자연스럽게 대체할 수 있다:

예 4: 최신 프로토콜을 우선하고 이전 프로토콜로 대체 
// 선호도 순으로 정렬됨. DigitalCredential을 구현하는 브라우저에서는
// 알 수 없는 프로토콜이 예외를 던지는 대신 false를 반환한다.
const protocol = [
  "example-new-protocol",
  "example-legacy-protocol",
].find(DigitalCredential.userAgentAllowsProtocol);

if (protocol) {
  // 이 브라우저가 지원하는 최선의 프로토콜을 사용한다.
} else {
  // 지원되는 프로토콜을 찾지 못했다. 다른 방식으로 대체한다.
}

2.3 디지털 자격 증명 요청

다음 예는 API를 사용하여 디지털 자격 증명을 요청하는 방법을 보여준다. API의 진입점은 navigator.credentials.get() 메서드이며, 이 메서드는 사용자 에이전트로부터 디지털 자격 증명을 요청하는 데 사용된다. 사용자 에이전트가 제시를 지원하는 경우, 사용자가 디지털 자격 증명 선택기를 통해 디지털 자격 증명을 선택할 수 있도록 한다:

예 5: 디지털 자격 증명 요청 
<button>신원 확인</button>
<script>
  const button = document.querySelector("button");
  button.addEventListener("click", async () => {
    const protocol = "example-request-protocol";
    // DC API 및 프로토콜 지원을 확인한다
    if (!DigitalCredential.userAgentAllowsProtocol(protocol)) {
      // 브라우저가 이 프로토콜의 사용을 허용하지 않는다.
      // 다른 검증 방법으로 대체한다.
      showTraditionalVerificationForm();
      return;
    }
    try {
      const credential = await navigator.credentials.get({
        digital: {
          requests: [{
            protocol,
            data: { /* 제시 요청 데이터 */ }
          }]
        }
      });

      // 복호화 및 검증을 위해 검증자 서버로 다시 전송한다
      const response = await fetch("/verify-credential", {
        method: "POST",
        headers: {
          "Content-Type": "application/json"
        },
        body: JSON.stringify(credential)
      });

      // 응답을 확인한다
      if (!response.ok) {
        throw new Error("Failed to verify credential");
      }

      // 검증 결과를 렌더링한다
      displayVerificationResult(await response.json());

    } catch (error) {
      console.error("Error requesting digital credential:", error);
    }
  });
</script>

마찬가지로 사이트에서 디지털 자격 증명을 발급해야 하는 경우, 디지털 자격 증명 API는 사이트, 사용자 에이전트, 그리고 보유자의 자격 증명 관리자 간의 디지털 자격 증명 발급을 자격 증명 관리자 선택기를 통해 중개합니다.

2.4 디지털 자격 증명 발급

다음 예는 디지털 자격 증명 API를 사용하여 디지털 자격 증명의 발급을 요청하는 방법을 보여준다. 디지털 자격 증명을 발급하려면 사이트가 navigator.credentials.create() 메서드를 호출하며, 사용자 에이전트가 발급을 지원하는 경우 이 메서드는 발급 흐름을 시작한다:

예 6: 디지털 자격 증명 발급 요청 
<button>디지털 자격 증명 발급 요청</button>
<script>
  const button = document.querySelector("button");
  button.addEventListener("click", async () => {
    const protocol = "example-issuance-protocol";
    // DC API 및 프로토콜 지원을 확인한다
    if (!DigitalCredential.userAgentAllowsProtocol(protocol)) {
      // 브라우저가 이 프로토콜의 사용을 허용하지 않는다.
      // 다른 발급 방법으로 대체한다.
      showTraditionalIssuanceForm();
      return;
    }
    try {
      const credential = await navigator.credentials.create({
        digital: {
          requests: [{
            protocol,
            data: { /* 발급 요청 데이터 */ }
          }]
        }
      });
    } catch (error) {
      console.error("Error issuing digital credential:", error);
    }
  });
</script>

2.5 오리진 간 디지털 자격 증명 요청

이 명세는 "digital-credentials-get" 정책 제어 기능을 통해 원격/서드파티 오리진에서 자격 증명을 제시하기 위해 API를 사용하는 것을 허용한다. 이는 웹사이트가 다른 오리진에서 호스팅되는 검증 서비스로부터 디지털 자격 증명을 요청하려는 시나리오에 유용하다. API를 사용하려는 웹사이트를 삽입하는 iframe에 권한 정책을 설정할 수 있다. 다음은 iframe에 권한 정책을 설정하는 방법의 예이다:

예 7: 오리진 간 디지털 자격 증명 요청 
<iframe src="https://verifier-service.example.com"
        allow="digital-credentials-get">
</iframe>

2.6 오리진 간 디지털 자격 증명 발급

마찬가지로 이 명세는 "digital-credentials-create" 정책 제어 기능을 통해 원격/서드파티 오리진에서 자격 증명을 발급하기 위해 API를 사용하는 것을 허용한다. 이는 웹사이트가 다른 오리진의 발급 서비스를 사용하여 디지털 자격 증명 발급을 요청하려는 시나리오에 유용하다. 발급자의 인터페이스를 삽입하는 iframe에 권한 정책을 설정할 수 있다. 다음은 예이다:

예 8: 오리진 간 디지털 자격 증명 발급 
<iframe src="https://issuer.example.com"
        allow="digital-credentials-create">
</iframe>

3. 범위

이 절은 비규범적이다.

다음 항목은 이 명세의 범위에 포함된다:

다음 항목은 범위에 포함되지 않는다:

4. 용어

참고: 논의 중인 정의

이 절의 정의가 목표로 하는 것은 다양한 디지털 자격 증명 형식과 프로토콜에 공통으로 적용되는 용어를 재사용하거나 확립하는 것이다. 이러한 정의는 현재 적극적으로 발전하고 있다.

자격 증명 관리자 선택기
하나 이상의 자격 증명 관리자를 사용자에게 제시하여, 사용자가 발급 요청을 처리할 자격 증명 관리자를 선택하거나 작업을 취소할 수 있도록 하는 플랫폼 제공 사용자 인터페이스입니다.
자격 증명 요청
제시 요청 또는 발급 요청입니다.
자격 증명 응답
제시 응답 또는 발급 응답입니다.
디지털 자격 증명
하나 이상의 주장을 포함하는 암호학적으로 서명된 디지털 문서로, 이러한 주장은 발급자가 하나 이상의 주체에 대해 한 것입니다.
참고: 사람에 관한 디지털 자격 증명에 중점

이 명세는 현재 사람과 관련된 디지털 자격 증명에 중점을 두고 있습니다.

디지털 자격 증명 선택기
하나 이상의 자격 증명 요청을 사용자에게 제시하여, 사용자가 요청을 충족할 수 있는 디지털 자격 증명 또는 보유자를 선택하거나 작업을 취소할 수 있도록 하는 플랫폼 제공 사용자 인터페이스입니다.
참고: 자격 증명 선택기와의 관계
발급 프로토콜
발급자와 보유자 사이에서 디지털 자격 증명을 발급하는 동안 통신에 사용되는 표준화된 프로토콜입니다. 발급 프로토콜은 프로토콜 식별자로 식별됩니다. 5. 프로토콜을 참조하십시오.
발급 요청
발급 요청은 일부 발급 요청 데이터와 발급 프로토콜로 구성된 디지털 자격 증명을 발급하기 위한 요청입니다.
발급 요청 데이터
발급자 또는 사용자 에이전트가 발급 프로토콜을 통해 디지털 자격 증명을 발급자가 발급하도록 요청하기 위한 데이터 구조입니다.
발급 응답
보유자가 발급 프로토콜을 통해 발급 요청에 응답하기 위해 사용하는 형식으로, 해당 요청은 발급자가 한 것입니다.
제시 프로토콜
보유자와 검증자 사이에서 디지털 자격 증명을 제시하는 데 사용되는 표준화된 프로토콜입니다. 프로토콜은 프로토콜 식별자로 식별됩니다. 5. 프로토콜을 참조하십시오.
제시 요청
제시 요청은 제시 요청 데이터와 제시 프로토콜로 구성된 디지털 자격 증명에 대한 요청입니다.
제시 요청 데이터
검증자 소프트웨어 또는 사용자 에이전트가 제시 프로토콜을 통해 디지털 자격 증명을 보유자에게 요청하기 위해 사용하는 형식입니다.
제시 응답
디지털 지갑과 같은 보유자의 자격 증명 관리자가 제시 프로토콜을 통해 제시 요청에 응답하기 위해 사용하는 형식으로, 해당 요청은 검증자가 한 것입니다.
프로토콜 식별자
하나 이상의 ASCII 소문자 알파벳 코드 포인트, 0개 이상의 U+002D HYPHEN-MINUS 코드 포인트, 그리고 0개 이상의 ASCII 숫자 코드 포인트를 임의의 순서로 조합하여 구성한 문자열입니다. 예를 들어, "123a-protocol", "abc", 또는 단순히 "a"입니다.
요청 조정자
자격 증명 요청 조정자를 참조하십시오.

5. 프로토콜

다음 제시 프로토콜 및 발급 프로토콜의 사용은 이 명세에서 정의한다.

사용자 에이전트는 지원되는 제시 및 발급 프로토콜 표에 나열된 모든 제시 프로토콜을 반드시 지원해야 한다. 지원되는 제시 및 발급 프로토콜 표에 나열된 모든 발급 프로토콜도 사용자 에이전트가 지원하는 것이 권고된다. 해당 프로토콜은 그 표에 나열되어 있다.

참고: 필수 프로토콜의 근거
참고: 사용자 에이전트가 허용하는 프로토콜 확인
지원되는 제시 및 발급 프로토콜 표
식별자 명세
제시 프로토콜
openid4vp-v1-unsigned 검증 가능한 제시를 위한 OpenID 1.0 § A.3.1. 서명되지 않은 요청
openid4vp-v1-signed 검증 가능한 제시를 위한 OpenID 1.0 § A.3.2. 서명된 요청
openid4vp-v1-multisigned 검증 가능한 제시를 위한 OpenID 1.0 § A.3.2.2. JWS JSON 직렬화 (다중 서명 요청)
org-iso-mdoc ISO/IEC 18013-7:2025 ISO 준수 운전면허증, 제7부: 모바일 운전면허증(mDL) 추가 기능 § 부속서 C
발급 프로토콜
openid4vci-v1 검증 가능한 자격 증명 발급을 위한 OpenID 1.0 § 추후 제공 예정
이슈: API 통합

5.1 요청 프로토콜 변환

DigitalCredentialGetRequest 또는 DigitalCredentialCreateRequest request가 주어졌을 때 요청 프로토콜을 변환하려면:

  1. request가 다음 중 하나인 경우:
    DigitalCredentialGetRequest:
    1. protocolString을 request의 protocol로 둔다.
    2. protocolString이 DigitalCredentialPresentationProtocol의 어떤 열거형 값과도 같지 않으면 실패를 반환한다.
    3. 값이 protocolString인 DigitalCredentialPresentationProtocol 열거형 값을 반환한다.
    DigitalCredentialCreateRequest:
    1. protocolString을 request의 protocol로 둔다.
    2. protocolString이 DigitalCredentialIssuanceProtocol의 어떤 열거형 값과도 같지 않으면 실패를 반환한다.
    3. 값이 protocolString인 DigitalCredentialIssuanceProtocol 열거형 값을 반환한다.

6. 자격 증명 요청 코디네이터

자격 증명 요청 코디네이터는 최상위 탐색 가능 객체를 통해 디지털 자격 증명 상호작용을 중개하는 사용자 에이전트 정의 구성 요소이다. 각 최상위 탐색 가능 객체에는 정확히 하나의 연결된 코디네이터가 있다. 코디네이터는 모든 하위 탐색 가능 객체 전체에서 최대 하나의 상호작용만 활성화되도록 보장하고, 제시 또는 발급의 종단 간 흐름을 조율하며 상호작용 상태 간 전환을 관리한다.

자격 증명 요청 코디네이터는 활성 프로미스를 유지하며, 사용자 에이전트는 이를 null로 초기화한다. 이 Promise를 통해 코디네이터는 비동기 자격 증명 요청 워크플로의 상태를 스크립트에 반영하며, 상호작용이 성공적으로 완료되면 자격 증명 응답으로 이행하거나, 처리가 실패하거나 사용자가 UI를 통해 요청을 취소하거나 스크립트가 AbortSignal을 통해 작업을 중단하면 거부한다.

자격 증명 요청 코디네이터는 중단 신호를 유지하며, 사용자 에이전트는 이를 null로 초기화한다.

자격 증명 요청 코디네이터는 중단 알고리즘을 유지하며, 사용자 에이전트는 이를 null로 초기화한다.

자격 증명 요청 코디네이터는 다음을 수행한다:

사용자 에이전트는 사용자 또는 플랫폼 정책에 따라 코디네이터 책임의 일부 또는 전부를 외부 자격 증명 관리자, 플랫폼 구성 요소 또는 기타 신뢰할 수 있는 엔터티에 위임할 수 있다.

참고

6.1 상호작용 상태

자격 증명 요청 코디네이터에는 자격 증명 요청의 수명 주기를 관리하는 데 사용되는 유한한 상호작용 상태 집합이 있다:

"유휴":
현재 진행 중인 자격 증명 요청이 없다.
"요청 중":
자격 증명 요청이 진행 중이며 사용자 인터페이스가 표시되어 있다.
"중단 중":
오류, 사용자 동작 또는 신호 중단으로 인해 활성 상호작용이 취소되고 있으며, 코디네이터는 "유휴" 상태로 돌아가기 전에 정리 작업을 수행한다.

코디네이터는 유휴 상호작용 상태로 초기화된다.

6.2 자격 증명 요청 준비

Window global, 오리진 origin, DigitalCredentialGetRequest 값의 시퀀스 또는 DigitalCredentialCreateRequest 값의 시퀀스 requests, 그리고 선택적 AbortSignal signal이 주어졌을 때 자격 증명 요청을 준비하려면:

  1. realm을 global의 관련 realm으로 설정합니다.
  2. document를 global의 연결된 Document로 설정합니다.
  3. document가 완전히 활성 상태가 아니면, realm에서 "InvalidStateError" DOMException으로 거부된 프로미스를 반환합니다.
  4. document가 사용자의 주의를 받는 최상위 탐색 가능 항목의 완전히 활성 상태인 자손이 아니면, realm에서 "NotAllowedError" DOMException으로 거부된 프로미스를 반환합니다.
  5. global에 일시적 활성화가 없으면, realm에서 "NotAllowedError" DOMException으로 거부된 프로미스를 반환합니다.
  6. global의 사용자 활성화를 소비합니다.
  7. promise를 realm의 새 프로미스로 설정합니다.
  8. 자격 증명 요청 조정자가 "유휴" 상호작용 상태가 아니면:
    1. global이 주어졌을 때 DOM 조작 태스크 소스에서 전역 태스크를 큐에 추가하여, "NotAllowedError" DOMException으로 promise를 거부합니다.
    2. promise를 반환합니다.
  9. 단언: 자격 증명 요청 조정자의 활성 프로미스는 null입니다.
  10. 자격 증명 요청 조정자의 상호작용 상태를 "요청 중"으로 설정합니다.
  11. 자격 증명 요청 조정자의 활성 프로미스를 promise로 설정합니다.
  12. validatedRequests를 requests가 주어졌을 때 자격 증명 요청을 검증한 결과로 둡니다. 그 결과가 예외를 발생시키고 그 예외가 error라면 다음을 수행합니다:
    1. error와 promise를 사용하여 자격 증명 요청을 거부합니다.
    2. promise를 반환합니다.
  13. validatedRequests가 비어 있으면, 다음을 수행합니다:
    1. 새로 생성된 TypeError와 promise로 자격 증명 요청을 거부합니다.
    2. promise를 반환합니다.
  14. signal이 전달되었다면, 다음을 수행합니다:
    1. 단언: signal은 중단된 상태가 아닙니다.
      참고

      미리 중단된 signal은 이 알고리즘이 호출되기 전에 Credential을 요청하고 Credential을 생성하는 과정에서 처리됩니다.

    2. 자격 증명 요청 조정자의 중단 signal을 signal로 설정합니다.
    3. abortAlgorithm을 promise와 signal을 포착하는 다음 알고리즘으로 설정합니다:
      1. 자격 증명 요청 조정자의 활성 프로미스가 promise가 아니면 반환합니다.
      2. signal의 중단 사유가 주어졌을 때 자격 증명 요청을 중단합니다.
    4. 자격 증명 요청 조정자의 중단 알고리즘을 abortAlgorithm으로 설정합니다.
    5. abortAlgorithm을 signal에 추가합니다.
  15. document가 완전히 활성 상태이기를 중단하면, "AbortError" DOMException으로 자격 증명 요청을 중단합니다.
  16. handled를 promise와 global이 주어졌을 때 가상 지갑 동작을 처리한 결과로 설정합니다.
  17. handled가 true이면, promise를 반환합니다.
  18. document, validatedRequests, promise, 그리고 signal로 자격 증명 요청을 시작합니다.
  19. promise를 반환합니다.

6.3 자격 증명 요청 필터링

DigitalCredentialGetRequest 또는 DigitalCredentialCreateRequest 객체의 시퀀스 requests가 주어졌을 때 자격 증명 요청을 필터링하려면:

  1. supportedRequests를 새로운 빈 리스트로 둔다.
  2. requests의 각 request에 대해 반복한다:
    1. protocol을 request가 주어졌을 때 요청 프로토콜을 변환한 결과로 둔다.
    2. protocol이 실패이면 계속한다.
    3. protocol이 주어졌을 때 사용자 에이전트가 프로토콜을 허용한 결과가 false이면 계속한다.
    4. request를 supportedRequests에 추가한다.
  3. supportedRequests를 반환한다.
참고

프로토콜이 모두 지원되지 않는 요청이 사용자 활성화를 소비하지 않고 TypeError로 거부되도록 하기 위해 필터링은 사용자 활성화를 소비하기 전에 수행된다. 이후 자격 증명 요청 검증에서는 남은 모든 요청이 지원되는 프로토콜을 사용한다고 안전하게 가정할 수 있다.

6.4 자격 증명 요청 검증

DigitalCredentialGetRequest 또는 DigitalCredentialCreateRequest 객체의 시퀀스 requests가 주어졌을 때 자격 증명 요청을 검증하려면:

  1. validatedRequests를 새로운 빈 리스트로 둔다.
  2. requests의 각 request에 대해 반복한다:
    1. request가 DigitalCredentialGetRequest이면 data를 request의 data로 두고, request가 DigitalCredentialCreateRequest이면 request의 data로 둔다.
    2. data를 JSON 문자열로 직렬화한다.
    3. 직렬화 결과가 예외이면, 그 예외를 던진다.
    4. request의 제시 요청 데이터 또는 발급 요청 데이터를 request의 제시 프로토콜 또는 발급 프로토콜이나 기타 기준에 따라 검증한다.

      프로토콜에서 정의한 요구 사항 외에도 사용자 에이전트는 로컬 정책, 구성 또는 사용자의 선택을 기반으로 검증 기준을 적용할 수 있다. 예를 들어 사용자 에이전트는 특정 자격 증명 속성을 요구하는 요청을 거부할 수 있다.

      무엇이 검증 실패를 구성하는지는 프로토콜별로 다르지만, 그러한 실패를 예외 유형으로 분류하는 방법은 아래에서 정의한다:

      참고: 프로토콜별 검증 세부 정보
      1. 검증에 실패한 경우:
        1. error를 다음과 같이 결정한다:
          사용자 에이전트가 로컬 정책, 구성 또는 사용자의 선택에 따라 요청을 허용하지 않는 경우:
          생성된 "NotAllowedError" DOMException.
          참고

          "NotAllowedError"는 사용자가 작업을 취소했을 때 반환되는 오류와 의도적으로 구별할 수 없게 되어 있으므로, 웹사이트는 요청이 사용자에 의해 거부되었는지 사용자 에이전트에 의해 거부되었는지 판단할 수 없으며 사용자의 구성이나 자격 증명에 관한 어떤 정보도 추론할 수 없다.

          컨텍스트 또는 전송과 같이 사용자와 무관한 보안상의 이유로 요청이 허용되지 않는 경우:
          생성된 "SecurityError" DOMException.
          요청 데이터의 형식이 잘못되었거나 유효하지 않은 경우:
          생성된 TypeError.
          그 밖의 경우:
          생성된 "OperationError" DOMException.
        2. error를 던진다.
      2. 그 밖의 경우 request를 validatedRequests에 추가한다.
  3. validatedRequests를 반환한다.

6.5 자격 증명 요청 중단

JavaScript 값 error가 주어졌을 때 자격 증명 요청을 중단하려면:

  1. 자격 증명 요청 코디네이터의 활성 프로미스가 null이면 반환한다.
  2. activePromise를 자격 증명 요청 코디네이터의 활성 프로미스로 둔다.
  3. 자격 증명 요청 코디네이터가 "요청 중" 상호작용 상태인 경우:
    1. 자격 증명 요청 코디네이터의 상호작용 상태를 "중단 중"으로 설정한다.
    2. 디지털 자격 증명 선택기 또는 자격 증명 관리자 선택기를 닫습니다.
      참고

      닫기에 실패할 수 있지만(예: 디지털 자격 증명 선택기가 메모리 부족으로 인해 제거된 경우), 조정자는 그와 관계없이 자격 증명 요청을 계속 완료합니다.

  4. error 및 activePromise로 자격 증명 요청을 거부한다.

6.6 자격 증명 요청 거부

(JavaScript Value) error 및 Promise promise가 주어졌을 때 자격 증명 요청을 거부하려면:

  1. 단언: 자격 증명 요청 코디네이터의 활성 프로미스는 promise이다.
  2. promise의 관련 전역 객체가 주어졌을 때 DOM 조작 태스크 소스에 전역 태스크를 큐에 추가하여 다음 단계를 수행한다:
    1. 자격 증명 요청 코디네이터의 활성 프로미스가 promise가 아니면 반환한다.
    2. signal을 자격 증명 요청 코디네이터의 중단 신호로 둔다.
    3. abortAlgorithm을 자격 증명 요청 코디네이터의 중단 알고리즘으로 둔다.
    4. signal이 null이 아니고 abortAlgorithm도 null이 아니면:
      1. abortAlgorithm을 signal에서 제거한다.
    5. 자격 증명 요청 코디네이터의 중단 신호를 null로 설정한다.
    6. 자격 증명 요청 코디네이터의 중단 알고리즘을 null로 설정한다.
    7. promise를 error로 거부한다.
    8. 자격 증명 요청 코디네이터의 활성 프로미스를 null로 설정한다.
    9. 자격 증명 요청 코디네이터의 상호작용 상태를 "유휴"로 설정한다.

6.7 자격 증명 요청 시작

Document document, 검증된 자격 증명 요청 validatedRequests의 리스트, Promise promise, 그리고 선택적 AbortSignal signal이 주어졌을 때 자격 증명 요청을 시작하려면:

  1. topLevelOrigin을 document의 최상위 탐색 가능 객체의 활성 문서의 관련 설정 객체의 오리진으로 둔다.
  2. requestData를 요청이 validatedRequests이고 최상위 오리진이 topLevelOrigin인 새로운 요청 컨텍스트로 둔다.
  3. 병렬로:
    1. requestData를 사용하여 디지털 자격 증명 선택기를 표시하고 다음 결과 중 하나를 기다린다:
      • 사용자가 요청을 충족할 수 있는 디지털 자격 증명 또는 소지자를 선택한다.
      • 사용자가 작업을 취소한다.
      • 플랫폼에서 오류가 발생한다.

      사용자 에이전트가 다른 기기에 있는 자격 증명 관리자와 통신할 때는 사용자 에이전트가 클라이언트 대 인증자 프로토콜(CTAP)을 사용하는 것이 권고된다.

    2. signal이 null이 아니고 signal이 중단된 상태이면:
      1. 반환한다.
        참고: 중단은 이미 처리됨

        자격 증명 요청 준비 단계에서 signal에 추가된 중단 알고리즘이 디지털 자격 증명 선택기를 종료하는 작업을 처리한다.

    3. 사용자가 작업을 취소했거나 자격 증명이 선택되지 않은 경우:
      1. error를 새로 생성한 "NotAllowedError" DOMException으로 둔다.
      2. error 및 promise로 자격 증명 요청을 거부한다.
      3. 반환한다.
    4. 플랫폼이 플랫폼별 오류를 반환하는 경우:
      1. error를 다음과 같이 결정한다:
        사용자 에이전트 또는 플랫폼이 작업을 허용하지 않는 경우:
        새로 생성한 "NotAllowedError" DOMException.
        요청 데이터의 형식이 잘못되었거나 유효하지 않은 경우:
        새로 생성한 TypeError.
        자격 증명 요청이 이미 진행 중인 경우:
        새로 생성한 "InvalidStateError" DOMException.
        그 밖의 경우:
        새로 생성한 "OperationError" DOMException.
      2. error 및 promise로 자격 증명 요청을 거부한다.
      3. 반환한다.
    5. 사용자가 디지털 자격 증명을 선택한 경우:
      1. protocol을 이 교환에 대해 디지털 자격 증명 선택기가 반환한 프로토콜 식별자로 둔다.
        참고: 프로토콜은 플랫폼이 결정함

        디지털 자격 증명 선택기 또는 기반 플랫폼은 validatedRequests의 어떤 항목을 소지자에게 전달할지 결정하고 해당 교환의 프로토콜 식별자를 반환한다. 사용자 에이전트는 어떤 특정 항목이 선택되었는지 반드시 알 필요는 없다.

      2. responseData를 문자열 제시 응답 또는 문자열 발급 응답으로 두며, 이는 소지자가 반환한 것이다.
        참고: 응답이 문자열인 이유
      3. document의 관련 전역 객체가 주어졌을 때 DOM 조작 태스크 소스에 전역 태스크를 큐에 추가하여 다음 단계를 수행한다:
        1. 자격 증명 요청 코디네이터의 활성 프로미스가 promise가 아니면 반환한다.
        2. parsedResponseDataOrError를 responseData가 주어졌을 때 JSON 문자열을 JavaScript 값으로 파싱한 결과로 둔다.
        3. abortSignal을 자격 증명 요청 코디네이터의 중단 신호로 둔다.
        4. abortAlgorithm을 자격 증명 요청 코디네이터의 중단 알고리즘으로 둔다.
        5. abortSignal이 null이 아니고 abortAlgorithm도 null이 아니면, abortAlgorithm을 abortSignal에서 제거한다.
        6. 자격 증명 요청 코디네이터의 중단 신호를 null로 설정한다.
        7. 자격 증명 요청 코디네이터의 중단 알고리즘을 null로 설정한다.
        8. parsedResponseDataOrError가 예외이면:
          1. promise를 parsedResponseDataOrError로 거부한다.
        9. 그 밖에 parsedResponseDataOrError가 객체가 아니면:
          1. promise를 새로 생성한 TypeError로 거부한다.
        10. 그 밖의 경우:
          1. credential을 새로 생성한 DigitalCredential 인스턴스로 두고, 그 data는 parsedResponseDataOrError로 초기화하고 protocol은 protocol로 초기화한다.
          2. promise를 credential로 이행한다.
        11. 자격 증명 요청 코디네이터의 활성 프로미스를 null로 설정한다.
        12. 자격 증명 요청 코디네이터의 상호작용 상태를 "유휴"로 설정한다.

7. 디지털 자격 증명 API

디지털 자격 증명 API는 자격 증명 관리 레벨 1 명세를 활용하여 사용자 에이전트가 발급 및 제시를 디지털 자격 증명에 대해 중개할 수 있도록 합니다.

이 API를 사용하면 사용자 에이전트에 요청하여 디지털 자격 증명을 받을 수 있으며, 그러면 사용자 에이전트는 사용자에게 디지털 자격 증명 선택기를 제시하여, 사용자가 요청을 충족할 수 있는 디지털 자격 증명을 선택할 수 있도록 합니다. 이는 웹사이트에서 navigator.credentials.get() 메서드를 호출하여 수행하며, 이 메서드는 자격 증명 관리 레벨 1의 Credential 요청 알고리즘을 실행합니다. 그러면 해당 알고리즘은 이 명세의 DigitalCredential 인터페이스의 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 내부 메서드를 다시 호출합니다.

또한 이 API를 사용하면 발급을 요청하여 디지털 자격 증명을 받을 수도 있으며, 그러면 사용자에게 자격 증명 관리자 선택기를 제시하여, 사용자가 자격 증명 관리자를 선택하여 디지털 자격 증명을 저장할 수 있도록 합니다. 이는 navigator.credentials.create() 메서드를 호출하여 수행하며, 이 메서드는 자격 증명 관리 레벨 1의 자격 증명 생성 알고리즘을 실행합니다. 그러면 해당 알고리즘은 이 명세의 DigitalCredential 인터페이스의 [[Create]](origin, options, sameOriginWithAncestors) 내부 메서드를 다시 호출합니다.

이 API를 통한 디지털 자격 증명 발급은 디지털 자격 증명 제시와 약간 다릅니다. 응답 데이터에는 발급 프로토콜에서 정의한 보유자의 자격 증명 관리자가 반환한 프로토콜별 응답이 포함되며, 실제로 발급된 디지털 자격 증명 자체를 나타내지는 않습니다.

자격 증명 관리 레벨 1 명세와 통합하는 방법에 대한 전체 세부 정보는 자격 증명 관리 통합을 참조하십시오.

7.1 CredentialRequestOptions 딕셔너리 확장 

WebIDLpartial dictionary CredentialRequestOptions {
  DigitalCredentialRequestOptions digital;
};

7.1.1 digital 멤버

digital 멤버를 사용하면 디지털 자격 증명 요청을 구성하는 옵션을 지정할 수 있다.

7.2 DigitalCredentialRequestOptions 딕셔너리 

WebIDLdictionary DigitalCredentialRequestOptions {
  required sequence<DigitalCredentialGetRequest> requests;
};

7.2.1 requests 멤버

requests는 제시 프로토콜과 제시 요청 데이터를 지정하며, 사용자 에이전트는 이를 디지털 지갑과 같은 자격 증명 관리자와 일치시킬 수 있다.

7.3 DigitalCredentialGetRequest 딕셔너리

DigitalCredentialGetRequest 딕셔너리는 제시 요청을 나타낸다. 이 딕셔너리는 제시 프로토콜 및 일부 제시 요청 데이터를 지정하는 데 사용되며, 사용자 에이전트는 이를 디지털 지갑과 같은 자격 증명 관리자와 일치시킬 수 있다. 

WebIDLdictionary DigitalCredentialGetRequest {
  required DOMString protocol;
  required object data;
};

7.3.1 protocol 멤버

protocol 멤버는 제시 프로토콜을 나타낸다.

protocol 멤버의 값은 DigitalCredentialPresentationProtocol에 정의된 프로토콜 식별자 중 하나이다.

7.3.2 data 멤버

data 멤버는 디지털 신원 지갑과 같은 소지자의 자격 증명 관리자가 처리할 제시 요청 데이터이다.

7.4 CredentialCreationOptions 딕셔너리 확장 

WebIDLpartial dictionary CredentialCreationOptions {
  DigitalCredentialCreationOptions digital;
};

7.4.1 digital 멤버

digital 멤버를 사용하면 디지털 자격 증명 발급을 구성하는 옵션을 지정할 수 있다.

7.5 DigitalCredentialCreationOptions 딕셔너리 

WebIDLdictionary DigitalCredentialCreationOptions {
  required sequence<DigitalCredentialCreateRequest> requests;
};

7.5.1 requests 멤버

requests는 발급 프로토콜 및 발급 요청 데이터를 지정하며, 사용자 에이전트는 이를 소지자에게 전달할 수 있다.

7.6 DigitalCredentialCreateRequest 딕셔너리

DigitalCredentialCreateRequest 딕셔너리는 발급 요청을 나타낸다. 이는 발급 프로토콜과 일부 발급 요청 데이터를 지정하여 발급자와 소지자 사이에 발급 요청을 전달하는 데 사용된다. 

WebIDLdictionary DigitalCredentialCreateRequest {
  required DOMString protocol;
  required object data;
};

7.6.1 protocol 멤버

protocol 멤버는 발급 프로토콜을 나타낸다.

protocol 멤버의 값은 DigitalCredentialIssuanceProtocol에 정의된 프로토콜 식별자 중 하나이다.

7.6.2 data 멤버

data 멤버는 디지털 신원 지갑과 같은 소지자의 자격 증명 관리자가 처리할 발급 요청 데이터이다.

7.7 DigitalCredential 인터페이스

DigitalCredential 인터페이스는 개념적인 디지털 자격 증명을 나타낸다.

DigitalCredential 인터페이스는 사용자의 제어와 동의를 보장하기 위해 모든 작업에 사용자 중개를 요구한다.

DigitalCredential과 관련된 get() 호출에서 개발자 경험을 단순화하기 위해, 사용자 에이전트는 mediation 멤버가 없거나 그 값이 "required"가 아니더라도 오류를 던져서는 안 된다. 마찬가지로 DigitalCredential과 관련된 create() 호출에서도 사용자 에이전트는 mediation 멤버가 없거나 그 값이 "required"가 아니더라도 오류를 던져서는 안 된다. 이로써 "required" 중개는 API의 암시적이며 재정의할 수 없는 동작이 된다. 

WebIDLtypedef (DigitalCredentialPresentationProtocol or DigitalCredentialIssuanceProtocol) DigitalCredentialProtocol;

[Exposed=Window, SecureContext]
interface DigitalCredential : Credential {
  [Default] object toJSON();
  readonly attribute DigitalCredentialProtocol protocol;
  [SameObject] readonly attribute object data;
  static boolean userAgentAllowsProtocol(DOMString protocol);
};

DigitalCredential 인스턴스는 출처에 바인딩되어 있습니다.

7.7.1 protocol 멤버

protocol 멤버는 디지털 자격 증명을 요청하는 데 사용된 제시 프로토콜 또는 디지털 자격 증명을 발급하는 데 사용된 발급 프로토콜이다.

7.7.2 data 멤버

data 멤버는 자격 증명의 응답 데이터이다. 여기에는 JSON으로 파싱할 수 있는 객체 유형의 하위 집합이 포함된다.

7.7.3 userAgentAllowsProtocol() 메서드

userAgentAllowsProtocol() 메서드를 사용하면 디지털 자격 증명 검증자가 사용자 에이전트가 어떤 제시 프로토콜 및 발급 프로토콜을 허용하는지 확인할 수 있다.

참고

이 메서드는 기반 OS/플랫폼에서의 제시 프로토콜 또는 발급 프로토콜 지원 여부를 전달하지 않는다.

사용자 에이전트는 하드웨어 가용성, 소프트웨어의 존재 또는 구성, 자격 증명 관리자 또는 디지털 자격 증명, 사용자 구성이나 기본 설정에 관한 정보에 따라 응답 값을 변경해서는 안 된다. 응답 값이 달라진다면 사용자 에이전트는 지문 채취와 사용자 행동 또는 구성에 관한 다른 세부 정보를 은밀하게 드러낼 위험을 모두 초래하게 된다. 응답 값은 사용자 에이전트의 주요 버전에 따라서만 달라지는 것이 권고되며, 브라우저가 해당 프로토콜을 사용하는 요청을 기반 플랫폼 또는 공급자에 배포할 수 있는지를 나타내야 한다.

DOMString protocol이 주어졌을 때 사용자 에이전트가 프로토콜을 허용하는지 확인하려면 다음 단계를 수행한다:

  1. protocol이 DigitalCredentialProtocol의 열거형 값이 아니면 false를 반환한다.
  2. 사용자 에이전트가 protocol을 허용하면 true를 반환하고, 그렇지 않으면 false를 반환한다.

이 메서드가 호출되면 사용자 에이전트는 protocol이 주어졌을 때 사용자 에이전트가 프로토콜을 허용하는지의 결과를 반드시 반환해야 한다.

7.8 지원 데이터 구조

이 명세에서 DigitalCredential을 지원하는 열거형 등의 데이터 구조.

7.8.1 요청 컨텍스트 구조체

요청 컨텍스트는 다음 항목을 갖는 구조체이다:

요청
검증된 자격 증명 요청의 리스트.
최상위 오리진
환경 설정 객체의 오리진.

7.8.2 DigitalCredentialPresentationProtocol 열거형

이 열거형의 값은 5. 프로토콜에 나열된 지원되는 제시 프로토콜에 대응한다. 

WebIDLenum DigitalCredentialPresentationProtocol {
  "openid4vp-v1-unsigned",
  "openid4vp-v1-signed",
  "openid4vp-v1-multisigned",
  "org-iso-mdoc"
};

7.8.3 DigitalCredentialIssuanceProtocol 열거형

이 열거형의 값은 5. 프로토콜에 나열된 지원되는 발급 프로토콜에 대응한다. 

WebIDLenum DigitalCredentialIssuanceProtocol {
  "openid4vci-v1",
};

8. 자격 증명 관리 레벨 1과의 통합

8.1 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 내부 메서드

호출되었을 때, [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 내부 메서드는 사용자 에이전트가 제시 요청을 지원하지 않는 경우(예: 플랫폼이 디지털 자격 증명 선택기를 제공할 수 없는 경우), 동일한 인수로 Credential의 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 내부 메서드의 기본 구현을 호출한다. 그 밖의 경우:

  1. requests를 options의 digital의 requests 멤버로 둔다.
  2. requests를 requests가 주어졌을 때 자격 증명 요청을 필터링한 결과로 설정한다.
  3. requests가 비어 있으면, 새로 생성한 TypeError로 거부된 프로미스를 반환한다.
  4. signal을 options의 signal로 두되, 존재하는 경우에만 그렇게 한다.
  5. global을 this의 관련 전역 객체로 둔다.
  6. global, origin, requests 및 signal이 주어졌을 때 자격 증명 요청을 준비한 결과를 반환한다.

8.2 [[Store]](credential, sameOriginWithAncestors) 내부 메서드

호출되었을 때 [[Store]](credential, sameOriginWithAncestors)는 동일한 인수로 Credential의 [[Store]](credential, sameOriginWithAncestors) 내부 메서드의 기본 구현을 반드시 호출해야 한다.

8.3 [[Create]](origin, options, sameOriginWithAncestors) 내부 메서드

호출되었을 때 [[Create]](origin, options, sameOriginWithAncestors) 내부 메서드는 사용자 에이전트가 발급 요청을 지원하지 않는 경우, 동일한 인수로 Credential의 [[Create]](origin, options, sameOriginWithAncestors) 내부 메서드의 기본 구현을 호출한다. 그 밖의 경우:

  1. requests를 options의 digital의 requests 멤버로 둔다.
  2. requests를 requests가 주어졌을 때 자격 증명 요청을 필터링한 결과로 설정한다.
  3. requests가 비어 있으면, 새로 생성한 TypeError로 거부된 프로미스를 반환한다.
  4. signal을 options의 signal로 두되, 존재하는 경우에만 그렇게 한다.
  5. global을 this의 관련 전역 객체로 둔다.
  6. global, origin, requests 및 signal이 주어졌을 때 자격 증명 요청을 준비한 결과를 반환한다.

8.4 [[type]] 내부 슬롯

DigitalCredential 인터페이스 객체에는 [[type]]이라는 내부 슬롯이 있으며 그 값은 "digital"이다.

8.5 [[discovery]] 내부 슬롯

DigitalCredential 인터페이스 객체에는 [[discovery]]라는 내부 슬롯이 있으며 그 값은 "remote"이다.

8.6 사용자 권한

이 절은 비규범적이다.

디지털 자격 증명 API는 최종 사용자의 명시적 권한을 요구하는 강력한 기능이다. 이 요구 사항은 CredentialsContainer의 get() 메서드를 호출할 때 규범적으로 적용된다.

9. 권한 정책 통합

이 명세는 두 가지 정책 제어 기능을 정의한다:

"digital-credentials-get"
문서가 디지털 자격 증명을 요청할 수 있도록 하는 정책 제어 기능. 그 기본 허용 목록은 'self'이다. Credential 요청 알고리즘이 정책 적용 지점 역할을 한다.
"digital-credentials-create"
문서가 디지털 자격 증명을 발급할 수 있도록 하는 정책 제어 기능. 그 기본 허용 목록은 'self'이다. Credential 생성 알고리즘이 정책 적용 지점 역할을 한다.

10. 보안 고려 사항

이 절은 비규범적이다.

다음 절에서는 API의 보안 속성, 범위에 포함되는 위협, 보안이 의존하는 가정, 그리고 완화책이 적용된 후에도 남아 있는 잔여 위협을 설명한다. 이 명세는 자격 증명 응답을 중개할 때의 사용자 에이전트 동작에 대해서만 요구 사항을 정의한다.

참고

프로토콜, 자격 증명 관리자 구현, 운영 체제 또는 전송 보안에 의존하는 기타 보안 고려 사항은 기대 사항 또는 전제 조건으로 설명되지만, 이미 규범적으로 명시되어 있지 않는 한 이 명세에서 규범적으로 요구하지 않는다.

10.1 위협 모델

이 명세의 위협 모델에는 이 API와 생태계의 인접 표준에 대한 위협이 포함된다.

이 명세에서 위협은 두 범주로 나뉜다: 범위 내 위협과 범위 외 위협.

10.1.1 범위 내 위협

범위 내 위협은 DC API 자체가 도입하거나 다루는 위협이다. 다음은 이 명세의 범위 내 위협이다:

요청 변조
안전하지 않은 컨텍스트에서 페이지 콘텐츠를 삽입하거나 수정할 수 있는 네트워크 공격자가 처리 전에 DigitalCredentialGetRequest 또는 DigitalCredentialCreateRequest를 변경하려고 시도한다.
API 플러딩
악성 웹사이트가 시스템 리소스를 고갈시키거나, 사용자를 혼란스럽게 하거나, 불필요한 자격 증명 상호작용을 만들거나, 사용자 경험을 저하시키는 프롬프트 피로를 유발하기 위해 빠르고 반복적인 요청을 보내 API를 압도하려고 시도한다. 여기에는 페이지 로드 중이나 의미 있는 사용자 컨텍스트가 없는 경우처럼 부적절한 시점에 요청하는 것도 포함된다.
승인되지 않은 교차 오리진 접근
악성 웹사이트가 iframe과 같은 삽입된 서드파티 콘텐츠를 통해 삽입 사이트의 명시적 허가 없이 디지털 자격 증명을 요청하거나 발급하려고 시도하여, 자격 증명 수집 또는 민감한 사용자 데이터에 대한 승인되지 않은 접근을 가능하게 할 수 있다.
기반 플랫폼에 대한 악성 페이로드
악성 웹사이트는 API를 통해 신중하게 조작되거나 잘못된 형식의 프로토콜 요청을 전달하여 기반 운영 체제 또는 자격 증명 관리자의 취약점을 악용하려고 시도한다.

10.1.2 범위 외 위협

범위 밖 위협은 프로토콜, 자격 증명 관리자, OS 플랫폼 보안 또는 전송 계층에서 처리되는 위협이다. "범위 밖"이라 하더라도 자격 증명 제시 및 발급의 종단 간 보안에 영향을 미치므로 관련성이 있다. 다음은 이 명세의 범위 밖 위협을 정의한다:

OS 또는 기기 침해
사용자의 운영 체제 또는 기기 하드웨어에 대한 제어권을 획득한 공격자는 사용자 에이전트의 보호 기능을 우회하거나, 저장소에서 민감한 자격 증명 데이터를 직접 추출하거나, API 호출을 조작할 수 있습니다. 이 위협은 OS 플랫폼 보안 및 하드웨어 기반 키 저장소를 통해 대응합니다.
악의적인 자격 증명 관리자
사용자는 의도적으로 데이터를 유출하거나, 자격 증명을 안전하게 암호화하지 못하거나, 사용자 동의를 무시하는 자격 증명 관리자를 설치하거나, 기관의 의무 규정 또는 필수 서비스를 통해 사용하도록 강요받을 수 있습니다. API는 명시적인 사용자 권한을 통해 지갑을 선택하기 전에 사용자를 보호하지만(다음 참조: 11.6 사용자 권한 및 투명성), 사용자가 요청을 처리하도록 승인한 이후에는 자격 증명 관리자의 내부 동작을 통제할 수 없습니다. 이 위험을 완화하려면 OS 플랫폼 보안, 앱 스토어 심사, 그리고 지갑 제공자를 규율하는 법률/규제 체계가 필요합니다.
프로토콜 및 형식 취약점
사용되는 특정 프레젠테이션 프로토콜, 발급 프로토콜, 또는 자격 증명 형식의 취약점(예: 암호학적 결함, 안전하지 않은 알고리즘, 재전송 방지 기능 부족 또는 요청 인증 누락)으로 인해 공격자가 전송 중인 자격 증명을 가로채거나, 위조하거나, 변조할 수 있습니다. 완화는 주로 프로토콜, 형식 및 전송 계층에서 이루어집니다(예: 응답 암호화, 요청 서명 및 TLS를 의무화하는 방식). API는 형식별 암호화를 정의하거나 프로토콜 페이로드의 암호학적 안전성을 검사하지 않지만, 지원되는 프로토콜에 기본 보안 기준을 적용합니다(예: 응답 암호화를 요구하고 서명된 요청을 권장함)으로써 요청이 가장 안전한 경로를 통하도록 유도합니다.

10.2 완화책

다음 완화 조치는 명세의 규범적 요구사항을 통해 범위 내 위협에 대응합니다.

Digital Credential API의 WebIDL 인터페이스는 보안 컨텍스트에서만 노출되어, 변조가 안전하지 않은 컨텍스트를 통해 발생할 위험을 줄입니다(예: 악성 스크립트가 네트워크를 통해 삽입되는 경우). 자세한 내용은 § 5 보안 고려사항 절의 보안 컨텍스트 명세를 참조하십시오.

기반 플랫폼에 대한 악성 페이로드의 위험을 완화하기 위해, 사용자 에이전트는 요청 매개변수를 자격 증명 관리자에 JSON 직렬화를 사용하여 전달합니다(자격 증명 요청 검증 참조). 기반 플랫폼과 자격 증명 관리자는 이러한 프로토콜별 JSON 페이로드에 따라 동작하기 전에 이를 견고하게 파싱하고 검증할 책임이 있습니다.

Digital Credentials API는 다음 두 가지 메커니즘을 통해 API 플러딩을 줄입니다:

자격 증명 요청의 남용을 방지하는 추가 지침은 자격 증명 관리 레벨 1 명세의 § 7 개인정보 보호 고려사항 절을 참조하십시오. 다만 사이트가 여전히 다크 패턴을 사용하여 자격 증명 요청을 트리거하는 불필요한 사용자 상호작용을 유도할 수 있으므로, 이러한 보호에는 한계가 있다는 점에 유의하십시오.

Digital Credentials API는 권한 정책과의 통합을 통해(권한 정책 통합 참조) 교차 출처 남용을 줄입니다. Credential 요청 및 Credential 생성 알고리즘은 각각 "digital-credentials-get" 및 "digital-credentials-create" 정책 제어 기능의 정책 시행 지점 역할을 합니다. 두 기능은 의도적으로 분리되어 있습니다. 사이트는 "digital-credentials-get"을 활성화하면서 "digital-credentials-create"은 활성화하지 않을 수 있으며, 그 반대도 가능하여 각 임베디드 컨텍스트를 필요한 기능으로만 제한합니다. 이 통합이 제공하는 추가 보안 속성은 권한 정책 명세의 권한 정책 절을 참조하십시오.

또한 불투명 출처에서 발생한 요청은 거부됩니다. DigitalCredential 인스턴스는 출처에 바인딩되어 있으므로, 불투명 출처에서 디지털 자격 증명을 요청하거나 생성하는 호출(예: data: 문서 또는 allow-same-origin 없이 샌드박스된 문서)은 자격 증명 관리 레벨 1에 의해 거부되어, 신뢰할 수 없는 환경에서 악의적으로 추출하거나 스푸핑할 위험을 줄입니다.

10.3 프레젠테이션 요청 서명

제시 프로토콜이 요청에 서명하는 방법을 제공하는 경우, 검증자는 이를 사용할 것을 강력히 권장한다.

서명되지 않은 요청은 검증자 자신의 페이지에서 실행되는 스크립트에 의해 변경될 수 있으며, 악성 브라우저 확장 프로그램에 의해 삽입된 스크립트가 그 예이다. 이러한 스크립트는 요청되는 내용을 변경하여, 제한적인 요청을 훨씬 더 많은 것을 요구하는 요청으로 바꿀 수 있으며, 응답을 암호화하는 데 사용되는 매개변수를 바꿔 응답이 검증자가 아니라 공격자에게 암호화되도록 할 수도 있다. API를 보안 컨텍스트에서 사용하도록 요구해도 이를 막을 수 없다. 공격자가 이미 그 안에 있기 때문이다. 서명되지 않은 요청의 경우, 자격 증명 관리자는 검증자가 자신의 페이지에 그러한 스크립트가 없도록 유지했다고 신뢰해야 한다. 반면 서명된 요청은 자격 증명 관리자가 확인할 수 있는 정보를 제공하므로, 변경 사항이 감지되지 않은 채 넘어가는 대신 이를 감지할 수 있다.

그렇더라도 서명은 자격 증명 관리자가 해당 서명이 요청을 수행하는 검증자의 것임을 확인할 수 있는 경우에만 도움이 된다. 페이지 내부의 스크립트는 자신이 보유한 키로 변경된 요청에 다시 서명할 수 있으므로, 해당 서명을 이미 검증자의 것으로 인식된 서명 키와 대조하여 확인할 수 없다면 서명은 이러한 공격자로부터 아무런 보호도 제공하지 않는다. 어떤 서명 키를 허용할지와 그러한 키를 어떻게 설정할지는 이 명세가 아니라 자격 증명이 속한 생태계에서 결정하며, 서명된 요청이 실제로 제공하는 보호 수준은 그 결정에 따라 달라진다. 동일 기기 내 페이지 변조로부터 보호하는 것 외에도, 요청 서명은 여러 기기에 걸쳐 자격 증명을 제시할 때 중요한 심층 방어 기능도 제공한다(다음 참조: 10.4 기기 간 보안 및 근접성).

10.4 장치 간 보안 및 근접성

Digital Credentials API는 사용자가 보조 기기에서 디지털 자격 증명을 제시하는 기기 간 경험을 지원한다. 예를 들어 자격 증명 관리자 역할을 하는 스마트폰에서 주 기기인 노트북으로 제시할 수 있다. 구체적인 데이터 교환 프로토콜(예: 암호화 형식 및 전송 방식)은 이 API의 범위를 벗어나지만, 이러한 기기 간 상호작용은 일반적으로 Client to Authenticator Protocol (CTAP)과 같은 확립된 프로토콜에 의존한다(클라이언트 대 인증자 프로토콜(CTAP)).

이러한 프로토콜은 암호학적으로 안전한 채널을 설정하고 물리적 근접성(예: Bluetooth Low Energy를 통한)을 강제하여 원격 릴레이 공격을 완화함으로써 보안을 보장한다. 특히 기기 간 흐름에서는 자격 증명 관리자가 주 기기에서 전달된 출처 문자열을 본질적으로 신뢰할 수 없다. 주 기기 또는 그 브라우저가 침해되었을 수 있기 때문이다. 따라서 검증자가 자신의 신원을 암호학적으로 증명하는 서명된 요청을 사용하는 프로토콜은 브라우저가 주장한 출처에만 의존하는 것보다 훨씬 더 강력한 보안 보장을 제공한다.

11. 개인정보 보호 고려 사항

이 절은 비규범적이다.

이슈: 개인정보 보호 고려 사항 절은 작업 진행 중

이 절은 이 문서가 발전함에 따라 계속 작업 중이다.

Digital Credentials API는 여러 기술 계층과 다양한 참여자가 있는 복잡한 생태계에 통합된다(여기에는 검증자, 소지자, 발급자 등이 포함되지만 이에 한정되지 않는다). 각 참여자는 사용자 개인정보 보호의 서로 다른 측면을 고려해야 한다. 이 명세는 서로 다른 참여자에 대한 모든 고려 사항을 빠짐없이 나열하려고 하지 않는다. 대신 이러한 당사자에게 디지털 자격 증명의 위협 모델을 보다 전체적으로 다루는 여러 다른 자료를 참조하도록 한다:

대신 이러한 고려 사항은 Digital Credentials API 자체에 초점을 맞추고, 사용자 에이전트가 API 구현에서 상호작용하는 생태계의 관련 개인정보 보호 속성을 고려하면서 사용자 에이전트의 의무를 어떻게 충족할 수 있는지 설명한다.

디지털 자격 증명에 대한 개인정보 보호 고려 사항은 고정되어 있지 않다. 생태계가 성숙함에 따라 시간이 지나면서 발전할 것이며, 생태계의 다른 행위자들의 행동, 스택의 다른 계층에서의 개선, 사용자 개인정보에 대한 새로운 위협, 그리고 변화하는 사회적 규범과 규제의 영향을 받을 수 있다.

Digital Credentials API의 설계 및 구현에 참여하는 여러 그룹은 변화하는 개인정보 보호 환경을 적극적으로 모니터링하고 이에 대응하는 API의 발전에 참여할 것으로 기대된다.

11.1 설계 고려 사항 및 대안

Digital Credentials API는 웹사이트의 디지털 자격 증명 요청을 중개하도록 설계되었으며, 자격 증명 형식과 그 안에 포함된 정보뿐 아니라 이를 교환하는 데 사용되는 프로토콜에도 종속되지 않는다. 이와 다른 주요 설계 선택은 기존 대안(예: [custom-schemes])보다 사용자에게 더 안전하고 개인정보 보호에 유리한 자격 증명 교환 경험을 제공하면서도, 도입이 쉽도록 일반적인 교환 프로토콜과 계속 호환되게 한다는 목표에서 비롯되었다.

이 API는 검증자와 보유자 사이의 연결 인터페이스를 제공한다. 즉, 자격 증명 제시 프로토콜이 시작되고 사용자가 자격 증명을 선택하기 위해 보유자 애플리케이션으로 전환하는 수단을 제공한다. 과거에 이 목적으로 사용된 해결책에는 QR 코드와 사용자 지정 URL 스킴이 포함된다. 웹에서 자격 증명 제시 및 ID 제시에 사용자 지정 스킴을 사용하는 것에 대한 우려 사항에 문서화된 것처럼, 이러한 해결책에는 보안, 프라이버시 및 접근성 관련 우려 사항이 있다.

생태계의 요구와 규제 의무에 의해 디지털 자격 증명 기술의 도입이 추진됨에 따라, Web 플랫폼은 개발자가 쉽게 사용할 수 있고 기존 자격 증명 제시 프로토콜과 호환되며, 가장 중요하게는 앞서 언급한 대안보다 사용자에게 더 나은 프라이버시, 보안 및 접근성 특성을 제공하는 덜 바람직한 기술에 대한 대안을 제공한다.

디지털 자격 증명 API는 사용자 에이전트가 사용자를 대신하여 중개할 수 있는 기능을 제공합니다(예: 디지털 자격 증명 선택기 또는 자격 증명 관리자 선택기 형태로). 이를 통해 요청에 맥락을 부여하고 보유자 애플리케이션에 즉시 노출되는 것을 방지할 수 있습니다. 또한 지원되는 프로토콜에 대해 응답 암호화와 같은 특정 최소 요구 사항도 적용합니다.

참고

11.2 개인정보 보호의 스펙트럼

Digital Credentials API는 서로 다른 수준의 데이터 공개를 요구하는 다양한 사용 사례와, 자신이 처한 컨텍스트에 따라 서로 다른 선호를 가진 개별 사용자를 지원한다. 특히 이 API가 중개하는 자격 증명 교환의 개인정보 보호 속성은 개별 사용자의 법률 및 규제 환경에 의해 의무화될 수도 있다.

이는 일부 사용자가 자격 증명 정보를 교환하는 가장 개인정보 보호 친화적인 수단을 원하지 않거나 사용할 수 없을 수도 있음을 의미한다. 그럼에도 사용자 에이전트는 기본적으로 개인정보를 보호하는 경험을 사용자에게 제공하고 피해로부터 보호해야 한다.

이러한 선호와 사용 사례의 스펙트럼 때문에 사용자 에이전트가 사용자가 자신의 개인 정보를 노출하려는 것인지 아니면 그렇게 하도록 속고 있는지 구별하기 어려울 수 있다. 따라서 교환이 시작되기 전에 모든 사용자가 어떤 데이터를 공유하며 정보 교환에 누가 참여하는지 이해하도록 보장하는 것은 사용자 에이전트의 책임이다.

11.3 제시 프로토콜 및 자격 증명 형식

Digital Credentials API는 여러 독립적인 당사자가 참여하는 교환의 중심에 위치하므로, 이들 당사자가 사용자 정보를 교환하는 데 사용하는 제시 프로토콜과 자격 증명 형식은 사용자 개인정보 보호라는 사용자 에이전트의 목표에 매우 중요하다.

11.3.1 사용자 개인정보 보호를 위한 제시 프로토콜 고려 사항

이슈 255: 지원되는 프로토콜에 대한 구체적인 개인정보 보호 및 보안 요구 사항 정의 privacy-trackersecurity-trackerregistryprivacy-considerationssecurity-considerations

추가 설명이 필요하다고 생각하는 프로토콜 요구 사항은 두 가지이다:

개인정보 보호 검토를 거쳤어야 한다 [...]

그리고

보안 검토를 거쳤어야 한다 [...]

기술적으로는 "이 프로토콜은 모든 면에서 형편없다"라는 검토도 이러한 기준을 충족한다.

프로토콜이 충족해야 하는 구체적인 개인정보 보호 및 보안 요구 사항 집합이 있다면 더 유용할 것이다. 그러면 검토에서 표준이 달성되었는지 여부를 판단할 수 있다. 검토에 주관적인 요소가 있을 수도 있지만, 각 프로토콜이 넘어야 할 최소 기준도 있어야 한다.

이는 현재 포함 기준에 있는 기존 요구 사항 집합을 넘어선다. 지금 당장 포괄적인 목록을 가지고 있지는 않지만, 하나를 개발하는 것은 가능할 것이다. 그리고 일단 개발되면 그 목록은 명세에 포함되어야 한다. 예를 들어 프로토콜은 본거지에 연락하기에 의존하는가? 프로토콜(또는 프로토콜이 전달하는 형식)은 제시의 연결 불가능성을 보장하는가? 아니면 연결 불가능성이 일부 사용 사례에는 의미가 없다는 점을 고려할 때, 어떤 조건에서 API가 프로토콜에 연결 불가능성 제공을 요구하는가? 프로토콜은 어떤 종류의 투명성 기능을 포함하는가? 어떤 종류의 은밀 채널이 허용 가능한가?

11.3.1.1 선택적 공개

선택적 공개는 데이터 최소화를 위한 기본적인 기술로, 보유자가 검증자가 요청한 최소한의 필수 정보만 공유할 수 있도록 한다. 프로토콜은 검증자가 필요한 정확한 클레임을 지정할 수 있도록 하여 선택적 공개를 지원할 것으로 예상된다.

11.3.1.2 연결 불가능한 제시

연결 불가능성은 사용자가 자격 증명의 속성을 여러 번 제시하는 경우, 검증자가 이러한 별도의 제시를 연결하여 동일한 사용자에 관한 것이라고 결론 내릴 수 없도록 보장하는 속성이다 (검증자-검증자 연결 가능성). 또는 검증자가 발급자와 공모하여 자격 증명 관리자에서 발급자로 자격 증명이 교환되었다는 사실을 보고할 수 없도록 하는 속성이다 (검증자-발급자 연결 가능성). 전자는 보유자와 발급자가 유지할 수 있는 속성이다. 예를 들어 개별 검증자를 위해 새로운 자격 증명을 발급하는 방식으로 유지할 수 있다.

후자는 예를 들어 영지식 증명을 통해 달성할 수 있지만, 암호화된 응답과 같은 API의 설계 선택으로 인해 사용자 에이전트가 실제 환경에서 검증자-발급자 연결 불가능성이 달성되었음을 증명하는 것은 불가능하다. 그럼에도 불구하고 프로토콜은 가능한 경우 연결 가능성을 제한하도록 요청된다.

연결 불가능성은 특정 사용자 신원과 연결될 수 없는 속성에 대해서만 고려된다는 점에 유의해야 한다. 이름, 운전면허 번호 또는 전화번호와 같이 본질적으로 연결 가능한 속성은 연결 불가능성의 혜택을 받지 못한다.

Digital Credentials API를 통해 사용자 에이전트는 검증자와 자격 증명 관리자가 연결 불가능한 속성을 교환하도록 지원할 수 있지만, 응답 암호화로 인해 검증자와 자격 증명 관리자 사이에 연결 가능한 정보가 전달되지 않는다고 보장할 수는 없다. 사용자 에이전트는 사용자 권한 경험에서 이 사실을 고려할 것을 권장한다.

이슈 279: 프로토콜 요구 사항으로서의 연결 가능성과 발급자 관여 privacy-tracker

이 API가 목표로 하는 연결 불가능성의 수준은 무엇인가? 특정 연결 불가능성 기능에 대한 지원을 규범적으로 강제할 수 있는가?

11.3.1.3 "본거지에 연락" 메커니즘

"본거지로 연락하기"는 디지털 자격 증명의 제시 또는 검증으로 인해 발급자 또는 다른 중앙 엔터티에 다시 알림이나 통신이 이루어져 개인의 추적 및 프로파일링으로 이어질 수 있는 시나리오를 의미한다.

연결 불가능성과 마찬가지로, 사용자 에이전트가 사용자가 자격 증명 요청을 계속 진행하도록 권한을 부여한 후 발급자가 자격 증명 제시의 생성 또는 검증에 적극적으로 관여하지 않는다고 보장하는 것은 불가능하다. 그 시점부터 이 결정은 자격 증명 관리자에게 달려 있다. 일부 자격 증명 관리자는 사용자 에이전트로 간주될 수 있지만, 일반적으로 사용자 에이전트가 Digital Credentials API를 구현할 때 그 권한 경험을 사용자 확인 전에 자격 증명 관리자에 요청이 노출되는 것을 방지하도록 설계할 것을 권장한다 (여러 협력 사용자 에이전트를 통합할 때의 고려 사항을 염두에 두어야 한다).

프로토콜은 발급자, 자격 증명 관리자 및 검증자가 "본거지로 연락하기" 메커니즘에 대한 의존성을 피하거나 줄일 수 있는 메커니즘을 지원해야 한다.

이슈 279: 프로토콜 요구 사항으로서의 연결 가능성 및 발급자 관여 privacy-tracker

이 API의 목표는 어느 수준의 연결 불가능성인가? 명세는 어느 정도까지 발급자의 관여를 제한하도록 요구할 수 있는가?

11.3.1.4 연결 불가능한 철회

자격 증명 교환에서 발급자가 관여하는 일반적인 사례는 자격 증명 철회 검사이다. 이는 특히 제시가 검증자-발급자 간 연결 불가능성을 갖도록 의도된 경우 어려운 문제이다. 예를 들어 영지식 증명을 사용해 자격 증명 제시를 연결 불가능하게 만드는 경우, 프로토콜에서 사용하는 자격 증명 형식은 암호학적 누산기와 같은 오프라인 철회 방법을 지원할 것으로 기대된다. 또한 프로토콜 설계와 명세는 가능한 경우 철회 목적으로 검증자가 관여하는 것을 억제할 것으로 기대된다.

이슈 280: 프로토콜에 연결 불가능한 철회 지원을 요구할 수 있는가? privacy-trackerregistry

연결 불가능한 철회 기법이 규범적으로 요구할 만큼 실용적인지 논의해야 한다.

11.3.1.6 검증자 권한 부여 지원

검증자 권한 부여는 검증자가 자신의 신원을 증명하고 특정 속성 또는 자격 증명을 요청할 정당한 권한이 있음을 입증하는 과정을 의미한다. 이는 정부가 발급한 자격 증명과 같은 민감한 데이터를 교환할 때 특히 유용하다. 검증자 권한 부여는 불필요하거나 악의적인 자격 증명 요청을 제한하고, 검증자의 접근이 등록한 특정 자격 증명 속성으로 제한되도록 보장할 수 있다.

검증자 권한 부여 확인은 일반적으로 자격 증명 관리자가 처리하지만, 사용자 에이전트는 이러한 체계의 존재가 API 남용을 방지하고 충분한 정보를 바탕으로 한 사용자 권한 경험을 설계하는 데 도움이 된다고 판단할 수 있다.

이슈 281: 승인된 검증자만 지원하는 사용자 에이전트(정부 자격 증명용) privacy-tracker

사용자 에이전트가 검증자 권한 부여를 이해할 수 있도록 하는 조항을 프로토콜에 포함하도록 요구해야 하는가?

11.3.1.7 자격 증명 응답 암호화

"전송" 중에 사용자 정보가 다른 당사자에게 노출되는 것을 방지하기 위해, 예를 들어 검증자 페이지에 로드된 브라우저 확장 프로그램으로부터 보호하고, 검증자가 사용자 자격 증명을 안전하게 저장하도록 장려하기 위해, 프로토콜은 자격 증명 교환에서 암호화된 응답을 지원하고 의무화해야 한다.

이슈 109: 응답 암호화를 필수로 해야 하는가 discussionpending closureprivacy-trackersecurity-tracker

#49 및 지금까지 있었던 여러 다른 논의와 관련됨: 응답이 항상 암호화되어야 한다고 할 것인가 (그렇다면 어떤 알고리즘을 사용할 것인가), 아니면 이를 선택 사항으로 두어도 괜찮은가?

11.4 불필요한 자격 증명 요청

불필요한 자격 증명 요청은 전체 디지털 자격 증명 생태계의 주요 개인정보 보호 위험이다. 이는 다양한 방식과 다양한 동기로 나타날 수 있다:

여기서 한 가지 어려움은 무엇이 "유효한" 목적을 구성하며 따라서 어떤 요청이 "불필요한"지 판단하는 것으로, 자격 증명 교환에 참여하는 모든 당사자의 참여가 필요하다.

불필요한 사용을 판단하고 대응하는 방법을 더 자세히 살펴보려면 정부가 발급한 자격 증명과 그 밖의 자격 증명을 별도로 고려하는 것이 타당하다. 이들은 데이터의 민감도와 오용으로 인해 발생할 수 있는 피해뿐 아니라 법적 및 규제상 고려 사항에서도 잠재적으로 차이가 있기 때문이다.

두 유형의 자격 증명 모두에 적용되는 위험 완화와 사용자 통제 보장의 핵심 요소는 사용자 에이전트가 자격 증명 요청 메타데이터를 검사하고 이를 바탕으로 결정하거나 UI 표시를 구성할 수 있는 능력이다. 이 명세는 요청을 암호화하지 않은 상태로 전송하고 관련 정보를 포함하도록 하는 프로토콜 요구 사항을 통해 이러한 사용자 에이전트의 접근을 보장한다(다음 참조: 5. 프로토콜 및 6.2 자격 증명 요청 준비).

11.4.1 정부 발급 자격 증명

정부 발급 디지털 자격 증명에는 여행 문서, 개인 면허, 복지 및 공중 보건 프로그램 증명, 차량 등록증, 그리고 정부 기관이 발급한 기타 문서 또는 이러한 정보를 나타내는 다른 문서가 포함된다. 이러한 문서는 개인의 신원과 필수 공공 서비스와 상호작용할 수 있는 능력의 핵심이 되는 영구적이고 취소할 수 없으며 고유한 식별자를 포함할 수 있기 때문에 매우 민감하다.

11.4.1.1 정부 자격 증명의 도난 및 유출 위험

이러한 자격 증명이 사용자와 공격자에게 높은 가치를 지니므로 도난 위험이 크고 승인되지 않은 서드파티에 유출될 경우 잠재적인 피해도 상당하다. 여기에는 추적 및 개인화를 목적으로 정부 신원을 요청하는 것도 포함된다.

11.4.1.2 정부 자격 증명 요청 확산의 위험

온라인에서 정부 자격 증명을 더 쉽게 이용할 수 있게 되면서 발생하는 주요 우려 중 하나는 제번스의 역설이다. 즉, 접근 마찰이 줄어들면서 자격 증명에 대한 수요가 증가할 가능성이다. 이러한 효과는 본질적으로 Digital Credentials API 자체가 유발하는 것이 아니라 생태계 전체에서 디지털 자격 증명의 채택이 증가하면서 발생하는 것이다. 다만 사용자 에이전트가 Digital Credentials API를 구현하면 이러한 추세가 더 가속될 가능성이 있다. 따라서 API를 구현하는 사용자 에이전트는 이 효과를 고려해야 한다. 사용자에게 해로운 결과를 초래할 수 있기 때문이다:

  • 정보 유출 위험 증가와 궁극적으로 웹에서의 신뢰도 낮은 사용자 경험. 많은 서비스가 정부 발급 자격 증명에 접근하여 안전하지 않은 방식으로 저장하는 경우 (즉, 암호화를 유지하지 않거나 개인 키를 제대로 보호하지 못하는 경우), 데이터 유출과 승인되지 않은 접근 가능성도 증가한다. 생년월일과 우편번호처럼 겉보기에는 식별 정보가 아닌 정보조차 함께 결합하면 통계적으로 개인을 식별할 수 있다.
  • 많은 웹사이트가 개인 정보 공유를 요구하면서 사용자에게 발생하는 프롬프트 피로와 신뢰 상실.
  • 감시 가능성 증가와 온라인 서비스의 가명 사용에 대한 제한. 검증자와 발급자 또는 다른 당사자가 공모하면 웹에서 사용자의 활동을 면밀히 감시하고 해당 개인에게 불리한 조치를 취할 수 있게 될 수 있다. 실제로 아무 조치도 취해지지 않더라도 감시 가능성만으로 불안, 불편함 및 위축과 자기 검열 같은 행동 변화가 발생하여 개인의 자율성과 표현의 자유에 영향을 줄 수 있다.
  • 이러한 자격 증명을 제공할 수 없거나 제공하고 싶지 않은 개인에 대한 배제와 차별로 인해, 과거에는 정부 발급 자격 증명을 요구하지 않았던 웹의 포럼 및 소셜 미디어 플랫폼 같은 서비스에 참여하지 못하게 될 수 있다.
11.4.1.3 불필요한 정부 자격 증명 요청 완화

위에서 설명한 정부 발급 디지털 자격 증명의 위험은 생태계의 단일 참여자만으로 해결할 수 없는 문제이며, 현실 세계의 자격 증명을 통해 온라인 서비스에 접근하는 것의 위험과 이점에 관해 각 주권 국가 내에서 더 폭넓은 정책 논의가 필요하다.

디지털 자격 증명을 발급하는 정부가 그 자격 증명을 어떤 방식과 어떤 목적으로 사용할 수 있는지 명확하게 정의하는 법률과 규정도 제정하는 것이 바람직하다. 교환에 참여하는 모든 당사자는 법적으로 의무가 있든 없든 간에, 존재하는 경우 정부의 검증자 인증 체계를 지원하는 것이 권고된다. 검증자 인증 체계(예: EUDI 접근 및 등록 인증서)를 지원하고 통합하면 불필요한 자격 증명 요청 확산의 위험을 완화할 수 있다. 그러나 이러한 체계가 항상 존재하는 것은 아니므로 자격 증명 교환의 위험이 크게 증가한다.

Digital Credentials API를 구현하는 사용자 에이전트가 위험을 줄이고 사용자의 이해를 높이며 특정 유형의 피해를 방지하기 위해 취할 수 있는 다른 실질적인 조치도 있다:

  • 선택적 공개와 기타 데이터 최소화 기법을 지원하는 프로토콜만 지원하면 정보 유출의 영향과 가능성을 줄이고, 권한 및 동의 흐름에서 사용자에게 더 나은 맥락을 제공할 수 있다.
  • 영지식 증명과 같은 연결 불가능성 메커니즘을 허용하는 프로토콜을 지원하면 발급자를 숨김으로써 검증자 기반 감시와 잠재적인 차별을 방지할 수 있다.
  • 유용한 맥락과 명확하게 이해할 수 있는 권한 흐름을 제공하면 사용자가 자격 증명 교환을 수락할지 여부를 더 잘 판단할 수 있으며, 구체적인 사용자 필요 없이 이루어지는 교환 요청의 실효성을 낮출 수 있다.

또한 사용자 에이전트가 이러한 완화책의 부재를 고려한 권한 경험을 설계하는 것이 매우 중요하다. 예를 들어 어떠한 검증자 인증 체계도 없는 상태에서 정부 자격 증명의 개인 정보를 교환하는 경우이다. 이러한 유형의 교환에는 더 높은 수준의 마찰과 관련 위험을 강조하는 명확한 사용자 메시지를 적용하는 것이 권고된다.

11.4.2 비정부 발급 자격 증명

비정부 발급 자격 증명에는 정부가 발급하지 않았으며 정부 발급 문서를 나타내지도 않는 모든 기타 디지털 문서, 인증서 및 증명이 포함된다. 여기에는 재직 증명, (비정부) 교육 자격 증명 또는 영화 티켓 등이 포함될 수 있다. 특히 이러한 자격 증명의 교환은 법률과 규제에 의해 제한되는 정도가 더 낮을 가능성이 있다. 이러한 문서는 흔히 정부 발급 자격 증명과 동일한 위험을 보이지는 않지만, 식별 가능하거나 민감한 정보를 포함할 수도 있다.

11.4.2.1 비정부 자격 증명의 도난 및 유출 위험

비정부 자격 증명의 도난과 유출이 미치는 영향과 실현 가능성은 각 자격 증명 유형의 콘텐츠에 크게 좌우된다. 일반적으로 이는 민감한 개인 정보에 대한 통제권 상실과 노출뿐만 아니라 사칭과 데이터 도난으로 이어져 영향을 받은 개인에 대한 추가 공격 가능성을 높일 수 있다.

11.4.2.2 비정부 자격 증명 요청 확산의 위험

비정부 자격 증명의 유연성과 규제 부족은 이메일 주소나 전화번호와 같은 장기 식별자를 통한 교차 사이트 추적 및 신원 연결 목적으로 악용될 가능성을 갖는다. 디지털 자격 증명 기반 추적 체계에 참여하는 검증자는 사용자가 자신의 개인정보에 미치는 영향을 충분히 이해하지 못한 채 여러 사이트에서 식별자 자격 증명을 공유하도록 유도하는 인센티브("웹용 로열티 카드")를 만들 수 있다.

이러한 체계에서 자신의 정보를 공유하고 싶지 않은 사용자조차 프롬프트 피로의 영향을 받고 해당 서비스 이용에서 배제될 위험이 있을 수 있다.

11.4.2.3 불필요한 비정부 자격 증명 요청 완화

비정부 발급 자격 증명의 경우 사용자 에이전트가 요청된 자격 증명 형식과 개인정보 보호 속성을 이해하고, 사용자에게 표시되는 맥락과 각 자격 증명 유형에 적합한 마찰 수준을 결정하는 위험 프레임워크를 구축하는 것이 권고된다. 이러한 자격 증명의 교환에 사용되는 프로토콜과 형식은 일반적으로 선택적 공개와 연결 불가능성 같은 기능을 지원할 것으로 기대되지만, 특히 영화 티켓과 같이 위험이 낮은 자격 증명의 정보를 교환할 때는 이러한 기능이 항상 적절하거나 필요하지 않을 수 있다.

요청 중인 자격 증명 유형을 인식하는 사용자 에이전트는 해당 자격 증명에 가장 적합하도록 권한 경험을 맞춤화하고, 사용자가 이를 공유했을 때의 결과를 이해할 수 있도록 돕는 것이 권장된다.

사용자 에이전트가 모든 자격 증명 요청을 이해할 수 있을 것으로 기대해서는 안 된다. 요청 중인 자격 증명의 유형을 인식하지 못하는 사용자 에이전트는 권한 경험에서 사용자의 마찰을 크게 늘리고, 알 수 없는 자격 증명을 웹사이트와 공유할 때의 위험을 사용자에게 명확하게 전달하는 것이 권고된다. 적절한 수준의 마찰과 투명성을 적용하려면 서로 다른 사용자 에이전트 간 통합이 필요할 수 있다는 점에 유의하라. 예를 들어 브라우저는 자격 증명 요청에 대한 지식을 운영 체제에 위임할 수 있으며, 운영 체제는 자격 증명 관리자가 알려진 자격 증명 유형을 등록하도록 요구하고 알 수 없는 자격 증명 유형의 교환 요청을 거부하도록 할 수 있다.

이슈 100: 사용자 에이전트 요청 검증과 관련하여 견고성 원칙 적용 고려 discussionprivacy-considerations

사용자에게 적절한 투명성을 제공해야 한다는 필요는 명시적인 사용자 에이전트의 동의 없이도 생태계가 새로운 자격 증명 형식을 개발할 수 있게 하려는 바람과 충돌한다.

11.4.2.4 악용 신고
이슈 267: 자격 증명 요청 악용 신고 privacy-trackerprivacy-considerations

불필요하고 악의적인 요청을 하는 검증자를 위한 상호운용 가능한 악용 신고 시스템을 고려한다.

11.5 지문 채취 및 데이터 유출

11.5.1 브라우저 지문 채취

API는 권한 프롬프트 없이 사용자 데이터가 절대로 공유되지 않도록 보장하지만([[[#user-permission-and-transparency|사용자 권한 및 투명성]] 절 참조), Digital Credentials API가 반환할 가능성이 높은 현실 세계 식별자의 수명과 고유성 때문에 추적자와 지문 채취자의 잠재적 대상이 될 수 있다.

선택적 공개를 사용하더라도 공격자는 디지털 자격 증명의 데이터(예: 사용자의 연령 또는 자격 증명 발급자, 타임스탬프; [[[#leaking-incidental-data|부수적 데이터 유출]] 절 참조)를 결합하여 사용자를 다시 식별하거나 지문을 채취할 수 있다.

이 공격은 서드파티 공격자(예: 검증자의 페이지에 삽입되었지만 추적 목적으로 적극적으로 협력하지는 않는 스크립트)에게는 더 어려울 수 있다. 응답 암호화가 필수이고 응답은 검증자의 서버에서 복호화되어야 하기 때문이다. 따라서 검증자는 복호화된 정보를 클라이언트 측 JavaScript에 다시 반영하지 않도록 할 수 있다. 그러나 모든 검증자가 그렇게 하기로 선택하는 것은 아니다.

11.5.2 자격 증명 제시를 통한 부수적 데이터 유출

자격 증명의 진위를 보장하기 위해, 이를 검증자에게 제시할 때는 일반적으로 검증자가 접근을 요청하는 콘텐츠보다 더 많은 정보가 포함된다. 일반적으로 최소한 발급자와 자격 증명 관리자의 서명과, 잠재적으로 다른 메타데이터도 포함된다.

이러한 추가 정보는 사용자를 재식별하고 핑거프린팅하는 데 사용될 수 있으며, 이는 그 밖의 경우에는 연결 불가능한 제시가 이루어질 때 특히 중요하다.

Digital Credentials API는 자격 증명 응답의 콘텐츠를 제어하지 않지만, 사용자 에이전트는 요청된 것 이외에 어떤 정보가 검증자와 공유될 가능성이 있는지를 명확하게 강조하고, 더 광범위하게는 검증자가 API를 통해 수행하는 핑거프린팅을 식별하고 차단함으로써 이러한 유형의 추적으로부터 사용자를 보호하는 데 도움을 줄 수 있다.

11.5.3 프로토콜 가용성을 통한 기기 속성 노출

Digital Credentials API는 어떤 제시 및 발급 프로토콜이 사용자 에이전트에서 지원되는지에 관한 정보를 userAgentAllowsProtocol()을 통해 노출한다. 이는 예를 들어 사용자의 기기에 어떤 자격 증명 관리자 애플리케이션이 설치되어 있는지에 따라 응답을 맞춤화하지 않음으로써 브라우저 핑거프린팅과 사용자 기기 구성에 관한 정보의 노출을 완화한다. 따라서 반환되는 정보는 기껏해야 사용자 에이전트 버전과 동등한 수준이다.

11.5.4 자격 증명 가용성 유출 방지

Digital Credentials API는 사이트가 먼저 사용자 권한 흐름을 거치지 않고 자격 증명의 사용 가능 여부를 알아낼 수 있게 하지 않는다. 자격 증명의 존재를 노출하면 사용자 개인정보 보호에 위험이 된다. 자격 증명의 존재 자체가 사용자가 사이트와 공유하고 싶지 않았을 수 있는 개인 정보이며, 다른 신호와 결합하면 사용자 허가 없이 사용자를 식별하는 데 사용될 수 있기 때문이다. 또한 웹사이트가 서비스 접근을 위해 사용자에게 이러한 자격 증명의 제시를 점점 더 요구하기 시작하여 자격 증명을 제시하고 싶지 않은 개인을 배제할 수 있으므로 표현의 자유에도 위험이 된다.

이 보호가 견고하게 유지되도록 하기 위해, API가 반환하는 오류는 서로 다른 오류 유형이나 타이밍 공격과 같은 관찰 가능한 차이를 통해 사용자가 이용할 수 있는 자격 증명에 관한 정보를 유출하지 않습니다. 예를 들어, 사용자에게 일치하는 자격 증명이 없기 때문에 요청을 거부하는 경우에도, 사용자가 프롬프트를 취소했기 때문에 요청을 거부하는 경우와 동일한 일반 오류를 반환합니다. 또한 인위적인 지연에 의존하지 않고 타이밍 공격을 방지하기 위해, 사용자 에이전트는 일치하는 자격 증명이 없는 경우 사용자에게 표시되는 대화상자(예: 빈 선택기 또는 알림)를 표시하여, 프롬프트 닫기 지연 시간이 사용자의 취소와 구별되지 않도록 합니다.

11.6 사용자 권한 및 투명성

이슈: 작업 진행 중

Digital Credentials API는 자격 증명을 통해 매우 개인적이고, 민감하며, 위험에 노출될 수 있는 사용자 정보를 웹사이트와 공유할 수 있게 하며, 영구적이고 고유하며 취소할 수 없는 컨텍스트 간 식별자를 통해 온라인과 오프라인에서 사용자를 추적할 수 있는 가능성을 제공한다. 또한 사용자의 브라우징 활동 일부와 특정 웹사이트 및/또는 자격 증명 관리자에 자신을 식별하려는 의도도 드러낸다. 자격 증명 요청에서 사용자 에이전트의 중요한 책임 중 하나는 정보 교환을 진행하기 위한 사용자의 권한을 얻는 것이다.

사용자가 자격 증명 교환을 진행할지에 대해 충분한 정보를 바탕으로 결정을 내리는 데 필요한 중요한 컨텍스트 세부 정보에는 다음이 포함된다:

사용자 에이전트는 구현 시 사용자와 관련된 어떠한 정보도 교환되기 전에 나열된 세부 정보를 사용자에게 완전히 공개하도록 하는 것이 권장된다.

이슈 252: 권한 프롬프트의 요소를 규범적으로 정의해야 하는가? privacy-considerations

이들을 명세에서 규범적으로 정의해야 하는가?

이슈 44: API 요청은 사이트가 요청한 자격 증명 정보를 왜, 어떻게 사용할지 설명하는 데 필요한 정보를 제공해야 한다 enhancementpending closureprivacy-tracker

사이트가 컨텍스트에 맞는 설명을 제공할 수 있도록 API를 설계해야 하는가?

11.6.1 여러 자격 증명 요청 처리

이슈 286: 여러 제시 요청(및 응답)에 대한 개인정보 보호 고려 사항 privacy-trackerprivacy-considerationsv2

자격 증명 제시에서 여러 요청과 응답을 처리하는 것의 우려 사항, 절충점 및 가능한 완화책을 설명해야 한다.

11.6.2 여러 사용자 에이전트 통합

사용자 시스템의 기술적 아키텍처에 따라 "사용자 에이전트"의 정의에는 브라우저와 운영 체제처럼 소프트웨어 스택의 여러 협력 계층이 포함될 가능성이 높다. 이러한 계층에서 가장 중요한 우선순위는 안전하고 충분한 정보에 기반한 사용자 권한 경험이어야 한다. 따라서 통합은 사용자 안전에 매우 중요할 수 있다. 일부 계층은 사용자의 자격 증명 가용성과 같이 다른 계층에서 접근할 수 없는 정보를 보유할 수 있다. 과도한 프롬프트 또는 충분한 맥락이 없는 프롬프트는 (악용 가능한) 혼란과 프롬프트 무시에 이어질 수 있다.

이러한 이유로 권한을 요청하는 사용자 에이전트는 안전하다고 판단되는 경우 이상적인 사용자 경험을 위해 소프트웨어 계층을 통합하는 것이 권장된다. 예를 들어 브라우저가 운영 체제의 API 계약을 신뢰하여 적절한 프롬프트를 표시한다고 보고 자체적으로 프롬프트를 표시하지 않는 방식이 가능하다.

11.6.3 자격 증명 관리자 선택 전 권한

사용자 권한 흐름의 일부로 사용자 에이전트는 사용자가 자격 증명 요청을 자격 증명 관리자에게 전달할지 여부와 어떤 자격 증명 관리자를 선택할지 결정할 권한을 유지하도록 보장해야 한다. 이는 요청의 일부로 정보 공개가 발생하고, 자격 증명 관리자가 요청 시점에 이 정보를 보존하거나 공유할 수 있기 때문이다.

11.7 데이터 삭제 및 지속 상태

Digital Credentials API 자체는 새로운 브라우저 관리형 지속 상태나 로컬 저장소 메커니즘을 도입하지 않습니다. 이 API를 통해 요청된 자격 증명은 외부 자격 증명 관리자 또는 운영 체제에서 저장하고 관리합니다. 따라서 사용자가 특정 출처 또는 전체에 대해 브라우징 데이터(예: 쿠키 또는 로컬 저장소)를 삭제하더라도, 일반적으로 이러한 외부 관리자에 보관된 자격 증명은 삭제되거나 영향을 받지 않습니다.

12. 접근성 고려 사항

디지털 자격 증명을 선택하고 승인하기 위한 사용자 인터페이스는 플랫폼에서 제공되며 대부분 이 명세의 범위를 벗어납니다. 그러나 해당 경험의 접근성은 범위에 포함됩니다(3. 범위 참조). 다음 지침은 사용자 에이전트 및 디지털 자격 증명 선택기, 자격 증명 관리자 선택기와 그 주변 흐름을 구현하는 플랫폼에 적용되며, [WCAG22]의 관련 성공 기준을 참조합니다. 어느 선택기든 비웹 사용자 인터페이스인 경우에는 해당 기준이 [WCAG2ICT-22]에 설명된 대로 적용됩니다.

발급 또는 제시 중 표시되는 모달 대화 상자의 내용은 텍스트, QR 코드 및 기타 시각적 미디어를 포함할 수 있으며, 적절한 이름, 역할 및 값을 사용하여 레이블을 지정하고 보조 기술에 노출해야 합니다(§ 성공 기준 4.1.2 이름, 역할, 값 참조). 또한 SHOULD 텍스트가 아닌 콘텐츠에 대한 텍스트 대체 수단을 제공해야 합니다(§ 성공 기준 1.1.1 비텍스트 콘텐츠 참조).

다른 기기를 기다리는 경우, 성공적인 응답, 오류 또는 취소와 같은 상호작용 상태의 변경은 프로그래밍 방식으로 확인할 수 있어야 하며, 포커스를 변경하지 않고 보조 기술에 전달되어야 합니다(§ 성공 기준 4.1.3 상태 메시지 참조).

작업이 실패하면 사용자 에이전트는 여러 가지 서로 다른 오류 중 하나로 거부합니다. 예를 들어 "NotAllowedError", "InvalidStateError" 또는 "OperationError" DOMException, 또는 TypeError가 있습니다. 플랫폼이 이러한 실패를 사용자에게 표시하는 경우, 단순히 오류가 발생했다는 사실만 알리는 대신 무엇이 잘못되었는지와, 해당하는 경우 어떻게 복구할 수 있는지를 텍스트로 식별해야 합니다(§ 성공 기준 3.3.1 오류 식별 참조).

상호작용 요소, 특히 사용자가 발급 또는 제시 요청을 계속하거나 중단할 수 있도록 하는 요소는 기기에 독립적인 방식으로 조작할 수 MUST 있습니다(예: 키보드를 통해서. § 성공 기준 2.1.1 키보드 참조). 특히 활성화는 유일한 조작 수단으로 다중 지점 또는 경로 기반 제스처를 요구해서는 MUST NOT 됩니다(§ 성공 기준 2.5.1 포인터 제스처 참조). 또한 기기 움직임을 유일한 조작 수단으로 요구해서도 안 됩니다(§ 성공 기준 2.5.4 움직임 작동 참조). 디지털 자격 증명 선택기와 자격 증명 관리자 선택기는 의미 있는 포커스 순서로 컨트롤을 표시해야 하며(§ 성공 기준 2.4.3 포커스 순서 참조), 선택기가 열릴 때 포커스를 선택기 내부로 이동하고, 표시되는 동안 포커스를 그 안에 유지하며, 닫힐 때 이전에 포커스된 요소 또는 다른 적절한 위치로 포커스를 복원해야 합니다.

디지털 자격 증명을 제공하기 위해 보유자가 인증해야 하는 경우, 접근 가능한 인증 방법을 사용할 수 있어야 합니다. 어떤 단계가 비밀번호 기억과 같은 인지 기능 테스트에 의존하는 경우, 그러한 테스트가 필요하지 않은 대안을 제공해야 합니다(§ 성공 기준 3.3.8 접근 가능한 인증(최소) 참조). 또한 인증은 일부 사용자가 제공할 수 없는 생체 정보와 같은 단일 신체적 특성에만 의존해서는 안 됩니다. 이 단계는 일반적으로 플랫폼 또는 자격 증명 관리자가 수행하며, 그 밖의 측면은 이 명세의 범위를 벗어납니다.

일부 플랫폼은 제시 요청을 여러 기기에 걸쳐 수행합니다. 예를 들어 사용자가 별도의 기기로 스캔할 수 있도록 QR 코드를 표시합니다. 이러한 흐름은 시각 능력, 카메라 또는 두 번째 기기의 사용에 의존할 수 있으므로, 플랫폼은 단일 감각 능력이나 입력 방식에 의존하지 않고 상호작용을 완료할 수 있는 동등하고 접근 가능한 수단을 제공해야 합니다. QR 코드와 같은 시각적 산출물을 통해서만 전달되는 기기 간 요청에 접근 가능한 대안이 없다면, 해당 방식을 사용할 수 없는 사용자를 배제하게 됩니다.

하나의 상호작용에는 둘 이상의 출처에서 시간 제한이 적용될 수 있습니다. 이러한 제한은 더 많은 시간이 필요한 사용자가 배제되지 않도록 처리해야 합니다(§ 성공 기준 2.2.1 시간 조절 가능 참조):

디지털 자격 증명을 검토하고 공개하기 위한 결정에는 주변 사이트 흐름에서 비롯된 시간 압박을 포함하여 강제적인 카운트다운이 적용되어서는 안 됩니다.

상호작용 중 표시되는 사람이 읽을 수 있는 자격 증명 콘텐츠와, 이미지의 텍스트 대체 수단과 같은 접근 가능한 대체 수단은 자격 증명 페이로드 내에 포함되며, 관련 자격 증명 형식 및 프로토콜에서 책임집니다. 이러한 형식과 프로토콜은 해당 콘텐츠의 언어와 방향도 결정합니다.

13. 국제화 고려 사항

이 절은 비규범적이다.

이 API는 자격 증명 형식과 교환 프로토콜에 종속되지 않으며, 요청 페이로드(DigitalCredentialGetRequest의 data 및 DigitalCredentialCreateRequest의 data)와 응답 페이로드 (DigitalCredential의 data)를 불투명한 것으로 취급한다. 그 결과, API는 사람이 읽을 수 있는 자연어 콘텐츠를 전달하는 문자열 타입 값을 정의하지 않는다:

따라서 이 명세는 언어 또는 방향 메타데이터가 필요한 자연어 텍스트를 새로 도입하지 않는다. 향후 개정판에서 API 계층에 사이트 작성자가 작성한 사람이 읽을 수 있는 텍스트, 규범적으로 정의된 권한 프롬프트 텍스트 또는 사용자 에이전트가 그리는 제시 요소를 도입한다면, 해당 텍스트에는 적절한 언어 및 방향 메타데이터가 포함되거나 연결되어야 한다.

14. 자동화 테스트

사용자 에이전트 자동화 및 애플리케이션 테스트를 위해 이 문서는 WebDriver BiDi 명세의 확장 모듈을 정의한다. 사용자 에이전트가 이를 지원하는 것은 선택 사항이다.

14.1 digitalCredentials 모듈

digitalCredentials 모듈에는 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 및 [[Create]](origin, options, sameOriginWithAncestors) 호출 중 자격 증명 관리자의 원격 엔드 동작을 관리하고 시뮬레이션하기 위한 명령이 포함된다.

14.1.1 타입 

CDDLdigitalCredentials.VirtualWalletAction = "decline" / "respond" / "wait" / "clear"

digitalCredentials.SetVirtualWalletBehaviorParameters = {
  action: digitalCredentials.VirtualWalletAction,
  ? context: text,
  ? protocol: text,
  ? response: { * text => any },
}

digitalCredentials.VirtualWalletAction 타입은 서로 다른 유형의 가상 지갑 동작을 나타낸다.

"decline"
가상 지갑은 사용자의 취소 또는 거부를 시뮬레이션하여 요청을 중단한다.
"respond"
가상 지갑은 성공적인 사용자 상호작용을 시뮬레이션하고 미리 정의된 자격 증명 응답을 반환한다.
"wait"
가상 지갑은 활성 상태의 대기 중 프롬프트를 시뮬레이션하며, 시간 초과나 동시 요청 처리를 테스트하기 위해 사실상 활성 프로미스를 미결 상태로 둔다.
"clear"
활성 가상 지갑 동작을 지운다.

14.1.2 명령

14.1.2.1 digitalCredentials.setVirtualWalletBehavior 명령
명령 타입 
CDDLdigitalCredentials.SetVirtualWalletBehavior = (
  method: "digitalCredentials.setVirtualWalletBehavior",
  params: digitalCredentials.SetVirtualWalletBehaviorParameters
)
반환 타입 
CDDLdigitalCredentials.SetVirtualWalletBehaviorResult = EmptyResult

session 및 command parameters가 주어졌을 때 digitalCredentials.setVirtualWalletBehavior 명령의 원격 엔드 단계는 다음과 같다:

  1. action을 command parameters["action"]으로 둔다.
  2. context를 command parameters["context"]로 두되, 존재하는 경우에만 그렇게 하고, 그렇지 않으면 null로 둔다.
  3. protocol을 command parameters["protocol"]로 두되, 존재하는 경우에만 그렇게 하고, 그렇지 않으면 null로 둔다.
  4. response를 command parameters["response"]로 두되, 존재하는 경우에만 그렇게 하고, 그렇지 않으면 null로 둔다.
  5. action이 "respond"인 경우:
    1. protocol이 null이거나 response가 null이면, 오류를 오류 코드 잘못된 인수와 함께 반환한다.
    2. protocol이 DigitalCredentialProtocol의 열거형 값이 아니면, 오류를 오류 코드 잘못된 인수와 함께 반환한다.
    3. response를 JSON 문자열로 직렬화한다.
    4. 직렬화 결과가 예외이면, 오류를 오류 코드 잘못된 인수와 함께 반환한다.
  6. 그 밖의 경우:
    1. response가 null이 아니거나 protocol이 null이 아니면, 오류를 오류 코드 잘못된 인수와 함께 반환한다.
  7. action이 "clear"인 경우:
    1. context가 null이 아니면, WebDriver 세션의 활성 가상 지갑 동작에서 context에 대한 항목을 제거한다.
    2. 그 밖의 경우, WebDriver 세션의 활성 가상 지갑 동작을 null로 설정한다.
  8. 그 밖의 경우:
    1. behavior를 (action, protocol, response) 튜플로 둔다.
    2. context가 null이 아니면 WebDriver 세션의 탐색 컨텍스트 ID context에 대한 활성 가상 지갑 동작을 behavior로 설정한다.
    3. 그 밖의 경우, WebDriver 세션의 기본 활성 가상 지갑 동작을 behavior로 설정한다.
  9. 데이터 null과 함께 성공을 반환한다.
참고: 테스트에서 지갑 오류 시뮬레이션

자동화 테스트를 작성하는 개발자는 AbortSignal을 signal로 (get()의 경우) 또는 signal로 (create()의 경우) 전달한 다음, 원하는 중단 이유로 이를 중단하여 지갑 오류를 시뮬레이션할 수 있다. 이는 요청 알고리즘에서 사용하는 것과 동일한 중단 경로를 실행한다.

예 9: AbortController로 지갑 오류 시뮬레이션 
(async () => {
  const controller = new AbortController();
  const credentialPromise = navigator.credentials.get({
    digital: {
      requests: [{
        protocol: "example-request-protocol",
        data: { /* 제시 요청 데이터 */ }
      }]
    },
    signal: controller.signal
  });

  controller.abort(
    new DOMException("Simulated wallet failure", "OperationError")
  );

  try {
    await credentialPromise;
  } catch (error) {
    console.assert(error.name === "OperationError");
  }
})();

14.2 가상 지갑 동작 처리

Promise promise와 전역 객체 global이 주어졌을 때 가상 지갑 동작을 처리하려면 다음 단계를 실행한다:

  1. 사용자 에이전트가 자동화 제어 중이 아니면 false를 반환한다.
  2. context ID를 global의 탐색 컨텍스트의 ID로 둔다.
  3. behavior를 현재 WebDriver 세션에서 context ID에 대한 활성 가상 지갑 동작으로 둔다.
  4. behavior가 null이면 behavior를 현재 WebDriver 세션의 기본 활성 가상 지갑 동작으로 설정한다.
  5. behavior가 null이면 false를 반환한다.
  6. (action, protocol, response)을 behavior로 둔다.
  7. action이 "wait"이면 true를 반환한다.
  8. action이 "decline"인 경우:
    1. promise를 "NotAllowedError" DOMException으로 거부한다.
    2. true를 반환한다.
  9. action이 "respond"인 경우:
    1. JSON string을 response를 직렬화한 결과로 둔다.
    2. JS object를 global의 관련 렐름이 주어졌을 때 JSON string을 파싱한 결과로 둔다.
    3. credential을 새로운 DigitalCredential 인스턴스로 둔다.
    4. credential의 protocol 속성을 protocol로 설정한다.
    5. credential의 data 속성을 JS object로 설정한다.
    6. global이 주어졌을 때 DOM 조작 태스크 소스에 전역 태스크를 큐에 추가하여 promise를 credential로 이행한다.
    7. true를 반환한다.

A. 색인

A.1 이 명세에서 정의된 용어

A.2 참조로 정의된 용어

B. IDL 색인

WebIDLpartial dictionary CredentialRequestOptions {
  DigitalCredentialRequestOptions digital;
};

dictionary DigitalCredentialRequestOptions {
  required sequence<DigitalCredentialGetRequest> requests;
};

dictionary DigitalCredentialGetRequest {
  required DOMString protocol;
  required object data;
};

partial dictionary CredentialCreationOptions {
  DigitalCredentialCreationOptions digital;
};

dictionary DigitalCredentialCreationOptions {
  required sequence<DigitalCredentialCreateRequest> requests;
};

dictionary DigitalCredentialCreateRequest {
  required DOMString protocol;
  required object data;
};

typedef (DigitalCredentialPresentationProtocol or DigitalCredentialIssuanceProtocol) DigitalCredentialProtocol;

[Exposed=Window, SecureContext]
interface DigitalCredential : Credential {
  [Default] object toJSON();
  readonly attribute DigitalCredentialProtocol protocol;
  [SameObject] readonly attribute object data;
  static boolean userAgentAllowsProtocol(DOMString protocol);
};

enum DigitalCredentialPresentationProtocol {
  "openid4vp-v1-unsigned",
  "openid4vp-v1-signed",
  "openid4vp-v1-multisigned",
  "org-iso-mdoc"
};

enum DigitalCredentialIssuanceProtocol {
  "openid4vci-v1",
};

C. CDDL 색인

C.1 모듈: remote-cddl

digitalCredentials.VirtualWalletAction = "decline" / "respond" / "wait" / "clear"

digitalCredentials.SetVirtualWalletBehaviorParameters = {
  action: digitalCredentials.VirtualWalletAction,
  ? context: text,
  ? protocol: text,
  ? response: { * text => any },
}

digitalCredentials.SetVirtualWalletBehavior = (
  method: "digitalCredentials.setVirtualWalletBehavior",
  params: digitalCredentials.SetVirtualWalletBehaviorParameters
)

C.2 모듈: local-cddl

digitalCredentials.SetVirtualWalletBehaviorResult = EmptyResult

D. 적합성

비규범적이라고 표시된 절뿐만 아니라 이 명세의 모든 작성 지침, 다이어그램, 예제 및 참고 사항은 비규범적이다. 이 명세의 그 밖의 모든 내용은 규범적이다.

이 문서에서 핵심 단어 할 수 있다, 반드시 해야 한다, 해서는 안 된다, 선택 사항, 권고된다, 하는 것이 좋다, 및 하지 않는 것이 좋다는 여기에서와 같이 모두 대문자로 나타날 때, 그리고 오직 그 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석해야 한다.

E. 감사의 말

일부 편집자는 이 명세에 대한 피드백과 기여를 제공한 다음 분들께 감사드린다: Christian Bormann (SPRIND), John Bradley (Yubico), Rick Byers (Google), Brian Campbell (Ping Identity), Lee Campbell (Google), Nick Doty (CDT), Heather Flanagan (Spherical Cow Consulting), Ryan Galluzzo (NIST), Joseph Heenan (Authlete), Dominique Hazael-Massieux (W3C), Bjorn Hjelm (Yubico), Johann Hofmann (Google), Mike Jones (Self-Issued Consulting), Tobias Looker (MATTR), Matthew Miller (Cisco), Theresa O'Connor (Apple Inc.), Simone Onofri (W3C), Helen Qin (Google), Wendy Seltzer (초청 전문가), Manu Sporny (Digital Bazaar), Orie Steele (Transmute), Ted Thibodeau Jr (OpenLink Software), David Waite (Ping Identity), 그리고 Kristina Yasuda (SPRIND).

F. 참고문헌

F.1 규범적 참고문헌

[credential-management]
자격 증명 관리 레벨 1. Nina Satragno; Marcos Caceres. W3C. 2026년 7월 2일. W3C 작업 초안. URL: https://www.w3.org/TR/credential-management-1/
[dom]
DOM 표준. Anne van Kesteren. WHATWG. 현행 표준. URL: https://dom.spec.whatwg.org/
[FIDO-CLIENT-TO-AUTHENTICATOR-PROTOCOL-V2.3]
클라이언트 대 인증자 프로토콜 (CTAP). FIDO Alliance. 편집자 초안. URL: https://fidoalliance.org/specs/fido-v2.3-ps-20260226/fido-client-to-authenticator-protocol-v2.3-ps-20260226.html
[html]
HTML 표준. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. 현행 표준. URL: https://html.spec.whatwg.org/multipage/
[INFRA]
Infra 표준. Anne van Kesteren; Domenic Denicola. WHATWG. 현행 표준. URL: https://infra.spec.whatwg.org/
[ISO18013-7]
ISO/IEC 18013-7:2025 ISO 준수 운전 면허증, 제7부: 모바일 운전 면허증(mDL) 추가 기능. ISO/IEC JTC 1/SC 17. 국제 표준화 기구. 2025년 5월. URL: https://www.iso.org/standard/91154.html
[OPENID4VCI]
검증 가능한 자격 증명 발급을 위한 OpenID 1.0. Torsten Lodderstedt; Kristina Yasuda; Tobias Looker; Paul Bastian. OpenID Foundation. 2025년 9월 16일. 최종. URL: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html
[OPENID4VP]
검증 가능한 프레젠테이션을 위한 OpenID 1.0. Oliver Terbu; Torsten Lodderstedt; Kristina Yasuda; Daniel Fett; Joseph Heenan. OpenID Foundation. 2025년 7월 9일. 최종. URL: https://openid.net/specs/openid-4-verifiable-presentations-1_0.html
[permissions]
권한. Marcos Caceres; Mike Taylor. W3C. 2025년 10월 6일. W3C 작업 초안. URL: https://www.w3.org/TR/permissions/
[permissions-policy]
권한 정책. Ian Clelland. W3C. 2026년 6월 18일. W3C 작업 초안. URL: https://www.w3.org/TR/permissions-policy-1/
[RFC2119]
요구사항 수준을 나타내기 위해 RFC에서 사용하는 핵심 단어. S. Bradner. IETF. 1997년 3월. 현행 모범 사례. URL: https://www.rfc-editor.org/info/rfc2119/
[RFC8174]
RFC 2119 핵심 단어의 대문자와 소문자 간 모호성. B. Leiba. IETF. 2017년 5월. 현행 모범 사례. URL: https://www.rfc-editor.org/info/rfc8174/
[vc-data-model]
검증 가능한 자격 증명 데이터 모델 v2.0. Ivan Herman; Michael Jones; Manu Sporny; Ted Thibodeau Jr; Gabe Cohen. W3C. 2025년 5월 15일. W3C 권고안. URL: https://www.w3.org/TR/vc-data-model-2.0/
[vc-use-cases]
검증 가능한 자격 증명 사용 사례. Joe Andrieu; Kevin Dean. W3C. 2026년 3월 18일. W3C 작업 그룹 노트. URL: https://www.w3.org/TR/vc-use-cases/
[WCAG22]
웹 콘텐츠 접근성 지침 (WCAG) 2.2. Michael Cooper; Andrew Kirkpatrick; Alastair Campbell; Rachael Bradley Montgomery; Charles Adams. W3C. 2024년 12월 12일. W3C 권고안. URL: https://www.w3.org/TR/WCAG22/
[WCAG2ICT-22]
비웹 정보 및 통신 기술에 WCAG 2를 적용하기 위한 지침 (WCAG2ICT). Mary Jo Mueller; Phil Day; Daniel Montalvo. W3C. 2025년 12월 11일. W3C 작업 그룹 노트. URL: https://www.w3.org/TR/wcag2ict-22/
[webdriver]
WebDriver. Simon Stewart; David Burns. W3C. 2026년 7월 2일. W3C 작업 초안. URL: https://www.w3.org/TR/webdriver2/
[webdriver-bidi]
WebDriver BiDi. James Graham; Alex Rudenko; Maksim Sadym. W3C. 2026년 8월 24일. W3C 작업 초안. URL: https://www.w3.org/TR/webdriver-bidi/
[webidl]
Web IDL 표준. Edgar Chen; Timothy Gu. WHATWG. 현행 표준. URL: https://webidl.spec.whatwg.org/

F.2 정보 제공용 참고문헌

[credential-considerations]
웹의 자격 증명에 대한 사용자 고려사항. Nick Doty; Rick Byers. W3C. 2025-03-26. URL: https://github.com/w3c/credential-considerations/blob/main/credentials-considerations.md
[custom-schemes]
신원 제시를 위한 커스텀 스킴에 대한 우려. Rick Byers. W3C. 2024-05-01. URL: https://github.com/w3c-fedid/digital-credentials/blob/main/custom-schemes.md
[identity-web-impact]
신원 & 웹. Simone Onofri. W3C. 2025-02-25. URL: https://www.w3.org/reports/identity-web-impact
[ISO18013-5]
ISO/IEC 18013-5:2021 ISO 준수 운전 면허증, 제5부: 모바일 운전 면허증(mDL) 애플리케이션. ISO/IEC JTC 1/SC 17. 국제 표준화 기구. 2021년 9월. URL: https://www.iso.org/standard/69084.html
[presenting-credentials-on-the-web]
웹에서 자격 증명 제시. Simone Onofri. URL: https://docs.google.com/document/d/1Ppaz_EnhzHqPOz5UusRJvbSunh-RXPWgJ3Np_TM2EE0/
[prevent-credential-abuse]
디지털 자격 증명의 남용 방지. Daniel Appelquist; Martin Thomson. W3C. 2025년 11월 14일. TAG 결정문. URL: https://www.w3.org/2001/tag/doc/prevent-credential-abuse/
[privacy-principles]
개인정보 보호 원칙. Robin Berjon; Jeffrey Yasskin. W3C. 2025년 5월 15일. STMT. URL: https://www.w3.org/TR/privacy-principles/
[rfc6973]
인터넷 프로토콜의 개인정보 보호 고려사항. A. Cooper; H. Tschofenig; B. Aboba; J. Peterson; J. Morris; M. Hansen; R. Smith. IETF. 2013년 7월. 정보 제공용. URL: https://www.rfc-editor.org/info/rfc6973/
[secure-contexts]
보안 컨텍스트. Mike West. W3C. 2023년 11월 10일. CRD. URL: https://www.w3.org/TR/secure-contexts/
[threat-model-decentralized-credentials]
탈중앙화 자격 증명을 위한 위협 모델. Simone Onofri; Amir Sharif. W3C. 2026년 6월 22일. DNOTE. URL: https://www.w3.org/TR/threat-model-decentralized-credentials/
[URL]
URL 표준. Anne van Kesteren. WHATWG. 현행 표준. URL: https://url.spec.whatwg.org/