設問と範囲
複数の大学が、単一の中央レジストリに依存することなく、機関やクレデンシャル発行者の検証可能なディレクトリを共有したいと考えています。RecognizedEntity、RecognizedAction、および VerifiableRecognitionCredential をどのようにモデル化し、プライバシー、失効、なりすまし、および競合するレジストリをどのように処理するかを説明してください。
W3C Recognized Entities v1.0 は現在、First Public Working Draft（最初の公開作業草案）の段階にあります。これは、特定のアクションを実行するためにエコシステムによって認識されたエンティティのデータモデルを記述し、認識情報を公開したり、検証者に直接渡したりできるようにするものです。この質問では、Working Draft を最終標準として扱うことなく、検証可能なデータモデリングと信頼の決定をテストします。
面接官が評価するポイント
面接官は、エンティティ、アクション、認識者（recognizer）、クレデンシャルの有効性、および検証ポリシーに対する個別のモデルに加えて、クロスレジストリチェック、失効、およびプライバシーの境界を評価します。優れた回答では、保持者（ホルダー）から提示されたクレデンシャルを検証者が必ずしも受け入れる必要はないこと、および認識の表明（assertion）が自動的なビジネス認可を意味するわけではないことを指摘します。
回答前に確認すべき明確化のための質問
- 認識者、認識対象のエンティティ、および最終検証者は誰であり、それぞれどのレジストリを信頼していますか？
- 認識されたアクションは発行、検証、またはその他のアクションのいずれであり、その出力スキーマはどのように定義されていますか？
- クレデンシャルは検証者に直接渡されますか、それとも発行者から現在のステータスを取得する必要がありますか？
- どのような失効、有効性、鍵ローテーション、およびプライバシー要件が適用されますか？
- レジストリ間で不一致が生じた場合、誰が仲裁し、その理由を記録しますか？
30秒の回答フレームワーク
「私は、エンティティ、アクション、認識者、およびクレデンシャルアサーションを検証可能なオブジェクトとしてモデル化します。RecognizedEntity は recognizedTo を介してアクションにリンクし、アクションは recognizedBy と出力スキーマを指定し、VerifiableRecognitionCredential は発行者、有効性、およびサブジェクトセットを記録します。検証者は署名、ステータス、時間をチェックした上で、ローカルトラストポリシーに従って認識者を選択し、認識チェーンをたどり、出力スキーマを検証します。保持者が提供するクレデンシャルにより参照（ルックアップ）を省くことはできますが、高リスクな決定における鮮度（freshness）チェックを置き換えることはできません。個人データを最小限に抑え、失効、鍵ローテーション、および競合の決定を監査します。」
ステップごとの詳細な回答
1. エンティティ、アクション、および認識のモデル化
エンティティにはグローバルに一意な URL を使用し、recognizedTo が1つ以上の RecognizedAction オブジェクトを指すようにします。アクションには、名前、認識者、および出力を検証するためのスキーマが含まれます。『この機関は信頼されている』という情報をスコープのないブール値としてエンコードしないでください。recognizedIn は、既存のトラストリストまたは別の認識クレデンシャルを参照できるため、検証者はアサーションの背後にあるエコシステムを特定できます。
2. アサーションを検証可能なクレデンシャルとしてラップする
クレデンシャルは Verifiable Credentials Data Model v2.0 に準拠し、そのタイプ、発行者、validFrom、validUntil、および credentialSubject 内の認識されたエンティティを含める必要があります。有効な署名は発行者の鍵の制御を証明するものであり、検証者がその発行者を信頼すべきであることを証明するものではありません。ローカルのトラストアンカー、許可リスト、およびアクションのスコープは別の決定として適用します。
credential = {
type: ["VerifiableCredential", "VerifiableRecognitionCredential"],
issuer: "did:web:accreditor.example",
validFrom: "2026-01-01T00:00:00Z",
credentialSubject: [{
id: "did:web:university.example",
recognizedTo: [{ action: "issue", outputValidation: [schema] }]
}]
}3. 検証と認識チェーンの設計
まず構文、署名、発行者、有効性、失効、およびスキーマをチェックし、次に認識者がローカルトラストセットに属しているかどうかを判断します。マルチレベルの recognizedBy または recognizedIn チェーンの場合、最大深度を設定し、循環を検出し、各レベルの有効期間を検証します。長いチェーンが自動的により信頼されるわけではありません。ポリシーで必要な場合は、ETSI Trust Service Lists、X.509 CA リスト、または別の管理されたレジストリとクロスチェックします。
4. 鮮度と失効の処理
保持者はクレデンシャルを直接提示できるため、発行者へのルックアップを減らすことができますが、検証者はリスクに基づいて現在のステータスを確認するかどうかを決定します。短い有効期間、ステータスリスト、失効通知、またはレジストリバージョンを使用します。検証時刻、トラストアンカー、およびコンテキストハッシュを記録します。鍵のローテーション、発行者の侵害、または認識されたアクションの変更が発生した場合、失効はキャッシュヒットよりも優先される必要があります。
5. プライバシーの保護と不正利用の防止
名前、識別子、組織の関係、およびアクションを公開リスト化すると、監視や連座（guilt by association）につながる可能性があります。コンテキストごとにフィールドを最小限に抑え、保持者が制御する選択的開示を優先します。1つの認識から無関係なプロパティを推測しないでください。署名、ステータス、ソース、およびスキーマを共同で検証し、受け入れ可能な発行者を制限することで、悪意のある保持者が偽のクレデンシャルを拡散するのを防ぎます。
6. 競合のガバナンスとロールバック
異なるレジストリが、同じエンティティに対して異なるアクション、有効性、またはステータスを割り当てる場合があります。決定を保存する前に、優先順位、スコープ、時間、および証拠のルールを定義し、選択された理由を監査します。Working Draft が変更された場合は、コンテキスト、スキーマ、および検証アルゴリズムのバージョンを管理します。ビジネス認可を変更せずにシャドーリード（shadow-read）を実行します。なりすまし、プライバシーの漏洩、または検証のリグレッションが発生した場合は、新しいパスを無効にして古いレジストリを復元する必要があります。
高品質な回答例
私は、RecognizedEntity、RecognizedAction、認識者、および VerifiableRecognitionCredential を個別にモデル化します。エンティティはグローバル URL を持ち、アクションはそのスコープ、認識者、および出力スキーマを指定し、クレデンシャルは発行者、有効性、およびサブジェクトを含む VC Data Model 2.0 に従います。検証者は署名、時間、失効、およびスキーマをチェックし、ローカルトラストルートと許可リストを適用します。認識チェーンには深度と循環の制限があり、ETSI または X.509 リストとクロスチェックされる場合があります。保持者提示のクレデンシャルはルックアップを削減しますが、高リスクケースの鮮度チェックを排除するものではありません。監視や連座を防ぐために個人フィールドを最小限に抑えます。スコープ、時間、およびガバナンスルールを使用してレジストリの競合を解決し、結果を監査します。Working Draft の更新中はコンテキストと検証者のバージョンを管理し、なりすまし、古い失効情報、またはプライバシーの障害が発生した場合はロールバックします。
よくある間違い
- 有効な署名をビジネス上の信頼として扱う → これは鍵の制御を証明するだけです → 依然としてトラストルート、ステータス、およびアクションのスコープをチェックしてください。
- 認識をスコープのない信頼フラグとしてエンコードする → 認識されたアクションが失われます →
recognizedToと出力スキーマをモデル化してください。 - 保持者の最新クレデンシャルを常に信頼する → 失効または期限切れになっている可能性があります → リスクに応じてステータスと有効性をチェックしてください。
- 完全な個人レジストリを公開する → 集約により監視が可能になる可能性があります → 開示を最小限に抑え、集約を制限してください。
- レジストリが競合した際に最初の結果を採用する → 決定が監査不能になり、操作されやすくなります → 優先順位、スコープ、時間、および証拠を定義してください。
フォローアップの質問と回答
なぜ認識クレデンシャルはビジネス権限を直接付与しないのですか？
これは、認識者が特定のアクションを実行するエンティティを認識していることを表明するだけだからです。ビジネス権限は、リソース、テナント、時間、リスク、およびローカルポリシーにも依存します。
無限の認識チェーンをどのように防ぎますか？
最大深度を設定し、訪問した識別子を追跡し、全体のバジェットを強制します。循環または制限超過時には失敗とし、理由を記録します。
検証者が現在のステータスを取得しなければならないのはどのような場合ですか？
高価値のトランザクション、短い失効ウィンドウ、鍵の侵害、またはレジストリバージョンの変更の場合です。リスクが低いケースでは、バージョン管理された時間制限付きキャッシュを使用できます。
個人が誤って認識された場合はどのように対処しますか？
失効、異議申し立て、および修正のパスを提供します。公開フィールドを最小限に抑え、発行と検証の証拠を保持し、修正された状態が有効になった時点で古いクレデンシャルの受け入れを停止します。
Working Draft を安全に試用するにはどうすればよいですか？
ビジネス認可を変更することなく、分離されたテナントでシャドー検証（shadow-verify）を行い、仕様とテストベクターを固定し、ロールバックスイッチを保持し、実装とセキュリティのレビュー後に拡張します。