次の方法で共有

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

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

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

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

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

Microsoft Entra Verified ID サービスをリセットするにはどうすればよいですか?

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

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

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

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

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

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

  3. 国または地域の値を参照してください。 値がヨーロッパの国またはリージョンの場合、Microsoft Entra Verified ID サービスはヨーロッパに設定されます。

Microsoft Entra Verified ID は DID メソッドとして ION をサポートしていますか?

検証済み ID では、2023 年 12 月までプレビュー段階の DID:ION メソッドがサポートされました。

did:ion から did:web へどうやって移行できますか?

did:ion から did:web に移動する場合は、管理 API を使用して次の手順に従います。 機関を変更するには、すべての資格情報の再発行が必要です。

既存のDID:ION認証定義をエクスポートする

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

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

  1. オンボード APIを使用して、新しい did:web 機関を作成します。 テナントに did:ion オーソリティが 1 つだけある場合は、まずサービスのオプトアウトを実行し、次にオプトイン操作を行うことで、Verified ID 構成で再起動することができます。 この場合、[簡易] と [手動] 設定のどちらかを選択できます。
  2. 管理 API を使用して did:web 機関を設定する場合は、DID ドキュメントの生成を呼び出して did ドキュメントを生成し、既知のドキュメントの生成を呼び出して、JSON ファイルをそれぞれの既知のパスにアップロードする必要があります。

資格情報の定義を再作成する

新しい did:web 機関を作成するときは、資格情報の定義を再作成する必要があります。 オプトアウトして再度オンボーディングした場合はポータル経由でこれを行うことができます。または、契約作成 API を使用して再作成する必要があります。

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

  1. 新しい did:web authority を使用するには、既存のアプリケーション (発行者/検証ツール アプリ) を更新します。 発行アプリの場合は、資格情報マニフェスト URL も更新します。
  2. テストの発行と検証は、新しい did:web 機関から行われます。 テストが成功したら、did: ionの権限削除のための次の手順に進みます。

did:ion 機関を削除する

オプトアウトせずに再オンボードした場合は、古い did:ion 機関を削除する必要があります。 delete authority API を使用して、did: ion authority を削除します。

はい。サービスを再構成した後、検証可能な資格情報の発行と検証に使用される新しい 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 へのコールバックを利用します。 コールバックを受信するには、この URL が Verified ID システムからアクセスできる必要があります。 コールバックは、Microsoft Entra テナントと同じリージョンの Azure インフラストラクチャから行われます。 ネットワークを強化する必要がある場合、2 つのオプションがあります。

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

QR コードのスキャン

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

Android 携帯電話では、QR コードのスキャンに関する既知の問題は次のとおりです。

  • Android 9 以前のバージョンでは、カメラ アプリで QR コードをスキャンしても機能せず、Microsoft Authenticator アプリを使用してスキャンする以外の回避策はありません。
  • 仕事用プロファイルと個人用プロファイルの両方を持つ Android フォンでは、各プロファイルに Microsoft Authenticator アプリの独自のインスタンスがあります。 仕事用プロファイルの Authenticator アプリに資格情報があり、個人用プロファイルからカメラ アプリを使用して QR コードをスキャンしようとすると、個人用 Authenticator アプリが開きます。 資格情報が個人プロファイルではなく仕事用プロファイルにあるため、エラーが発生します。 "この検証済み ID を追加してやり直す必要があります" というエラー メッセージが表示されます。

次のステップ

  • Last updated on