AI Agent Identity and Verifiable Data

AI エージェントのアイデンティティと検証可能なデータ

はじめに

エンドツーエンド検証可能データ基盤（EVDI）は、AI エージェントのエコシステムにおいて、デジタルアイデンティティと認証情報を管理するための包括的な基盤です。EVDI は、AI エージェントがほかのエージェント、人間、システムとやり取りする際に、自身のアイデンティティを確立、管理、検証できる安全な分散型フレームワークを提供します。

自己主権型アイデンティティ（SSI）とは？

自己主権型アイデンティティ（SSI）は、個人（この場合は AI エージェント）が自身のアイデンティティとデータを管理できるようにするデジタルアイデンティティ管理モデルです。単一の機関がアイデンティティを管理、検証する従来の中央集権型アイデンティティシステムとは異なり、SSI では次のことが可能です。

1. アイデンティティを所有する：中央機関に依存せず、自身のデジタル上の存在を管理します
2. 認証情報を管理する：必要に応じて、検証可能な認証情報を保存、共有します
3. 主張を証明する：不要な情報を開示せずに、自身の属性を証明します
4. 信頼を確立する：分散型の方法で、ほかのエンティティとの信頼できるつながりを構築します

発行者と検証者の役割

SSI エコシステムには、次の3つの主要な役割があります。

• 発行者：検証可能な認証情報を作成し、署名するエンティティです（例：AI エージェントが面接を実施した後、ユーザーのスキルを証明する）
• 保有者：認証情報を受け取り、保存するエンティティです（例：自身の能力を保存する AI エージェント）
• 検証者：認証情報を要求し、検証するエンティティです（例：エージェントの認可を確認するサービス）

このリポジトリでは、信頼できる機関が AI エージェントやほかのエンティティに検証可能な認証情報を作成、発行できるようにする発行者コンポーネントに焦点を当てています。

AI エージェントにとって EVDI が重要な理由

AI システムの自律性が高まり、さまざまなエンティティとやり取りするようになるにつれて、次のことを安全に行う方法が必要になります。

• 自身のアイデンティティと能力を証明する
• 人間、ほかの AI エージェント、外部システムとの信頼を確立する
• セキュリティを損なうことなく、検証可能な情報を共有する
• 複雑なやり取りを行いながらプライバシーを維持する

EVDI は、暗号技術で保護され、改ざんを検出できる認証情報によってこれらの機能を実現します。これらの認証情報は、発行元に問い合わせることなく検証できます。

やり取りの範囲

EVDI によって可能になるやり取りは、エージェント間の通信に限られません。次のようなやり取りにも対応します。

• エージェントと人間：AI エージェントは、人間に検証可能な認証情報を提示、発行できます
• エージェントとシステム：AI エージェントは、自身の認証情報を使って外部システムで認証できます
• 人間とエージェント：人間は、AI システムに認証情報を提示できます
• システムとエージェント：外部システムは、AI エージェントに認証情報を発行できます

詳しくは、ドキュメントをご覧ください。

このリポジトリには、より広範な EVDI エコシステムの最初のコンポーネントである Empe 自己主権型アイデンティティ発行者サービス用の MCP（Model Context Protocol）サーバーが含まれています。今後のコンポーネントには、認証情報の検証機能、エージェント間認証、AI エージェント向けの自己主権型アイデンティティ管理が含まれる予定です。

SSI 発行者サービス用 MCP サーバー

概要

このプロジェクトでは、自己主権型アイデンティティ（SSI）エコシステムにおいて、AI モデルと EMPE 発行者サービスの間をつなぐアダプターとして機能する Model Context Protocol（MCP）サーバーを実装しています。Spring Boot と Spring AI の MCP サーバー機能を基盤として構築されており、明確に定義されたツールを通じて AI アシスタントが発行者サービスの機能を利用できるようにし、AI を活用した認証情報管理ワークフローを実現します。

MCP とは？

Model Context Protocol（MCP）は、AI モデルが外部システムやツールとやり取りできるようにするプロトコルです。AI モデルは以下のことができます。

• 利用可能なツールを検出する
• 特定の操作を実行するためにツールを呼び出す
• それらの操作の結果を処理する

この MCP サーバーは、Issuer Service の機能を AI モデルが呼び出せるツールとして公開し、自然言語でのやり取りと SSI クレデンシャル操作の間を橋渡しします。

仕組み

1. ツールの登録：サーバーは、明確な説明とパラメーターを備えたツールとして SSI 操作を定義します
2. AI との連携：AI モデルが MCP サーバーに接続し、利用可能なツールを検出します
3. ツールの実行：AI が SSI 操作を実行する必要がある場合、このサーバーにツール呼び出しを行います
4. 結果の処理：サーバーは Issuer Service 上で操作を実行し、結果を AI に返します

主なコンポーネント

• MCP サーバー：AI モデルにツールを公開する基盤
• スキーマ管理ツール：クレデンシャルスキーマを作成、管理する機能
• クレデンシャル発行ツール：検証可能なクレデンシャルを生成、発行する機能
• Issuer Service クライアント：基盤となる Issuer Service API との通信を処理します

今後の機能

EVDI エコシステムは継続的に進化しており、以下の機能が計画されています。

1. クレデンシャルの検証：エージェントが提示するクレデンシャルを検証するツール
2. エージェントのアイデンティティ管理：AI エージェントが DID を使用して独自のアイデンティティを管理できるようにします
3. クレデンシャルの保存：エージェントが独自のクレデンシャルを収集、保存できるようにします
4. 選択的開示：すべての情報を明かさずに、エージェントが特定のクレデンシャル属性を共有できるようにします
5. エージェント間認証：DID を使用して AI エージェント間で安全に認証する仕組み

Issuer Service へのアクセス

ワンクリックポータル

Issuer または Verifier サービスの独自のインスタンスを簡単にデプロイできるワンクリックポータルを提供しています。ポータルには https://oneclick.empe.io/ からアクセスできます。

デモ環境

テスト用のデモ環境を以下で提供しています。

https://mcp-demo-issuer.evdi.app

注：デモ環境へのアクセスにはアクセスコードが必要ですが、セキュリティ上の理由から、この README には記載していません。アクセスコードは、利用を希望するユーザーに安全な手段で提供します。

MCP サーバーのセットアップ

前提条件

• Java 23 以降
• Maven 3.8+
• EMPE Issuer Service インスタンスへのアクセス

設定

application.properties または application.yml で MCP サーバーを設定します。

# MCP Server Configuration
spring.ai.mcp.server:
  port: 8090
  cors.allowed-origins: "*"  # For development only

# Issuer Service Connection
issuer:
  api:
    base-url: https://your-issuer-service.example.com/api/v1
    client-secret: your-client-secret
    schema-templates:
      proof-of-purchase:
        name: ProofOfPurchase
        type: ProofOfPurchase
        properties:
          ticket:
            type: string
            title: Ticket Number
          seat:
            type: string
            title: Seat Assignment
          description:
            type: string
            title: Event Description
        required-fields:
          - ticket
          - seat
          - description

ビルドと実行

mvn clean package
java -jar target/mpc-issuer-verifier-0.0.1-SNAPSHOT.jar

AI モデルを MCP サーバーに接続する

OpenAI Custom GPT の例

OpenAI で Custom GPT を作成する場合：

1. GPT Builder に移動します
2. 「Configure」タブで「Actions」を選択します
3. 次の内容で新しいアクションを追加します。
   • 認証：なし
   • API エンドポイント：http://your-mcp-server:8090/api/v1
   • スキーマ：「Import from URL」に設定し、http://your-mcp-server:8090/api/v1/openapi.json を使用します

Anthropic Claude の例

Claude では、関数呼び出し機能を使用します。

const response = await client.messages.create({
  model: "claude-3-opus-20240229",
  max_tokens: 1000,
  system: "You are an assistant that helps users manage SSI credentials.",
  messages: [
    {
      role: "user",
      content: "Create a proof of purchase credential"
    }
  ],
  tools: [
    {
      name: "mcp_tools",
      url: "http://your-mcp-server:8090/api/v1/openapi.json"
    }
  ]
});

利用可能な AI ツール

MCP サーバーは、適切な使い方を案内する詳細な説明とともに、以下のツールを AI モデルに公開します。

スキーマ管理ツール

createSchema

検証可能なクレデンシャルの構造を定義する新しいクレデンシャルスキーマを作成します。

パラメーター：

• name：人が読みやすい名前（例：'ProofOfPurchase'、'IdentityCredential'）
• type：このスキーマタイプの一意の識別子。オファリングの作成時に使用されます
• properties：スキーマのプロパティとその型、説明を定義する JSON マップ
• requiredFields：クレデンシャルに含める必要がある必須フィールドのリスト

getAllSchemas

システム内のすべてのクレデンシャルスキーマを取得します。

getSchemaById

一意の識別子（UUID）で特定のスキーマを取得します。

パラメーター：

• id：取得するスキーマの UUID（例：'db5a33ae-2eef-41b4-9c74-2ed16c4bb4f4'）

deleteSchema

システムからスキーマを完全に削除します。

パラメーター：

• id：削除するスキーマの UUID

schemaExistsByType

指定したタイプのスキーマがすでに存在するかどうかを確認します。

パラメーター：

• type：確認するスキーマのタイプ（大文字と小文字を区別）

getLatestSchemaByType

指定したタイプのスキーマの最新バージョンを取得します。

パラメーター：

• type：検索するスキーマのタイプ（大文字と小文字を区別）

認証情報発行ツール

createTargetedOffering

特定の受信者 DID 向けの認証情報オファリングを作成します。

パラメーター：

• type：オファリングする認証情報のタイプ（既存のスキーマと一致する必要があります）
• credentialSubject：キーと値のペアとして認証情報に含めるデータ
• recipientDid：対象となる受信者の DID（例：'did:empe:testnet:123abc456def'）

createOpenOffering

誰でも受け取ることができるオープンな認証情報オファリングを作成します。

パラメーター：

• type：オファリングする認証情報のタイプ（既存のスキーマと一致する必要があります）
• credentialSubject：キーと値のペアとして認証情報に含めるデータ

AI とのやり取りの例

例 1：スキーマの作成と認証情報オファリング

ユーザー：「プレミアム会員向けの会員認証情報を作成してください。」

AI による処理：

1. まず、適切なスキーマが存在するか確認します：

   {
     "name": "schemaExistsByType",
     "parameters": {
       "type": "MembershipCredential"
     }
   }
   

2. スキーマが存在しない場合は、作成します：

   {
     "name": "createSchema",
     "parameters": {
       "name": "MembershipCredential",
       "type": "MembershipCredential",
       "properties": {
         "memberName": {
           "type": "string",
           "title": "Member Name"
         },
         "membershipLevel": {
           "type": "string", 
           "title": "Membership Level"
         },
         "validUntil": {
           "type": "string",
           "title": "Valid Until",
           "format": "date"
         }
       },
       "requiredFields": ["memberName", "membershipLevel", "validUntil"]
     }
   }
   

3. 認証情報オファリングを作成します：

   {
     "name": "createOpenOffering",
     "parameters": {
       "type": "MembershipCredential",
       "credentialSubject": {
         "memberName": "Jane Smith",
         "membershipLevel": "Premium",
         "validUntil": "2026-03-19"
       }
     }
   }
   

例 2：スキーマ情報の取得

ユーザー：「現在、どのような認証情報タイプに対応していますか？」

AI による処理：

{
  "name": "getAllSchemas",
  "parameters": {}
}

その後、AI は結果を処理して、人が読みやすい要約を提示します： 「現在、次の認証情報タイプに対応しています：

1. MembershipCredential（2 バージョン）
2. EventTicket
3. ProofOfPurchase」