よくあるご質問 (FAQ)
このページには、Verifiable Credentials と分散化 ID に関してよく寄せられる質問が含まれています。 質問は、次の各セクションに整理されています。
基本
DID とは何ですか。
分散化識別子 (DID) は、リソースへのアクセスのセキュリティ保護、資格情報の署名と検証、およびアプリケーション データ交換の支援に使用できる一意識別子です。 従来のユーザー名や電子メール アドレスとは異なり、エンティティ自体 (ユーザー、デバイス、または会社) によって DID が所有および制御されます。 DID は、外部組織や信頼されている仲介者からは独立した存在です。 W3C の分散化識別子の仕様では、DID についてさらに詳しく説明されています。
なぜ DID が必要なのですか。
デジタル信頼では、基本的に、参加者が ID を所有して制御する必要があります。ID の基礎は、識別子です。 集中型識別子ハニーポットに対して毎日大規模なシステム侵害および攻撃が行われる時代において、ID の分散化は、ユーザーと企業にとって重要なセキュリティ上のニーズになりつつあります。 ID を所有および制御する個人間では、検証可能なデータと証明を交換できます。 分散化資格情報環境を使用すると、現在手動で労力を要する多くのビジネス プロセスを自動化できます。
検証可能な資格情報とは何ですか。
資格情報は日常生活の一部です。 運転免許証は、自動車を運転できることを証明するために使用されます。 学位は教育レベルを証明するために使用でき、政府発行のパスポートは国やリージョン間の移動を可能にします。 Verifiable Credentials は、Web 上でこれらの種類の資格情報を、暗号的に安全で、プライバシーを尊重し、マシンによる検証が可能な方法で表現するためのメカニズムを提供します。 W3C の検証可能な資格情報の仕様では、検証可能な資格情報についてさらに詳しく説明されています。
概念に関する質問
ユーザーが電話を紛失した場合はどうなりますか。 ID を復旧することはできますか。
ユーザーに復旧メカニズムを提供する方法は複数あり、それぞれに独自のトレードオフがあります。 Microsoft は現在、オプションを評価しており、ユーザーのプライバシーと自己裁量権を尊重しつつ、便利で安全な復旧のアプローチを設計しているところです。
ユーザーが発行者または検証者からの要求を信頼するにはどうすればよいですか。 DID が組織にとって本当の DID であることは、どうすればわかりますか。
Microsoft では、DID をよく知られている既存のシステム (ドメイン名) に接続するために、Decentralized Identity Foundation の Well Known DID Configuration 仕様を実装しています。 Microsoft Entra 確認済み ID を使って作成された各 DID には、DID ドキュメントにエンコードされるルート ドメイン名を含めるオプションがあります。 詳細については、「ドメインを分散化 ID にリンクする」というタイトルの記事を参照してください。
ライセンス要件は何ですか?
検証可能な資格情報を発行するための特別なライセンス要件はありません。
Microsoft Entra 確認済み ID サービスをリセットする方法は?
リセットするには、Microsoft Entra Verified ID サービスをオプトアウトしてから再度オプトインする必要があります。 既存の検証可能な資格情報の構成はリセットされ、テナントは発行とプレゼンテーションの際に使う新しい DID を取得します。
- オプトアウトの手順に従います。
- Microsoft Entra 確認済み ID のデプロイ手順に従って、サービスを再構成します。
- 検証済み ID を手動で設定する場合は、Azure Key Vault の場所として同じリージョンまたは最も近いリージョンを選びます。 これにより、パフォーマンスと待ち時間の問題が回避されます。
- 検証可能な資格情報サービスの設定を完了します。 資格情報を再作成する必要があります。
- テナントを発行者として構成する必要がある場合は、ストレージ アカウントを検証可能な資格情報サービスとしてヨーロッパ リージョンに配置することをお勧めします。
- また、テナントが新しい DID を保持するため、新しい資格情報を発行する必要もあります。
Microsoft Entra テナントのリージョンをチェックするにはどうすればよいですか?
- Azure portal で、Entra 確認済み ID のデプロイに使用するサブスクリプションの Microsoft Entra ID に移動します。
- [管理]の下で、[プロパティ] を選択します
- 国またはリージョンの値を参照してください。 値がヨーロッパの国またはリージョンの場合、Microsoft Entra 確認済み ID サービスはヨーロッパに設定されます。
Microsoft Entra Verified ID は DID メソッドとして ION をサポートしていますか?
Verified ID は、2023 年 12 月までプレビュー段階の DID:ION メソッドをサポートしていましたが、その後は廃止されました。
did:ion から did:web に移動するにはどうすればよいですか?
did:ion から did:web に移動する場合は、Admin API を使って次の手順のようにします。 機関を変更するには、すべての資格情報を再発行する必要があります。
既存の did:ion 資格情報の定義をエクスポートする
did:ion機関の場合は、ポータルを使って、既存の資格情報のすべての表示と規則の定義をコピーします。- 複数の機関があり、
did:ion機関が既定の機関でない場合は、Admin API を使う必要があります。 Verified ID テナントで、Admin API を使って接続し、機関の一覧を表示して、did:ion機関の機関 ID を取得します。 次に、コントラクト一覧表示 API を使ってそれらをエクスポートし、それらを作り直すことができるように結果をファイルに保存します。
新しい did:web 機関を作成する
- オンボード API を使って、新しい
did:web機関を作成します。 または、テナントに did:ion 機関が 1 つしかない場合は、サービスのオプトアウトを実行した後、オプトイン操作を行って、Verified ID の構成で再起動することもできます。 この場合は、クイックと手動のどちらかのセットアップを選択できます。 - Admin API を使って did:web 機関を設定する場合は、DID ドキュメントの生成を呼び出して did ドキュメントを生成し、既知のドキュメントの生成を呼び出してから、それぞれの既知のパスに JSON ファイルをアップロードする必要があります。
資格情報の定義を作成し直す
新しい did:web 機関を作成した後、資格情報の定義を作り直す必要があります。 オプトアウトして再オンボードした場合はポータルを使ってそれを行うことができ、またはコントラクトの作成 API を使って作成し直す必要があります。
既存のアプリケーションを更新する
- 新しい
did:web authorityを使うように、既存のアプリケーション (発行者または検証者アプリ) をすべて更新します。 発行アプリの場合は、資格情報マニフェストの URL も更新します。 - 新しい did:web 機関からの発行と検証のフローをテストします。 テストで問題がなければ、did:ion 機関を削除する次のステップに進みます。
did:ion 機関を削除する
オプトアウトしてオンボードし直さなかった場合は、以前の did:ion 機関を削除する必要があります。 機関の削除 API を使って、did:ion 機関を削除します。
Microsoft Entra 確認済み ID サービスを再構成する場合、自分の DID をドメインに再リンクする必要がありますか?
はい。サービスを再構成した後、検証可能な資格情報の発行と検証に使用される新しい DID がテナントに追加されます。 新しい DID をドメインに関連付ける必要があります。
"古い DID" の取得を Microsoft に要求できますか?
いいえ。現時点では、サービスをオプトアウトした後にテナントの DID を保持することはできません。
ngrok を使用できません。どうすればよいですか。
サンプルのデプロイと実行に関するチュートリアルでは、アプリケーション プロキシとしての ngrok ツールの使用について説明されています。 IT 管理者が、企業ネットワークでこのツールを使用できないようにブロックしている場合があります。 別の方法は、Azure App Service にサンプルをデプロイし、クラウドで実行することです。 次のリンクは、それぞれのサンプルを Azure App Service にデプロイするのに役立ちます。 サンプルをホストするには、Free 価格レベルで十分です。 チュートリアルごとに、最初に Azure App Service インスタンスを作成し、アプリは既に作成しているためアプリの作成はスキップして、デプロイからチュートリアルを続ける必要があります。
- Dotnet - App Service に発行する
- Node - App Service にデプロイする
- Java - App Service にデプロイする。 Azure App Service 用の Maven プラグインをサンプルに追加する必要があります。
- Python - Visual Studio Code を使用してデプロイする
使っているサンプルの言語に関係なく、Azure AppService のホスト名 (https://something.azurewebsites.net) がパブリック エンドポイントとして使われます。 機能させるために追加の構成を行う必要はありません。 コードまたは構成を変更する場合は、サンプルを Azure AppServices に再デプロイする必要があります。 トラブルシューティングとデバッグは、コンソール ウィンドウへのトレースでエラーが表示されるローカル コンピューターでのサンプルの実行ほど簡単ではありませんが、ログ ストリームを使ってほぼ同じことができます。