次の方法で共有

よくあるご質問 (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 ドキュメントにエンコードされるルート ドメイン名を含めるオプションがあります。 リンクされたドメインの詳細については、「ドメインを分散化識別子にリンクする」というタイトルの記事を参照してください。

Verified ID の検証可能な資格情報には、どのようなサイズ制限がありますか?

  • 発行要求の場合 - 1 MB
  • 検証可能な資格情報の写真 - 1 MB
  • コールバック結果 - 10 MB (受信なし)

ライセンス要件は何ですか?

検証可能な資格情報を発行するための特別なライセンス要件はありません。

Microsoft Entra 確認済み ID サービスをリセットする方法は?

リセットするには、Microsoft Entra 確認済み ID サービスをオプトアウトしてから再度オプトインする必要があります。 既存の検証可能な資格情報の構成はリセットされ、テナントは発行とプレゼンテーションの際に使う新しい DID を取得します。

  1. オプトアウトの手順に従います。
  2. Microsoft Entra 確認済み ID のデプロイ手順に従って、サービスを再構成します。
    1. 検証済み ID を手動で設定する場合は、Azure Key Vault の場所として同じリージョンまたは最も近いリージョンを選びます。 同じリージョンを選択すると、パフォーマンスと待機時間の問題を回避できます。
  3. 検証可能な資格情報サービスの設定を完了します。 資格情報を再作成する必要があります。
    1. また、テナントが新しい DID を保持するため、新しい資格情報を発行する必要もあります。

Microsoft Entra テナントのリージョンをチェックするにはどうすればよいですか?

  1. Azure portal で、Entra 確認済み ID のデプロイに使用するサブスクリプションの Microsoft Entra ID に移動します。

  2. [管理] の下で、 [プロパティ] を選択します。

    設定の削除とオプトアウトのスクリーンショット。

  3. 国またはリージョンの値を参照してください。 値がヨーロッパの国またはリージョンの場合、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 資格情報の定義をエクスポートする

  1. did:ion 機関の場合は、ポータルを使って、既存の資格情報のすべての表示と規則の定義をコピーします。
  2. 複数の機関があり、did:ion 機関が既定の機関でない場合は、Admin API を使う必要があります。 Verified ID テナントで、Admin API を使って接続し、機関の一覧を表示して、did:ion 機関の機関 ID を取得します。 次に、コントラクト一覧表示 API を使ってそれらをエクスポートし、それらを作り直すことができるように結果をファイルに保存します。

新しい did:web 機関を作成する

  1. オンボード API を使って、新しい did:web 機関を作成します。 または、テナントに did:ion 機関が 1 つしかない場合は、サービスのオプトアウトを実行した後、オプトイン操作を行って、検証済み ID の構成で再起動することもできます。 この場合は、クイックと手動のどちらかのセットアップを選択できます。
  2. Admin API を使って did:web 機関を設定する場合は、DID ドキュメントの生成を呼び出して did ドキュメントを生成し、既知のドキュメントの生成を呼び出してから、それぞれの既知のパスに JSON ファイルをアップロードする必要があります。

資格情報の定義を作成し直す

新しい did:web 機関を作成したら、資格情報の定義を作り直す必要があります。 オプトアウトして再オンボードした場合はポータルを使ってそれを行うことができ、またはコントラクトの作成 API を使って作成し直す必要があります。

既存のアプリケーションを更新する

  1. 新しい did:web authority を使うように、既存のアプリケーション (発行者または検証者アプリ) をすべて更新します。 発行アプリの場合は、資格情報マニフェストの URL も更新します。
  2. 新しい did:web 機関からの発行と検証のフローをテストします。 テストで問題がなければ、did:ion 機関を削除する次のステップに進みます。

did:ion 機関を削除する

オプトアウトしてオンボードし直さなかった場合は、以前の did:ion 機関を削除する必要があります。 機関の削除 API を使って、did:ion 機関を削除します。

はい。サービスを再構成した後、検証可能な資格情報の発行と検証に使用される新しい DID がテナントに追加されます。 新しい DID をドメインに関連付ける必要があります。

"古い DID" の取得を Microsoft に要求できますか?

いいえ。現時点では、サービスをオプトアウトした後にテナントの DID を保持することはできません。

ngrok を使用できません。どうすればよいですか。

サンプルのデプロイと実行に関するチュートリアルでは、アプリケーション プロキシとしての ngrok ツールの使用について説明されています。 IT 管理者が、企業ネットワークでこのツールを使用できないようにブロックしている場合があります。 別の方法は、Azure App Service にサンプルをデプロイし、クラウドで実行することです。 次のリンクは、それぞれのサンプルを Azure App Service にデプロイするのに役立ちます。 サンプルをホストするには、Free 価格レベルで十分です。 チュートリアルごとに、最初に Azure App Service インスタンスを作成し、アプリは既に作成しているためアプリの作成はスキップして、デプロイからチュートリアルを続ける必要があります。

使っているサンプルの言語に関係なく、Azure AppService のホスト名 (https://something.azurewebsites.net) がパブリック エンドポイントとして使われます。 機能させるために追加の構成を行う必要はありません。 コードまたは構成を変更する場合は、サンプルを Azure AppServices に再デプロイする必要があります。 トラブルシューティングとデバッグは、コンソール ウィンドウへのトレースでエラーが表示されるローカル コンピューターでのサンプルの実行ほど簡単ではありませんが、ログ ストリームを使ってほぼ同じことができます。

コールバック イベントのネットワーク強化

要求サービス API は、証明書利用者アプリケーションによって提供される URL へのコールバックを使用します。 コールバックを受信するには、検証済み ID システムからこの URL に到達できる必要があります。 コールバックは、Microsoft Entra テナントと同じリージョンの Azure インフラストラクチャから送信されます。 ネットワークを強化する必要がある場合、2 つのオプションがあります。

  • Azure Firewall サービス タグ AzureCloud を使用します。
  • 公開された CIDR 範囲を使用してファイアウォールを構成します。 要求サービス API からのコールバック トラフィックが通過できるようにファイアウォールを構成するには、Microsoft Entra テナントがデプロイされている場所と一致する AzureCloud."リージョン" を使用する必要があります。 たとえば、テナントがヨーロッパにある場合は、AzureCloud.northeurope、.westeurope などから、すべての CIDR 範囲をファイアウォール構成に選択する必要があります。

QR コードのスキャン

ドキュメントでは、特に明記されていない限り、scan the QR code という手順は Microsoft Authenticator モバイル アプリを使用してスキャンすることを指します。 モバイルのカメラ アプリで QR コードをスキャンして、Microsoft Authenticator を起動することができます。 これを機能させるには、openid-vc:// のプロトコル ハンドラーを Microsoft Authenticator に登録する必要があります。 別のモバイル アプリが登録されている場合、Authenticator は開きません。 一部の古い Android モバイル バージョンでは、カメラ アプリでの QR コードのスキャンが機能せず、Microsoft Authenticator アプリを使用してスキャンする以外の回避策はありません。

次のステップ