ユースケースに基づくワークフロー

1 概要#

参考資料：DSBA Technical Convergence v2.0 chapter 6

本節では、データサービス提供者が公共プラットフォーム上でサービスを提供し、サービス消費者がそのサービスへのアクセス権を取得できるシナリオを実現しています。さらに、これらの消費者は取得したサービスへのアクセス権をそのユーザー / 顧客に委任することができます。

本節のユースケース：データサービス提供者は、パッケージ配送会社であり、パッケージ配送注文の作成と管理をサポートし、注文の特定の属性を表示および変更するサービスを提供します。消費者は、顧客に商品システムを提供する小売業者であり、データスペースマーケットを通じてパッケージ配送会社のサービスへのアクセス権を取得し、そのアクセス権を顧客に委任します。

参考ユースケースでは、複数の参加者が関与しており、各参加者は独自のインフラストラクチャを持っています。具体的には：

データスペースマーケット：サービス製品を作成し、アクセス権を取得するための公共市場。
信頼のアンカー：シナリオ管理者の役割を担い、各参加者に関する情報【（ユニバーサル識別子である EU 経済体登録および識別番号（Economic Operators Registration and Identification: EORI number）を含む】を保持し、各参加者のアクセス状況を確認できるようにします。
パッケージ配送会社：パッケージ配送注文データの取得および更新サービスを提供します。
ハッピーペット：高級ペット小売業者。また、2 人の人間の役割が関与しています：ハッピーペットの従業員とハッピーペットの顧客。
ノーチーパー：大幅な割引を提供する小売業者。また、2 人の人間の役割が関与しています：ノーチーパーの従業員とノーチーパーの顧客。

全体のアーキテクチャは以下の通りです：
architecture

パッケージ配送会社と店舗システムのサービス提供者は、それぞれ独自のアイデンティティプロバイダー（identity provider: IdP）と認可レジストリ（authorization registry）を持っています。
パッケージ配送会社は、ユーザーがパッケージ配送注文の属性を表示および変更できるポータル（portal）をホストしています。
注文エンティティ（entity）は、コンテキストブローカー（context broker）のインスタンス（instance）に保存されます。
パッケージ配送注文エンティティへの読み書きアクセス（read-and-write access）は、ポリシー実行ポイント（policy enforcement point: PEP proxy）とポリシー決定ポイント（policy decision point: PDP）によって代理され、制御されます。これについては後で各参加者に詳しく説明します。

2 各部分詳解#

2.1 パッケージ配送会社#

対応するアーキテクチャ図は以下の通りです：
delivery

Packet Delivery は、グローバルなパッケージ配送サービスを提供する物流会社です。2 種類のパッケージ配送サービスを提供しています：

標準パッケージ配送サービス
- 顧客は、パッケージの差出人、受取先住所、パッケージの引き取り準備日および時間、受取人の名前と住所を指定できます。
- パッケージ配送会社が顧客のパッケージ配送注文を受け取ると、パッケージの予定到着日を返します。
- 定義された条件（terms and conditions）【例：税関違反なし、有効な住所など】の下で、同一国内で 48 時間以内にパッケージを配達することを約束し、国際輸送は 5-6 日を要します。
- ただし、顧客は具体的な配達日（例：より都合の良い日への延期）を調整したり、選定された配達日の具体的な配達時間を微調整したりすることはできません。
ゴールドパッケージ配送サービス
- 顧客は、標準パッケージ配送のすべての利点を享受しながら、提供された時間帯内で具体的な配達先、配達日、および選定された配達日の具体的な配達時間を微調整することができます。ただし、これらの調整が実行可能であること（例：十分な時間を持ってリクエストし、追加料金が発生しないこと）が前提です。

パッケージ配送会社は、さまざまな小売業者に電子的にサービスを提供し、彼らが REST API を通じてパッケージ配送情報システム（P.Info）にアクセスし、パッケージ配送注文を発行し、注文の位置を追跡し、彼らが認可した顧客に住所、日付、計画された配達時間の調整を実行させることを可能にします。

2.1.1 DELIVERYORDER#

P.Info は、コンテキストブローカー（context broker）によって提供される NGSI-LD インターフェースを介して実現されています。DELIVERYORDER は、以下の属性を持つエンティティです：

issuer
pickingAddress（取引先住所）
pickingDate（取引日）
pickingTime（取引時間）
destinee（受取人）
deliveryAddress（配達先住所）
PDA（planned date of arrival、予定到着日）
PTA（planned time of arrival、予定到着時間）
EDA（expected date of arrival、予想到着日）
ETA（expected time of arrival、予想到着時間）

Packet Delivery は、P.Info システムに対して 2 つの役割を定義しています：P.Info.standard と P.Info.gold であり、これらの役割に基づいて、コンテキストブローカーサービスを介して上記の属性に対して実行できる操作を定義しています。

シナリオの説明を簡素化するために、配達先住所、予定到着日、予定到着時間の 3 つの属性に焦点を当てます。これらの属性は、注文が作成されるときに値が割り当てられ、常に読み取り可能ですが、ユーザーは定義された役割を通じて変更することはできません。これらの 3 つの属性については、注文が作成された後、以下のポリシーが定義された役割に適用されます：
| Path | Verb | Verb |

/ngsild/v1/entities/{entityID}/attrs/{attrName}	GET	PATCH
deliveryAddress	P.Info.standard/gold	P.Info.gold
EDA	P.Info.standard/gold	---
ETA	P.Info.standard/gold	---
PDA	P.Info.standard/gold	P.Info.gold
PTA	P.Info.standard/gold	P.Info.gold

注意：注文は異なるパス（/ngsi-ld/v1/entities/）を使用して POST で作成されます。このようなリクエストを発行するために、Happy Pets と No Cheaper にのみ割り当てられた追加の役割 P.Create が定義されています。

パッケージ配送会社は、潜在的な小売業者や他のタイプの会社に対して 2 つの製品を提供しています：

基本（basic）配送：このサービスを取得する会社が顧客に標準パッケージ配送サービスを提供することを許可します。
高級（premium）配送：このサービスを取得する会社が顧客に標準およびゴールドパッケージ配送サービスを提供することを許可します。

注意すべき点は、Packet Deliveryは小売業者アプリケーション（application）ユーザーのアイデンティティを理解してはならないということです。彼らは、リクエストを受け取ったときに次のことができる必要があります：

a）識別そのリクエストが、彼らのプラットフォーム製品（offering）に関連付けられた小売業者会社からのものであること

b）確認ユーザーが小売業者会社に割り当てられた P.Info アプリケーション内の役割（role、すなわち P.Info.standard または P.Info.gold）

c）確認その役割が、その小売業者会社が割り当てることができる役割であるかどうかを、彼らがプラットフォーム上で取得した製品（offering）を考慮に入れて

これらのステップが完了した後、Packet Delivery は、役割を持つユーザーがリクエストされた操作を実行できるかどうかを確認するだけで済みます。

No Cheaper によって作成されたアプリケーションは、ユーザーに P.Info.gold 役割を割り当てたかどうかにかかわらず、特定の注文の PTA 属性の値を変更することはできません。なぜなら、彼らが取得した標準パッケージ配送サービスでは、これらの値を変更することが許可されていないからです。（No Cheaper は低価格の会社であるため、P.Info.gold 役割の権限は割り当てられていません）。

2.2 データサービス消費者：ハッピーペッツ株式会社#

pets

ハッピーペッツ株式会社（略称：ハッピーペッツ）は、ペット用品を販売する会社です。彼らはマーケットで「ゴールド配送」サービスを取得します。これにより、ハッピーペッツの店舗アプリケーションを通じて顧客に標準およびゴールド配送サービスを提供できるようになります。さらに、社内には、会社が提供する電話ヘルプデスクサービスの管理者や代理人などの特定の従業員がいる可能性があり、彼らは内部アプリケーション（HappyPetsBackOffice）を使用して、特定の注文の配達先、PDA、および PTA を変更することができます。

顧客が HappyPetsStore に登録すると、彼らは「通常」顧客または「主要」顧客（年会費を支払う）として登録されます。「通常」顧客は標準パッケージ配送サービスを受け取り、「主要」顧客はゴールドパッケージ配送サービスを受け取ります。これは、彼らがそれぞれ HappyPetsStore アプリケーション内で P.Info.standard 役割と P.Info.gold 役割を割り当てられることを意味します。

一方、異なる従業員は HappyPetsBackOffice アプリケーション内で異なる役割が割り当てられているため、実店舗（physical shop）で監督者（supervisor）役割を担う従業員や中央ヘルプデスクで働く代理人も P.Info.gold 役割が割り当てられています。

ハッピーペッツの従業員：

プラットフォーム上で高級パッケージ配送製品を取得します。
ハッピーペッツの顧客：
ハッピーペッツストアシステムに登録し、優良顧客役割として割り当てられます
- 簡素化のために、すでにハッピーペッツの顧客が優良顧客として登録されていると仮定します
ストアシステムで注文し、その本質は P.Info システム内でパッケージ配送注文を作成することです
- 簡素化のために、すでにその顧客のために P.Info システム内で注文が作成されていると仮定します
Packet Delivery ポータル（portal）を介して注文の PTA を正常に変更します
- この操作を実行する詳細なプロセスは 4. Detailed Workflow で説明します。

2.3 データサービス消費者：ノーチーパー株式会社#

nocheaper

ノーチーパーは、さまざまな製品を大幅な割引で販売する会社です。彼らはプラットフォーム上で Packet Delivery 会社の基本パッケージ配送製品を取得します。

ノーチーパーの従業員：

プラットフォーム上で基本パッケージ配送製品を取得します
ノーチーパーの顧客：
ノーチーパーの店舗システムに登録し、通常顧客役割として割り当てられます
- 簡素化のために、すでにノーチーパーの顧客が通常顧客として登録されていると仮定します
ストアシステムで注文し、その本質は P.Info システム内でパッケージ配送注文を作成することです
- 簡素化のために、すでにその顧客のために P.Info システム内で注文が作成されていると仮定します
Packet Delivery ポータル（portal）を介して注文の PTA を変更しようとしたときに拒否されます
また、ノーチーパーの従業員がノーチーパー顧客に優良顧客役割を割り当てた場合、そのリクエストも拒否されます

2.4 データマーケットプラットフォーム#

マーケットは、FIWARE BAE(Business Application Ecosystem) componentコンポーネントに基づいて構築されており、FIWARE ビジネスフレームワークとTMForumが提供する一連の API で構成されています。これにより、サービスライフサイクル全体にわたって異なるタイプの資産をマネタイズ（monetization）することが可能になります。製品の作成（offering creation）から請求（charging）、会計（accounting）、および関与する参加者の収益決済（revenue settlement required for billing and payment）まで。
FIWARE
オファー作成時のパッケージ配送注文パラメータ、およびマーケットが取得およびアクティベーション段階で実行する必要な手順の実装は、Charging Backend コンポーネントにインストールされた専用プラグインによって提供されます。

ここでMarketplace UIの専用テーマを見つけることができます。

2.5 信頼のアンカーフレームワーク#

このシステムは、検証可能な証明書（VC）を使用し、参加者は did を介して識別されます。参加者の証明書とアイデンティティを効果的かつ分散的に検証するためには、すべての認証フローに中央集権的なエンティティの仲介を避けるために、ブロックチェーンベースの信頼フレームワークを実装する必要があります。

信頼フレームワークは 2 つの部分で構成されています：

信頼組織リスト：ブロックチェーンに保存された信頼できる組織のアイデンティティリストと、各エンティティに関連する情報。
管理プロセス：信頼できるエンティティを追加、変更、削除するプロセスで、具体的なガバナンスモデルを実現します。

信頼フレームワークの設計は大部分が分散型であり、現実世界の信頼関係を表しています。ここでは、ブロックチェーンに基づく信頼フレームワークの実装方法の 1 つを説明します。

特徴：

分散型信頼システム：エコシステムに関与する法人のアイデンティティは、ブロックチェーンの公共ディレクトリに登録され、インターネットの DNS モデルに非常に似た階層的なスキームに従います。
自主管理子エンティティ：システムにエンティティが登録されると、そのエンティティは完全に自主管理で他のエンティティを子エンティティとして追加できます。
明確、透明、監査可能：任意の参加者は、エコシステムの現在の信頼構造に関する信頼できる情報を取得でき、システムが現在の状態に至るまでのイベントを知ることができます。たとえば、どのエンティティが別のエンティティを登録したか、いつ完了したか、親エンティティが子エンティティにどの属性を割り当てたかなど。
根信頼エンティティ：このシステムは非常に分散型である可能性があります。しかし、中央集権的な要素があります：階層構造の最上部に位置する信頼の根は、エコシステム内でシステムを導く責任を持つ信頼できるエンティティ（またはエンティティ連合）であるべきです。エコシステムの具体的なガバナンスフレームワークに応じて、これは根エンティティの唯一の使命である可能性があり、エコシステムの監視と監督を含む可能性があります。一般的には、これは規制機関、公共行政機関、またはエコシステム内のすべての参加者から完全に信頼される中立的な組織であるべきです。
階層構造：信頼フレームワークは、さまざまなガバナンスニーズに適応するために多層構造をサポートします。

単一のブロックチェーンネットワークのアプローチは以下の図に示されています（このスキームは異なるブロックチェーンネットワークに簡単に拡張でき、私たちはそれらの間に信頼を構築し、1 つのネットワーク内のエンティティが別のネットワーク内のエンティティと信頼できる方法で相互作用できるようにします）。
oneblock

根部：このエンティティは EBSI で信頼できる登録機関（TRA）と呼ばれ、他の文脈では「信頼のアンカー」と呼ばれます。以下の説明では、信頼のアンカーという用語を使用します。その本質的な特徴は、これはエコシステム内で最も信頼されるエンティティ / エンティティであることです。根エンティティは他のいくつかの信頼できるエンティティのアイデンティティを登録する責任を負います。
- たとえば、ある国の複数の地域に大学を管理する権限を持つ教育省は、ブロックチェーン上で各地域の大学を管理する地域機関のアイデンティティを登録できます。図中の domainA, domainN。
- この登録が完了すると、各地域機関は大学などの下位エンティティのアイデンティティを登録し続けることができます。図中の registerA1 など。
- 多層管理。たとえば、大学は非常に大きく、いくつかの一定の自主権を持つ組織単位が地理的に分散している可能性があります。子アイデンティティを作成し、ブロックチェーン内の子ノードとして登録できます。図中の subregisterA2_1。

2.5.1 エコシステムアイデンティティの登録#

新しいアイデンティティの登録：

新しいアイデンティティは、既存のアイデンティティによってのみ登録できます。
唯一の例外は信頼のアンカーです。これは、スマートコントラクトをブロックチェーンにデプロイするエンティティであり、特別な権限を持っています。デプロイ時に、スマートコントラクトは信頼のアンカーのアイデンティティと関連情報を登録することを許可します。
ドメイン名の割り当て：
システム内の各合法的なアイデンティティには、インターネットのドメイン名システムに類似したドメイン名が割り当てられます。新しいアイデンティティが作成されると、名前が割り当てられ、親アイデンティティに基づいて自動的にサブドメイン名が設定されます。
例外：ルートドメイン名（すなわち信頼のアンカー）は名前を持たず、システム内で最上位のアイデンティティです。
- たとえば、図中のエンティティ issuerA1 は完全なドメイン名を持っています：domainA.registerA2.subregisterA2_1.issuerA1。この完全なドメイン名は、そのエンティティを一意に識別でき、システム内での重複や混乱を防ぎます。この例では、「domainA」は最上位のドメイン名であり、信頼のアンカーエンティティによってすでにシステムに追加されている必要があります。
登録制限：エンティティはその親エンティティによってのみ登録でき、信頼フレームワーク内の他のエンティティ（親エンティティの親エンティティを含む）は登録できません。組織は、信頼フレームワーク内で子ノードとして表されるすべての子エンティティに対して責任を負う必要があります。

外部の第三者は、ブロックチェーンの読み取り権限を持つ場合、システムの起動以来の不変の歴史イベントを含む全体の信頼構造を見ることができます。この透明性は、システムの信頼性と安全性を確保するために重要です。

2.5.2 アイデンティティの検証：汎用リゾルバ#

汎用リゾルバの機能：

汎用リゾルバは、任意の参加者がアイデンティティを検証するために使用できる公開 API です。これは、分散型アイデンティティ識別子（DID）を解析し、さまざまな DID メソッドをサポートします。
DID を解析することで、参加者がアイデンティティの真実性を検証できることを保証します。
DID 解析プロセス：
DID 解析は、DID ドキュメントを取得するための重要なステップであり、「読み取り」、「作成」、「更新」、「無効化」の 4 つの主要な操作が含まれます。
解析後、DID URL の解参照も行うことができ、DID URL が表すリソースを取得します。
SIOP（Self-Issued OpenID Provider）プロセスでの適用：
SIOP プロセスでは、DID 解析を行ってエンティティの公開鍵を取得し、その署名を検証して情報交換の安全性を確保します。DID ドキュメント内の公開鍵は、DID 解析を通じて取得されます。
PS：中央集権的なリスクを避けるために、汎用リゾルバを複数のノードで実行するか、信頼できる第三者に依存することをお勧めします。

3 エコシステム内の検証可能な証明書#

本節では、エコシステムで機能に必要なさまざまなタイプの証明書について説明します。

3.1 Packet Delivery の従業員#

Packet Delivery は、従業員に証明書を発行し、彼らがマーケットプレイスにアクセスし、製品を作成または購入できるようにします。
この証明書は、Packet Delivery の従業員が第三者に対して雇用会社（この場合は Packet Delivery）を代表して特定の第三者が提供するサービスを使用する権限を持っていることを証明するために使用されます。言い換えれば、証明書は Packet Delivery がそのアクセス制御権を 1 人以上の従業員に委任するメカニズムとして機能します。
証明書の基本的な特徴：

発行以来、証明書の内容は誰にも改ざんされていません。証明書は発行者である Packet Delivery によってデジタル署名されています。
発行者が Packet Delivery であることを証明します。なぜなら、証明書の署名を検証する公開鍵が信頼フレームワークに登録された Packet Delivery の真のアイデンティティと暗号的に関連付けられているからです。
（オプション）証明書の発行が指定された時点より遅れていないことを証明できます。なぜなら、証明書は発行時にブロックチェーンに登録されているからです（タイムスタンプ）。
- Note1: タイムスタンプの日付は、証明書内の「発行日」フィールドの日付よりも大きくすることができます。たとえば、証明書を作成して署名した後、翌日にタイムスタンプを付けることができます（他の証明書と一緒にバッチ処理を行うため）。重要なのは、過去の証明書を作成することはできないということです。検証者は、証明書の「発行時間」内のフィールドがタイムスタンプよりも遅れていないことを確認する必要があります（少なくとも、時計の同期の違いを考慮するために少し余裕を持つ必要があります）。
- Note2：多くの証明書はタイムスタンプを必要としない場合があり、登録プロセスのオーバーヘッドを回避します。これは、証明書のタイプ、証明書の予想される用途、および想定されるリスクレベルによって完全に異なります。ここで議論されている従業員証明書は、同じリスクレベルを持つタイムスタンプを必要としない証明書の一例です。検証者が要求する唯一のことは、保持者が証明書を使用する際に（例：（ログイン））、証明書が雇用者によって発行されたことを証明できることです（この場合は Packet Delivery）。明らかに、これはタイムスタンプを必要としません。なぜなら、従業員がログインを実行する際に証明書を提供できる場合、それは証明書が以前に発行されている場合にのみ可能だからです。

上記の説明から、証明書を受け取る検証者に対して以下の信頼属性を導き出すことができます：

証明書発行者のアイデンティティに対する信頼の程度は、検証者が信頼フレームワークで実施される登録プロセスに対する信頼の程度に依存します。登録プロセスは、発行者の公開鍵をその真のアイデンティティに関連付けます。
証明書内の声明に対する信頼の程度は、検証者が発行者エンティティに対する信頼の程度に依存します。たとえば、Packet Delivery は、実際の従業員でない人物に従業員証明書を発行することができます。しかし、その場合、検証者は、発行者が誤った事実を述べたことを第三者（たとえば、裁判所）に証明するための強力な反証メカニズムを持っています。
したがって、Packet Delivery は、特定の従業員データ（名前、姓など）を含む従業員証明書を発行でき、検証者はこれらの声明に対して一定の信頼を寄せることができます。

しかし、これは Packet Delivery が証明書（声明）内のデータが真実であることを証明しているだけです。オンラインで証明書を提出する人物が、請求に記載されている人物と同じであるかどうかは示していません。言い換えれば、証明書を検証者に送信する人物は、従業員とは異なる可能性があります。これが、証明書に公的鍵を含める理由の 1 つです（「credentialSubject」オブジェクト内）。

この公的鍵は、従業員のデバイス（PC またはモバイルデバイス）上で証明書発行プロセス中に生成された秘密鍵に対応します。このプロセスは後で詳しく説明しますが、基本的には以下の流れを含みます：

従業員は公開鍵 / 秘密鍵のペアを生成し、認証された暗号化されたチャネル（たとえば、HTTPS）を介して公開鍵を雇用者に送信します。このチャネルは、従業員が企業アプリケーションに接続するために使用する一般的なメカニズムです。
雇用者は、特定の従業員データを含む証明書を生成し、公開鍵を含めます。
雇用者は証明書に署名し、同じ認証されたチャネルを介して従業員に送信します。

以下の例は、発行者 Packet Delivery が証明書のメタデータと視覚化された具体的な内容を発行したものです：

// PacketDeliveryが従業員に発行した証明書で、 
// Marketplaceへのアクセスを提供します。 
{ 
   "@context":[ 
   "https://www.w3.org/2018/credentials/v1", 
   "https://marketplace.fiware.io/2022/credentials/employee/v1" 
   ], 
   "id": "https://pdc.fiware.io/credentials/6e14b8b8-87fa0014fe2a", 
   "type": ["VerifiableCredential", "EmployeeCredential"], 
   "issuer": { 
        "id": "did:elsi:EU.EORI.NLPACKETDEL" 
   }, 
   "issuanceDate": "2022-03-22T14:00:00Z", 
   "validFrom": "2022-03-22T14:00:00Z", 
   "expirationDate": "2023-03-22T14:00:00Z", 
   "credentialSubject": { 
       "id": "did:peer:99ab5bca41bb45b78d242a46f0157b7d", 
       "verificationMethod":[ 
       { 
            "id":"did:peer:99ab5bca41bb45b78d242a46f0157b7d#key1", 
            "type":"JwsVerificationKey2020", 
            "controller": "did:peer:99ab5bca41bb45b78d242a46f0157b7d", 
            "publicKeyJwk": { 
                 "kid":"key1", 
                 "kty":"EC", 
                 "crv":"P-256", 
                 "x":"lJtvoA5_XptBvcfcrvtGCvXd9bLymmfBSSdNJf5mogo", 
                 "y":"fSc4gZX2R3QKKfHvS3m2vGSVSN8Xc04qsquyfEM55Z0" 
            } 
        } 
   ], 
       "roles": [ 
       { 
            "target": "did:elsi:EU.EORI.NLMARKETPLA", 
            "names": ["seller", "buyer"] 
       } 
       ], 
       "name":"Jane Doe", 
       "given_name":"Jane", 
       "family_name":"Doe", 
       "preferred_username":"j.doe", 
       "email": "[email protected]" 
   } 
}

上記の証明書の構造は視覚化すると以下のようになります：
employee

この証明書のタイプは EmployeeCredential であり、マーケットへのアクセスを有効にするために、埋め込まれた役割は buyer、seller、または両方である可能性があります。@context フィールド内の URL はマーケット（https://pdc.fiware.io/2022/credentials/employee/v1）を指し、マーケットは従業員証明書の一般的な要件を定義しています。しかし、エコシステム内の参加者はそれを拡張でき、もちろん彼ら自身の目的に必要な役割や役割名を使用できます。

証明書内の credentialSubject 部分には以下のオブジェクトがあります：

id、DID として指定されています。プライバシーの理由から、これは自然人であるため、W3C Peer DID メソッド仕様に指定された Peer Method が使用されています。このメソッドは、中央の真実の源（central source of truth）に依存せずに使用でき、安価で迅速、拡張可能かつ安全です。これは、ほとんどの人、組織、物事間のプライベートな関係に適しています。
verificationMethod、これは標準の W3C VC オブジェクトで、従業員の DID に関連付けられた公開鍵を指定します。従業員の DID と公開鍵の間のバインディングは、Packet Delivery が証明書を発行する際に完了します。
roles は、1 つ以上の役割仕様を含む配列です。各仕様は、証明書を受け取る潜在的なターゲットエンティティと、そのターゲットエンティティが定義する 1 つ以上の役割名を定義します。
- target は、証明書を受け取るエンティティの DID です。
- names は、ターゲットエンティティが認め、ターゲットエンティティが独自のアクセス制御ポリシーを適用するために使用する役割を含む配列です。例では、マーケットが定義した buyer および seller 役割を使用しています。他のエンティティは、特定の目的のために独自の役割を定義できます。名前は、エコシステム内でターゲット属性に基づいて一意になります。
残りのフィールドは、標準の W3C 可検証証明書データモデルで通常の意味を持ちます。

最上位の「id」フィールドは証明書の識別子であり、必要に応じてその機能を使用して取り消すことができます。「id」フィールドの基本要件は次のとおりです：

使用される範囲内で一意であること
暗号的に安全な乱数生成器に基づいているため、与えられた証明書を取り消そうとする潜在的な攻撃者が「推測」するのが難しいこと。こうした id を使用することで、攻撃者が id を推測する確率を、攻撃者が秘密鍵を推測する確率と同じレベルに低下させることができます。
証明書に含まれるプロファイルとは無関係であること、関連性のリスクを最小限に抑えるため。
UUID バージョン 4 は、これらすべての要件を満たしますが、他のパターンも使用できます。

3.2 ハッピーペッツまたはノーチーパーの従業員証明書#

ハッピーペッツとノーチーパーが従業員に発行する従業員証明書は、実際には上記で説明した Packet Delivery の従業員証明書と同じです。主な違いは、従業員に割り当てられる役割セットと、「役割」声明に指定された役割セットです。

// HappyPetsが従業員に発行した証明書で、PacketDeliveryでの 
// 注文作成へのアクセスを提供します。 
{ 
    "@context":[ 
        "https://www.w3.org/2018/credentials/v1", 
        "https://happypets.fiware.io/2022/credentials/employee/v1" 
    ], 
    "id":"https://happypets.fiware.io/credentials/25159389-8dd17b796ac0", 
    "type": ["VerifiableCredential", "EmployeeCredential"], 
    "issuer": { 
        "id":"did:elsi:EU.EORI.NLHAPPYPETS" 
    }, 
    "issuanceDate": "2022-03-22T14:00:00Z", 
    "validFrom": "2022-03-22T14:00:00Z", 
    "expirationDate": "2023-03-22T14:00:00Z", 
    "credentialSubject": { 
        "id": "did:peer:99ab5bca41bb45b78d242a46f0157b7d", 
        "verificationMethod":[ 
        { 
             "id":"did:peer:99ab5bca41bb45b78d242a46f0157b7d#key1", 
             "type":"JwsVerificationKey2020", 
             "controller":"did:peer:99ab5bca41bb45b78d242a46f0157b7d", 
             "publicKeyJwk": { 
                 "kid":"key1", 
                 "kty":"EC", 
                 "crv":"P-256", 
                 "x":"lJtvoA5_XptBvcfcrvtGCvXd9bLymmfBSSdNJf5mogo", 
                 "y":"fSc4gZX2R3QKKfHvS3m2vGSVSN8Xc04qsquyfEM55Z0" 
             } 
        } 
        ], 
        "roles":[ 
        { 
             "target": "did:elsi:EU.EORI.NLPACKETDEL", 
             "names": ["P.Create"] 
        } 
        ], 
        "name":"Jane Doe", 
        "given_name": "Jane", 
        "family_name": "Doe", 
        "preferred_username": "j.doe", 
        "email": "[email protected]" 
    } 
}

3.3 ハッピーペッツまたはノーチーパーの顧客証明書#

ハッピーペッツは、この証明書を使用して、Packet Delivery が提供するサービスにアクセスすることを希望する顧客に対してアクセス制御を委任します。これらのサービスは、ハッピーペッツが過去に購入したものです。

これは、従業員証明書と同じモデルに従います：

証明書は、ハッピーペッツが以前の顧客登録プロセス（KYC）の一部として、安全かつ認証されたチャネルを通じて顧客に発行する必要があります。
証明書に含まれる役割は、顧客タイプに対応し、役割名はサービス提供者（この場合は Packet Delivery）によって定義され、理解されます。

// HappyPetsが顧客に発行した証明書で、
// PacketDeliveryでのゴールドサービスへのアクセスを提供します。
{ 
    "@context":[ 
        "https://www.w3.org/2018/credentials/v1", 
        "https://happypets.fiware.io/2022/credentials/employee/v1" 
    ], 
    "id":"https://happypets.fiware.io/credentials/25159389-8dd17b796ac0", 
    "type": ["VerifiableCredential", "CustomerCredential"], 
    "issuer": { 
        "id":"did:elsi:EU.EORI.NLHAPPYPETS" 
    },
    "issuanceDate":"2022-03-22T14:00:00Z", 
    "validFrom":"2022-03-22T14:00:00Z", 
    "expirationDate":"2023-03-22T14:00:00Z", 
    "credentialSubject": { 
        "id":"did:peer:99ab5bca41bb45b78d242a46f0157b7d", 
        "verificationMethod":[ 
        { 
            "id":"did:peer:99ab5bca41bb45b78d242a46f0157b7d#key1", 
            "type":"JwsVerificationKey2020", 
            "controller":"did:peer:99ab5bca41bb45b78d242a46f0157b7d", 
            "publicKeyJwk":{ 
                "kid":"key1", 
                "kty":"EC", 
                "crv":"P-256", 
                "x":"lJtvoA5_XptBvcfcrvtGCvXd9bLymmfBSSdNJf5mogo", 
                "y": "fSc4gZX2R3QKKfHvS3m2vGSVSN8Xc04qsquyfEM55Z0" 
            } 
        } 
        ], 
        "roles":[ 
        { 
            "target":"did:elsi:EU.EORI.NLPACKETDEL", 
            "names": ["P.Info.gold"] // または P.Info.standard 
        } 
        ], 
        "name": "Jane Doe", 
        "given_name": "Jane", 
        "family_name": "Doe", 
        "preferred_username": "j.doe", 
        "email": "[email protected]" 
    } 
}

3.4 役割ベースのアクセス制御#

上記の証明書からわかるように、これらには指定された役割の声明が含まれています。役割は証明書の発行者によって定義されるのではなく、証明書を受け取る予定のエンティティが、検証と認可を実行するために定義するものです（この例では Packet Delivery）。

提供者は、特定の名前を持つ役割を定義し、その役割は提供者が実行したいポリシーセット（policy set）にマッピングされます。プラットフォーム上の製品は、特定の役割（または複数の役割）を表します。プラットフォーム上の製品へのアクセス権を取得する際、これらの役割は提供者の認可レジストリに発行され、アクセス権を取得した組織に割り当てられます。さらに、アクセス権を取得した組織は、これらの役割をVCに埋め込むことで、ユーザーに割り当てることができます。

サービスにアクセスする際、提供者の PEP プロキシ（proxy）/PDP コンポーネントは、割り当てられた役割に基づくポリシーセットを取得し、NGSI-LD リクエストに基づいてアクセス認可評価を行います。

本書の範囲には、これらのポリシーを実行するための実際のポリシー言語とエンジン（ODRL、Rego など）を説明することは含まれていません。

3.5 コンポーネントのデプロイ#

第 2 節の各部分に加えて、以下のコンポーネントも必要です：

検証可能データレジストリ（Verifiable Data Registry）：ブロックチェーンネットワークの形式で、エコシステム信頼フレームワークを実現するためのコア技術です。エコシステムに参加するいくつかのエンティティ（必ずしもすべてのエンティティではない）は、信頼フレームワークのバックボーンとして適切なブロックチェーンネットワークを共同で作成および運営するために、ブロックチェーンノードを操作する必要があります。
汎用リゾルバ（Universal Resolver）：汎用リゾルバは、W3C DID Core 1.0および DID 解析仕様に基づいて、さまざまな DID メソッドの分散型識別子（DID）を解析します。
証明書発行および検証コンポーネント（Credential Issuer and Verifier components）：これらのコンポーネントは、通常、既存の OpenID Credential（OIDC）プロセスを実装するコンポーネントの拡張として実現されます。
エンドユーザーウォレット（End-User wallet）：エンドユーザーが使用するウォレットコンポーネントで、受信、保持、および表示された検証可能な証明書を受け取ります。このコンポーネントは、ネイティブモバイルアプリケーション、PWA アプリケーション、またはエコシステム内の 1 つまたは複数の高度に信頼できるエンティティによってホストされる Web アプリケーションとして実装できます。

4 詳細なワークフロー#

検証可能な証明書を持つ SIOP フローを使用する際、マーケットプレイスは、必要なすべての情報が従業員が提供した検証可能な証明書と分散型検証可能レジストリ（この場合はブロックチェーンネットワークを使用）にあるため、エコシステム内の他のエンティティに問い合わせる必要がないことが観察されます。

言い換えれば、ワークフローは実際にはピアツーピアであり、集中型の IdP を問い合わせる必要がなく、効率的でスケーラブル、プライベートで弾力性のあるフレームワークを提供します。

4.1 注文作成#

アーキテクチャ概要では、さまざまな相互作用が示されています：
create_architecture

4.1.1 ユーザーアクセス#

1_3

1.Packet Delivery の従業員は、マーケットプレイスポータル（BAE Logic Proxy によって提供される）にアクセスしてログインします。

2.Marketplace ポータルは、ログインのために必要なアイデンティティプロバイダーを選択するためのアイデンティティプロバイダーのリストを表示します。その中の 1 つのログインオプションは「検証可能な証明書でログイン」です。Packet Delivery Co の従業員は「検証可能な証明書」ログイン方法を選択し、これによりマーケットプレイスポータルは、マーケットプレイスサーバーの / 認証リクエストエンドポイントの URL を含む QR を生成します。

3. 従業員はデジタルウォレットのスキャン機能を有効にして QR をスキャンし、携帯電話が / 認証リクエストエンドポイントを呼び出します。スキャンの目的は、認証フローを開始し、ログインユーザーが実際にその証明書を持っている従業員であることを確認することです。

4.1.2 認証フローの開始#

456

4. ウォレットは、QR に含まれる URL に自動的にアクセスして認証フローを開始します。このステップでは、ウォレットが指定された認証インターフェースに POST リクエストを送信し、サーバーに検証情報を要求します。

5.SIOP（Self-Issued OpenID Provider）は、オープンな認証プロトコルです。これにより、標準的な SIOP のプロセスが開始されます。
マーケットプレイスは依存者（OpenID Connect 用語での RP）の役割を果たし、従業員のモバイルデバイスは Self-Issued IDP として機能します。このステップでは、マーケットプレイスが SIOP 認証リクエストを作成します。自己発行された OP は、ネイティブアプリケーションまたはプログレッシブ Web アプリケーション（PWA）として実行される可能性があるため、RP は OP と直接通信するためのネットワークアドレス可能なエンドポイントを持っていない場合があります。私たちは、OpenID Connect の暗黙的なフローを利用して、これらのネイティブで実行される OP と通信する必要があります。詳細は [https://openid.net/specs/openid-connect-self-issued-v2-1_0.html] を参照してください。

6. 認証リクエストは SIOP によって従業員のウォレットに返されます。SIOP フローは、新しい応答モード post を使用します。この post は、SIOP が認証プロセスの結果を特定のエンドポイントに渡すように要求します。パラメータ response_mode はこの値を運ぶために使用されます。SIOP が認証結果を提供するエンドポイントは、標準パラメータ redirect_uri で定義されています。

4.1.3 DID の解析#

7. このステップでは、従業員は認証リクエストのclient_idパラメータで受け取ったマーケットプレイスの DID を解析して、マーケットプレイスがエコシステムの信頼できるエンティティであることを確認します。

DID を解析するために、ウォレットは /api/did/v1/identifiers/did:elsi.EORI.NLMARKETPLA のいくつかの信頼できるサーバーエンドポイントの 1 つに GET リクエストを送信します。

汎用リゾルバには、必要に応じて複数のノードがあるブロックチェーンノードが含まれます。そのタスクは、ブロックチェーンを使用して DID を解析し、関連する DID ドキュメントを返すことです。
DID ドキュメント（W3C による）は、DID エンティティの所有者に関する関連情報を含みます。これには、エンティティのデジタル署名を検証するための公開鍵が含まれます。また、エンティティがデータスペースエコシステム内での状態も含まれます。これは拡張可能であり、ユースケースに関連する任意の公共情報を含むことができます。汎用リゾルバサーバーは、顧客の信頼できるエンティティによって操作される必要があります。これらの信頼できるエンティティのうちの少なくとも 1 つは、従業員のウォレットに構成されている必要があります。

8. ウォレットはマーケットプレイスの DID ドキュメントを取得できます。ドキュメントは、マーケットの詳細を提供し、マーケットのデジタル署名公開鍵を含み、ウォレットが合法的なマーケットエンティティと対話していることを保証します。これには、エンティティに関する信頼できる情報が含まれ、マーケットがトークンにデジタル署名するために使用する秘密鍵に関連付けられた公開鍵が含まれます。たとえば：

{
    "payload": {
         "@context": [
            "https://www.w3.org/ns/did/v1",
            "https://w3id.org/security/v1"
        ],
        "id": "did:elsi:EU.EORI.NLMARKETPLA",
        "verificationMethod": [
        {
            "id": "did:elsi:EU.EORI.NLMARKETPLA#key-verification",
            "type": "JwsVerificationKey2020",
            "controller": "did:elsi:EU.EORI.NLMARKETPLA",
            "publicKeyJwk": {
            "kid": "key-verification",
            "kty": "EC",
            "crv": "secp256k1",
            "x": "V8XptJkb5wplYkExcTF4nkyYVp7t5H5d5C4UPqCCM9c",
            "y": "kn3nSPxIIvd9iaG0N4v14ceuo8E4PcLXhhGeDzCE7VM"
            }
        }
    ],
    "service": [
    {
        "id": "did:elsi:EU.EORI.NLMARKETPLA#info",
        "type": "EntityCommercialInfo",
        "serviceEndpoint": "https://marketplace.fiware.io/info",
        "name": "Packet Delivery co."
    },
    {
        "id": "did:elsi:EU.EORI.NLMARKETPLA#sms",
        "type": "SecureMessagingService",
        "serviceEndpoint": "https://marketplace.fiware.io/api/sms"
    }
    ],
    "anchors": [
    {
        "id": "redt.alastria",
        "resolution": "UniversalResolver",
        "domain": "marketplace.dataspace",
        "ethereumAddress": "0xbcB9b29eeb28f36fd84f1CfF98C3F1887D831d78"
    }
    ],
    "created": "2021-11-14T13:02:37Z",
    "updated": "2021-11-14T13:02:37Z"
    }
}

4.1.4 認証リクエストの検証#

9. ウォレットは受け取った認証リクエストを検証します。リクエストのデジタル署名を確認し、その署名が合法的なマーケットエンティティによって生成されたことを確認します。重要性：このステップは、ウォレットが本物のマーケットと対話していることを保証し、中間者攻撃や他の形式のネットワーク詐欺から保護します。
DID ドキュメントは、verificationMethod配列内に 1 つ以上の公開鍵を含みます。キーは、配列内の各要素のidフィールドによって識別されます。従業員のウォレットは、認証リクエスト（JWT の保護されたヘッダー内）で受け取ったkidフィールドを使用して、対応する公開鍵を選択し、JWT の署名を検証します。また、DID ドキュメント（「DID:elsi.EORI.NLMARKETPLA」）内の最上位のidフィールドが認証リクエストのclient_idパラメータと等しいかどうかを確認します。

4.1.5 認証応答の作成#

101112

10. 認証リクエストが合法であると検証された場合、ウォレットは認証応答を生成し、ステップ 5 でマーケットプレイスが指定した redirect_uri に発行します。この応答には、従業員のアイデンティティと権限を示す検証可能な証明書（VC）が含まれます。

重要なポイント：この検証可能な証明書は、パッケージ配送会社によって発行され、従業員が実際に会社の一員であり、相応のアクセス権を持っていることを証明します。

11. ウォレットは、認証応答をマーケットの SIOP セッションインターフェースに送信します。マーケットは、受信した応答に基づいて、従業員にアクセス権を付与するかどうかを決定します。

SIOP は、「application/x-www-form-urlencoded」エンコーディングの HTTP POST リクエストを使用して、認証リクエストパラメータで渡された redirect_uri エンドポイントに認証応答を送信します。応答には ID トークンと VP（検証可能な表現）トークンが含まれます。これは OpenID で定義された検証可能な表現に従います。

POST /siop_sessions HTTP/1.1
Host: marketplace.fiware.io
Content-Type: application/x-www-form-urlencoded
id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
&vp_token=...
&state=af0ifjsldkj

デコードされた id_token：

{
 "iss": "https://self-issued.me/v2",
 "aud": "did:elsi:EU.EORI.NLMARKETPLA",
 "iat": 1615910538,
 "exp": 1615911138,
 "sub": "did:peer:99ab5bca41bb45b78d242a46f0157b7d",
 "auth_time": 1615910535,
 "nonce": "n-0S6_WzA2Mj"
}

ここで、"sub": "did:peer:99ab5bca41bb45b78d242a46f0157b7d" はユーザー自身の DID であり、プライバシーの観点から、ブロックチェーンや任意の集中ストレージに登録されていません。これは、検証可能な証明書に含まれる DID と同じである必要があります。検証可能な証明書は、従業員が入社時にパッケージ配送会社によって発行され、認証応答に伝播されます。
vp_token には、検証可能な表現が含まれ、2 つの形式（jwt_vp（JWT エンコード）または ldp_vp（JSON-LD エンコード））を持つことができます。以下の例は、JWT エンコードを使用しています：

{
 "format": "jwt_vp",
 "presentation":
 "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImRpZDpleGFtcGxlOmFiZmUxM2Y3MTIxMjA0
 MzFjMjc2ZTEyZWNhYiNrZXlzLTEifQ.eyJzdWIiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxY
 zI3NmUxMmVjMjEiLCJqdGkiOiJodHRwOi8vZXhhbXBsZS5lZHUvY3JlZGVudGlhbHMvMzczMiIsImlzc
 yI6Imh0dHBzOi8vZXhhbXBsZS5jb20va2V5cy9mb28uandrIiwibmJmIjoxNTQxNDkzNzI0LCJpYXQiO
 jE1NDE0OTM3MjQsImV4cCI6MTU3MzAyOTcyMywibm9uY2UiOiI2NjAhNjM0NUZTZXIiLCJ2YyI6eyJAY
 29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vd
 3d3LnczLm9yZy8yMDE4L2NyZWRlbnRpYWxzL2V4YW1wbGVzL3YxIl0sInR5cGUiOlsiVmVyaWZpYWJsZ
 UNyZWRlbnRpYWwiLCJVbml2ZXJzaXR5RGVncmVlQ3JlZGVudGlhbCJdLCJjcmVkZW50aWFsU3ViamVjd
 CI6eyJkZWdyZWUiOnsidHlwZSI6IkJhY2hlbG9yRGVncmVlIiwibmFtZSI6IjxzcGFuIGxhbmc9J2ZyL
 UNBJz5CYWNjYWxhdXLDqWF0IGVuIG11c2lxdWVzIG51bcOpcmlxdWVzPC9zcGFuPiJ9fX19.KLJo5GAy
 BND3LDTn9H7FQokEsUEi8jKwXhGvoN3JtRa51xrNDgXDb0cq1UTYB-rK4Ft9YVmR1NI_ZOF8oGc_7wAp
 8PHbF2HaWodQIoOBxxT-4WNqAxft7ET6lkH-4S6Ux3rSGAmczMohEEf8eCeN-jC8WekdPl6zKZQj0YPB
 1rx6X0-xlFBs7cl6Wt8rfBP_tZ9YgVWrQmUWypSioc0MUyiphmyEbLZagTyPlUyflGlEdqrZAv6eSe6R
 txJy6M1-lD7a5HTzanYTWBPAUHDZGyGKXdJw-W_x0IWChBzI8t3kpG253fg6V3tPgHeKXE94fz_QpYfg
 --7kLsyBAfQGbg"
}

デコード後は：

{
    "@context": ["https://www.w3.org/2018/credentials/v1"],
    "type": ["VerifiablePresentation"],
    "verifiableCredential": [
    {
        "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://marketplace.fiware.io/2022/credentials/employee/v1"
    ],
    "id": "https://pdc.fiware.io/credentials/6e14b8b8-87fa0014fe2a",
    "type": ["VerifiableCredential", "EmployeeCredential"],
    "issuer": {
    "id": "did:elsi:EU.EORI.NLPACKETDEL"
    },
    "issuanceDate": "2022-03-22T14:00:00Z",
    "validFrom": "2022-03-22T14:00:00Z",
    "expirationDate": "2023-03-22T14:00:00Z",
    "credentialSubject": {
    "id": "did:peer:99ab5bca41bb45b78d242a46f0157b7d",
    "verificationMethod": [
        {
        "id": "did:peer:99ab5bca41bb45b78d242a46f0157b7d#key1",
        "type": "JwsVerificationKey2020",
        "controller": "did:peer:99ab5bca41bb45b78d242a46f0157b7d",
        "publicKeyJwk": {
        "kid": "key1",
        "kty": "EC",
        "crv": "P-256",
        "x": "lJtvoA5_XptBvcfcrvtGCvXd9bLymmfBSSdNJf5mogo",
        "y": "fSc4gZX2R3QKKfHvS3m2vGSVSN8Xc04qsquyfEM55Z0"
        }
    }
 ],
    "roles": [
    {
    "target": "did:elsi:EU.EORI.NLMARKETPLA",
    "names": ["seller", "buyer"]
    }
 ],
    "name": "Jane Doe",
    "given_name": "Jane",
    "family_name": "Doe",
    "preferred_username": "j.doe",
    "email": "[email protected]"
     }
     }
 ]
}

12. マーケットは、汎用リゾルバ（Universal Resolver）を介してパッケージ配送会社の DID ドキュメントを解析し、その会社のアイデンティティと公開鍵情報を検証します。このステップは、マーケットが合法的な会社エンティティと対話していることを保証します。この DID は、検証可能なプレゼンテーション内で受け取った検証可能な証明書内にあります。この DID は、上記の「verifiableCredential」構造の「issuer」フィールドで見つけることができます。解析は、汎用リゾルバに GET リクエストを送信することで実行されます：/api/did/v1/identifiers/did:elsi.EORI.NLPACKETDEL。マーケットは、異なるエンティティによって操作される汎用リゾルバを使用できますが、ブロックチェーンネットワークに直接接続された独自のサーバーを使用する場合と比較して、信頼レベルが低下します。

4.1.6 認証応答の検証#

1314

13. マーケットは、パッケージ配送会社の DID ドキュメントを取得し、その中には会社の公開鍵や、後続の検証プロセスに必要な他の情報が含まれています。

会社の公開鍵は、会社が従業員に最近示した検証可能な証明書にデジタル署名するために使用した秘密鍵に関連付けられています。これにより、認証フローの一部として、公開鍵と DID ドキュメントを使用して、検証可能な証明書の署名を検証し、パッケージ配送会社がエコシステム内の信頼できるエンティティであり、アクティブであることを確認できます。

14. マーケットは、パッケージ配送会社の公開鍵を使用して、認証応答のデジタル署名を検証し、認証応答が本当に合法的な会社によって生成されたことを確認します。

上記の内容は、検証可能な証明書を検証するためだけに使用されます。さらに、マーケットは、検証可能な証明書を含む検証可能なプレゼンテーションが従業員によって送信されたものであることを確認できます。これを行うために、マーケットは「credentialSubject」構造の「verificationMethod」で従業員の公開鍵を使用します。Packet Delivery Co が従業員