[データ駆動型社会を支える「データスペース」の実像─ハンズオンで理解するその価値と可能性]

2024年11月13日(水)角井 健太郎、土橋 昌、八木 拓馬、渡邊 凜太郎（NTTデータグループ 技術革新統括本部）

　これまで、第8回ではEDC Samplesのビルド手順、第9回ではアセットやポリシーなどの重要概念、第10回ではAPIを用いた操作の手順などを紹介してきました。これらの内容や相互の関連性から、EDCをコネクタとしてどう使うのか、何ができるのかを実感を持って把握していただけたと思います。

　本稿はEDCを用いたハンズオンの最終回として、データスペースの重要な側面の1つである「トラスト」と「認証」の関係や、EDCでコネクタ間の認証を行う方式を、実際の手順に沿ってご紹介します。

トラストと認証の深い関係

　トラスト（Trust）は、データスペースを旧来のインターネット上のデータ交換システムから隔てる特徴的なコンセプトの1つです（第1回を参照）。

　トラスト自体は、社会科学や人文科学を含めてさまざまな分野で研究の対象となっている概念ですが、工学的な定義としては、例えばソフトウェアの品質モデルの規格であるISO/IEC 25010:2011や、トラストに関連する用語の定義そのものを目的とした技術仕様であるISO/IEC TS 5723:2022によるものがあります（図1）。

　これらの定義に共通するポイントは、ある視点から見たときに、対象がこちらの意図どおりに動作する、あるいは期待に応えると確信できることにあります。ただし、この確信が成立するのは、トラストの対象が常に一貫して同一の主体であるときに限られます。

　対象がいつの間にかすり替わっていたとしたらどうでしょうか。そもそも、相手が単一かつ同一の主体であること（＝アイデンティティ）を、確実かつ継続的に確認できなければ、相手に対して何らの期待も確信も抱くことはできないため、トラストが成立する余地はありません。

　相手のアイデンティティを確認することを、情報工学では認証（Authentication）と呼びます。トラスト実現の第一歩はまず認証から始まります。これはデータスペースにおいても例外ではありません。システムとしてのデータスペースでは、コネクタがその参加者のエージェントとして機能するコンポーネントですから、まずコネクタ同士が相互に認証できる仕組みが必要です。

目の前のコネクタは何者？ コネクタ間認証の諸方式

　コネクタ間の認証プロセスは、今まさに通信相手としているコネクタ（ここでは「対向コネクタ」と呼びます）が、だれを代理するエージェントなのかを確認するものです。その方式として代表的なものを2つご紹介しましょう。

Dynamic Attribute Provisioning Service（DAPS）

　「Dynamic Attribute Provisioning Service（DAPS）」は、IDS（第7回を参照）で当初から提唱されていたコネクタのためのアイデンティティプロバイダ（IdP）であり、X.509形式の証明書に基づくPKI（公開鍵暗号基盤）を認証の基盤として生かしつつ、コネクタに対して柔軟に属性を付与可能とすることを目的とした仕組みです。

　これを実現するために、WebアプリケーションでデファクトスタンダードとなっているOAuth 2.0プロトコルを利用しています。OAuth 2.0用語で「DAPSサーバ」は「クライアントクレデンシャルズフローに対応した認可サーバ」と説明できます。

　DAPSによるコネクタ間認証の流れを示したのが図2です。まず被認証者であるコネクタがDAPSサーバに対してJWT（JSON Web Token）形式のクライアントアサーションによるクライアント認証を行うと、DAPSサーバはこのコネクタに対してトークンを発行します。このトークンは「Dynamic Attribute Token（DAT）」と呼ばれています。コネクタの識別子であるクライアントIDを含み、DAPSサーバーの秘密鍵で署名されています。

　次に、コネクタが受領したDATをHTTPリクエストヘッダに乗せ、認証者となる対向コネクタに送信します。DATを受け取った認証者側のコネクタは、DAPSサーバのJWKS（JSON Web Key Set）エンドポイントから取得した公開鍵を用いてDATの署名を検証し、送信されてきたDATに記載されているクライアントIDが確かに被認証者側コネクタのものであることを確認できます。

　DAPSサーバがDATを発行する際には、コネクタのクライアントIDの他にも、データスペースの要件に応じたさまざまな属性を含めることが可能です。例えばコネクタを運用する参加者の識別子となる文字列を含めておけば、それを用いて対向コネクタが誰の代理たるエージェントなのかを判定できるでしょう。このように、DAPSサーバはDATの発行を通じてデータスペースのトラストを支えるIdPとして機能します。

Decentrized Claims Protocol（DCP）

　「Decentralized Claims Protocol（DCP）」はかつて「Identity and Trust Protocol」と呼ばれ、「Catena-X」向けのオープンソースソフトウェアを開発する「Tractus-X」プロジェクトの一環として設計されたプロトコルです。現在、DCPはEclipse Foundationの傘下で「Specification Project（技術仕様やプロセス仕様の開発を目的とするプロジェクト）」となり、技術仕様としての開発プロセスが進行中です。

　DCPによるコネクタ間認証の基礎にあるのは、W3C等で標準化が進められている資格情報の表現形式である「Verifiable Credentials（VC）」と「Verifiable Presentations（VP）」、そして「Decentralized Identifiers（DID）」です。紙幅の関係でVC/VPやDIDの詳細は割愛しますが、あるコネクタを運用する主体がデータスペースの正当な参加者である、ということが、まさにVCが検証する「資格」情報にあたるという点を押さえておいてください。

　DCPによるコネクタ間認証の概要を示したのが図3です。以下では、DCPにおけるVC発効から利用までの流れな手順を紹介します（番号は図3に対応）。

　(1)VCが、コネクタを運用する主体の正当性を確認できる立場にある「イシュア」によって発行されます。発行されたVCは、コネクタと連携するコンポーネントである「クレデンシャルサービス」に格納され、認証プロセスの開始に備えます。(2)コネクタが他のコネクタと通信を開始するのを契機として、クレデンシャルサービスにアクセスするためのアクセストークンが対向コネクタ（認証者）に向けて発行されます。

　(3)アクセストークンを受領した側のコネクタは、それを用いて被認証者側のクレデンシャルサービスにアクセスします。そして、(4)VP（VCのコンテナのようなもの）を取得・検証することによって、被認証者側コネクタの運用者が正当なデータスペース参加者であることを確認します。

　上記の流れにおけるポイントは、被認証者側コネクタが発行したアクセストークンが、認証者側コネクタで「折り返し」て、被認証者側のクレデンシャルサービスにアクセスするために利用されている点です。

　一方で、アクセストークンは対向コネクタにクレデンシャルサービスのVPを取得させ、自らの資格情報（ある意味でアイデンティティそのもの）を提示するために使用するものです。そのため、受領したアクセストークンを第3のコネクタに対して“使いまわし”をするようなコネクタがいると、認証の仕組みとしては破綻します。

　そこで、アクセストークンをそのまま送信するのではなく、「Self-Issued IDトークン」というもう1つのトークンの中に包んでから、対向コネクタに送信します。このSelf-Issued IDトークンとは、OpenID Connectプロトコルのバリエーションの1つ、Self-Issued OpenID Provider仕様で定義されているものであり、その名のとおり自己署名されたトークンです。

　Self-Issued IDトークンは、コネクタと連携するもう1つのコンポーネントである「セキュアトークンサービス」によって生成されます。このとき付与された署名を検証することによって、Self-Issued IDトークンを受領したコネクタは、それが確かに自身に宛てて発行されたものであると確認し、内包するアクセストークンを用いて正当なVPを取得できるのです。

　またDCPにおいては、VC/VPやSelf-Issued IDトークンの検証に用いる公開鍵の配信のためにDID（Decentralized Identifier：分散型ID）ドキュメントを使用します。プロトコル上はどのようなDIDシステム、DIDメソッドを使用するかは指定されていませんが、実際のデータスペースでは「did:web」メソッドが採用された事例があります。

　以上、コネクタ間の認証方式であるDAPSとDCPの概要をご説明しました。方式としては、DAPSは典型的な集中型であり、より非集中型に近いDCPの方が分散連邦型アーキテクチャを旨とするデータスペースに親和性が高いといえるかもしれません。実際に、Catena-Xのように、かつてはDAPSを使用していたが、DCPに移行したデータスペースも存在します。一方で、DCPは複雑な方式であり、用意すべきコンポーネントも多いため、安定的なシステムとして設計、構築、運用するのはよりハードルが高いともいえます。

●Next：DAPS方式でコネクタ間認証を実践する