Copyright © 2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
この文書は、ユーザーエージェント が 提示および発行を仲介できるようにする API を規定します。対象となるのは、デジタル クレデンシャルであり、たとえば 運転免許証、政府発行の身分証明書、または その他の種類のデジタルクレデンシャルがあります。 この API は クレデンシャル管理レベル 1を基盤としており、 クレデンシャル形式に依存しないように 設計されています。
この節では、公開時点におけるこの 文書のステータスについて説明します。現在の W3C の公開文書一覧およびこの技術報告書の最新版は、 W3C 標準および草案 インデックスにあります。
この文書は、Federated Identity Working Groupによって、 勧告 トラックを使用した作業草案として公開されました。
作業草案としての公開は、 W3C およびそのメンバーによる承認を 意味するものではありません。
これは草案文書であり、いつでも他の 文書によって更新、置換、または廃止される可能性があります。この文書を 作業中の文書以外のものとして引用することは不適切です。
この文書は、 W3C 特許 ポリシーの下で活動するグループによって作成されました。 W3C は、このグループの成果物に関連して行われた 特許開示の公開リストを 維持しています。そのページには、 特許を開示するための手順も含まれています。ある個人が、 必須クレームを含むとその個人が考える特許について 実際の知識を有する場合、その情報を W3C 特許ポリシーの第 6 節に従って開示しなければなりません。
この文書は、 2025年8月18日付 W3C プロセス文書に準拠します。
この節は規範的ではありません。
この文書は、ウェブサイトがデジタルクレデンシャルの提示 および発行を要求できるようにする API を定義します。
この API はクレデンシャル形式に依存せず、複数の提示プロトコルおよび 発行プロトコルへ拡張できるように設計されています。5. プロトコルを参照してください。
この API は、次の目標をサポートするように設計されています:
多くの種類のデジタルクレデンシャルを、この API を使用して提示および発行できます。 これらの種類の 例には、次のものがあります:
この節は規範的ではありません。
次の例は、APIを 使用してデジタルクレデンシャルを要求および発行する方法を示しています。
APIを使用する前に、ユーザー エージェントが必要な機能をサポートしているかを 確認することが重要です。これは、次の コードを使用して確認できます:
if (typeof DigitalCredential !== "undefined") {
// API はサポートされている
} else {
// API はサポートされていない
}
userAgentAllowsProtocol()
静的メソッドを使用すると、
デジタルクレデンシャルの発行または提示について、ユーザーエージェントが
特定のプロトコルを許可しているかどうかを確認できます。これは、
API 呼び出しを行う前に、ユーザーのブラウザーで許可されているプロトコルを
確認するのに役立ちます。DigitalCredential
（上記のtypeofチェックで検出可能）を実装するブラウザーでは、プロトコル識別子は
DigitalCredentialProtocol
に、ユーザーエージェントがそれらのサポートを採用するにつれて段階的に追加されるため、
不明な
プロトコル識別子を指定してこのメソッドを呼び出しても、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) {
// 少なくとも 1 つのプロトコルがサポートされている。発行を続行する。
} else {
// サポートされているプロトコルがない。別の発行方法にフォールバックする。
}
プロトコル識別子はDigitalCredentialProtocolに
段階的に追加されるため、このメソッドを使用して新しいプロトコルを優先しつつ、
レガシーブラウザでは古いものへ適切にフォールバックできます:
// 優先順位順。DigitalCredential を実装するブラウザでは、
// 不明なプロトコルは投げるのではなく false を返す。
const protocol = [
"example-new-protocol",
"example-legacy-protocol",
].find(DigitalCredential.userAgentAllowsProtocol);
if (protocol) {
// このブラウザがサポートする最適なプロトコルを使用する。
} else {
// サポートされているプロトコルが見つからない。別の方法にフォールバックする。
}
次の例は、APIを使用して
デジタルクレデンシャルを要求する方法を示しています。API のエントリーポイントは
navigator.credentials.get() メソッドであり、
これは
ユーザーエージェントからデジタルクレデンシャルを要求するために使用されます。
ユーザーエージェントが提示をサポートしている場合、ユーザーはデジタルクレデンシャル選択 UIを通じて
デジタルクレデンシャルを選択できます:
<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は、 サイト、ユーザーエージェント、 および保有者の間でデジタルクレデンシャルの発行を仲介します。
次の例は、デジタル
クレデンシャル 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" ポリシー制御対象機能を介して、リモート／第三者オリジンからクレデンシャルを提示するために API を使用できます。これは、 ウェブサイトが異なる オリジン上でホストされている検証サービスからデジタル クレデンシャルを要求したいシナリオで有用です。Permissions Policy は、 API を使用するウェブサイトを埋め込む iframe に設定できます。 iframe に Permissions Policy を設定する方法の例を次に示します:
<iframe src="https://verifier-service.example.com"
allow="digital-credentials-get">
</iframe>同様に、この仕様では、 "digital-credentials-create" ポリシー制御対象機能を介して、リモート／第三者オリジンから クレデンシャルを発行するために API を使用できます。これは、 ウェブサイトが異なるオリジン上の発行サービスを使用して デジタルクレデンシャルの発行を要求したいシナリオで有用です。 Permissions Policy は、発行者の インターフェイスを埋め込む iframe に設定できます。例を次に示します:
<iframe src="https://issuer.example.com"
allow="digital-credentials-create">
</iframe>この節は規範的ではありません。
次の項目は、この仕様の適用範囲内です:
次の項目は適用範囲外です:
この節の定義の目的は、さまざまなデジタルクレデンシャル形式 およびプロトコルに共通する用語を再利用または確立することです。 これらの定義は現在も積極的に発展しています。
この仕様は現在、人に 関係するデジタルクレデンシャルに焦点を当てています。
次の提示プロトコルおよび 発行プロトコルの使用は、この 仕様によって定義されます。
ユーザーエージェントは、提示プロトコルのうち、サポートされる 提示および発行プロトコルの表に列挙されているすべてをサポートしなければなりません。ユーザーエージェントは、発行プロトコルのうち、その表に列挙されているすべても サポートすることが推奨されます。
| 識別子 | 仕様 |
|---|---|
| 提示プロトコル | |
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 統合
|
DigitalCredentialGetRequestまたはDigitalCredentialCreateRequest
requestが与えられたときに要求プロトコルを変換するには:
DigitalCredentialGetRequestの場合:
protocolとします。
DigitalCredentialPresentationProtocol内のどの列挙値とも等しくない場合、
failure を返します。
DigitalCredentialPresentationProtocolの
列挙値を返します。
DigitalCredentialCreateRequestの場合:
protocolとします。
DigitalCredentialIssuanceProtocol内のどの列挙値とも等しくない場合、
failure を返します。
DigitalCredentialIssuanceProtocolの
列挙値を返します。
クレデンシャル要求コーディネーターは、 最上位 traversableを通じてデジタル クレデンシャルの インタラクションを仲介する、ユーザーエージェント定義のコンポーネントです。各最上位 traversableには、関連付けられた コーディネーターが正確に 1 つ存在します。コーディネーターは、 すべての子 navigable全体で同時にアクティブになるインタラクションが最大 1 つであることを保証し、提示または 発行のエンドツーエンドのフローを調整し、インタラクション状態間の遷移を管理します。
クレデンシャル要求コーディネーターは、アクティブな promiseを保持し、ユーザー
エージェントはこれを null に初期化します。このPromiseを通じて、
コーディネーターは、非同期の
クレデンシャル要求ワークフローの状態をスクリプトに反映し、
インタラクションが正常に完了した場合はクレデンシャル
応答で解決し、処理が失敗した場合、
ユーザーが UI を介して要求をキャンセルした場合、またはスクリプトが
AbortSignalを介して操作を中止した場合は拒否します。
クレデンシャル要求コーディネーターは、中止シグナルを保持し、ユーザーエージェントは
これを null に初期化します。
クレデンシャル要求コーディネーターは、中止アルゴリズムを保持し、ユーザー
エージェントはこれを null に初期化します。
ユーザーエージェントは、ユーザーまたはプラットフォームのポリシーに従って、 コーディネーターの責務の一部または全部を外部のクレデンシャルマネージャー、プラットフォームコンポーネント、またはその他の信頼された エンティティに委任してもよいです。
クレデンシャル要求コーディネーターには有限個の インタラクション 状態があり、クレデンシャル 要求のライフサイクルを管理するために使用されます:
コーディネーターは、アイドルのインタラクション 状態で初期化されます。
Window global、オリジン origin、
DigitalCredentialGetRequest値のシーケンス、
またはDigitalCredentialCreateRequest
値のシーケンス requests、およびオプションの
AbortSignal signalが与えられたときに、クレデンシャル
要求を準備するには:
SecurityError" DOMExceptionで拒否された promiseを返します。
Documentとします。
InvalidStateError" DOMExceptionで拒否された promiseを返します。
NotAllowedError" DOMExceptionで拒否された promiseを返します。
NotAllowedError" DOMExceptionで拒否された promiseを返します。
NotAllowedError"
DOMExceptionで
promiseを拒否します。
null です。
TypeErrorおよび
promiseを指定して、クレデンシャル
要求を拒否します。
事前に中止されたシグナルは、
このアルゴリズムが呼び出される前にCredential を
要求するおよびCredential を
作成するによって処理されます。
AbortError" DOMExceptionを指定してクレデンシャル要求を中止します。
true の場合、promiseを返します。
DigitalCredentialGetRequestまたは
DigitalCredentialCreateRequest
オブジェクトのシーケンス requestsが与えられたときにクレデンシャル
要求をフィルタリングするには:
false を返す場合、続行します。
フィルタリングはユーザーアクティベーションを消費する前に行われるため、
すべてのプロトコルがサポートされていない要求は、ユーザーアクティベーションを
消費せずにTypeErrorで拒否されます。
その後のクレデンシャル要求の検証では、残っているすべての要求が
サポートされているプロトコルを使用していると安全に仮定できます。
DigitalCredentialGetRequestまたは
DigitalCredentialCreateRequest
オブジェクトのシーケンス requestsが与えられたときにクレデンシャル
要求を検証するには:
DigitalCredentialGetRequestの場合は
requestのdataを、
requestが
DigitalCredentialCreateRequestの場合はrequestの
dataを、
dataとします。
プロトコルで定義された要件に加えて、ユーザーエージェントは、 ローカルポリシー、設定、またはユーザーの選択に基づく検証基準を 適用する場合があります。たとえば、ユーザーエージェントは、特定のクレデンシャル 属性を要求するリクエストを拒否する場合があります。
何を検証失敗とみなすかはプロトコル固有ですが、 その失敗をどの例外型に分類するかは 以下で定義します:
NotAllowedError"
DOMException。
"NotAllowedError"
は、ユーザーが操作をキャンセルしたときに返されるエラーと
意図的に区別できないようにされています。これによりウェブサイトは、
要求がユーザーによって拒否されたのか
ユーザーエージェントによって拒否されたのかを
判断したり、ユーザーの設定やクレデンシャルについて
推測したりできません。
SecurityError"
DOMException。
TypeError。
OperationError"
DOMException。
JavaScript 値 errorが与えられたときにクレデンシャル 要求を中止するには:
null の場合、
返ります。
閉じる処理は失敗する場合があります（たとえば、デジタルクレデンシャル選択 UIが メモリ圧迫により破棄されていた場合）が、コーディネーターは それにかかわらずクレデンシャル要求の完了処理を続行します。
(JavaScript Value) errorおよび
Promise promiseが与えられたときにクレデンシャル
要求を拒否するには:
null でなく、abortAlgorithmも
null でない場合:
null に設定します。
null に設定します。
null に設定します。
Document
document、検証済みクレデンシャル要求validatedRequestsのリスト、
Promise
promise、およびオプションのAbortSignal
signalが与えられたときに、クレデンシャル
要求を開始するには:
ユーザーエージェントが、別のデバイス上にあるクレデンシャルマネージャーと 通信する場合、ユーザーエージェントがClient to Authenticator Protocol (CTAP)を使用することが推奨されます。
クレデンシャル要求を 準備する手順によってsignalに追加された 中止アルゴリズムが、デジタルクレデンシャル 選択 UIの終了処理を行います。
NotAllowedError"
DOMExceptionとします。
NotAllowedError"
DOMException。
TypeError。
InvalidStateError"
DOMException。
OperationError"
DOMException。
デジタルクレデンシャル 選択 UIまたは基盤となるプラットフォームが、 validatedRequestsのどの項目を保有者へ転送するかを決定し、その交換のプロトコル 識別子を返します。ユーザーエージェントは、 どの特定の項目が選択されたかを必ずしも認識しません。
null でなく、
abortAlgorithmも
null でない場合、abortAlgorithmを
abortSignalから削除します。
null に設定します。
null に設定します。
DigitalCredential
インスタンスとし、その
data
を
parsedResponseDataOrErrorで初期化し、
protocol
をprotocolで初期化します。
null に設定します。
デジタルクレデンシャル APIは、 Credential Management Level 1 仕様を利用し、ユーザーエージェントが デジタル クレデンシャルの発行および提示を仲介できるようにします。
この API は、ユーザーエージェントから
デジタルクレデンシャルを要求できるようにします。ユーザーエージェントは、その要求を満たせる
デジタルクレデンシャルを選択できる
デジタルクレデンシャル選択 UIをユーザーに提示します。これは、
ウェブサイトが
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は、
提示プロトコルおよび提示要求データを指定し、ユーザーエージェントはこれを
デジタルウォレットなどのクレデンシャルマネージャーと照合してもよいです。
DigitalCredentialGetRequest
辞書は提示要求を表します。これは、
提示プロトコルおよび提示要求データを指定するために使用され、ユーザーエージェントはこれらを
デジタルウォレットなどのクレデンシャルマネージャーと照合してもよいです。
WebIDLdictionary DigitalCredentialGetRequest {
required DOMString protocol;
required object data;
};
protocol メンバーは、
提示プロトコルを示します。
protocol メンバーの値は、
DigitalCredentialPresentationProtocolで定義されている
プロトコル識別子のいずれかです。
data メンバーは、
デジタル ID ウォレットなどの保有者のクレデンシャルマネージャーによって処理される
提示要求データです。
WebIDLpartial dictionary CredentialCreationOptions {
DigitalCredentialCreationOptions digital;
};
digital メンバーは、
デジタルクレデンシャルの発行を設定するためのオプションを指定できるようにします。
WebIDLdictionary DigitalCredentialCreationOptions {
required sequence<DigitalCredentialCreateRequest> requests;
};
requestsは、
発行プロトコルおよび発行要求データを指定し、ユーザーエージェントはこれを
保有者に転送してもよいです。
DigitalCredentialCreateRequest
辞書は発行要求を表します。これは、
発行プロトコルおよび発行要求データを指定し、
発行者と保有者の間で発行要求を伝達するために使用されます。
WebIDLdictionary DigitalCredentialCreateRequest {
required DOMString protocol;
required object data;
};
protocol
メンバーは発行プロトコルを示します。
protocol メンバーの
値は、
DigitalCredentialIssuanceProtocolで定義されている
プロトコル識別子のいずれかです。
data メンバー
は、デジタル ID
ウォレットなどの保有者のクレデンシャルマネージャーによって処理される発行要求データです。
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);
};
protocol メンバーは、
デジタルクレデンシャルの要求に使用された
提示プロトコル、またはデジタルクレデンシャルの発行に使用された発行プロトコルです。
data メンバーは、
クレデンシャルの応答データです。JSON で解析可能な
オブジェクト型のサブセットを含みます。
userAgentAllowsProtocol()
メソッドにより、デジタル
クレデンシャルの検証者は、ユーザーエージェントがどの提示プロトコルおよび発行プロトコルを許可するかを判断できます。
ユーザーエージェントは、ハードウェアの利用可否、ソフトウェアの存在や設定、 クレデンシャルマネージャーやデジタルクレデンシャル、 またはユーザー設定や 環境設定に関する情報に基づいて応答値を変化させてはなりません。 応答値が変化すると、ユーザーエージェントは フィンガープリンティングと、ユーザーの行動や設定に関するその他の詳細を 密かに明らかにすることの両方のリスクをもたらします。応答値は、 ユーザーエージェントのメジャーバージョンによってのみ変化し、そのプロトコルを使用する要求を 基盤となるプラットフォームまたはプロバイダーへ配布することをブラウザがサポートしているかどうかを 示すことが望ましいです。
DOMString
protocolが与えられたときに、
ユーザーエージェントがプロトコルを許可するかを確認するには、
次の手順を実行します:
DigitalCredentialProtocolの列挙値でない場合、
false を返します。
true を返し、それ以外の場合は
false を返します。
このメソッドが呼び出された場合、ユーザーエージェントは、 protocolを指定したユーザーエージェントがプロトコルを許可するの結果を 返さなければなりません。
この仕様でDigitalCredentialをサポートする、
列挙型などのデータ構造。
request contextは、次の 項目を持つ構造体です:
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) 内部メソッドが呼び出されたとき、ユーザーエージェントが
提示要求をサポートしていない場合（たとえば、プラットフォームが
デジタルクレデンシャル選択 UIを提供できない場合）、
同じ引数を使用してCredentialの
[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)
内部メソッドのデフォルト
実装を呼び出します。
それ以外の場合:
digitalの
requests メンバーとします。
TypeErrorで拒否された promiseを返します。
signalが
存在する場合、signalをそれとします。
[[Store]](credential, sameOriginWithAncestors)が呼び出されたとき、
同じ引数を使用してCredentialの
[[Store]](credential, sameOriginWithAncestors)
内部
メソッドのデフォルト実装を呼び出さなければなりません。
[[Create]](origin, options,
sameOriginWithAncestors) 内部メソッドが呼び出されたとき、ユーザーエージェントが
発行要求をサポートしていない場合、同じ
引数を使用してCredentialの[[Create]](origin, options, sameOriginWithAncestors)
内部メソッドのデフォルト実装を呼び出します。それ以外の場合:
digitalの
requests メンバーとします。
TypeErrorで拒否された promiseを返します。
signalが
存在する場合、signalをそれとします。
DigitalCredential インターフェイスオブジェクトは、
[[type]]
という名前の内部スロットを持ち、その値は "digital" です。
DigitalCredential インターフェイスオブジェクトは、
[[discovery]]
という名前の内部スロットを持ち、その値は "remote" です。
この節は規範的ではありません。
デジタルクレデンシャル
APIは、エンドユーザーからの明示的な許可を必要とする強力な機能です。この
要件は、CredentialsContainerの
get()
メソッドを呼び出す際に規範的に適用されます。
この仕様は、2 つのポリシー制御対象機能を定義します:
Credential を要求する
アルゴリズムがポリシー適用点として機能します。
Credential を作成するアルゴリズムが
ポリシー適用点として機能します。
この節は規範的ではありません。
以下の節では、API のセキュリティ特性、対象範囲内の 脅威、セキュリティが依存する前提条件、および 緩和策を適用した後も残る残余脅威について説明します。この 仕様は、クレデンシャル応答を仲介する場合に限り、 ユーザーエージェントの動作に関する要件を定義します。
プロトコル、クレデンシャルマネージャーの実装、 オペレーティングシステム、またはトランスポートセキュリティに依存するその他のセキュリティ上の考慮事項は、 期待事項または前提条件として説明されていますが、すでに規範的に 規定されている場合を除き、この仕様によって規範的に要求されるものではありません。
この仕様の脅威モデルには、この API およびエコシステムに隣接する標準に対する脅威が含まれます。
この仕様では、脅威は 2 つのカテゴリに分類されます: 対象範囲内の 脅威と対象範囲外の脅威です。
対象範囲内の脅威とは、DC API 自体によって導入される、または対処される脅威です。以下は、この 仕様における対象範囲内の脅威です:
DigitalCredentialGetRequest
またはDigitalCredentialCreateRequest
を変更しようとします。
iframe
などの埋め込まれた第三者コンテンツを通じて、
埋め込み元サイトからの明示的な許可なしにデジタルクレデンシャルを
要求または発行しようとし、クレデンシャルの収集や機微なユーザーデータへの
認可されていないアクセスを可能にするおそれがあります。
適用範囲外の脅威とは、プロトコル、 資格情報マネージャー、OS プラットフォームのセキュリティ、または トランスポート層によって対処される脅威です。 「適用範囲外」であっても、資格情報の提示および発行における エンドツーエンドのセキュリティに影響を与えるため、これらは関連性があります。以下では、 この仕様における適用範囲外の脅威を 定義します：
以下の緩和策は、仕様内の規範的要件を通じて対象範囲内の脅威に対処します。
Digital Credential API の WebIDL インターフェイスは、 セキュアコンテキストでのみ公開され、 安全でないコンテキストを通じた改ざん（たとえば、ネットワークを介して悪意のあるスクリプトが 注入されること）のリスクを低減します。詳細については、 Secure Contexts仕様の § 5 セキュリティに関する考慮事項の節を参照してください。
基盤プラットフォームに対する悪意のある ペイロードのリスクを軽減するため、ユーザーエージェントは、リクエストパラメーターを 資格情報マネージャーに、JSON シリアル化を使用して渡します（ 資格情報リクエストを検証するを参照）。基盤 プラットフォーム および資格情報マネージャーは、これらのプロトコル固有の JSON ペイロードを処理する前に、堅牢に 解析し、 検証する責任を負います。
さらに、不透明なオリジンからの要求は拒否されます。
不透明なオリジン（たとえば、
data: 文書、または allow-same-origin なしで
サンドボックス化された文書）からの
[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)
および[[Create]](origin, options, sameOriginWithAncestors)
の呼び出しは拒否され、
信頼できない環境からの悪意ある抽出またはなりすましのリスクを低減します。
Digital Credentials API は、次の 2 つの メカニズムによって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" ポリシー制御対象機能のポリシー適用点として機能します。
2 つの機能は意図的に分離されています。サイトは
"digital-credentials-create"を有効にせずに
"digital-credentials-get"を有効にすることも、その逆も可能であり、
各埋め込みコンテキストを必要な機能だけに制限できます。この統合によって提供される追加の
セキュリティ特性については、
Permissions Policy仕様の
Permissions Policyの節を
参照してください。
提示プロトコルがリクエストに 署名する方法を提供している場合、検証者には、その方法を使用することが強く推奨されます。
署名されていないリクエストは、検証者自身のページで実行されている スクリプト、たとえば悪意のあるブラウザー 拡張機能によって注入されたスクリプトによって改変される可能性があります。そのスクリプトは要求されている内容を変更し、 限定的なリクエストをはるかに多くのものを求める要求へと変えることができ、さらに レスポンスを 暗号化するために使用されるパラメーターを置き換えることで、レスポンスが検証者ではなく 攻撃者に対して暗号化されるようにすることもできます。API をセキュアコンテキストで使用することを要求しても、これを防ぐことはできません。なぜなら、 攻撃者はすでに その内部にいるからです。署名されていないリクエストでは、資格情報マネージャーは、 検証者が自身のページにそのような スクリプトが存在しない状態を保っていることを信頼しなければなりません。一方、署名されたリクエストは、資格情報マネージャーに確認できるものを提供するため、 変更が気付かれないまま通過するのではなく、検出できるようになります。
それでも、署名が役立つのは、資格情報マネージャーが、 その署名がリクエストを行っている検証者のものであると判断できる場合に限られます。 ページ内のスクリプトは、改変したリクエストに 自身の鍵で再署名できるため、署名を、 その検証者のものとしてすでに認識されている署名鍵と照合できない限り、この攻撃者に対する 保護にはなりません。どの署名鍵を受け入れるか、またそれらをどのように 確立するかは、この仕様ではなく、資格情報が 属するエコシステムによって決定され、署名されたリクエストが実際に提供する保護は その決定に依存します。同一デバイス上のページ内での改ざんから 保護することに加え、リクエストへの署名は、 複数のデバイス間で資格情報を提示する際にも重要な多層防御を 提供します（ 10.4 デバイス間のセキュリティと近接性を参照）。
Digital Credentials API は、ユーザーがスマートフォンなどのセカンダリデバイスから デジタル資格情報を、資格情報マネージャーとして機能させ、 ノートパソコンなどのプライマリデバイスに提示するクロスデバイス体験をサポートします。 特定のデータ交換 プロトコル（例：暗号形式およびトランスポート）は、この API の 適用範囲外ですが、このようなクロスデバイスのやり取りは通常、 Client to Authenticator Protocol (CTAP)（クライアント から認証器へのプロトコル (CTAP)）のような確立されたプロトコルに依存します。
これらのプロトコルは、暗号学的に 安全なチャネルを確立し、物理的近接性（例：Bluetooth Low Energy 経由）を強制することで、リモートリレー攻撃を軽減し、セキュリティを確保します。重要なのは、 クロスデバイスフローでは、資格情報マネージャーが、プライマリデバイスから転送された オリジン文字列を本質的に信頼することはできないという点です。プライマリ デバイスまたはそのブラウザーが侵害されている可能性があるためです。したがって、 検証者が暗号学的に 自身の身元を証明する署名付きリクエストを採用するプロトコルは、 ブラウザーが表明するオリジンのみに依存する場合よりも大幅に強力なセキュリティ 保証を提供します。
この節は規範的ではありません。
この節は、この文書の発展に伴い作業中です。
Digital Credentials API は、複数の技術層とさまざまな参加者 （検証者、保有者、および発行者を含むが、これらに限定されません）が存在する 複雑なエコシステムに統合されます。それぞれが ユーザーのプライバシーについて異なる側面を考慮する必要があります。この仕様では、 各参加者に関するすべての考慮事項を網羅的に列挙しようとはしません。 これらの関係者には、デジタルクレデンシャルの脅威モデルを より包括的に検討している次のさまざまな資料を参照することを推奨します:
代わりに、ここでの考慮事項は Digital Credentials API 自体に焦点を当て、API と相互作用するエコシステムの 関連するプライバシー特性を考慮しつつ、ユーザーエージェントが API の実装においてユーザーエージェントの責務をどのように果たせるかを説明します。
デジタルクレデンシャルに関するプライバシー上の考慮事項は静的ではありません。 エコシステムが成熟するにつれて時間とともに発展し、 エコシステム内の他の主体の行動、スタックの他の 層における改善、ユーザーのプライバシーに対する新たな脅威、さらには 社会規範や規制の変化によって影響を受ける可能性があります。
Digital Credentials API の設計および 実装に関与するさまざまなグループは、変化する プライバシー状況を積極的に監視し、それに対応する API の発展に参加することが期待されます。
Digital Credentials API は、ウェブサイトからの デジタルクレデンシャル要求を仲介するように設計されており、 クレデンシャル形式やその中に含まれる情報、およびそれを交換するために 使用されるプロトコルに依存しません。この設計やその他の主要な設計上の選択は、 既存の代替手段（たとえば [custom-schemes]）よりも、 ユーザーにとって安全かつプライバシーに配慮したクレデンシャル 交換体験を提供しつつ、導入を容易にするために一般的な交換 プロトコルとの互換性を維持するという目標から導かれています。
この API は、検証者と 保持者の間の接続インターフェースを提供する。 すなわち、資格情報提示プロトコル が開始され、ユーザーが保持者アプリケーションへ切り替えて 資格情報を選択するための手段を提供する。過去にこの目的で使用されてきた ソリューションには、QR コードやカスタム URL スキームが含まれる。 Presenting Credentials on the Web および Concerns with custom schemes for identity presentment に記載されているように、 これらのソリューションにはセキュリティ、プライバシー、アクセシビリティ上の懸念がある。
デジタル資格情報技術の採用は、エコシステムの需要および規制上の義務によって 推進されているため、Web プラットフォームは、前述の望ましくない技術に代わる 選択肢を提供する。この選択肢は開発者にとって使いやすく、既存の資格情報 提示プロトコルと互換性があり、 さらに最も重要な点として、前述の代替手段よりもユーザーに対して 優れたプライバシー、セキュリティ、およびアクセシビリティ特性を備えている。
Digital Credentials API は、ユーザー エージェントがユーザーに代わって 仲介し（たとえばデジタルクレデンシャル選択 UIの形で）、 要求にコンテキストを与え、 保有者アプリケーションへの 即時の露出を防ぐ機能を提供します。また、 応答の 暗号化など、サポートされるプロトコルに一定の最低要件も課します。
Digital Credentials API は、データ開示の程度が異なる さまざまなユースケースと、置かれているコンテキストによって 異なる嗜好を持つ個々のユーザーに対応します。 特に、この API によって仲介されるクレデンシャル交換の プライバシー特性は、個々のユーザーの法的および規制上の環境によって 義務付けられる場合があります。
これは、一部のユーザーがクレデンシャル情報を交換するための 最もプライバシー保護の強い手段を望まない、または使用を許可されない可能性があることを意味します。 それでも、ユーザーエージェントは、デフォルトでプライバシーを保護し、 害から守る体験をユーザーに提供する必要があります。
このように嗜好やユースケースが幅広いため、 ユーザーエージェントが、ユーザーが自ら個人情報を 公開しようとしているのか、それともそうするよう欺かれているのかを見分けることは 難しい場合があります。したがって、情報交換を開始する前に、 各ユーザーがどのデータを共有するのか、そして誰が 情報交換に参加するのかを理解していることを保証するのは、ユーザーエージェントの責任です。
Digital Credentials API は複数の独立した関係者が関与する 交換の中心に位置するため、これらの関係者が ユーザー情報を交換するために使用する提示プロトコルおよびクレデンシャル形式は、 ユーザーのプライバシーを保護するというユーザーエージェントの目標にとって極めて重要です。
プロトコルについて、さらに詳しく説明する必要があると考える要件が 2 つあります:
プライバシーレビューを受けていなければならない [...]
そして
セキュリティレビューを受けていなければならない [...]
技術的には、「このプロトコルはあらゆる点でひどい」とするレビューでも、これらの 基準を満たします。
プロトコルが満たす必要のある具体的なプライバシーおよびセキュリティ 要件の集合があり、レビューによって 標準を達成したかどうかを判断できる方が有用でしょう。レビューには主観的な要素が 含まれる場合もありますが、各プロトコルが超える必要のある最低基準も 存在すべきです。
これは現在の包含基準にある現在の要件を超えるものです。包括的な一覧を今すぐ 提示できるわけではありませんが、作成することは可能なはずです。そして作成されたら、その一覧を仕様に含めるべきです。 たとえば、プロトコルはphone homeに依存しているでしょうか？プロトコル（またはそれが伝送する形式）は、 提示のリンク不可能性を保証するでしょうか？あるいは、リンク不可能性が一部のユースケースでは意味を持たないことを踏まえ、 どのような条件で API はプロトコルにリンク不可能性を提供するよう要求するのでしょうか？ プロトコルにはどのような透明性のための仕組みが含まれるでしょうか？どのような 隠れたチャネルが許容されるでしょうか？
選択的開示は、 データ最小化のための 基本的な技術であり、 保持者が 検証者によって要求された 最小限の必要な情報を共有できるようにする。プロトコルは、 検証者が必要なクレームを 正確に指定できるようにすることで、選択的開示を実現することが期待される。
非リンク可能性 は、ユーザーが資格情報から属性を複数回提示した場合に、 検証者がこれらの個別の提示を 同じユーザーに関するものだと結論付けるために関連付けることができない （検証者間リンク可能性）、または検証者が 発行者と共謀して、 資格情報マネージャーから 発行者への資格情報の交換を報告できない （検証者・発行者間リンク可能性）ことを保証する特性である。前者は、 保持者および 発行者によって維持できる特性であり、 例えば個々の検証者ごとに新しい資格情報を発行することによって実現できる。
後者は、例えば ゼロ知識証明によって 実現可能であるが、暗号化された応答などの API の設計上の選択により、 ユーザーエージェントが 検証者・発行者間の非リンク可能性が実際に達成されたことを証明することは 不可能である。それでも、プロトコルは可能な限りリンク可能性を制限することが 求められる。
非リンク可能性は、特定のユーザー ID に関連付けることができない属性に 限って考慮される点に注意する必要がある。名前、運転免許証番号、 電話番号など、本質的にリンク可能な属性は非リンク可能性の恩恵を受けない。
Digital Credentials API を通じて、ユーザー エージェントは、 検証者と資格情報マネージャーがリンク不能な 属性を交換するのを支援できますが、レスポンスが暗号化されているため、 検証者と 資格情報マネージャーの間でリンク可能な情報が一切渡されないことを保証することはできません。 ユーザーエージェントは、 ユーザー許可の体験において、この事実を考慮することが推奨されます。
この API の目標とするリンク不可能性のレベルはどの程度でしょうか？ 特定のリンク不可能性機能のサポートを規範的に 強制できるでしょうか？
「ホームへの 通信」とは、 デジタル資格情報の提示または検証によって、 発行者または別の中央エンティティへの通知や通信が発生し、それによって個人の 追跡や プロファイリングにつながる可能性があるシナリオを指します。
リンク不能性と同様に、ユーザー エージェントが、 ユーザーが資格情報リクエストの続行を 許可した後に、発行者が資格情報提示の作成または 検証に積極的に関与していないことを保証することは不可能です。その時点以降、 この判断は資格情報マネージャーに委ねられます。一部の資格情報 マネージャーはユーザー エージェントとみなすことができますが、一般には、 ユーザーエージェントが Digital Credentials APIを実装する際、その許可 体験を、ユーザーによる確認前に リクエストが資格情報マネージャーに 露出することを防ぐように設計することが推奨されます （協調する複数のユーザーエージェントを 統合する際の考慮事項に留意してください）。
プロトコルには、発行者、 資格情報マネージャー、および検証者が「ホームへの通信」メカニズムへの 依存を回避または低減できるようにする仕組みをサポートすることが要求されます。
この API の目標とするリンク不能性のレベルはどの程度でしょうか？仕様はどの程度まで 発行者の関与に制限を課すことができるでしょうか？
クレデンシャル交換における発行者の関与の一般的な例は、 クレデンシャルの失効確認です。これは、提示を 検証者・発行者間でリンク不可能にすることを意図している場合、特に困難です。 クレデンシャル提示が、たとえば ゼロ知識 証明の使用によってリンク不可能にされる場合、 プロトコルで使用されるクレデンシャル形式は、暗号学的 アキュムレータなどのオフライン失効方式をサポートすることが期待されます。さらに、 プロトコルの設計および仕様は、可能な場合には 失効を目的とした検証者の関与を抑制することが期待されます。
リンク不可能な失効技術が規範的に要求できるほど 実用的であるかどうかを議論する必要があります。
ユーザーの理解と参加は、クレデンシャル提示において 妥協できない特性です。プロトコルは、十分な情報に基づく許可 および／または同意に不可欠な情報を提供することにより、関係するすべての 当事者がユーザー参加を可能にすることを支援することが期待されます。
ユーザー情報が「転送中」に他の当事者へ公開されることを防ぐため、 例えば検証者 ページに読み込まれたブラウザー拡張機能などに対して公開されることを防止し、 また検証者による ユーザー資格情報の安全な保存を促進するため、プロトコルは資格情報交換において 暗号化された応答をサポートし、かつ必須とすることが求められる。
#49およびこれまで行ってきたいくつかの 議論に関連します。応答は常に暗号化されなければならない （そうであれば、どのアルゴリズムを使用するか）とするのか、それともオプションのままにしても よいとするのか？
不要なクレデンシャル要求は、デジタルクレデンシャル エコシステム全体にとって重要なプライバシーリスクです。それらは、さまざまな 形や動機で現れる可能性があります:
ここでの課題の 1 つは、何が「正当な」目的を構成し、 したがってどの要求が「不要」であるかを判断することであり、 クレデンシャル交換に関与するすべての当事者の参加が必要です。
不必要な利用をどのように判断し、対処するかをより詳細に検討するには、 政府発行の資格情報とその他の資格情報を個別に 考慮することが適切です。これらは、データの機密性や 悪用によって生じ得る被害、さらに法的および規制上の考慮事項において 異なる可能性があるためです。
両方の種類の資格情報に適用される、リスク軽減およびユーザー制御を確保するための 重要な要素は、ユーザー エージェントが 資格情報リクエストのメタデータを検査し、それに基づいて判断したり UI 表示を行ったりできることです。この仕様では、リクエストを 暗号化せずに送信し、関連情報を含めるというプロトコル要件を通じて、このユーザー エージェントによるアクセスを保証します（5. プロトコル および6.2 資格情報リクエストを準備するを参照）。
政府発行の デジタルクレデンシャルには、渡航文書、個人の免許証、 福祉および公衆衛生プログラムの証明、車両登録、 その他の政府当局が発行する文書、またはこの情報を 表すその他の文書が含まれます。これらの文書は、 個人の ID や重要な公共サービスを利用する能力の 中心となる、恒久的で失効不能かつ一意の 識別子を含む可能性があるため、非常に機微性が高いものです。
これらのクレデンシャルはユーザーと攻撃者の双方にとって価値が高いため、 窃取の重大なリスクがあり、認可されていない第三者への漏えいによる 潜在的な被害も重大です。これには、追跡や パーソナライズを目的として政府発行 ID を要求することも含まれます。
政府発行クレデンシャルがオンラインで広く利用可能になることについての大きな懸念は、 ジェボンズのパラドックス、 すなわちアクセスの摩擦が低下することでクレデンシャルへの 需要が増える可能性です。この効果は Digital Credentials API 自体によって本質的に引き起こされるものではなく、エコシステム全体での デジタルクレデンシャル採用の増加によるものですが、 ユーザー エージェントによる Digital Credentials API の実装は、 それにさらなる勢いを与える可能性があります。そのため、ユーザーに有害な 結果をもたらす可能性があることから、API を実装するユーザーエージェントはこの影響を 考慮する必要があります:
上述した政府発行デジタルクレデンシャルのリスクは、 エコシステム内の 1 つの参加者だけでは解決できない課題であり、 現実世界のクレデンシャルを用いてオンラインサービスへアクセスすることの リスクと利点について、各主権国家内でより広範な政策議論が必要になります。
デジタルクレデンシャルを発行する政府が、それらのクレデンシャルを どのように、どのような目的で使用できるかを明確に定義する 法律や規制も制定することが望まれます。交換に関与するすべての当事者は、 法的に義務付けられているか否かにかかわらず、存在する場合には政府の検証者認証 スキームをサポートすることが推奨されます。 検証者認証スキーム、たとえば EUDI アクセスおよび登録証明書のサポート（および統合）は、 不要なクレデンシャル要求の増加リスクを緩和できます。しかし、 このようなスキームの存在は保証されておらず、そのことが クレデンシャル交換におけるリスクを大幅に高めます。
Digital Credentials API を実装するユーザー エージェントが、リスクを低減し、ユーザーの 理解を高め、特定の種類の被害を防止するために実行できる その他の実践的な手段があります:
さらに、ユーザー エージェントが、これらの緩和策がない場合、たとえば 検証者認証スキームなしで政府発行クレデンシャルから 個人情報を交換する場合を考慮した許可 体験を設計することが極めて重要です。この種の交換には、 より高い摩擦と、関与するリスクを強調する明確なユーザーメッセージを 適用することが推奨されます。
政府発行ではないクレデンシャルには、政府が 発行したものではなく、政府発行文書を表すものでもない、その他すべてのデジタル 文書、証明書、および証明が含まれます。 これには、雇用証明、（政府以外の）教育 クレデンシャル、映画のチケットなどが含まれる場合があります。特に、それらの交換は 法律や規制による制限が比較的少ない可能性があります。これらの文書は 政府発行クレデンシャルと同じリスクを持たない場合が多い一方、 個人を特定できる情報や機微な情報を含む可能性もあります。
政府発行ではないクレデンシャルの窃取および漏えいの影響と 実行可能性は、主に個々のクレデンシャル型の内容に 基づきます。一般には、機微な個人情報に対する 制御の喪失や露出、なりすましやデータ窃取につながる可能性があり、 影響を受けた個人に対する さらなる攻撃の可能性を高めることがあります。
政府発行ではないクレデンシャルの柔軟性と規制の少なさには、 電子メールアドレスや電話番号のような長期間存続する識別子を通じて、 サイト間追跡や ID の関連付けを行う目的で悪用される可能性があります。 デジタルクレデンシャルに基づく追跡 スキームに参加する検証者は、ユーザーが プライバシーへの影響を十分に理解しないまま、多数のサイトで識別子クレデンシャルを 共有することを受け入れるようなインセンティブ（Web の「ロイヤルティ カード」）を作り出す可能性があります。
このような仕組みで情報を共有したくないユーザーでさえ、 プロンプト疲れの影響を受け、これらのサービスの利用から排除される リスクを負う可能性があります。
政府発行ではないクレデンシャルについては、 ユーザーエージェントが、要求されたクレデンシャル 形式とそのプライバシー特性を理解し、ユーザーに表示する コンテキストと、各クレデンシャル型に適切な摩擦の程度を決定する リスクフレームワークを構築することが推奨されます。これらのクレデンシャルの交換に 関与するプロトコルおよび形式には、一般に選択的開示やリンク不可能性などの 機能をサポートすることが期待されますが、これらの機能は 情報交換において常に適切または必要とは限らず、特に映画のチケットのような 低リスクのクレデンシャルについてはその限りではありません。
要求されているクレデンシャルの種類を認識するユーザーエージェントには、 要求されたクレデンシャルに最適に適合し、 それを共有した場合の影響をユーザーが理解できるようにするため、 許可体験をカスタマイズすることが推奨されます。
ユーザーエージェントがすべてのクレデンシャル 要求を理解することは期待できません。要求されているクレデンシャルの種類を 認識しないユーザーエージェントには、許可体験におけるユーザーの 摩擦を大幅に増加させ、不明なクレデンシャルをウェブサイトと共有する リスクをユーザーに明確に伝えることが推奨されます。このためには、 適切な程度の摩擦と透明性を適用するために、 異なるユーザー エージェント間の統合が必要になる場合があることに注意してください。たとえば、 ブラウザはクレデンシャル要求に関する知識を オペレーティングシステムに委任し、オペレーティングシステムがクレデンシャルマネージャーに 既知のクレデンシャル型を登録させ、不明なクレデンシャル型に対する 交換要求を拒否させる場合があります。
ユーザーに適切な透明性を提供する必要性は、 明示的なユーザーエージェントの承認なしに エコシステムが新しいクレデンシャル形式を開発できるようにしたいという要望と矛盾します。
不要または不正な要求を行う検証者のための、 相互運用可能な不正利用報告システムを検討する。
API は、許可プロンプトなしにユーザーデータが共有されることが 決してないようにしますが（[[[#user-permission-and-transparency|ユーザーの 許可と透明性]]] の節を参照）、Digital Credentials API から返される可能性が高い現実世界の識別子は長期間存続し一意であるため、 トラッカーやフィンガープリンターの標的となる可能性があります。
選択的開示を使用していても、攻撃者は デジタルクレデンシャルのデータ（ユーザーの年齢、クレデンシャルの 発行者、タイムスタンプなど。[[[#leaking-incidental-data|付随 データの漏えい]]] の節を参照）を組み合わせて、ユーザーを再識別 および／またはフィンガープリントする可能性があります。
この攻撃は、第三者の攻撃者（たとえば、 検証者のページに埋め込まれているが、追跡目的で 積極的に協力していないスクリプト）にとっては困難になる可能性があります。なぜなら、 応答の暗号化が必須であり、応答は 検証者のサーバーで復号されるべきだからです。 したがって、検証者は、復号された情報を クライアント側 JavaScript に返さないようにできます。ただし、すべての 検証者がそうするとは限りません。
資格情報の真正性を確保するため、資格情報を 検証者に提示する際には、通常、 検証者がアクセスを要求している内容よりも多くの情報が含まれます。通常、少なくとも 発行者および資格情報マネージャーの署名、 さらに場合によってはその他のメタデータが含まれます。
この追加情報は、ユーザーの再識別や フィンガープリンティングに使用される可能性があり、これは、それ以外の点では リンク不能な提示が行われる場合に特に重要です。
Digital Credentials API は資格情報レスポンスの内容を制御しませんが、 ユーザーエージェントは、要求された内容を超えてどの情報が 検証者と共有される可能性が高いかを明確に強調し、 より広範には、検証者による API を通じたフィンガープリンティングを特定してブロックすることで、 この種の追跡からユーザーを保護するのに役立ちます。
Digital Credentials API は、どの提示および発行プロトコルが
ユーザーエージェントによってサポートされているかに関する情報を、
userAgentAllowsProtocol()を通じて公開します。
これは、たとえば、どの資格情報マネージャーアプリケーションがユーザーの
デバイスにインストールされているかに基づいてレスポンスをカスタマイズしないことで、ブラウザーの
フィンガープリンティングやユーザーのデバイス
構成に関する情報の漏洩を軽減します。したがって、返される情報は、せいぜい
ユーザーエージェントのバージョンと同等です。
Digital Credentials API は、最初に ユーザー許可 フローを経ることなく、クレデンシャルが利用可能かどうかを サイトが知ることを可能にしません。 クレデンシャルの存在を明らかにすることはユーザーの プライバシーに対するリスクです。クレデンシャルの存在自体が、 ユーザーがサイトと共有したくない可能性のある個人情報であり、 他のシグナルと組み合わせると、ユーザーの許可なしに ユーザーを特定するために使用される可能性があるためです。また、 ウェブサイトがサービスへのアクセス条件としてこれらの クレデンシャルの提示をますます要求し始める可能性があり、 クレデンシャルを提示したくない個人を排除するため、表現の自由に対するリスクでもあります。
Digital Credentials API は、資格情報を介して、極めて個人的で、 機密性が高く、危険にさらされ得るユーザー情報をウェブサイトと共有できるようにし、 永続的で一意かつ取り消し不能な、コンテキストをまたぐ 識別子を通じて、オンラインおよび オフラインでユーザーを追跡できる可能性があります。また、ユーザーの閲覧活動の一部だけでなく、 特定のウェブサイトや 資格情報マネージャーに対して自身を識別しようとする意図も明らかにします。資格情報リクエストにおける ユーザーエージェントの重要な責務の一つは、情報交換を 続行するための許可をユーザーから得ることです。
ユーザーが資格情報の交換を続行するかどうかについて 十分な情報に基づいて判断するために必要となる重要なコンテキスト情報には、 以下が含まれます：
ユーザーエージェントは、その実装において、 ユーザーに関連する情報の交換が行われる前に、一覧に示した詳細が ユーザーに完全に開示されるようにすることが推奨されます。
これらを仕様で規範的にすべきでしょうか？
サイトがコンテキスト内で 説明を提供できるように API を設計すべきでしょうか？
クレデンシャル提示における複数の要求と応答の処理について、 懸念事項、トレードオフ、および可能な緩和策を説明する必要があります。
ユーザーのシステムの技術アーキテクチャによっては、 「ユーザー エージェント」の定義には、 ブラウザとオペレーティングシステムなど、 ソフトウェアスタックの複数の協調する層が含まれる可能性があります。これらの層にとっての 最優先事項は、安全で十分な情報に基づくユーザー許可体験でなければなりません。 そのため、統合はユーザーの安全にとって重要になる場合があります。一部の層は、 ユーザーのクレデンシャルの利用可否など、他の層からアクセスできない 情報を保持している場合があります。過剰なプロンプトや 十分なコンテキストなしのプロンプトは、（悪用可能な）混乱や プロンプトへの無関心を招く可能性があります。
このため、許可を求めるユーザーエージェントには、 安全であると判断する場合、理想的なユーザー体験のために ソフトウェア層を統合することが推奨されます。たとえば、 ブラウザがオペレーティングシステムの API 契約を信頼して 適切なプロンプトを表示すると判断し、そのためブラウザ自身はプロンプトを表示しない、 という形で行われる可能性があります。
ユーザー許可フローの一部として、ユーザー エージェントは、 クレデンシャル要求をクレデンシャルマネージャーへ転送するかどうか、 またどのクレデンシャル マネージャーを選択するかを、ユーザーが選択する権限を保持していることを 保証する必要があります。これは、要求の一部として情報が開示され、 クレデンシャル マネージャーが要求時点でその情報を保持または共有できるためです。
ユーザー エージェントによって仲介される許可は、同意ではありません。同意には、 法的および規制上の環境によって異なり得る特定の法的定義があり、 情報を 資格情報マネージャーが 検証者と共有する前に収集する必要がある場合や、検証者自身がリクエストを開始する前に 収集する必要がある場合があります。同意を取得するための枠組みや規制はまだ 策定中ですが、この API は、以下を含み得る 必要な情報の交換を可能にすることを目的としています：
この情報のより多くが構造化形式で利用可能になるにつれて、 ユーザーエージェントおよびこの仕様も、それを活用して ユーザー許可の体験を改善することが期待されます。
デジタル クレデンシャルを選択して認可するためのユーザーインターフェイスは プラットフォームによって提供され、その大部分はこの仕様の 適用範囲外です。ただし、その体験のアクセシビリティは適用範囲内です （3. 適用範囲を参照）。以下のガイダンスは、 ユーザーエージェントおよびデジタルクレデンシャル選択 UIとその周辺フローを実装する プラットフォームに適用され、[WCAG22] の関連する 達成基準を参照します。選択 UI が Web ではない ユーザーインターフェイスである場合、それらの基準は [WCAG2ICT-22] に記載されているように適用されます。
発行または提示の際に表示されるモーダルダイアログの内容には、 テキスト、QR コード、およびその他の視覚的メディアが含まれる場合がありますが、適切な名前、ロール、および値を用いて ラベル付けし、支援技術に公開すべきです （§ 達成基準 4.1.2 名前・役割・値を参照）。また、非テキストコンテンツにはテキストによる 代替を提供すべきです（§ 達成基準 1.1.1 非テキストコンテンツを参照）。
別のデバイスを待機している状態、成功した応答、エラー、またはキャンセルなど、 インタラクション状態の変化は、プログラムによって判別可能であり、 フォーカスの変更を必要とせずに支援技術へ伝達すべきです （§ 達成基準 4.1.3 ステータスメッセージを参照）。
操作が失敗した場合、ユーザーエージェントは複数の
異なるエラーのいずれかで拒否します。たとえば、"NotAllowedError"、
"InvalidStateError"、または "OperationError" DOMException、または
TypeErrorです。プラットフォームがこのような
失敗をユーザーに提示する場合、単にエラーが発生したことを示すだけではなく、
何が問題だったのか、該当する場合にはどう回復できるのかを
テキストで特定すべきです（
§ 達成基準 3.3.1
エラーの特定を参照）。
インタラクティブな要素、特にユーザーが 発行 または提示要求を続行または中止できる要素は、 デバイスに依存しない方法（たとえば キーボードを介して。§ 達成基準 2.1.1 キーボードを参照）で操作可能でなければなりません。特に、アクティベーションは マルチポイントまたは経路ベースのジェスチャー（ § 達成基準 2.5.1 ポインタジェスチャを参照）やデバイスの動き（ § 達成基準 2.5.4 動きによる起動を参照）を唯一の操作手段として 要求してはなりません。デジタルクレデンシャル選択 UIは、 そのコントロールを意味のあるフォーカス順序で提示すべきです（§ 達成基準 2.4.3 フォーカス順序を参照）。 また、選択 UI を開いたときはフォーカスをその内部に移動し、表示されている間は その内部にフォーカスを保持し、閉じたときには以前フォーカスされていた要素、 または別の適切な位置へフォーカスを戻すべきです。
デジタルクレデンシャルを提供するために保有者の 認証が必要な場合、アクセシブルな認証方法が利用可能であるべきです。 パスワードを思い出すなど、認知機能テストに依存する手順では、 そのようなテストを必要としない代替手段を提供すべきです （§ 達成 基準 3.3.8 アクセシブルな認証（最低限）を参照）。また、 認証は、一部のユーザーが提供できない生体情報など、単一の身体的 特性だけに依存すべきではありません。 この手順は通常、プラットフォームまたはクレデンシャルマネージャーによって実行され、それ以外の点ではこの仕様の 適用範囲外です。
一部のプラットフォームは提示要求を デバイス間で満たします。たとえば、ユーザーが別のデバイスで スキャンするための QR コードを表示します。このようなフローは視覚、 カメラ、または 2 台目のデバイスの使用に依存する場合があるため、プラットフォームは、 単一の感覚能力または入力モダリティに依存せずにインタラクションを完了できる、 同等でアクセシブルな手段を提供すべきです。 QR コードなどの視覚的なアーティファクトだけで伝達され、 アクセシブルな代替手段がないデバイス間要求は、そのモダリティを使用できない ユーザーを排除します。
インタラクションには、複数の要因による時間制限が適用される場合があります。 これらは、より多くの時間を必要とするユーザーが排除されないように 処理すべきです（§ 達成基準 2.2.1 タイミング調整可能を参照）:
AbortSignalを
signalとして渡すことで、
インタラクションに上限を設定できます。たとえば
AbortSignal.timeout() で作成されたものです。サイトは十分な時間を
許容すべきであり、ユーザーを急がせるような短い制限を
設けるべきではありません。
デジタルクレデンシャルを確認して開示するという判断は、 周囲のサイトフローから引き継がれた時間的圧力を含め、 強制的なカウントダウンの対象とすべきではありません。
インタラクション中に表示される人間が読めるクレデンシャル内容と、 画像のテキストによる代替など、そのアクセシブルな代替手段は、 クレデンシャルのペイロード内に含まれており、関連するクレデンシャル形式および プロトコルの責任です。それらの形式およびプロトコルは、その コンテンツの言語と方向も決定します。
この節は規範的ではありません。
この API はクレデンシャル形式および交換プロトコルに依存せず、
要求ペイロード（DigitalCredentialGetRequestの
dataおよび
DigitalCredentialCreateRequestの
data）および応答ペイロード
（DigitalCredentialのdata）を不透明なものとして扱います。その
結果、この API は、人間が読める自然言語コンテンツを
保持する文字列型の値を定義しません:
JSON.stringify 操作を呼び出します。また、応答はJSON 文字列を
JavaScript 値に解析するを使用して解析されます。JSON.stringify は
単独の（対をなさない）サロゲートコードポイントを \uXXXX エスケープシーケンスとして出力するため、
シリアライズされた要求は常に整形式であり、UTF-8 でエンコード可能な JSON です。
したがって、この仕様は、言語または方向のメタデータを 必要とする自然言語テキストを導入しません。将来の改訂で、 API 層にサイト作成の人間が読めるテキスト、 規範的に定義された許可プロンプトのテキスト、またはユーザーエージェントが描画する 表示要素が導入される場合、そのテキストには適切な言語および方向のメタデータを 持たせるか、それらと関連付ける必要があります。
ユーザーエージェントの自動化およびアプリケーションテストの目的で、この 文書はWebDriver BiDi 仕様の拡張モジュールを定義します。ユーザーエージェントが それらをサポートすることは任意です。
digitalCredentials モジュールには、
[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)
および[[Create]](origin, options, sameOriginWithAncestors)
呼び出し中のクレデンシャルマネージャーのリモートエンドの動作を管理および
シミュレートするためのコマンドが含まれます。
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
digitalCredentials.setVirtualWalletBehavior コマンドのリモートエンド手順は、session
およびcommand parametersが与えられたとき、次のとおりです:
action"]とします。
context"]が存在する場合はそれを
contextとし、
それ以外の場合は null とします。
protocol"]が
存在する場合はそれをprotocolとし、
それ以外の場合は null とします。
response"]が
存在する場合はそれをresponseとし、
それ以外の場合は null とします。
"respond" の場合:
"clear" の場合:
null でない場合、
contextのエントリを
WebDriver セッションのアクティブな
仮想ウォレットの動作から削除します。
null に設定します。
null でない場合、WebDriver セッションの
ブラウジングコンテキスト ID contextに対する
アクティブな仮想ウォレットの動作を
behaviorに設定します。
null を伴う成功を返します。
自動テストを記述する開発者は、
AbortSignalを
signal
（get()の場合）
またはsignal
（create()の場合）として渡し、
その後、目的の中止理由で中止することで、
ウォレットエラーをシミュレートできます。これは要求アルゴリズムが使用するものと同じ
中止経路を実行します。
(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");
}
})();
Promise
promiseおよびグローバルオブジェクトglobalが与えられたときに、
仮想ウォレットの動作を処理するには、次の手順を実行します:
false を返します。
null の場合、behaviorを現在の WebDriver
セッションのデフォルトのアクティブな仮想ウォレットの動作に設定します。
null の場合、false を返します。
"wait" の場合、true を返します。
"decline" の場合:
NotAllowedError"
DOMExceptionで拒否します。
true を返します。
"respond" の場合:
DigitalCredentialインスタンスとします。
protocol属性を
protocolに設定します。
data
属性をJS
objectに設定します。
true を返します。
action
§14.1.1
"clear"
§14.1.1
context
§14.1.1
[[Create]](origin, options, sameOriginWithAncestors)
DigitalCredential の内部スロット
§8.3
DigitalCredentialGetRequest のメンバー
§7.3.2
DigitalCredentialCreateRequest のメンバー
§7.6.2
DigitalCredential の属性
§7.7.2
"decline"
§14.1.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
§14.1.2.1
"digitalCredentials.setVirtualWalletBehavior"
§14.1.2.1
digitalCredentials.SetVirtualWalletBehaviorParameters
§14.1.1
digitalCredentials.SetVirtualWalletBehaviorResult
§14.1.2.1
digitalCredentials.VirtualWalletAction
§14.1.1
[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)
DigitalCredential の内部スロット
§8.1
[[discovery]]
DigitalCredential の内部スロット
§8.5
method
§14.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
§14.1.2.1
DigitalCredentialGetRequest のメンバー
§7.3.1
DigitalCredentialCreateRequest のメンバー
§7.6.1
DigitalCredential の属性
§7.7.1
DigitalCredentialRequestOptions のメンバー
§7.2.1
DigitalCredentialCreationOptions のメンバー
§7.5.1
"respond"
§14.1.1
response
§14.1.1
[[Store]](credential, sameOriginWithAncestors)
DigitalCredential の内部スロット
§8.2
text
§14.1.1
[[type]] DigitalCredential
の内部スロット
§8.4
userAgentAllowsProtocol()
DigitalCredential のメソッド
§7.7.3
"wait"
§14.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
型
Window
インターフェイス
list 用）
iteration 用）
list 用）
list 用）
struct 用）
AbortError 例外
boolean
型
exception 用）
[Default] 拡張属性
DOMException インターフェイス
DOMString インターフェイス
[Exposed] 拡張属性
InvalidStateError 例外
NotAllowedError 例外
object
型
OperationError 例外
Promise インターフェイス
ReferenceError 例外
[SameObject] 拡張属性
[SecureContext] 拡張属性
SecurityError 例外
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、RECOMMENDED、SHOULD、および SHOULD NOT は、 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)。
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:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: