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により、 勧告 トラックを使用して 作業草案として公開されました。
作業草案としての公開は、 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() メソッドであり、
これは、ユーザーエージェントから デジタルクレデンシャル を要求するために
使用されます。ユーザーエージェントが プレゼンテーション をサポートしている場合、ユーザーは
デジタルクレデンシャル選択器 を通じて
デジタルクレデンシャルを選択できます。
<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("認証情報の検証に失敗しました");
}
// 検証結果をレンダリングします
displayVerificationResult(await response.json());
} catch (error) {
console.error("デジタル認証情報の要求中にエラーが発生しました:", 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);
}
});
</script>この仕様は、 "digital-credentials-get" ポリシー制御機能を介して、 リモート/第三者オリジンから認証情報を提示するために API を使用することを許可しています。これは、 ウェブサイトが別のオリジンでホストされている検証サービスから デジタル認証情報を要求したいシナリオで有用です。Permissions Policy は、 API を使用したいウェブサイトを埋め込む iframe に設定できます。次は、 Permissions Policy を iframe に設定する方法の例です。
<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>この節は非規範的です。
次の項目は、この仕様のスコープ内です。
次の項目はスコープ外です。
この節における定義の目的は、さまざまなデジタル認証情報形式およびプロトコルで 共通する用語を再利用または確立することです。これらの定義は活発に進化しています。
この仕様は現在、人に関するデジタル認証情報に焦点を当てています。
次の提示プロトコルの使用は、 この仕様によって定義されます。
#401で、私は次を追加することを提案しました。
<p>
[=user agent=] は、[=table of exchange protocols=] に列挙された [=digital credential/exchange protocol=] のうち少なくとも 1 つを実装しなければなりません。
[=user agent=] は、[=table of exchange protocols=] に列挙されたすべての [=digital credential/exchange protocols=] を実装することが推奨されます。
</p>
<aside class="note" title="ユーザーエージェントがどの交換プロトコルを許可するかの確認">
<p>開発者は、`DigitalCredential.`{{DigitalCredential.userAgentAllowsProtocol()}} 静的メソッドを呼び出すことで、
[=user agent=] がどの [=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-compliant driving licence, Part 7: Mobile driving licence (mDL) add-on functions § Annex C |
| 発行プロトコル | |
openid4vci-v1
|
OpenID
for Verifiable Credential Issuance 1.0 § 近日公開
Issue:
API 統合
|
DigitalCredentialGetRequest または DigitalCredentialCreateRequest
request が与えられたとき、リクエストプロトコルを変換するには:
DigitalCredentialGetRequest:
protocol
とする。
DigitalCredentialPresentationProtocol
内のどの列挙値とも等しくない場合、
失敗を返す。
DigitalCredentialPresentationProtocol
の列挙値を返す。
DigitalCredentialCreateRequest:
protocol
とする。
DigitalCredentialIssuanceProtocol
内のどの列挙値とも等しくない場合、
失敗を返す。
DigitalCredentialIssuanceProtocol
の列挙値を返す。
認証情報要求コーディネーターは、 トップレベル traversableを通じて、デジタル 認証情報のインタラクションを仲介する、ユーザーエージェント定義のコンポーネントです。各トップレベル traversableには、関連付けられた コーディネーターがちょうど 1 つあります。コーディネーターは、 すべての子 navigable全体でアクティブなインタラクションが高々 1 つであることを保証し、 提示または発行のエンドツーエンドのフローを調整し、インタラクション状態間の遷移を管理します。
認証情報要求コーディネーターは、ユーザー
エージェントが null として初期化する アクティブ
Promiseを保持します。このPromiseを通じて、
コーディネーターは、非同期の
認証情報要求ワークフローの状態をスクリプトに反映し、
インタラクションが正常に完了した場合は解決して認証情報
応答を返し、処理が失敗した場合、
ユーザーが UI 経由で要求を取り消した場合、またはスクリプトが
AbortSignalを介して操作を中止した場合は
拒否します。
認証情報要求コーディネーターは、ユーザーエージェントが
null として初期化する 中止シグナルを保持します。
認証情報要求コーディネーターは、ユーザー
エージェントが null として初期化する 中止アルゴリズムを保持します。
認証情報要求コーディネーターは次を行います。
ユーザーエージェントは、ユーザーまたはプラットフォームポリシーに従い、 コーディネーターの責務の一部またはすべてを、外部の認証情報マネージャー、プラットフォームコンポーネント、またはその他の 信頼されたエンティティに委任してもよい。
認証情報要求コーディネーターは、 認証情報 要求のライフサイクルを管理するために使用される、有限個の インタラクション 状態を持ちます。
コーディネーターは、idle インタラクション 状態で初期化されます。
Document document、
DigitalCredentialGetRequest値の
シーケンスまたは
DigitalCredentialCreateRequest
値のシーケンス requests、Promise
promise、および任意のAbortSignal signalが与えられたときに、認証情報要求を
準備するには、次を行います。
NotAllowedError"
DOMExceptionで
拒否します。
null です。
TypeErrorおよび
promiseで
認証情報要求を拒否します。
事前に中止済みのシグナルは、
このアルゴリズムが呼び出される前に、Credential を
要求するおよびCredential を
作成するによって処理されます。
true の場合、戻ります。
AbortError"
DOMExceptionで
認証情報要求を中止します。
DigitalCredentialGetRequest または
DigitalCredentialCreateRequest
オブジェクトのシーケンス requests が与えられたとき、クレデンシャル
リクエストを検証するには:
false を返す場合、継続する。
DigitalCredentialGetRequest
である場合は、data を request の data とし、
または request が
DigitalCredentialCreateRequest
である場合は、request の
data とする。
prepare 手順は当初、次のように述べていた:
プロトコルで定義された要件に加えて、[=user agent=] は、ローカルポリシー、 構成、または進化するセキュリティ上の考慮事項に基づいて追加の検証基準を適用する場合がある。たとえば、[=user agent=] は、 (a) 特定のクレデンシャル属性を求めるリクエスト、(b) [=user agent=] が受け入れないよう構成されている暗号アルゴリズムを使用または要求するリクエスト（たとえば、 アルゴリズムアジリティやポスト量子方式への移行の一環として）、または (c) [=user agent=] の構成された信頼判断で受け入れられていない証明書やトラストアンカーに依存するリクエストを拒否する場合がある。
これらについてさらに詳述できるとよい。
JavaScript 値またはDOMException
errorが与えられたときに、認証情報要求を
中止するには、次を行います。
nullである場合は、戻ります。
閉じる処理は失敗する場合があります（例：デジタル認証情報選択UIが メモリ圧迫により破棄された場合）が、コーディネーターは それでも認証情報要求の完了へ進みます。
（JavaScript 値）errorおよび
Promise promiseで、認証情報要求を
拒否するには、次を行います。
null でなく、abortAlgorithmが
nullでない場合：
nullに設定します。
nullに設定します。
nullに設定します。
Document
document、検証済み認証情報要求のリスト
validatedRequests、Promise
promise、および任意のAbortSignal
signalが与えられたときに、
認証情報要求を
開始するには、次を行います。
@mohamedamir と議論していましたが、クロスプラットフォームかつクロスデバイスの認証情報交換は CTAP 経由で行うべき（または推奨される）であることを仕様で述べるべきです。
これを必須（すなわち MUST）にすることはできません。理由は次のとおりです。
認証情報要求を準備する手順によって signalに追加された中止アルゴリズムが、デジタル認証情報 選択UIの破棄を処理します。
NotAllowedError"
DOMExceptionとします。
NotAllowedError"
DOMException。
TypeError。
InvalidStateError"
DOMException。
OperationError"
DOMException。
デジタル認証情報 選択UIまたは基盤となるプラットフォームは、 validatedRequests内のどの項目を保持者に転送するかを決定し、その交換の プロトコル 識別子を返します。ユーザーエージェントは、 どの具体的な項目が選択されたかを必ずしも知りません。
null でなく、かつ
abortAlgorithmが
nullでない場合は、
abortAlgorithmを
abortSignalから削除します。
nullに設定します。
nullに設定します。
dataを
parsedResponseDataOrErrorに初期化し、
protocolを
protocolに初期化した、新しく作成された
DigitalCredential
インスタンスとします。
nullに設定します。
Digital Credentials API は、 Credential Management Level 1 仕様を活用し、ユーザーエージェントが 発行およびプレゼンテーションをデジタル クレデンシャルについて仲介できるようにします。
この API は、ユーザーエージェントに
要求して、
デジタルクレデンシャルを取得できるようにします。ユーザーエージェントは次に、
ユーザーに
デジタルクレデンシャル選択器を提示し、ユーザーが
要求を満たすことができる
デジタルクレデンシャルを選択できるようにします。これは、
Web サイトが
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 Integration を参照してください。
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 は、次の 項目を持つ構造体です。
この列挙の値は、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)
内部メソッドの既定実装を呼び出します。
そうでない場合は、次を行います。
signalとします。
Documentとします。
NotAllowedError" DOMExceptionで
拒否された promiseを返します。
digitalの
requests メンバーとします。
NotAllowedError" DOMExceptionで
拒否された promiseを返します。
呼び出されたとき、[[Store]](credential, sameOriginWithAncestors) は、
同じ引数で Credential の
[[Store]](credential, sameOriginWithAncestors)
内部
メソッドの既定実装を呼び出さなければなりません。
呼び出されたとき、[[Create]](origin, options,
sameOriginWithAncestors) 内部メソッドは、ユーザーエージェントが
発行要求をサポートしていない場合、同じ
引数で Credential の[[Create]](origin, options, sameOriginWithAncestors)
内部メソッドの既定実装を呼び出します。
そうでない場合は、次を行います。
signalとします。
Documentとします。
NotAllowedError" DOMExceptionで
拒否された promiseを返します。
digitalの
requests メンバーとします。
NotAllowedError" DOMExceptionで
拒否された promiseを返します。
DigitalCredential インターフェイスオブジェクトは、
[[type]]
という名前の内部スロットを持ち、その値は "digital" です。
DigitalCredential インターフェイスオブジェクトは、
[[discovery]]
という名前の内部スロットを持ち、その値は "remote" です。
この節は非規範的です。
Digital Credentials
API は、エンドユーザーからの明示的な許可を
必要とする強力な機能です。この
要件は、CredentialsContainer の
get() メソッドを
呼び出す際に、規範的に強制されます。
この仕様は、2 つのポリシー制御機能を定義します。
Credential を要求する
アルゴリズムがポリシー強制点として機能します。
Credential を作成するアルゴリズムが
ポリシー強制点として
機能します。
この節は非規範的です。
以降の節では、この API のセキュリティ特性、スコープ内の 脅威、セキュリティが依存する前提、および緩和策を適用した後にも 残る残余脅威について説明します。この仕様は、 認証情報応答を仲介するときの ユーザーエージェントの挙動についてのみ要件を定義します。
プロトコル、認証情報マネージャー実装、オペレーティングシステム、または トランスポートセキュリティに依存するその他のセキュリティ上の考慮事項は、 期待事項または前提条件として説明されますが、すでに規範的に 指定されていない限り、この仕様によって規範的に要求されるものではありません。
この仕様の脅威モデルには、この API およびエコシステム内の 隣接する標準に対する脅威が含まれます。
この仕様では、脅威は 2 つのカテゴリに分類されます。スコープ内の 脅威およびスコープ外の脅威です。
スコープ内の脅威は、DC API 自体によって導入または対処される脅威です。次のものが、この 仕様におけるスコープ内の脅威です。
DigitalCredentialGetRequest
または DigitalCredentialCreateRequest
を改変しようとします。
iframe
などの
埋め込まれた第三者コンテンツを通じて、埋め込み側サイトからの明示的な許可なしに
デジタル認証情報を要求または発行しようとし、
認証情報の収集または機微なユーザーデータへの未承認アクセスを可能にする可能性があります。
スコープ外の脅威は、プロトコル、 認証情報マネージャー、OS プラットフォームセキュリティ、または トランスポート層によって扱われる脅威です。 「スコープ外」であっても、それらは認証情報の提示および発行の エンドツーエンドのセキュリティに影響するため関連があります。次は、この 仕様におけるスコープ外の脅威を定義します。
次の緩和策は、仕様内の規範的要件を通じて スコープ内の脅威に対処します。
デジタルクレデンシャル API の WebIDL インターフェイスは、 セキュアコンテキストでのみ公開され、 非セキュアコンテキストを通じた 改ざんのリスクを低減する （例: 悪意のあるスクリプトがネットワーク経由で注入される場合）。詳細については、 Secure Contexts 仕様の 5 セキュリティ上の考慮事項の節を参照されたい。
デジタルクレデンシャル API は、次の 2 つの 仕組みによりAPI フラッディングを低減する:
[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)
メソッドと [[Create]](origin, options, sameOriginWithAncestors)
メソッドはいずれもユーザーアクティベーションを消費し、ユーザー操作なしの
自動または反復的なリクエストを防止する。
required」
にする（DigitalCredential
インターフェイスを参照）。これにより、すべてのクレデンシャル
操作について、プラットフォームのクレデンシャル選択インターフェイスを通じてユーザー許可が取得されることを保証する。
クレデンシャルリクエストの濫用防止に関する追加の指針については、 Credential Management Level 1 仕様の 7 プライバシー上の考慮事項の節を参照されたい。ただし、これらの 保護には限界があることに注意されたい。サイトは依然としてダークパターンを用いて、 クレデンシャルリクエストを発生させる不要なユーザー操作を促す可能性があるためである。
デジタルクレデンシャル API は、
Permissions Policy との統合により
クロスオリジン濫用を低減する
（Permissions Policy
統合を参照）。Credential をリクエストするアルゴリズムとCredential を作成するアルゴリズムは、
それぞれ "digital-credentials-get" および
"digital-credentials-create" ポリシー制御機能のポリシー適用
ポイントとして機能する。この 2 つの機能は意図的に分離されている。サイトは
"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 スキームがあります。 Web 上での 認証情報の提示および身元提示のための カスタムスキームに関する懸念に記載されているように、 これらの解決策には、セキュリティ、プライバシー、およびアクセシビリティ上の懸念があります。
デジタルクレデンシャル技術の採用がエコシステムの需要と規制上の義務によって 進められている中で、Web プラットフォームは、前述のあまり望ましくない技術に代わるものを提供する。 それは開発者にとって使いやすく、既存のクレデンシャル 提示プロトコルと互換性があり、最も重要なことに、 前述の代替手段よりも、ユーザーにとってより優れたプライバシー、セキュリティ、およびアクセシビリティの特性を 備えている。
Digital Credentials API は、ユーザー エージェントに対し、ユーザーの代理として仲介する能力（例：デジタル認証情報選択UIの形で）を提供し、 要求を文脈化し、 保持者アプリケーションへの 即時露出を防ぐことを可能にします。また、サポートされるプロトコルに対し、 応答 暗号化など、一定の最小要件を強制します。
デジタルクレデンシャル API は、データ開示の度合いが異なる さまざまなユースケースと、置かれているコンテキストに応じて 異なる選好を持つ個々のユーザーに対応する。特に、 この API によって媒介されるクレデンシャル交換のプライバシー特性は、 個々のユーザーの法的および規制上の環境によって義務付けられる可能性がある。
これは、一部のユーザーが、クレデンシャル情報を交換するための 最もプライバシー保護的な手段を使用したくない、または使用を許可されない 場合があることを意味する。それにもかかわらず、ユーザーエージェントは、デフォルトでプライベートな体験を ユーザーに提供し、ユーザーを害から保護する必要がある。
このような選好とユースケースの幅があるため、ユーザーエージェントが、ユーザーが自分の個人情報を 公開する意図を持っているのか、それともそうするよう欺かれているのかを判別することは 困難な場合がある。したがって、交換が始まる前に、すべての ユーザーが、自分がどのデータを共有しているのか、また誰が情報交換に参加するのかを 理解していることを保証するのは、ユーザーエージェントの責任である。
Digital Credentials API は、複数の独立した関係者が関与する交換の中心に位置するため、 これらの関係者がユーザー情報を交換するために使用する提示プロトコルおよび認証情報形式は、 ユーザープライバシーを保護するというユーザーエージェントの目標にとって重要です。
さらに詳述が必要だと思う、プロトコルに関する 2 つの要件があります。
MUST have undergone privacy review [...]
および
MUST have undergone security review [...]
技術的には、「このプロトコルはあらゆる面でひどい」と述べるレビューでも、これらの 基準を満たしてしまいます。
プロトコルが満たす必要のある具体的なプライバシーおよびセキュリティ要件の集合があり、 レビューが標準に達したかどうかを判断できるなら、より有用でしょう。レビューには主観的な要素が あるかもしれませんが、各プロトコルが越える必要のある最低基準もあるべきです。
これは現在の包含基準における現在の要件群を超えるものです。手元に包括的なリストは ありませんが、作成することは可能なはずです。そして作成されたなら、そのリストは仕様に含めるべきです。 たとえば、そのプロトコルはphone homeに依存するのでしょうか。そのプロトコル（またはそれが伝達する形式）は、 提示のリンク不能性を保証するのでしょうか。あるいは、リンク不能性が一部のユースケースでは意味をなさないとして、 どの条件下で API はプロトコルにリンク不能性を提供することを要求するのでしょうか。プロトコルには どのような透明性のための支援が含まれているのでしょうか。どのような covert channel が許容されるのでしょうか。
選択的 開示は、データ最小化のための 基本的な技法であり、 保持者が、検証者によって要求された最小限の必要情報を共有できるようにします。 プロトコルは、検証者が必要な 正確な主張を指定できるようにすることで、選択的開示を促進することが期待されます。
リンク不能性は、 ユーザーが認証情報から属性を複数回提示した場合に、検証者がこれらの別々の 提示を結び付けて同じユーザーに関するものだと結論できないこと （検証者間リンク可能性）、または検証者が発行者と結託して、認証情報マネージャーから発行者へ認証情報の交換を報告できないこと （検証者-発行者リンク可能性）を保証する特性です。前者は、 保持者および発行者によって維持できる特性であり、たとえば個々の 検証者向けに新しい認証情報を発行することによって実現できます。
後者は、たとえば ゼロ知識 証明を通じて実現可能である一方で、 暗号化されたレスポンスなどの API の設計上の選択により、 ユーザーエージェントが、検証者と発行者の間の リンク不能性が実際に達成されたことを証明することは不可能になる。それにもかかわらず、プロトコルには、 可能な限りリンク可能性を制限することが求められる。
リンク不能性は、特定のユーザー識別子に結び付けることができない属性にのみ 関係する考慮事項であることに注意されたい。名前、運転免許証番号、電話 番号などの本質的にリンク可能な属性は、リンク不能性の恩恵を受けない。
デジタルクレデンシャル API を通じて、ユーザー エージェントは、 検証者とクレデンシャルマネージャーがリンク不能な 属性を交換することを支援できるが、レスポンスの暗号化により、 検証者と クレデンシャルマネージャーの間でリンク可能な情報が渡されないことを保証することはできない。 ユーザーエージェントは、 ユーザー許可の体験においてこの事実を考慮することが推奨される。
この API の目標はどの水準のリンク不能性でしょうか。特定のリンク不能性機能のサポートを 規範的に強制できるでしょうか。
「ホームへ 通信する」とは、 デジタルクレデンシャルの提示または検証が、 発行者または別の中央エンティティへの通知または通信を引き起こす シナリオを指し、これにより個人の追跡や プロファイリングにつながる可能性がある。
リンク不能性と同様に、ユーザーがクレデンシャルリクエストを続行する許可を 与えた後に、ユーザー エージェントが、 発行者がクレデンシャル提示の作成または 検証に能動的に関与していないことを保証することは不可能である。その時点以降、 この判断はクレデンシャルマネージャーに属する。 一部のクレデンシャル マネージャーはユーザー エージェントと見なすことができるが、一般には、 ユーザーエージェントが実装する Digital Credentials APIは、ユーザー確認の前に リクエストが クレデンシャルマネージャーに露出することを防ぐように、その許可体験を設計することが 推奨される （複数の協調するユーザーエージェントを 統合するための考慮事項を念頭に置く）。
プロトコルは、発行者、 クレデンシャルマネージャー、および検証者が「phone home」メカニズムへの 依存を回避または低減できるようにする仕組みをサポートすることが求められる。
この API の目標はどの水準のリンク不能性でしょうか。仕様は、発行者の関与に対する制限をどの程度 義務付けることができるでしょうか。
クレデンシャル交換における発行者の関与の一般的な事例は、 クレデンシャルの失効確認です。これは、プレゼンテーションが検証者と発行者の間で リンク不能であることを意図している場合に、特に困難です。 クレデンシャルのプレゼンテーションが、たとえば ゼロ知識 証明の使用を通じてリンク不能にされる場合、 プロトコルで使用されるクレデンシャル形式は、暗号 アキュムレータなどのオフライン失効方式をサポートすることが期待されます。さらに、 プロトコルの設計および仕様では、可能な場合には失効を 目的とした検証者の関与を 抑制することが期待されます。
リンク不能な失効技術が、規範的に要求できるほど実用的かどうかを議論すべきです。
ユーザーの理解と参加は、認証情報提示の交渉不可能な特性です。 プロトコルは、十分な情報に基づく許可および/または同意に不可欠な 情報を提供することで、関与するすべての関係者がユーザー参加を可能にするのを 助けることが期待されます。
たとえば検証者ページに読み込まれたブラウザー拡張など、 「転送中」に他の関係者へユーザー情報が露出することを防ぎ、 検証者によるユーザー認証情報の安全な保存を促すために、 プロトコルは認証情報交換において暗号化された 応答をサポートし義務付けることが要求されます。
#49およびこれまで行ってきた いくつかの議論に関連します。応答は常に暗号化されなければならない（もしそうなら、どのアルゴリズムで）と 述べたいのでしょうか、それとも任意のままにしておいてよいのでしょうか。
不要な認証情報要求は、デジタル認証情報エコシステム全体にとって 重要なプライバシーリスクです。それらはさまざまな形で、 さまざまな動機から現れる可能性があります。
ここでの課題の 1 つは、何が「正当な」目的を構成し、 したがってどの要求が「不要」なのかを判断することであり、 認証情報交換に関与するすべての関係者の参加を必要とします。
不要な使用をどのように判断し対処するかをより詳細に検討するには、 政府発行のクレデンシャルとその他のクレデンシャルを別々に考慮することが理にかなっている。 これらは、データの機微性、誤用による潜在的な害、および法的・規制上の考慮事項において 異なる可能性があるためである。
両方の種類のクレデンシャルに適用される、リスク軽減とユーザー制御を確保するための 重要な構成要素は、ユーザー エージェントが クレデンシャルリクエストのメタデータを検査し、それに基づいて判断または UI 表示を行う能力である。この仕様は、リクエストを暗号化せずに送信し、関連情報を含めるという プロトコル要件を通じて、このユーザー エージェントアクセスを保証する（5. プロトコル および6.2 クレデンシャルリクエストの準備を参照）。
政府発行の デジタル認証情報には、渡航文書、個人ライセンス、 福祉および公衆衛生プログラムの証明、車両登録、 ならびに政府当局によって発行されるその他の文書、またはこの情報を表すその他の 文書が含まれます。これらの文書はきわめて機微であり、 個人の固有の身元および重要な公共サービスとやり取りする能力の中心となる、 永続的で取り消し不能な一意識別子を含む可能性があります。
これらの認証情報はユーザーおよび攻撃者にとって価値が高いため、 盗難の重大なリスクがあり、未承認の第三者への漏えいによる 潜在的な害も重大です。これには、追跡および パーソナライゼーションを目的とした政府身元情報の要求が含まれます。
政府認証情報がオンラインでより利用可能になることに関する大きな懸念は、 ジェボンズのパラドックス、 すなわちアクセスの摩擦が低下することで認証情報への需要が増加する可能性です。 この効果は Digital Credentials API 自体によって本質的に引き起こされるものではなく、 エコシステム全体でデジタル認証情報の採用が進むことによるものです。ただし、 ユーザー エージェントによる Digital Credentials API の実装によって追加の勢いを得る可能性があります。 そのため、この効果は API を実装するユーザーエージェントによって考慮される必要があり、 ユーザーに有害な結果をもたらす可能性があります。
政府発行デジタル認証情報について概説したリスクは、 エコシステム内の単一の参加者では解決できない課題であり、 実世界の認証情報を通じてオンラインサービスへアクセスすることの リスクと利点について、各主権国家内でより広範な政策議論を 必要とします。
デジタル認証情報を発行する政府が、それらの認証情報をどのように、 どの目的で使用できるかを明確に定義する法律および規制も制定することが 望ましいです。交換に関与するすべての関係者は、法的義務があるかどうかに かかわらず、存在する場合には政府の検証者認証 方式をサポートすることが助言されます。検証者認証方式（たとえば EUDI アクセスおよび登録証明書）のサポート（および統合）は、 不要な認証情報要求が増殖するリスクを緩和できます。しかし、そのような方式の存在は 保証されておらず、これにより認証情報交換におけるリスクは大幅に増加します。
Digital Credentials API を実装するユーザー エージェントがリスクを低減し、ユーザー理解を高め、特定の種類の害を 防ぐために取ることのできる、その他の実践的な手段があります。
さらに、ユーザー エージェントが、これらの緩和策が存在しないことを考慮した許可 体験を設計することが極めて重要である。たとえば、 検証者認証スキームなしに、政府発行クレデンシャルから 個人情報を交換する場合などである。このような種類の交換には、 より高い摩擦と、関係するリスクを強調する明確なユーザーメッセージを 適用することが推奨される。
非政府発行の認証情報には、政府発行ではなく、政府発行文書を表すものでもない、 その他すべてのデジタル文書、証明書、および証明が含まれます。 これには、雇用証明、（非政府の）教育認証情報、または映画チケットが 含まれる可能性があります。特に、それらの交換は法律および規制による制約が 比較的少ない可能性があります。これらの文書は政府発行の認証情報と同じリスクを 示さないことが多い一方で、識別可能または機微な情報を含む場合もあります。
非政府認証情報の盗難および漏えいの影響と実行可能性は、 主に各個別の認証情報タイプの内容に基づきます。一般に、 これは機微な私的情報の制御喪失および露出、ならびに なりすましやデータ窃取につながる可能性があり、影響を受けた個人への さらなる攻撃の可能性を高めます。
非政府認証情報の柔軟性と規制の少なさは、メールアドレスや電話番号などの 長期識別子を通じて、クロスサイト追跡および身元のリンクを目的とした 濫用の可能性を伴います。デジタル認証情報に基づく追跡方式に参加する 検証者は、ユーザーが自身のプライバシーへの 影響を十分に理解しないまま、多くのサイトで識別子認証情報を共有することを受け入れる インセンティブ（Web 向けの「ロイヤルティカード」）を作り出す可能性があります。
そのような仕組みで自分の情報を共有したくないユーザーであっても、 プロンプト疲れの影響を受け、これらのサービスを利用できなくなるリスクを 負う可能性があります。
非政府発行の認証情報については、ユーザーエージェントが、要求された認証情報 形式とそのプライバシー属性を理解し、ユーザーに示される文脈と各認証情報タイプに 適切な摩擦の量を知らせるリスクフレームワークを構築することが推奨されます。 これらの認証情報の交換に関与するプロトコルおよび形式は、一般に選択的開示や リンク不能性などの機能をサポートすることが期待されますが、これらの機能は、 特に映画チケットなどの低リスク認証情報に関する情報交換では、常に適切または 必要であるとは限りません。
要求されている認証情報の種類を認識するユーザーエージェントは、 要求された認証情報に最も適合し、共有することの結果をユーザーが理解できるように、 許可体験をカスタマイズすることが推奨されます。
ユーザーエージェントが、すべての クレデンシャル リクエストを理解することは期待できない。要求されているクレデンシャルの種類を認識しない ユーザーエージェントには、許可体験におけるユーザーの 摩擦を大幅に増やし、不明なクレデンシャルを Web サイトと共有することの リスクをユーザーに明確に伝えることが推奨される。これには、適切な水準の 摩擦と透明性を適用するために、 異なるユーザー エージェント間の統合が必要になる可能性があることに注意されたい。たとえば、 ブラウザーは、クレデンシャルリクエストに関する知識を オペレーティングシステムに委譲する場合があり、オペレーティングシステムは クレデンシャルマネージャーに、 既知のクレデンシャルタイプを登録し、不明なクレデンシャルタイプに対する交換リクエストを 拒否することを要求する場合がある。
ユーザーに適切な透明性を提供する必要性は、明示的なユーザーエージェントの賛同なしに エコシステムが新しい認証情報形式を開発できるようにしたいという希望と衝突します。
不要かつ濫用的な要求を行う検証者に対する、相互運用可能な不正利用報告システムを 検討してください。
API は、許可プロンプトなしにユーザーデータが共有されることが決してないようにしますが （[[[#user-permission-and-transparency|User Permission and Transparency]] セクションを参照）、Digital Credentials API によって返される可能性の高い 現実世界の識別子の長寿命性と一意性により、トラッカーやフィンガープリンターの 潜在的な標的になります。
選択的開示を用いた場合でも、攻撃者はデジタルクレデンシャルからのデータ （ユーザーの年齢やクレデンシャルの 発行者、タイムスタンプなど。[[[#leaking-incidental-data|Leaking Incidental Data]] セクションを参照）を組み合わせて、ユーザーを再識別したり、 フィンガープリントしたりする可能性があります。
この攻撃は、第三者攻撃者（たとえば検証者のページに埋め込まれているが、 追跡目的で検証者と能動的に協力していないスクリプトなど）にとっては、応答暗号化が必須であり、 応答は検証者のサーバーで復号されるべきであるため、 より困難である可能性があります。したがって、検証者は、復号された情報をクライアント側 JavaScript に 反映しないよう保証できます。ただし、すべての 検証者がそうするとは限りません。
認証情報の真正性を保証するため、検証者への提示には、通常、 検証者がアクセスを要求している内容よりも多くの情報が含まれます。 それには通常、少なくとも発行者および認証情報マネージャーの署名が含まれ、 さらに他のメタデータが含まれる可能性があります。
この追加情報は、ユーザーの再識別やフィンガープリンティングに使用される可能性があり、 それ以外の点ではリンク不能な提示が行われる場合に特に関連します。
Digital Credentials API は認証情報応答の内容を制御しませんが、 ユーザーエージェントは、要求されたものを超えて どの情報が検証者に共有される可能性が高いかを明確に強調し、 より広くは、検証者による API を通じたフィンガープリンティングを 特定してブロックすることにより、この種の追跡からユーザーを保護するのに役立ちます。
Digital Credentials API は、どの提示および発行プロトコルが
ユーザーエージェントによってサポートされているかに関する情報を、
userAgentAllowsProtocol()
を通じて公開します。
これは、たとえばユーザーのデバイスにどの
認証情報マネージャーアプリケーションがインストールされているかに
基づいて応答をカスタマイズしないことにより、ブラウザー・フィンガープリンティングと、
ユーザーのデバイス構成に関する情報の開示を緩和します。したがって返される情報は、
良くてもユーザーエージェントのバージョンと同等です。
Digital Credentials API は、サイトが ユーザー許可 フローを最初に経ることなく、認証情報が利用可能かどうかを知ることを可能にしません。 認証情報の存在を明らかにすることは、ユーザーのプライバシーへのリスクになります。 認証情報の存在は、ユーザーがサイトと共有したいと思っていなかったかもしれない 個人情報であり、他のシグナルと組み合わされると、ユーザーの許可なしに ユーザーを識別するために使用される可能性があるためです。これは表現の自由に対する リスクでもあります。ウェブサイトが、サービスへアクセスするためにこれらの認証情報の 提示をユーザーに求めるようになり、認証情報の提示を望まない個人を 排除する可能性があるためです。
Digital Credentials API は、認証情報を介して、きわめて個人的で 機微かつリスクのあるユーザー情報をウェブサイトと共有できるようにし、 永続的で一意かつ取り消し不能な、コンテキスト横断の識別子を通じて、 オンラインおよびオフラインでユーザーを追跡する能力を与える可能性があります。 また、ユーザーの閲覧活動の一部、および特定のウェブサイトおよび/または 認証情報マネージャーに対して身元を示す意図も明らかにします。 認証情報要求におけるユーザーエージェントの重要な責任の 1 つは、 情報交換を進めるための許可をユーザーから取得することです。
ユーザーが認証情報交換を進めるかどうかについて十分な情報に基づく 判断を行うために必要な重要な文脈情報には、次のものが含まれます。
ユーザーエージェントは、その実装において、 ユーザーに関するいかなる情報交換が発生する前に、列挙された詳細が ユーザーへ完全に開示されることを保証するよう助言されます。
これらを仕様内で規範的にすべきでしょうか。
サイトが文脈内の説明を提供できるように API を設計すべきでしょうか。
認証情報提示のために複数の要求および応答を処理することに関する 懸念、トレードオフ、および可能な緩和策を説明する必要があります。
ユーザーのシステムの技術アーキテクチャによっては、 「ユーザー エージェント」の定義に、ブラウザーや オペレーティングシステムなど、ソフトウェアスタックの複数の協調する層が 含まれる可能性があります。これらの層にとって最大の優先事項は、 安全で十分な情報に基づくユーザー許可体験でなければなりません。そのため、 統合はユーザーの安全にとって不可欠な場合があります。一部の層は、 ユーザーの認証情報の利用可能性など、他の層からはアクセスできない情報を保持する場合があります。 過剰なプロンプトや十分な文脈のないプロンプトは、（悪用可能な）混乱や プロンプト盲目を招く可能性があります。
このため、許可を求めるユーザーエージェントは、 そうすることが安全であると考える場合、理想的なユーザー体験のために ソフトウェア層を統合することが推奨されます。これは、たとえば ブラウザーが、適切なプロンプトを表示するオペレーティングシステムの API 契約を信頼し、 そのためブラウザー自身はプロンプトを表示しない場合に起こり得ます。
ユーザー許可フローの一部として、ユーザー エージェントは、認証情報要求を認証情報マネージャーへ転送するかどうか、 およびどの認証情報マネージャーを選択するかをユーザーが選べる権限を保持することを 確保する必要があります。これは、要求の一部として発生する情報開示と、 認証情報マネージャーが要求時点でこの情報を保持または共有できることに 起因します。
ユーザー エージェントによって仲介される許可は同意ではありません。同意には、 法的および規制上の環境によって異なり得る特定の法的定義があり、 情報を 検証者と共有する前に 認証情報マネージャーによって、または 要求を開始する前に検証者自身によって収集される必要がある場合があります。 同意を取得するための枠組みや規制はまだ開発中であるため、この API は、 必要な情報の交換を可能にすることを目指しています。その情報には次のものが含まれ得ます。
この情報のより多くが構造化された形式で利用可能になるにつれて、 ユーザーエージェントおよびこの仕様も、 ユーザー許可体験を改善するためにそれを活用することが期待されます。
実装者は、この API に特化した認証情報選択UIを設計する際に、アクセシビリティを考慮する必要があります。 発行または 提示中に表示されるモーダルダイアログの 内容（テキスト、QR コード、およびその他の視覚メディアを含む場合があります）は、ラベル付けされ、 支援技術に公開されるべきです。
インタラクティブ要素、特にユーザーが発行または 提示要求を 続行または中止できるようにする要素は、 デバイスに依存しない方法で操作可能でなければなりません。
ユーザーエージェントの自動化およびアプリケーションテストの目的で、この 文書は 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
session および command parameters が与えられたときの
digitalCredentials.setVirtualWalletBehavior コマンドの
リモート端手順は次のとおりです。
action"]とします。
context"]、
そうでない場合は
nullとします。
protocol"]、
そうでない場合は nullとします。
response"]、
そうでない場合は nullとします。
"respond" である場合：
null、または responseが
nullである場合、
エラーを、エラーコード invalid argumentで返します。
DigitalCredentialProtocolの
列挙値でない場合、
エラーを、エラーコード invalid argumentで返します。
null でない、または protocolが
nullでない場合、
エラーを、エラーコード invalid argumentで返します。
"clear" である場合：
null でない場合、
context のエントリーを
WebDriver セッションのアクティブな
仮想ウォレット動作から削除します。
null に設定します。
null でない場合、閲覧
コンテキスト ID context に対する WebDriver セッションの
アクティブな仮想ウォレット動作を
behaviorに設定します。
null を伴う成功を返します。
Promise
promise およびグローバルオブジェクト global が与えられたときに、
仮想ウォレット動作を処理するには、次の手順を実行します。
falseを返します。
null である場合、behaviorを現在の WebDriver
セッションの既定のアクティブな仮想ウォレット動作に設定します。
null である場合、falseを返します。
"wait" である場合、trueを返します。
"decline" である場合：
NotAllowedError"
DOMExceptionで
拒否します。
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
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 (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: