Copyright © 2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
이 문서는 사용자 에이전트가 제시 및 발급을 중개할 수 있게 하는 API를 명시합니다. 이는 디지털 자격 증명, 예를 들어 운전면허증, 정부 발급 신분증 또는 기타 유형의 디지털 자격 증명에 적용됩니다. 이 API는 Credential Management Level 1을 기반으로 하며 자격 증명 형식에 구애받지 않도록 설계되었습니다.
이 절은 이 문서가 발행된 시점의 상태를 설명합니다. 현재 W3C 발행물 목록과 이 기술 보고서의 최신 개정판은 W3C 표준 및 초안 색인에서 확인할 수 있습니다.
이 문서는 Federated Identity Working Group에서 Recommendation 트랙을 사용하여 작업 초안으로 발행했습니다.
작업 초안으로 발행되었다고 해서 W3C와 그 회원들의 지지를 의미하지는 않습니다.
이 문서는 초안 문서이며 언제든지 다른 문서로 갱신, 대체 또는 폐기될 수 있습니다. 이 문서를 진행 중인 작업 이외의 것으로 인용하는 것은 적절하지 않습니다.
이 문서는 W3C 특허 정책에 따라 운영되는 그룹에서 작성했습니다. W3C는 해당 그룹의 산출물과 관련하여 이루어진 모든 특허 공개의 공개 목록을 유지합니다. 그 페이지에는 특허를 공개하는 방법에 대한 지침도 포함되어 있습니다. 개인이 필수 청구항을 포함한다고 믿는 특허에 대해 실제 지식을 가지고 있는 경우, W3C 특허 정책 제6절에 따라 해당 정보를 공개해야 합니다.
이 문서는 2025년 8월 18일 W3C Process Document의 적용을 받습니다.
이 절은 비규범적입니다.
이 문서는 웹 사이트가 디지털 자격 증명의 제시 및 발급을 요청할 수 있게 하는 API를 정의합니다.
이 API는 자격 증명 형식에 구애받지 않으며, 여러 제시 프로토콜 및 발급 프로토콜로 확장할 수 있도록 설계되었습니다. 5. 프로토콜을 참조하십시오.
이 API는 다음 목표를 지원하도록 설계되었습니다.
많은 유형의 디지털 자격 증명을 이 API를 사용하여 제시하고 발급할 수 있습니다. 이러한 유형의 예에는 다음이 포함됩니다.
이 절은 비규범적입니다.
다음 예제들은 API를 사용하여 디지털 자격 증명을 요청하고 발급하는 방법을 보여준다.
API를 사용하기 전에, 사용자 에이전트가 필요한 기능을 지원하는지 확인하는 것이 중요하다. 이는 다음 코드를 사용하여 수행할 수 있다:
if (typeof DigitalCredential !== "undefined") {
// API가 지원됨
} else {
// API가 지원되지 않음
}
userAgentAllowsProtocol()
정적 메서드는
사용자 에이전트가 디지털 자격 증명 발급 또는 제시에 대해 특정 프로토콜을
허용하는지 확인하는 데 사용할 수 있습니다. 이는 API 호출을 하기 전에
사용자의 브라우저에서 어떤 프로토콜이 허용되는지
확인하는 데 유용합니다. DigitalCredential을 구현하는
브라우저에서는
(위에 표시된 typeof 검사로 감지 가능), 프로토콜 식별자가
DigitalCredentialProtocol에
사용자 에이전트가 지원을 채택함에 따라 점진적으로 추가되므로, 알 수 없는
프로토콜 식별자로 이 메서드를 호출하면
throw하여 예외를
발생시키지 않고 안전하게 false를 반환합니다.
DigitalCredential이 정의되지 않은 브라우저에서 이
메서드를 호출하면 ReferenceError가 발생하므로, 이
메서드를 사용하기 전에 위에 표시된 typeof DigitalCredential !==
"undefined" 가드가 여전히 필요합니다.
if (DigitalCredential.userAgentAllowsProtocol("example-protocol")) {
// DC API가 지원됩니다. 발급 또는 제시를 진행합니다.
} else {
// DC API가 지원되지 않습니다. 예를 들어
// 기존 HTML 폼 기반 접근 방식으로 대체합니다.
showHTMLForm();
}또는 여러 프로토콜의 지원 여부를 확인하고, 지원되지 않는 프로토콜을 걸러낼 수 있습니다.
const protocols = [
"example-issuance-protocol",
"another-issuance-protocol"
];
const supportedProtocols = protocols.filter(DigitalCredential.userAgentAllowsProtocol);
if (supportedProtocols.length > 0) {
// 하나 이상의 프로토콜이 지원됩니다. 발급을 진행합니다.
} else {
// 지원되는 프로토콜이 없습니다. 다른 발급 방법으로 대체합니다.
}
프로토콜 식별자는 DigitalCredentialProtocol에
점진적으로 추가되므로, 이 메서드를 사용하여 최신 프로토콜을 선호하면서
레거시 브라우저에서는 이전 프로토콜로 우아하게 대체할 수 있습니다.
// 선호도 순서입니다. DigitalCredential을 구현하는 브라우저에서는
// 알 수 없는 프로토콜이 throw하지 않고 false를 반환합니다.
const protocol = [
"example-new-protocol",
"example-legacy-protocol",
].find(DigitalCredential.userAgentAllowsProtocol);
if (protocol) {
// 이 브라우저가 지원하는 최선의 프로토콜을 사용합니다.
} else {
// 지원되는 프로토콜을 찾지 못했습니다. 다른 접근 방식으로 대체합니다.
}
다음 예제는 API를 사용하여 디지털 자격 증명을 요청하는 방법을 보여준다.
API의 진입점은
navigator.credentials.get() 메서드이며,
이는
사용자 에이전트로부터 디지털 자격 증명을 요청하는 데 사용된다. 사용자
에이전트가 프레젠테이션을 지원하는 경우, 사용자가 디지털 자격 증명 선택기를 통해 디지털
자격 증명을 선택할 수 있게 한다:
<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>마찬가지로, 사이트가 디지털 자격 증명을 발급해야 하는 경우, Digital Credentials API는 사이트, 사용자 에이전트, 그리고 보유자 사이에서 디지털 자격 증명의 발급을 중재한다.
다음 예제는 Digital
Credentials API를 사용하여 디지털
자격 증명의 발급을 요청하는 방법을 보여준다. 디지털
자격 증명을 발급하려면, 사이트는
navigator.credentials.create()
메서드를 호출하며,
이 메서드는 사용자 에이전트가 발급을 지원하는 경우 발급
흐름을 시작한다:
<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>이 명세는 "digital-credentials-get" 정책 제어 기능을 통해 원격/제3자 오리진에서 자격 증명을 제시하기 위해 API를 사용할 수 있도록 허용합니다. 이는 웹 사이트가 다른 오리진에서 호스팅되는 검증 서비스로부터 디지털 자격 증명을 요청하려는 시나리오에 유용합니다. Permissions Policy는 API를 사용하려는 웹 사이트를 임베드하는 iframe에 설정할 수 있습니다. 다음은 iframe에 Permissions Policy를 설정하는 방법의 예입니다.
<iframe src="https://verifier-service.example.com"
allow="digital-credentials-get">
</iframe>마찬가지로, 이 명세는 "digital-credentials-create" 정책 제어 기능을 통해 원격/제3자 오리진에서 자격 증명을 발급하기 위해 API를 사용할 수 있도록 허용합니다. 이는 웹 사이트가 다른 오리진의 발급 서비스를 사용하여 디지털 자격 증명 발급을 요청하려는 시나리오에 유용합니다. Permissions Policy는 발급자의 인터페이스를 임베드하는 iframe에 설정할 수 있습니다. 예는 다음과 같습니다.
<iframe src="https://issuer.example.com"
allow="digital-credentials-create">
</iframe>이 절은 비규범적입니다.
다음 항목은 이 명세의 범위에 포함됩니다.
다음 항목은 범위에서 제외됩니다.
이 절의 정의 목표는 다양한 디지털 자격 증명 형식과 프로토콜 전반에서 공통적으로 사용되는 용어를 재사용하거나 확립하는 것입니다. 이러한 정의는 활발히 발전 중입니다.
이 명세는 현재 사람과 관련된 디지털 자격 증명에 초점을 맞추고 있습니다.
다음 제시 프로토콜의 사용은 이 명세에서 정의합니다.
#401에서, 저는 다음을 추가하자고 제안했습니다.
<p>
[=user agent=]는 [=table of exchange protocols=]에 나열된 [=digital credential/exchange protocol=] 중 적어도 하나를 구현해야 합니다.
[=user agent=]가 [=table of exchange protocols=]에 나열된 모든 [=digital credential/exchange protocols=]을 구현하는 것이 권장됩니다.
</p>
<aside class="note" title="사용자 에이전트가 허용하는 교환 프로토콜 확인">
<p>개발자는 `DigitalCredential.`{{DigitalCredential.userAgentAllowsProtocol()}} 정적 메서드를 호출하여
사용자 에이전트가 허용하는 [=digital credential/exchange protocols=]를 확인할 수 있습니다.
사용 예는 [[[#checking-if-protocol-is-allowed]]]를 참조하십시오.
</p>
</aside>그 이유는 다음과 같습니다.
| 식별자 | 명세 |
|---|---|
| 제시 프로토콜 | |
openid4vp-v1-unsigned
|
OpenID for Verifiable Presentations 1.0 § A.3.1. Unsigned Request |
openid4vp-v1-signed
|
OpenID for Verifiable Presentations 1.0 § A.3.2. Signed Request |
openid4vp-v1-multisigned
|
OpenID for Verifiable Presentations 1.0 § A.3.2.2. JWS JSON Serialization (다중 서명 요청) |
org-iso-mdoc
|
ISO/IEC 18013-7:2025 ISO 준수 운전면허증, Part 7: 모바일 운전면허증(mDL) 부가 기능 § 부속서 C |
| 발급 프로토콜 | |
openid4vci-v1
|
OpenID
for Verifiable Credential Issuance 1.0 § 곧 제공 예정
이슈:
API 통합
|
DigitalCredentialGetRequest 또는 DigitalCredentialCreateRequest
request가 주어졌을 때, 요청 프로토콜을 변환하려면:
DigitalCredentialGetRequest인
경우:
protocol로
둔다.
DigitalCredentialPresentationProtocol의
열거형 값 중 어느 것과도
같지 않으면, failure를 반환한다.
DigitalCredentialPresentationProtocol
열거형 값을 반환한다.
DigitalCredentialCreateRequest인
경우:
protocol로
둔다.
DigitalCredentialIssuanceProtocol의
열거형 값 중 어느 것과도
같지 않으면, failure를 반환한다.
DigitalCredentialIssuanceProtocol
열거형 값을 반환한다.
credential request coordinator는 top-level traversable을 통해 디지털 자격 증명 상호작용을 중개하는, 사용자 에이전트가 정의한 구성요소입니다. 각 top-level traversable에는 정확히 하나의 관련 조정자가 있습니다. 이 조정자는 모든 child navigables 전반에서 동시에 최대 하나의 상호작용만 활성화되도록 보장하고, 제시 또는 발급의 종단 간 흐름을 조율하며, 상호작용 상태 간 전환을 관리합니다.
credential request coordinator는 active promise를 유지하며, 사용자
에이전트는 이를 null로 초기화합니다. 이 Promise를 통해,
coordinator는 비동기
자격 증명 요청 워크플로의 상태를 스크립트에 반영하고,
상호작용이 성공적으로 완료되면 자격 증명
응답으로 resolve하거나,
처리가 실패하거나, 사용자가 UI를 통해 요청을 취소하거나, 스크립트가
AbortSignal을 통해 작업을 중단하면
reject합니다.
credential request coordinator는 abort signal을 유지하며, 사용자 에이전트는
이를 null로 초기화합니다.
credential request coordinator는 abort algorithm을 유지하며, 사용자
에이전트는 이를 null로 초기화합니다.
credential request coordinator는 다음을 수행합니다.
사용자 에이전트는 사용자 또는 플랫폼 정책에 따라 일부 또는 모든 조정자 책임을 외부 credential managers, 플랫폼 구성요소 또는 기타 신뢰할 수 있는 엔터티에 위임할 MAY 있습니다.
credential request coordinator는 유한한 상호작용 상태 집합을 가지며, 이는 자격 증명 요청의 생명주기를 관리하는 데 사용됩니다.
Document document, sequence
of DigitalCredentialGetRequest values
또는 sequence of
DigitalCredentialCreateRequest
values requests, Promise
promise, 그리고 선택적 AbortSignal signal이 주어졌을 때 자격 증명
요청을 준비하려면 다음을 수행합니다.
NotAllowedError"
DOMException으로
reject합니다.
null입니다.
TypeError와 promise로 자격 증명 요청을
reject합니다.
미리 중단된 signals는
이 알고리즘이 호출되기 전에
Credential 요청 및
Credential 생성에서 처리됩니다.
true이면 반환합니다.
AbortError" DOMException으로 자격 증명 요청을 중단합니다.
DigitalCredentialGetRequest 또는
DigitalCredentialCreateRequest
객체들의 시퀀스 requests가 주어졌을 때,
자격 증명 요청을
검증하려면:
false를 반환하면, continue한다.
DigitalCredentialGetRequest인
경우 data를 request의 data로 두고,
request가
DigitalCredentialCreateRequest인
경우 request의
data로 둔다.
준비 단계는 원래 다음과 같이 명시했다:
프로토콜에서 정의한 요구사항 외에도, [=user agent=]는 로컬 정책, 구성 또는 변화하는 보안 고려사항에 기반한 추가 검증 기준을 적용할 수 있다. 예를 들어, [=user agent=]는 (a) 특정 자격 증명 속성을 요구하는 요청, (b) [=user agent=]가 수락하지 않도록 구성된 암호화 알고리즘을 사용하거나 요구하는 요청(예: 알고리즘 민첩성 또는 포스트 양자 체계로의 전환의 일부로서), 또는 (c) [=user agent=]의 구성된 신뢰 결정에서 수락되지 않는 인증서나 신뢰 앵커에 의존하는 요청을 거부할 수 있다.
이러한 사항들을 더 확장해 설명하면 좋을 것이다.
JavaScript 값 또는 DOMException
error가 주어졌을 때 자격 증명
요청을 중단하려면 다음을 수행합니다.
null이면,
반환합니다.
닫기에 실패할 수 있지만(예: 디지털 자격 증명 선택기가 메모리 압박으로 인해 파괴된 경우), coordinator는 그와 관계없이 자격 증명 요청 완료를 계속 진행합니다.
(JavaScript Value) error와
Promise promise가 주어졌을 때 자격 증명
요청을 reject하려면 다음을 수행합니다.
null이 아니고 abortAlgorithm도
null이 아니면:
null로 설정합니다.
null로 설정합니다.
null로 설정합니다.
Document
document, 검증된 자격 증명 요청의 list
validatedRequests, Promise
promise, 그리고 선택적 AbortSignal signal이 주어졌을
때
자격 증명
요청을 개시하려면 다음을 수행합니다.
@mohamedamir와 논의 중이었습니다... 명세에서 크로스 플랫폼 교차 기기 자격 증명 교환은 CTAP을 통해 발생해야 한다고 SHOULD(또는 RECOMMENDED)라고 말해야 합니다.
우리가 이를 의무화할 수 없는 이유(즉, MUST로 할 수 없는 이유)는 다음과 같습니다.
자격 증명 요청 준비 단계에서 signal에 추가된 abort algorithm이 디지털 자격 증명 선택기 해제를 처리합니다.
NotAllowedError"
DOMException으로
둡니다.
NotAllowedError"
DOMException.
TypeError.
InvalidStateError"
DOMException.
OperationError"
DOMException.
디지털 자격 증명 선택기 또는 그 기반 플랫폼은 validatedRequests 중 어느 항목을 보유자에게 전달할지 결정하고, 해당 교환에 대한 프로토콜 식별자를 반환합니다. 사용자 에이전트는 어떤 특정 항목이 선택되었는지 반드시 알지는 못합니다.
null이 아니고
abortAlgorithm이
null이 아니면, abortAlgorithm을
abortSignal에서
제거합니다.
null로
설정합니다.
null로 설정합니다.
DigitalCredential
인스턴스로 둡니다. 이 인스턴스의
data는
parsedResponseDataOrError로 초기화되고,
protocol은
protocol로 초기화됩니다.
null로 설정합니다.
Digital Credentials API는 Credential Management Level 1 명세를 활용하여, 사용자 에이전트가 발급 및 프레젠테이션 디지털 자격 증명을 중재할 수 있게 한다.
이 API는 사용자 에이전트로부터
요청하는 것을 허용하며,
디지털 자격 증명을 사용자 에이전트에 요청하면, 사용자 에이전트는
사용자에게
디지털 자격 증명 선택기를 표시하여, 사용자가
요청을 충족할 수 있는
디지털 자격 증명을 선택할 수 있게 한다. 이는
웹사이트가
navigator.credentials.get() 메서드를
호출하여 이루어지며, 이 메서드는
Credential Management Level 1의
Credential 요청 알고리즘을 실행한다.
그러면 해당 알고리즘은 이 명세의
DigitalCredential 인터페이스의
[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)
내부 메서드로 다시 호출한다.
또한 이 API는 발급
요청도 허용한다. 이는 디지털 자격 증명의
발급을 요청하여, 사용자 에이전트 및/또는
보유자 사이에서 중재된 발급 흐름을 시작한다. 이는
navigator.credentials.create() 메서드를
호출하여 이루어지며,
이 메서드는 Credential Management Level 1의
자격 증명 생성 알고리즘을 실행한다. 그러면
해당 알고리즘은 이 명세의 DigitalCredential 인터페이스의
[[Create]](origin, options, sameOriginWithAncestors)
내부 메서드로 다시 호출한다.
Credential Management Level 1 명세와 통합하는 방법에 대한 전체 세부 사항은 Credential Management 통합을 참조하라.
WebIDLpartial dictionary CredentialRequestOptions {
DigitalCredentialRequestOptions digital;
};
digital 멤버는
디지털 자격 증명 요청을 구성하기 위한 옵션을 허용합니다.
WebIDLdictionary DigitalCredentialRequestOptions {
required sequence<DigitalCredentialGetRequest> requests;
};
requests는
제시 프로토콜과 제시 요청 데이터를 지정하며, 사용자 에이전트는 이를
디지털 지갑과 같은 credential manager와
일치시킬 MAY 있습니다.
DigitalCredentialGetRequest
딕셔너리는 제시 요청을 나타냅니다. 이는
제시 프로토콜과 일부 제시 요청 데이터를 지정하는 데 사용되며, 사용자 에이전트는 이를
디지털 지갑과 같은 credential manager와
일치시킬 MAY 있습니다.
WebIDLdictionary DigitalCredentialGetRequest {
required DOMString protocol;
required object data;
};
protocol 멤버는
제시 프로토콜을 나타냅니다.
protocol 멤버의 값은
DigitalCredentialPresentationProtocol에
정의된
프로토콜 식별자 중 하나입니다.
data 멤버는
디지털 신원 지갑과 같은 보유자의 credential manager가 처리할
제시 요청 데이터입니다.
WebIDLpartial dictionary CredentialCreationOptions {
DigitalCredentialCreationOptions digital;
};
digital 멤버는
디지털 자격 증명 발급을 구성하기 위한 옵션을 허용합니다.
WebIDLdictionary DigitalCredentialCreationOptions {
required sequence<DigitalCredentialCreateRequest> requests;
};
requests는
발급 프로토콜과 발급 요청 데이터를 지정하며, 사용자 에이전트는 이를
보유자에게 전달할
MAY 있습니다.
DigitalCredentialCreateRequest
딕셔너리는 발급 요청을 나타냅니다. 이는
발급 프로토콜과 일부 발급 요청
데이터를 지정하고,
발급자와 보유자 사이에서 발급 요청을 전달하는 데 사용됩니다.
WebIDLdictionary DigitalCredentialCreateRequest {
required DOMString protocol;
required object data;
};
protocol
멤버는 발급 프로토콜을 나타냅니다.
protocol 멤버의
값은
DigitalCredentialIssuanceProtocol에
정의된
프로토콜 식별자 중 하나입니다.
data 멤버는
디지털 신원 지갑과 같은 보유자의 credential manager가 처리할
발급 요청 데이터입니다.
DigitalCredential 인터페이스는 개념적
디지털 자격 증명을 나타냅니다.
DigitalCredential
인터페이스는 사용자 제어와 동의를 보장하기 위해 모든 작업에 대해
사용자 중개를 요구합니다.
DigitalCredential과 관련된
get()
호출의 개발자 경험을 단순화하기 위해, 사용자 에이전트는
mediation 멤버가
없거나 "required"가 아닌
값을 갖는 경우에도
오류를 throw해서는 MUST NOT 됩니다.
마찬가지로,
DigitalCredential과 관련된
create()
호출에서, 사용자
에이전트는
mediation 멤버가
없거나 "required"가 아닌
값을 갖는 경우에도
오류를 throw해서는 MUST NOT 됩니다.
이는
"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);
};
protocol 멤버는
디지털 자격 증명을 요청하는 데 사용된
제시 프로토콜 또는
디지털 자격 증명을 발급하는 데 사용된
발급 프로토콜입니다.
data 멤버는
자격 증명의 응답 데이터입니다. 이는 JSON으로 파싱 가능한 객체 유형의 하위 집합을 포함합니다.
userAgentAllowsProtocol()
메서드는 디지털 자격 증명
검증자가 사용자 에이전트가 허용하는
제시 프로토콜과
발급 프로토콜을 결정할 수 있게 합니다.
사용자 에이전트는 하드웨어 가용성, 소프트웨어의 존재 또는 구성, credential managers 또는 디지털 자격 증명, 또는 사용자 구성이나 환경설정에 관한 어떠한 정보에 따라서도 응답 값을 달리해서는 MUST NOT 됩니다. 응답 값이 달라진다면, 사용자 에이전트는 핑거프린팅 위험과 사용자 행동 또는 구성에 관한 다른 세부사항을 은밀히 드러낼 위험을 모두 도입하게 됩니다. 응답 값은 사용자 에이전트의 주요 버전에 의해서만 달라지고, 브라우저가 해당 프로토콜로 요청을 기반 플랫폼 또는 제공자에 배포하는 것을 지원하는지 여부를 나타내야 SHOULD 합니다.
DOMString protocol이
주어졌을 때
사용자
에이전트가 프로토콜을 허용하는지 확인하려면,
다음 단계를 수행합니다.
DigitalCredentialProtocol의
enumeration value가 아니면,
false를 반환합니다.
true를 반환하고, 그렇지 않으면
false를 반환합니다.
이 메서드가 호출되면, 사용자 에이전트는 protocol이 주어졌을 때 사용자 에이전트가 프로토콜을 허용하는지의 결과를 반환해야 MUST 합니다.
이 명세에서
DigitalCredential을 지원하는 열거형 등의 데이터 구조입니다.
request context는 다음 items를 가진 struct입니다.
DigitalCredentialPresentationProtocol
열거형
이 열거형의 값은 5. 프로토콜에 나열된 지원되는 제시 프로토콜에 해당합니다.
WebIDLenum DigitalCredentialPresentationProtocol {
"openid4vp-v1-unsigned",
"openid4vp-v1-signed",
"openid4vp-v1-multisigned",
"org-iso-mdoc"
};
DigitalCredentialIssuanceProtocol
열거형
이 열거형의 값은 5. 프로토콜에 나열된 지원되는 발급 프로토콜에 해당합니다.
WebIDLenum DigitalCredentialIssuanceProtocol {
"openid4vci-v1",
};
호출되었을 때, [[DiscoverFromExternalSource]](origin, options,
sameOriginWithAncestors) 내부 메서드는, 사용자 에이전트가
제시 요청을 지원하지 않는 경우(예: 플랫폼이
디지털 자격 증명 선택기를 제공할 수 없는 경우),
동일한 인수로 Credential의
[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)
내부 메서드의 기본 구현을 호출합니다.
그렇지 않으면:
signal이
존재하면, signal을 그것으로 둡니다.
Document로 둡니다.
NotAllowedError" DOMException으로
reject된 promise를 반환합니다.
digital의
requests 멤버로 둡니다.
NotAllowedError" DOMException으로
reject된 promise를 반환합니다.
호출되었을 때, [[Store]](credential, sameOriginWithAncestors)는
동일한 인수로 Credential의
[[Store]](credential, sameOriginWithAncestors)
내부
메서드의 기본 구현을 호출해야 MUST 합니다.
호출되었을 때, [[Create]](origin, options,
sameOriginWithAncestors) 내부 메서드는, 사용자 에이전트가
발급 요청을 지원하지 않는 경우, 동일한
인수로 Credential의 [[Create]](origin, options, sameOriginWithAncestors)
내부 메서드의 기본 구현을 호출합니다.
그렇지 않으면:
signal이
존재하면, signal을 그것으로 둡니다.
Document로 둡니다.
NotAllowedError" DOMException으로
reject된 promise를 반환합니다.
digital의
requests 멤버로 둡니다.
NotAllowedError" DOMException으로
reject된 promise를 반환합니다.
DigitalCredential interface object에는
[[type]]이라는 내부 슬롯이 있으며,
그 값은 "digital"입니다.
DigitalCredential interface object에는
[[discovery]]라는 내부 슬롯이
있으며,
그 값은 "remote"입니다.
이 절은 비규범적입니다.
Digital Credentials
API는 최종 사용자의 명시적 권한을
요구하는 강력한 기능이다. 이
요구사항은 CredentialsContainer의
get() 메서드를 호출할
때
규범적으로 적용된다.
이 명세는 두 가지 정책 제어 기능을 정의합니다.
Credential 요청
알고리즘이 정책 강제 지점 역할을 합니다.
Credential 생성 알고리즘이
정책 강제 지점 역할을 합니다.
이 절은 비규범적입니다.
이어지는 절들은 API의 보안 속성, 범위에 포함되는 위협, 보안이 의존하는 가정, 그리고 완화 조치가 적용된 후에도 남는 잔여 위협을 설명합니다. 이 명세는 자격 증명 응답을 중개할 때에만 사용자 에이전트의 동작에 대한 요구사항을 정의합니다.
프로토콜, credential manager 구현, 운영 체제 또는 전송 보안에 의존하는 기타 보안 고려사항은 기대사항 또는 전제조건으로 설명되지만, 이미 규범적으로 명시되어 있지 않는 한 이 명세에서 규범적으로 요구하지 않습니다.
이 명세의 위협 모델에는 이 API에 대한 위협과 생태계의 인접 표준에 대한 위협이 포함됩니다.
이 명세에서 위협은 두 범주로 나뉩니다: 범위 내 위협과 범위 외 위협.
범위 내 위협은 DC API 자체가 도입하거나 처리하는 위협입니다. 다음은 이 명세의 범위 내 위협입니다.
DigitalCredentialGetRequest
또는 DigitalCredentialCreateRequest를
변경하려고 시도합니다.
iframe과
같은
임베드된 제3자 콘텐츠를 통해 디지털 자격 증명을 요청하거나 발급하려고 시도하여,
잠재적으로 자격 증명 수집 또는 민감한 사용자 데이터에 대한 무단 접근을 가능하게 합니다.
범위 외 위협은 프로토콜, credential managers, OS 플랫폼 보안 또는 전송 계층에서 처리하는 위협입니다. "범위 밖"이라 하더라도, 자격 증명 제시 및 발급의 종단 간 보안에 영향을 주기 때문에 관련이 있습니다. 다음은 이 명세의 범위 외 위협을 정의합니다.
다음 완화 조치는 명세의 규범적 요구사항을 통해 범위 내 위협을 다룹니다.
Digital Credential API의 WebIDL 인터페이스는 보안 컨텍스트에서만 노출되어, 안전하지 않은 컨텍스트를 통한 변조의 위험을 줄인다 (예: 악성 스크립트가 네트워크를 통해 삽입되는 경우). 자세한 내용은 Secure Contexts 명세의 5 보안 고려사항 절을 참조하라.
Digital Credentials API는 두 가지 메커니즘을 통해 API 플러딩을 줄인다:
[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)
및 [[Create]](origin, options, sameOriginWithAncestors)
메서드는 사용자 활성화를 소비하여,
사용자 상호작용 없이 자동화되거나 반복되는 요청을 방지한다.
required"로
만든다(DigitalCredential
인터페이스 참조). 이를 통해 모든 자격 증명 작업에 대해
플랫폼의 자격 증명 선택기 인터페이스를 통한 사용자 권한이 확보되도록 한다.
자격 증명 요청 남용을 방지하기 위한 추가 지침은 Credential Management Level 1 명세의 7 개인정보 보호 고려사항 절을 참조하라. 그러나 사이트가 여전히 자격 증명 요청을 트리거하는 불필요한 사용자 상호작용을 유도하기 위해 다크 패턴을 사용할 수 있으므로, 이러한 보호에는 한계가 있음에 유의한다.
Digital Credentials API는
Permissions Policy와의
통합을 통해 교차 출처 남용을
줄인다(Permissions Policy
통합 참조). Credential 요청 및 Credential 생성 알고리즘은
각각 "digital-credentials-get" 및
"digital-credentials-create" 정책 제어 기능에 대한 정책 시행
지점으로 작동한다. 두 기능은 의도적으로 분리되어 있다. 사이트는
"digital-credentials-get"을 활성화하지 않고
"digital-credentials-create"를 활성화할 수 있으며,
그 반대도 가능하여, 각 임베드된 컨텍스트를 필요한 기능으로만 제한한다. 이 통합이 제공하는
추가 보안 속성은
Permissions Policy 명세의
Permissions Policy
절을 참조하라.
이 절은 비규범적입니다.
이 절은 이 문서가 발전함에 따라 진행 중인 작업입니다.
Digital Credentials API는 여러 기술 계층과 다양한 참여자(예를 들어 검증자, 보유자, 발급자를 포함하되 이에 한정되지 않음)가 있는 복잡한 생태계에 통합되며, 각 참여자는 사용자 개인정보 보호의 서로 다른 측면을 고려해야 합니다. 이 명세는 서로 다른 참여자에 대한 모든 고려사항을 빠짐없이 나열하려고 하지 않습니다. 우리는 이러한 당사자들에게 디지털 자격 증명 위협 모델을 더 전체적으로 살펴보는 다양한 다른 자료를 참조하도록 안내하고자 합니다.
대신, 이러한 고려사항은 Digital Credentials API 자체에 초점을 맞추며, 사용자 에이전트가 API 구현에서 자신의 사용자 에이전트 의무를 충족할 수 있는 방법을 설명합니다. 이때 API가 상호작용하는 생태계의 관련 개인정보 보호 속성을 고려합니다.
디지털 자격 증명에 대한 개인정보 보호 고려사항은 정적이지 않습니다. 생태계가 성숙함에 따라 시간이 지나며 발전할 것이고, 생태계 내 다른 행위자의 동작, 스택의 다른 계층에서의 개선, 사용자 개인정보 보호에 대한 새로운 위협, 그리고 변화하는 사회적 규범과 규제의 영향을 받을 수 있습니다.
Digital Credentials API의 설계와 구현에 관여하는 다양한 그룹은 발전하는 개인정보 보호 환경을 적극적으로 모니터링하고 API의 상응하는 발전에 참여할 것으로 기대됩니다.
Digital Credentials API는 웹 사이트의 디지털 자격 증명 요청을 중개하도록 설계되었으며, 자격 증명 형식과 그 안에 포함된 정보, 그리고 이를 교환하는 데 사용되는 프로토콜에 구애받지 않습니다. 이러한 설계 선택과 기타 핵심 설계 선택은 기존 대안(예: [custom-schemes])보다 사용자에게 더 안전하고 개인정보 보호가 강화된 자격 증명 교환 경험을 제공하면서도, 채택을 쉽게 하기 위해 일반적인 교환 프로토콜과 계속 호환되도록 하려는 목표에서 비롯됩니다.
이 API는 검증자와 보유자 사이의 연결 인터페이스를 제공합니다. 즉, 자격 증명 제시 프로토콜이 시작되고 사용자가 자격 증명을 선택하기 위해 보유자 애플리케이션으로 전환하는 수단입니다. 과거에 이 목적으로 사용된 해결책에는 QR 코드와 사용자 정의 URL 스킴이 포함됩니다. 웹에서 자격 증명 제시하기 및 신원 제시를 위한 사용자 정의 스킴의 우려사항에 문서화된 것처럼, 이러한 해결책에는 보안, 개인정보 보호 및 접근성 문제가 있습니다.
디지털 자격 증명 기술의 채택이 생태계 수요와 규제 명령에 의해 추진됨에 따라, 웹 플랫폼은 앞서 언급한 덜 바람직한 기술에 대한 대안을 제공한다. 이 대안은 개발자가 사용하기 쉽고, 기존 자격 증명 프레젠테이션 프로토콜과 호환되며, 무엇보다도 앞서 언급한 대안보다 사용자에게 더 나은 개인정보 보호, 보안 및 접근성 특성을 제공한다.
Digital Credentials API는 사용자 에이전트에게 사용자 대신 중개할 수 있는 능력을 제공합니다(예: 디지털 자격 증명 선택기 형태). 이를 통해 요청에 맥락을 부여하고 보유자 애플리케이션에 대한 즉각적인 노출을 방지할 수 있습니다. 또한 지원되는 프로토콜에 대해 응답 암호화와 같은 특정 최소 요구사항을 강제합니다.
Digital Credentials API는 서로 다른 수준의 데이터 공개를 수반하는 다양한 사용 사례와, 자신이 처한 맥락에 따라 서로 다른 선호를 가진 개별 사용자를 지원한다. 특히, 이 API가 중재하는 자격 증명 교환의 개인정보 보호 속성은 개별 사용자의 법률 및 규제 환경에 의해 의무화될 수 있다.
이는 일부 사용자가 자격 증명 정보를 교환하는 가장 개인정보 보호적인 수단을 사용하기를 원하지 않거나, 사용이 허용되지 않을 수도 있음을 의미한다. 그럼에도 불구하고, 사용자 에이전트는 기본적으로 비공개인 경험을 사용자에게 제공하고, 사용자를 피해로부터 보호해야 한다.
이러한 선호와 사용 사례의 스펙트럼 때문에, 사용자 에이전트가 사용자가 자신의 개인 정보를 노출하려는 것인지, 아니면 그렇게 하도록 속고 있는 것인지를 판별하기 어려울 수 있다. 따라서 교환이 시작되기 전에, 모든 사용자가 자신이 어떤 데이터를 공유하는지와 정보 교환에 누가 참여할 것인지를 이해하도록 보장하는 것은 사용자 에이전트의 책임이다.
Digital Credentials API는 여러 독립 당사자가 관여하는 교환의 중심에 위치하기 때문에, 이러한 당사자들이 사용자 정보를 교환하는 데 사용하는 제시 프로토콜과 자격 증명 형식은 사용자 개인정보를 보호하려는 사용자 에이전트의 목표에 매우 중요합니다.
프로토콜에 대해 더 자세한 설명이 필요하다고 생각하는 두 가지 요구사항이 있습니다.
개인정보 보호 검토를 거쳤어야 함 [...]
그리고
보안 검토를 거쳤어야 함 [...]
기술적으로, "이 프로토콜은 모든 면에서 끔찍하다"라고 말하는 검토도 이러한 기준을 충족합니다.
프로토콜이 충족해야 하는 구체적인 개인정보 보호 및 보안 요구사항 집합이 있다면 더 유용할 것입니다. 그러한 검토는 표준이 달성되었는지 여부를 말할 수 있을 것입니다. 검토에는 주관적인 요소가 있을 수도 있지만, 각 프로토콜이 넘어야 하는 최소 기준도 있어야 합니다.
이는 현재 포함 기준에 있는 현재 요구사항 집합을 넘어섭니다. 저는 지금 포괄적인 목록을 가지고 있지는 않지만, 개발할 수는 있을 것입니다. 그리고 일단 개발되면 그 목록은 명세에 있어야 합니다. 예를 들어, 프로토콜이 phone home에 의존합니까? 프로토콜(또는 그것이 전달하는 형식)이 제시의 연결 불가능성을 보장합니까? 또는 일부 사용 사례에서는 연결 불가능성이 의미가 없다는 점을 고려할 때, API는 어떤 조건에서 프로토콜이 연결 불가능성을 제공하도록 요구합니까? 프로토콜에는 어떤 종류의 투명성 장치가 포함되어 있습니까? 어떤 종류의 은닉 채널이 허용됩니까?
선택적 공개는 데이터 최소화를 위한 기본 기술로, 보유자가 검증자가 요청한 최소한의 필수 정보만 공유할 수 있게 합니다. 프로토콜은 검증자가 필요한 정확한 클레임을 지정할 수 있도록 하여 선택적 공개를 용이하게 할 것으로 기대됩니다.
연결 불가능성은 사용자가 자격 증명에서 나온 속성을 여러 번 제시하더라도 검증자가 이러한 별도의 제시를 연결하여 동일한 사용자와 관련된 것이라고 결론 내릴 수 없도록 보장하는 속성입니다 (검증자-검증자 연결 가능성). 또는 검증자가 발급자와 공모하여 credential manager에서 나온 자격 증명 교환을 발급자에게 보고할 수 없도록 보장하는 속성이기도 합니다 (검증자-발급자 연결 가능성). 전자는 보유자와 발급자가 유지할 수 있는 속성입니다. 예를 들어 개별 검증자를 위해 새로운 자격 증명을 발급하는 방식입니다.
후자는 예를 들어 영지식 증명을 통해 달성 가능하지만, 암호화된 응답과 같은 API의 설계 선택으로 인해 사용자 에이전트가 검증자-발급자 비연결성이 실제로 달성되었음을 증명하는 것은 불가능하다. 그럼에도 불구하고 프로토콜은 가능한 모든 곳에서 연결 가능성을 제한하도록 요청된다.
비연결성은 특정 사용자 신원에 연결될 수 없는 속성에 대해서만 고려된다는 점에 유의하라. 이름, 운전면허 번호 또는 전화번호와 같이 본질적으로 연결 가능한 속성은 비연결성의 이점을 얻지 못한다.
Digital Credentials API를 통해 사용자 에이전트는 검증자와 자격 증명 관리자가 비연결 속성을 교환하도록 도울 수 있지만, 응답 암호화 때문에 검증자와 자격 증명 관리자 사이에 연결 가능한 정보가 전달되지 않는다고 보장할 수는 없다. 사용자 에이전트는 사용자 권한 경험에서 이 사실을 고려하는 것이 권장된다.
이 API의 목표는 어느 수준의 연결 불가능성입니까? 특정 연결 불가능성 기능에 대한 지원을 규범적으로 강제할 수 있습니까?
"폰 홈"은 디지털 자격 증명의 제시 또는 검증이 발급자나 다른 중앙 엔터티로 다시 알림 또는 통신을 유발하여, 개인의 추적과 프로파일링으로 이어질 수 있는 시나리오를 가리킨다.
비연결성과 마찬가지로, 사용자가 자격 증명 요청을 진행할 권한을 부여한 후에는 사용자 에이전트가 발급자가 자격 증명 제시의 생성 또는 검증에 적극적으로 관여하지 않는다고 보장하는 것은 불가능하다. 그 시점부터는 자격 증명 관리자가 이 결정을 맡는다. 일부 자격 증명 관리자는 사용자 에이전트로 간주될 수 있지만, 일반적으로 사용자 에이전트는 Digital Credentials API를 구현할 때, 사용자 확인 전에 요청이 자격 증명 관리자에게 노출되는 것을 방지하도록 권한 경험을 설계하는 것이 권장된다 (여러 협력하는 사용자 에이전트를 통합하기 위한 고려사항을 염두에 둔다).
프로토콜은 발급자, 자격 증명 관리자 및 검증자가 "phone home" 메커니즘에 대한 의존을 피하거나 줄일 수 있게 하는 메커니즘을 지원해야 한다.
이 API의 목표는 어느 수준의 연결 불가능성입니까? 명세가 발급자 관여에 대한 제한을 어느 정도까지 의무화할 수 있습니까?
자격 증명 교환에서 발급자가 관여하는 일반적인 사례는 자격 증명 철회 확인이다. 이는 프레젠테이션이 검증자-발급자 연결 불가능을 의도하는 경우 특히 어렵다. 자격 증명 프레젠테이션이 예를 들어 영지식 증명의 사용을 통해 연결 불가능하게 만들어지는 경우, 프로토콜에서 사용되는 자격 증명 형식은 암호학적 누산기와 같은 오프라인 철회 방법을 지원할 것으로 예상된다. 또한 프로토콜 설계와 명세는 가능한 경우 철회를 목적으로 한 검증자의 관여를 억제할 것으로 예상된다.
연결 불가능한 폐기 기술이 규범적으로 요구될 만큼 충분히 실용적인지 논의해야 합니다.
사용자의 이해와 참여는 자격 증명 제시에서 타협할 수 없는 속성입니다. 프로토콜은 관련된 모든 당사자가 충분히 정보를 바탕으로 한 권한 및/또는 동의를 위해 필수적인 정보를 제공함으로써 사용자 참여를 가능하게 하도록 도울 것으로 기대됩니다.
"전송 중" 사용자 정보가 다른 당사자에게 노출되는 것을 방지하기 위해, 예를 들어 검증자 페이지에 로드된 브라우저 확장 프로그램에 노출되는 것을 방지하고, 검증자가 사용자 자격 증명을 안전하게 저장하도록 장려하기 위해, 프로토콜은 자격 증명 교환에서 암호화된 응답을 지원하고 의무화해야 합니다.
#49 및 우리가 진행한 여러 다른 논의와 관련이 있습니다. 응답은 항상 암호화되어야 한다고 말하고 싶은가요 (그렇다면 어떤 알고리즘으로), 아니면 이를 선택 사항으로 남겨두어도 괜찮은가요?
불필요한 자격 증명 요청은 전체 디지털 자격 증명 생태계의 핵심 개인정보 보호 위험입니다. 이는 서로 다른 방식과 동기에서 나타날 수 있습니다.
여기서 한 가지 과제는 무엇이 "유효한" 목적을 구성하는지, 따라서 어떤 요청이 "불필요한"지를 판단하는 것이며, 이는 자격 증명 교환에 관여하는 모든 당사자의 참여를 필요로 합니다.
불필요한 사용을 판단하고 대응하는 방법을 더 자세히 살펴보려면, 정부 발급 자격 증명과 기타 자격 증명을 별도로 고려하는 것이 타당하다. 두 유형은 데이터의 민감도와 오용으로 인한 잠재적 피해뿐 아니라 법률 및 규제 고려사항에서도 잠재적으로 다르기 때문이다.
두 유형의 자격 증명 모두에 적용되는 위험 완화와 사용자 통제 보장의 핵심 구성요소는 사용자 에이전트가 자격 증명 요청 메타데이터를 검사하고 이를 기반으로 결정이나 UI 표시를 수행할 수 있는 능력이다. 이 명세는 요청을 암호화하지 않고 전송하며 관련 정보를 포함하도록 하는 프로토콜 요구사항을 통해 이러한 사용자 에이전트 접근을 보장한다(5. 프로토콜 및 6.2 자격 증명 요청 준비 참조).
정부 발급 디지털 자격 증명에는 여행 문서, 개인 면허, 복지 및 공중보건 프로그램 증명, 차량 등록, 그리고 정부 기관이 발급한 기타 문서 또는 이 정보를 나타내는 기타 문서가 포함됩니다. 이러한 문서는 사람의 개인 신원과 필수 공공 서비스와 상호작용할 수 있는 능력의 중심이 되는 영구적이고, 폐기 불가능하며, 고유한 식별자를 포함할 수 있으므로 매우 민감합니다.
이러한 자격 증명이 사용자와 공격자에게 가지는 높은 가치는 도난의 상당한 위험과 인가되지 않은 제3자에게 유출될 경우의 상당한 잠재적 피해를 의미합니다. 여기에는 추적과 개인화를 목적으로 정부 신원 정보를 요청하는 것도 포함됩니다.
온라인에서 정부 자격 증명의 가용성이 높아지는 것에 대한 주요 우려는 제번스의 역설, 즉 접근 마찰이 낮아짐으로써 자격 증명에 대한 수요가 증가할 가능성입니다. 이 효과는 Digital Credentials API 자체로 인해 본질적으로 발생하는 것이 아니라 생태계 전반에서 디지털 자격 증명의 채택이 증가함에 따라 발생합니다. 다만 사용자 에이전트가 Digital Credentials API를 구현하면 추가적인 추진력이 생길 가능성이 큽니다. 따라서 API를 구현하는 사용자 에이전트는 이 효과를 고려해야 하며, 이는 사용자에게 해로운 결과를 초래할 수 있습니다.
앞서 설명한 정부 발급 디지털 자격 증명의 위험은 생태계의 단일 참여자가 해결할 수 없는 과제를 제시하며, 실제 세계의 자격 증명을 통해 온라인 서비스에 접근하는 것의 위험과 이점에 대해 개별 주권 국가 내에서 더 광범위한 정책 논의를 필요로 합니다.
디지털 자격 증명을 발급하는 정부가 해당 자격 증명을 어떻게, 어떤 목적으로 사용할 수 있는지 명확히 정의하는 법률과 규정을 함께 제정하는 것이 바람직합니다. 교환에 관여하는 모든 당사자는, 법적으로 그렇게 할 의무가 있는지 여부와 관계없이, 존재하는 경우 정부 검증자 인증 체계를 지원하는 것이 권고됩니다. 검증자 인증 체계, 예를 들어 EUDI 접근 및 등록 인증서에 대한 지원(및 통합)은 불필요한 자격 증명 요청 확산 위험을 완화할 수 있습니다. 그러나 그러한 체계의 존재는 보장되지 않으며, 이는 자격 증명 교환의 위험을 크게 증가시킵니다.
Digital Credentials API를 구현하는 사용자 에이전트가 위험을 줄이고, 사용자의 이해를 높이며, 특정 유형의 피해를 방지하기 위해 취할 수 있는 다른 실용적인 단계도 있습니다.
또한 사용자 에이전트가 이러한 완화 조치의 부재를 고려한 권한 경험을 설계하는 것이 매우 중요하다. 예를 들어, 검증자 인증 체계 없이 정부 자격 증명에서 개인 정보를 교환하는 경우가 이에 해당한다. 이러한 유형의 교환에는 관련 위험을 강조하는 명확한 사용자 메시지와 더 높은 수준의 마찰을 적용하는 것이 권장된다.
비정부 발급 자격 증명에는 정부 발급이 아니며 정부 발급 문서를 나타내지 않는 모든 기타 디지털 문서, 인증서 및 증명이 포함됩니다. 여기에는 재직 증명, (비정부) 교육 자격 증명 또는 영화 티켓이 포함될 수 있습니다. 특히, 이러한 자격 증명의 교환은 법률과 규제에 의해 덜 제한될 가능성이 큽니다. 이러한 문서는 종종 정부 발급 자격 증명과 동일한 위험을 보이지는 않지만, 식별 가능한 정보 또는 민감한 정보를 포함할 수도 있습니다.
비정부 자격 증명의 도난과 유출이 미치는 영향과 실현 가능성은 대체로 각 개별 자격 증명 유형의 내용에 기반합니다. 일반적으로 이는 민감한 사적 정보의 통제 상실과 노출, 그리고 사칭과 데이터 도난으로 이어질 수 있으며, 이는 영향을 받은 개인에 대한 추가 공격 가능성을 높일 수 있습니다.
비정부 자격 증명의 유연성과 규제 부족은 이메일 주소나 전화번호와 같은 장기 식별자를 통한 교차 사이트 추적 및 신원 연결을 목적으로 한 악용 가능성을 지닙니다. 디지털 자격 증명에 기반한 추적 체계에 참여하는 검증자는 사용자가 자신의 개인정보에 미치는 영향을 완전히 이해하지 못한 채 여러 사이트에서 식별자 자격 증명 공유를 수락하도록 유인을 만들 수 있습니다(웹을 위한 "로열티 카드").
그러한 체계에서 정보를 공유하기를 원하지 않는 사용자도 프롬프트 피로의 영향을 받을 수 있으며, 이러한 서비스를 사용하는 데서 배제될 위험도 있을 수 있습니다.
비정부 발급 자격 증명의 경우, 사용자 에이전트가 요청된 자격 증명 형식과 그 개인정보 보호 속성을 이해하고, 사용자에게 표시되는 맥락과 각 자격 증명 유형에 적절한 마찰의 양을 알려주는 위험 프레임워크를 구축하는 것이 권장됩니다. 이러한 자격 증명의 교환에 관여하는 프로토콜과 형식은 일반적으로 선택적 공개와 연결 불가능성 같은 기능을 지원할 것으로 기대되지만, 특히 영화 티켓과 같은 저위험 자격 증명과 관련된 정보 교환에서는 이러한 기능이 항상 적절하거나 필요하지 않을 수 있습니다.
요청되는 자격 증명의 유형을 인식하는 사용자 에이전트는 요청된 자격 증명에 가장 잘 맞도록 권한 경험을 사용자화하고, 사용자가 이를 공유하는 결과를 이해하도록 돕는 것이 권장됩니다.
사용자 에이전트가 모든 자격 증명 요청을 이해할 것으로 기대할 수는 없다. 요청되는 자격 증명의 유형을 인식하지 못하는 사용자 에이전트는 권한 경험에서 사용자 마찰을 크게 높이고, 알 수 없는 자격 증명을 웹사이트와 공유할 때의 위험을 사용자에게 명확히 전달하는 것이 권고된다. 이는 적절한 수준의 마찰과 투명성을 적용하기 위해 서로 다른 사용자 에이전트 간의 통합이 필요할 수 있음에 유의하라. 예를 들어, 브라우저는 자격 증명 요청에 관한 지식을 운영 체제에 위임할 수 있으며, 운영 체제는 자격 증명 관리자가 알려진 자격 증명 유형을 등록하고 알 수 없는 자격 증명 유형에 대한 교환 요청을 거부하도록 요구할 수 있다.
사용자에게 적절한 투명성을 제공해야 할 필요성은 명시적인 사용자 에이전트의 동의 없이도 생태계가 새로운 자격 증명 형식을 개발할 수 있도록 하려는 바람과 충돌합니다.
불필요하고 악의적인 요청을 하는 검증자를 위한 상호운용 가능한 악용 신고 시스템을 고려하십시오.
API는 권한 프롬프트 없이 사용자 데이터가 절대 공유되지 않도록 보장하지만 ([[[#user-permission-and-transparency|사용자 권한 및 투명성]] 섹션 참조), Digital Credentials API가 반환할 가능성이 있는 실제 세계 식별자의 수명과 고유성은 이를 추적자와 핑거프린터의 잠재적 대상으로 만든다.
선택적 공개가 있더라도, 공격자는 디지털 자격 증명에서 얻은 데이터 (예: 사용자의 나이, 또는 자격 증명의 발급자, 타임스탬프; [[[#leaking-incidental-data|부수적 데이터 유출]] 섹션 참조)를 결합하여 사용자를 재식별하거나 핑거프린팅할 수 있다.
이 공격은 제3자 공격자(예: 검증자의 페이지에 삽입되었지만 추적 목적으로 적극적으로 협력하지 않는 스크립트)에게는 더 어려울 수 있습니다. 응답 암호화가 의무이며 응답은 검증자의 서버에서 복호화되어야 하기 때문입니다. 따라서 검증자는 복호화된 정보가 클라이언트 측 JavaScript로 다시 반영되지 않도록 보장할 수 있습니다. 그러나 모든 검증자가 그렇게 하기로 선택하지는 않을 것입니다.
자격 증명의 진위를 보장하기 위해, 검증자에게 제시되는 자격 증명에는 일반적으로 검증자가 접근을 요청하는 내용보다 더 많은 정보가 포함됩니다. 보통 최소한 발급자와 credential manager의 서명, 그리고 잠재적으로 기타 메타데이터가 포함됩니다.
이러한 추가 정보는 사용자를 재식별하고 핑거프린팅하는 데 사용될 수 있으며, 이는 그 외에는 연결 불가능한 제시가 이루어질 때 특히 관련이 있습니다.
Digital Credentials API가 자격 증명 응답의 내용을 제어하지는 않지만, 사용자 에이전트는 요청된 것 외에 어떤 정보가 검증자와 공유될 가능성이 있는지 명확히 강조하고, 더 넓게는 검증자가 API를 통해 수행하는 핑거프린팅을 식별하고 차단함으로써 이러한 유형의 추적으로부터 사용자를 보호하는 데 도움을 줄 수 있습니다.
Digital Credentials API는 userAgentAllowsProtocol()을
통해
사용자 에이전트가 어떤 제시 및 발급 프로토콜을 지원하는지에 관한
정보를 노출합니다. 예를 들어 사용자의 기기에 어떤
credential manager 애플리케이션이 설치되어 있는지에
따라 응답을 사용자화하지 않음으로써, 브라우저 핑거프린팅과 사용자의
기기 구성에 관한 정보 노출을 완화합니다. 따라서 반환되는 정보는 기껏해야
사용자 에이전트 버전과 동등합니다.
Digital Credentials API는 사이트가 먼저 사용자 권한 흐름을 거치지 않고는 자격 증명이 사용 가능한지 알 수 있게 하지 않습니다. 자격 증명의 존재를 드러내는 것은 사용자 개인정보 보호에 대한 위험입니다. 자격 증명의 존재는 사용자가 사이트와 공유하고 싶지 않았을 수 있는 개인정보이며, 다른 신호와 결합될 경우 사용자의 허락 없이 사용자를 식별하는 데 사용될 수 있기 때문입니다. 이는 표현의 자유에 대한 위험이기도 합니다. 웹 사이트가 서비스에 접근하기 위해 사용자에게 이러한 자격 증명의 제시를 점점 더 요구하기 시작할 수 있으며, 자격 증명을 제시하고 싶지 않은 개인을 배제할 수 있기 때문입니다.
Digital Credentials API는 자격 증명을 통해 매우 개인적이고, 민감하며 위험에 노출될 수 있는 사용자 정보를 웹 사이트와 공유할 수 있게 하며, 영구적이고 고유하며 폐기 불가능하고 교차 컨텍스트에서 사용되는 식별자를 통해 온라인과 오프라인에서 사용자를 추적할 수 있는 능력을 잠재적으로 부여합니다. 또한 사용자의 탐색 활동 일부와 특정 웹 사이트 및/또는 credential managers에 자신을 식별하려는 의도도 드러냅니다. 자격 증명 요청에서 사용자 에이전트의 중요한 책임 중 하나는 정보 교환을 진행하기 위한 사용자 권한을 수집하는 것입니다.
사용자가 자격 증명 교환을 진행할지에 대해 충분히 정보를 바탕으로 결정을 내리는 데 필요한 중요한 맥락 세부사항에는 다음이 포함됩니다.
사용자 에이전트는 구현에서 사용자 관련 정보의 어떠한 교환이 발생하기 전에, 나열된 세부사항이 사용자에게 완전히 공개되도록 보장하는 것이 권고됩니다.
이것들이 명세에서 규범적이어야 합니까?
사이트가 맥락 내 설명을 제공할 수 있도록 API를 설계해야 합니까?
자격 증명 제시를 위한 여러 요청과 응답을 처리할 때의 우려사항, 절충점 및 가능한 완화 조치를 설명해야 합니다.
사용자의 시스템 기술 아키텍처에 따라, "사용자 에이전트"의 정의에는 브라우저와 운영 체제와 같은 소프트웨어 스택의 여러 협력 계층이 포함될 가능성이 큽니다. 이러한 계층의 최우선 순위는 안전하고 충분히 정보를 바탕으로 한 사용자 권한 경험이어야 합니다. 따라서 통합은 사용자 안전에 매우 중요할 수 있습니다. 일부 계층은 사용자의 자격 증명 가용성과 같이 다른 계층이 접근할 수 없는 정보를 보유할 수 있습니다. 과도한 프롬프트 또는 충분한 맥락 없는 프롬프트는 (악용 가능한) 혼란과 프롬프트 무감각으로 이어질 수 있습니다.
이러한 이유로, 권한을 요청하는 사용자 에이전트는 그렇게 하는 것이 안전하다고 판단하는 경우, 이상적인 사용자 경험을 위해 소프트웨어 계층을 통합하는 것이 권장됩니다. 예를 들어, 브라우저가 운영 체제의 API 계약을 신뢰하여 적절한 프롬프트를 표시하도록 하고, 따라서 브라우저 자체는 프롬프트를 표시하지 않는 경우가 이에 해당할 수 있습니다.
사용자 권한 흐름의 일부로, 사용자 에이전트는 사용자가 자격 증명 요청을 credential manager에 전달할지 여부와 어떤 credential manager를 선택할지 선택할 권한을 유지하도록 보장해야 합니다. 이는 요청의 일부로 발생하는 정보 공개와, credential manager가 요청 시점에 이 정보를 보관하거나 공유할 수 있는 능력 때문입니다.
사용자 에이전트가 중개하는 권한은 동의가 아닙니다. 동의는 서로 다른 법적 및 규제 환경에 따라 달라질 수 있는 특정한 법적 정의를 가지며, 정보를 credential manager가 검증자와 공유하기 전에 credential manager가 수집해야 할 수도 있고, 요청을 시작하기 전에 검증자 자체가 수집해야 할 수도 있습니다. 동의를 얻기 위한 프레임워크와 규제가 아직 개발 중이므로, 이 API는 다음을 포함할 수 있는 필요한 정보의 교환을 가능하게 하는 것을 목표로 합니다.
이러한 정보가 구조화된 형식으로 더 많이 제공됨에 따라, 사용자 에이전트와 이 명세도 이를 활용하여 사용자 권한 경험을 개선할 것으로 기대합니다.
구현자는 이 API를 위해 특별히 자격 증명 선택기를 설계할 때 접근성을 고려해야 합니다. 발급 또는 제시 중에 제시되는 모달 대화상자의 콘텐츠는 텍스트, QR 코드 및 기타 시각 매체를 포함할 수 있으며, 레이블이 지정되고 보조 기술에 노출되어야 SHOULD 합니다.
상호작용 요소, 특히 사용자가 발급 또는 제시 요청을 계속하거나 중단할 수 있게 하는 요소는 기기 독립적인 방식으로 조작 가능해야 MUST 합니다.
사용자 에이전트 자동화 및 애플리케이션 테스트를 위해, 이 문서는 WebDriver BiDi 명세를 위한 확장 모듈을 정의합니다. 사용자 에이전트가 이를 지원하는 것은 OPTIONAL입니다.
digitalCredentials 모듈은
[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors),
및 [[Create]](origin, options, sameOriginWithAncestors)
호출 중 credential managers의 원격 끝 동작을 관리하고
시뮬레이션하기 위한 명령을 포함합니다.
CDDLdigitalCredentials.VirtualWalletAction = "decline" / "respond" / "wait" / "clear"
digitalCredentials.SetVirtualWalletBehaviorParameters = {
action: digitalCredentials.VirtualWalletAction,
? context: text,
? protocol: text,
? response: { * text => any },
}
digitalCredentials.VirtualWalletAction
유형은 다양한 유형의 가상 지갑 동작을 나타냅니다.
"decline"
"respond"
"wait"
"clear"
CDDLdigitalCredentials.SetVirtualWalletBehavior = (
method: "digitalCredentials.setVirtualWalletBehavior",
params: digitalCredentials.SetVirtualWalletBehaviorParameters
)
CDDLdigitalCredentials.SetVirtualWalletBehaviorResult = EmptyResult
session 및 command parameters가 주어졌을 때
digitalCredentials.setVirtualWalletBehavior 명령에 대한
원격 끝 단계는 다음과 같습니다.
action"]으로 둡니다.
context"]가 존재하면
context를 그것으로 두고,
그렇지 않으면 null로 둡니다.
protocol"]이
존재하면 protocol을 그것으로 두고,
그렇지 않으면 null로 둡니다.
response"]가 존재하면
response를 그것으로 두고,
그렇지 않으면 null로 둡니다.
"respond"이면:
null이거나 response가
null이면, invalid argument
오류 코드를 가진
오류를 반환합니다.
DigitalCredentialProtocol의
enumeration value가 아니면,
invalid argument
오류 코드를 가진
오류를 반환합니다.
null이 아니거나 protocol이
null이 아니면,
invalid argument
오류 코드를 가진
오류를 반환합니다.
"clear"이면:
null이 아니면,
WebDriver session의 active
virtual wallet behavior에서
context에 대한 항목을 제거합니다.
null로 설정합니다.
null이 아니면, WebDriver session의
browsing context ID context에 대한
active virtual wallet behavior를
behavior로 설정합니다.
null과 함께 success를 반환합니다.
Promise
promise와 전역 객체 global이 주어졌을 때
가상
지갑 동작을 처리하려면, 다음 단계를 실행합니다.
false를 반환합니다.
null이면, behavior를 현재 WebDriver
session의 기본 active virtual wallet behavior로 설정합니다.
null이면, false를 반환합니다.
"wait"이면, true를 반환합니다.
"decline"이면:
NotAllowedError"
DOMException으로
Reject합니다.
true를 반환합니다.
"respond"이면:
DigitalCredential 인스턴스로 둡니다.
protocol 속성을
protocol로 설정합니다.
data
속성을 JS
object로 설정합니다.
true를 반환합니다.
action
§13.1.1
"clear"
§13.1.1
context
§13.1.1
[[Create]](origin, options, sameOriginWithAncestors)
DigitalCredential의 내부 슬롯
§8.3
DigitalCredentialGetRequest의 멤버
§7.3.2
DigitalCredentialCreateRequest의 멤버
§7.6.2
DigitalCredential의 속성
§7.7.2
"decline"
§13.1.1
CredentialRequestOptions의 멤버
§7.1.1
CredentialCreationOptions의 멤버
§7.4.1
DigitalCredential 인터페이스
§7.7
DigitalCredentialCreateRequest
딕셔너리
§7.6
DigitalCredentialCreationOptions
딕셔너리
§7.5
DigitalCredentialGetRequest 딕셔너리
§7.3
DigitalCredentialIssuanceProtocol
열거형
§7.8.3
DigitalCredentialPresentationProtocol
열거형
§7.8.2
DigitalCredentialProtocol
§7.7
DigitalCredentialRequestOptions
딕셔너리
§7.2
digitalCredentials.SetVirtualWalletBehavior
§13.1.2.1
"digitalCredentials.setVirtualWalletBehavior"
§13.1.2.1
digitalCredentials.SetVirtualWalletBehaviorParameters
§13.1.1
digitalCredentials.SetVirtualWalletBehaviorResult
§13.1.2.1
digitalCredentials.VirtualWalletAction
§13.1.1
[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)
DigitalCredential의 내부 슬롯
§8.1
[[discovery]]
DigitalCredential의 내부 슬롯
§8.5
method
§13.1.2.1
"openid4vci-v1"
DigitalCredentialIssuanceProtocol의 열거형 값
§5.
"openid4vp-v1-multisigned"
DigitalCredentialPresentationProtocol의 열거형 값
§5.
"openid4vp-v1-signed"
DigitalCredentialPresentationProtocol의 열거형 값
§5.
"openid4vp-v1-unsigned"
DigitalCredentialPresentationProtocol의 열거형 값
§5.
"org-iso-mdoc"
DigitalCredentialPresentationProtocol의 열거형 값
§5.
params
§13.1.2.1
DigitalCredentialGetRequest의 멤버
§7.3.1
DigitalCredentialCreateRequest의 멤버
§7.6.1
DigitalCredential의 속성
§7.7.1
DigitalCredentialRequestOptions의 멤버
§7.2.1
DigitalCredentialCreationOptions의 멤버
§7.5.1
"respond"
§13.1.1
response
§13.1.1
[[Store]](credential, sameOriginWithAncestors)
DigitalCredential의 내부 슬롯
§8.2
text
§13.1.1
[[type]] DigitalCredential의 내부
슬롯
§8.4
userAgentAllowsProtocol()
DigitalCredential의 메서드
§7.7.3
"wait"
§13.1.1
[[Create]](origin, options, sameOriginWithAncestors)
(Credential 대상)
[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)
(Credential 대상)
[[Store]](credential, sameOriginWithAncestors)
(Credential 대상)
create() (CredentialsContainer
대상)
Credential 인터페이스
CredentialCreationOptions
CredentialRequestOptions
CredentialsContainer 인터페이스
get() (CredentialsContainer 대상)
mediation (
CredentialRequestOptions 대상)
mediation (
CredentialCreationOptions 대상)
required (
CredentialMediationRequirement 대상)
signal (
CredentialRequestOptions 대상)
signal (
CredentialCreationOptions 대상)
AbortSignal 대상)
AbortSignal 대상)
AbortSignal 인터페이스
AbortSignal 대상)
AbortSignal 대상)
AbortController 대상)
AbortController 대상)
Document 대상)
Document 대상)
iframe
요소
object
유형
list 대상)
iteration 대상)
list 대상)
list 대상)
struct 대상)
AbortError 예외
boolean
유형
[Default] 확장 속성
DOMException 인터페이스
DOMString 인터페이스
[Exposed] 확장 속성
InvalidStateError 예외
NotAllowedError 예외
object
유형
OperationError 예외
Promise 인터페이스
ReferenceError 예외
[SameObject] 확장 속성
[SecureContext] 확장 속성
exception 대상)
TypeError 예외
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",
};
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
)digitalCredentials.SetVirtualWalletBehaviorResult = EmptyResult비규범적으로 표시된 절뿐만 아니라, 이 명세의 모든 작성 지침, 다이어그램, 예제 및 참고는 비규범적입니다. 이 명세의 그 밖의 모든 것은 규범적입니다.
이 문서의 핵심 단어 MAY, MUST, MUST NOT, OPTIONAL, 그리고 SHOULD는 여기에 표시된 것처럼 모두 대문자로 나타날 때, 그리고 오직 그 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석되어야 합니다.
편집자 일부는 이 명세에 대한 피드백과 기여에 대해 다음 개인들에게 감사드립니다: 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).
Some of the Editors would like to thank the following individuals for their feedback and contributions to this specification: 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 (Invited Expert), Manu Sporny (Digital Bazaar), Orie Steele (Transmute), Ted Thibodeau Jr (OpenLink Software), David Waite (Ping Identity), and Kristina Yasuda (SPRIND).
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: