基於用例的工作流程

1 概要#

參考資料：DSBA 技術融合 v2.0 第六章

本節實現了一個場景，其中數據服務提供者在公共平台上提供服務，以便服務消費方能夠獲取該服務的訪問權限。此外，這些消費方可以將獲取的服務訪問權限委託給其用戶 / 客戶。

本節用例：數據服務提供者是一家包裹遞送公司，支持創建和管理包裹遞送訂單，並且提供查看和修改訂單的特定屬性的服務；消費方是向其客戶提供商品系統的零售商，他們可以通過數據空間市場獲得對包裹遞送公司服務的訪問權，並將訪問權委託給客戶。

在參考用例中，涉及到多個參與方，每個參與方都有自己的基礎設施。具體包括：

數據空間市場：用於創建服務產品和獲取訪問權的公共市場。
信任錨：擔任方案管理員角色，持有有關每個參與方的信息【（包括通用唯一識別碼，稱為歐盟經濟體註冊和識別號（Economic Operators Registration and Identification: EORI number）】，並允許它檢查每個參與方的準入情況。
包裹遞送公司：提供檢索和更新包裹交付訂單數據的服務。
Happy pets: 高級寵物零售商。此外，還涉及兩個人類角色：Happy Pets 員工和 Happy Pets 客戶。
No Cheaper：提供大幅折扣的零售商。此外，還涉及兩個人類角色：No Cheaper 員工和 No Cheaper 客戶。

總體架構如下：
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 是一家提供全球包裹遞送服務的物流公司。它提供兩種包裹遞送服務：

標準包裹遞送服務
- 客戶可以指定包裹的發件人、收件地址、包裹準備取件的日期和時間，以及包裹的收件人姓名和地址。
- 當包裹遞送公司收到客戶的包裹遞送訂單時，它會返回包裹計劃送達的目標日期。
- 在定義的條款和條件下（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 系統定義了兩個角色：P.Info.standard 和 P.Info.gold，並根據這些角色定義了通過上下文代理服務可以對上述屬性執行的操作。

為了簡化場景描述，我們將關注送達地址、計劃送達日期和計劃送達時間這三個屬性，因為我們可以假設其他屬性在訂單創建時將被分配值，始終可讀，但用戶無法通過已定義的角色進行更改。對於這三個屬性，一旦訂單創建後，以下策略適用於已定義的角色：
| 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 創建。為了發出此類請求，定義了一個額外的角色 P.Create，該角色僅分配給 Happy Pets 和 No Cheaper。

包裹遞送公司針對潛在零售商和其他類型公司發布兩種產品：

基礎（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 數據服務消費者：HappyPets Inc.#

pets

HappyPets Inc.（簡稱 HappyPets）是一家銷售寵物用品的公司。它將在市場上獲得 “高級遞送” 服務。這將使其能夠通過 HappyPets 的商店應用程序向客戶提供標準和金牌配送服務。此外，公司內部可能有某些員工，即公司提供的電話幫助台服務的主管和代理，他們可能會使用內部應用程序（HappyPetsBackOffice）更改給定訂單的送貨地址、PDA 和 PTA。

當客戶在 HappyPetsStore 註冊時，它可以作為 “普通” 客戶或 “主要” 客戶（支付年費）。“普通” 客戶將獲得標準包裹遞送服務，而 “優質” 客戶將獲得金牌包裹遞送服務。這意味著他們分別在 HappyPetsStore 應用程序中被分配了 P.Info.standard 角色和 P.Info.gold 角色。

另一方面，不同的員工在 HappyPetsBackOffice 應用程序中被分配了不同的角色，因此在實體店（physical shop）擔任監督員（supervisor）角色的員工或在中央幫助台工作的代理也被分配了 P.Info.gold 角色。

Happy Pets 員工：

在平台上獲取高級包裹遞送產品。
Happy Pets 客戶：
在 Happy Pets 商店系統中註冊並被分配為優質客戶角色
- 為簡化，假設已經有一個 Happy Pets 客戶已經註冊為優質客戶
在商店系統下單，其本質是在 P.Info 系統中創建了一個包裹遞送訂單
- 為簡化，假設已經為該客戶在 P.Info 系統中創建了一個訂單
成功通過 Packet Delivery 門戶（portal）更改訂單的 PTA
- 我們將在 4. Detailed Workflow 描述執行此操作的詳細流程。

2.3 數據服務消費者：No Cheaper Ltd.#

nocheaper

No Cheaper 是一家以較大折扣銷售各種產品的公司。它將在平台上獲取 Packet Delivery 公司的基礎包裹遞送產品。

No Cheaper 員工：

在平台上獲取基礎包裹遞送產品
No Cheaper 客戶：
在 No Cheaper 商店系統中註冊並被分配為普通客戶角色
- 為簡化，假設已經有一個 No Cheaper 客戶已經註冊為普通客戶
在商店系統下單，其本質是在 P.Info 系統中創建了一個包裹遞送訂單
- 為簡化，假設已經為該客戶在 P.Info 系統中創建了一個訂單
當嘗試通過 Packet Delivery 門戶（portal）更改訂單的 PTA 時，被拒絕
還可以展示，當 No Cheaper 員工在其自己的身份提供者系統中為 No Cheaper 客戶分配優質客戶角色時，該請求也將被拒絕

2.4 數據市場平台#

市場是基於FIWARE BAE(Business Application Ecosystem) component
組件構建的，該組件由 FIWARE 企業框架和TMForum提供的一組 API 組成。它允許在整個服務生命周期（life cycle）內對不同類型的資產進行貨幣化（monetization），從創建產品（offering creation）到收費（charging）、記帳（accounting）和涉及參與方的收入結算（revenue settlement required for billing and payment）。
FIWARE
創建 offer 時的包裹遞送訂單參數，以及市場在獲取和激活階段執行的必要步驟的實現，都由安裝在 Charging Backend 組件中的專用插件提供。

您可以在這裡找到Marketplace UI的專用主題。

2.5 信任錨框架#

該系統使用可驗證憑證 (VC)，參與者通過 did 進行識別。為了對參與者的憑據和身份進行有效和分散的驗證，必須實施基於區塊鏈的信任框架，以避免在所有身份驗證流中進行中央實體中介。

信任框架由兩部分組成：

信任組織列表：存儲在區塊鏈中的受信任組織的身份列表，以及每個實體的相關信息。
管理流程：添加、修改和刪除可信實體的流程，實現具體的治理模型。

信任框架的設計很大程度上是去中心化的，代表了現實世界中的信任關係。這裡我們描述一種可能的實現方法一個基於區塊鏈的信任框架。

特點：

去中心化的信任系統：生態系統中中涉及的法人的身份註冊在區塊鏈中的公共目錄，遵循與互聯網中的 DNS 模式非常相似的分層方案。
自主管理子實體：一旦在系統中註冊了一個實體，他就可以完全自主的添加作為子實體管理的其他實體。
明確、透明、可審計：任何參與者都可以獲得關於生態系統當前信任結構的可信信息，以及導致系統處於當前狀態的事件。例如，哪個實體註冊了另一個實體，什麼時候完成，父實體給子實體分配了什麼屬性。
根信任實體：這個系統可以非常去中心化。然而，有一個集中的元素：位於層次結構頂部的信任根應該是生態系統中負責引導系統的受信任實體（或實體聯盟）。根據生態系統的具體治理框架，這可能是根實體的唯一使命，可能包括對生態系統的監測和監督。一般來說，它應該是一個監管機構、公共行政部門或一個中立的組織，被生態系統中所有參與者完全信任。
層級結構：信任框架支持多層級結構，以適應不同的治理需求。

單個區塊鏈網絡的方法如下圖所示（該方案很容易擴展到不同的區塊鏈網絡，我們希望在它們之間建立信任，以便一個網絡中的實體可以以可信的方式與另一個網絡中的實體進行交互）。
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 文檔的關鍵步驟，涉及 “讀取”、“創建”、“更新” 和 “註銷” 四個主要操作。
解析後，還可以進行 DID URL 解引用，即獲取 DID URL 代表的資源。
在 SIOP（Self-Issued OpenID Provider）流程中的應用：
在 SIOP 流程中，進行 DID 解析用於獲取實體的公鑰，並驗證其簽名，以確保信息交換的安全性。DID 文檔中的公鑰是通過 DID 解析獲得的。
PS：為避免中心化風險，建議在多個節點上運行通用解析器，或者依賴可信的第三方。

3 生態系統中的可驗證憑據#

在本節中，我們將描述生態系統中功能所需的不同類型的憑證。

3.1 Packet Delivery 員工#

Packet Delivery 向它的一些員工發放憑據，這樣他們就可以訪問 Marketplace，創建產品或購買產品。
該憑據由 Packet Delivery 的員工用於向第三方證明其有權代表雇佣公司（本例中為 Packet Delivery）使用某些第三方提供的服務。換句話說，憑據用作 Packet Delivery 將其訪問控制權利委託（delegate）給一個或多個員工的機制。
證書的基本特徵：

自發行以來，無人篡改過證書的內容。因為證書是由頒發者 Packet Delivery 進行數字簽名的。
證明發行者是 Packet Delivery，因為驗證憑證簽名的公鑰與在信任框架中註冊的 Packet Delivery 的真實身份以加密方式相關聯。
（可選）它可以證明憑證的發布不遲於給定時間，因為憑證在發布時已在區塊鏈中註冊（時間戳）。
- Note1: 時間戳的日期可以大於證書內包含的 “簽發日期” 字段中的日期。例如，一次創建並簽名憑據，但在第二天打上時間戳（可能是為了與其他憑據一起批處理操作）。關鍵是，沒有人可以創建過去的憑證。驗證者必須檢查憑據 “簽發時間” 內的字段不晚於時間戳（至少要留有一點餘地，以考慮時鐘同步差異）。
- Note2：許多憑證可能不需要時間戳，從而避免了註冊過程的開銷。這完全取決於憑證的類型、憑證的預期用途和假定的風險級別。這裡討論的員工憑證是不需要具有相同風險級別的時間戳的憑證的一個示例。驗證者要求的唯一一件事是，持有者可以證明在使用憑證的時候（例如：（登錄）），憑證是由雇主頒發的（在我們的例子中是 Packet Delivery）。顯然，這並不需要時間戳，因為如果員工可以在執行登錄時提供憑據，那麼只有在憑據以前頒發過的情況下，她才能這樣做。

從以上描述中，我們可以為接收憑據的驗證者得出以下信任屬性：

對憑據發行者身份的信任程度取決於驗證者對信任框架中實施的註冊過程的信任程度。註冊過程將發行者的公鑰與其真實身份關聯起來。
對憑據內聲明的信任程度取決於驗證者對發行者實體的信任程度。例如，Packet Delivery 可以向並非真正員工的人士簽發員工憑據。然而，如果發生這種情況，驗證者有一個強有力的不可否認的機制來向第三方（例如法院）證明發行者陳述了錯誤的事實。
由此可見，Packet Delivery 可以簽發包含某些員工數據（姓名、姓氏等）的員工憑據，並且驗證者可以對這些聲明給予一定程度的信任。

但這只是證明了 Packet Delivery 證明憑據（稱為聲明）中的數據是真實的。它沒有說明在線提交憑據的人是否與索賠中提到的人相同。換句話說，將員工憑據發送給驗證者的人可能與員工不同。這就是憑據包含公鑰作為與員工關聯的聲明之一的原因（在 “credentialSubject” 對象中）。

該公鑰對應於在員工設備（PC 或移動設備）上憑據簽發過程中生成的私鑰。該過程稍後將詳細說明，但基本上包含以下流程：

員工生成一對公鑰 / 私鑰，並通過經過身份驗證和加密的通道（例如，HTTPS）將公鑰發送給雇主。該通道可以是員工用於連接企業應用程序的常用機制。
雇主生成包含某些員工數據的憑據並包括公鑰。
雇主簽署憑據並通過同一經過身份驗證的通道將其發送給員工。

下面這個例子是由發行者 Packet Delivery 頒發憑據的元數據和可視化後的具體內容：

// Credential issued by PacketDelivery to its employees, providing access to 
// Marketplace, either to create offerings or to purchase offerings. 
{ 
   "@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 是一個包含一個或多個角色規範的數組。每個規範定義一個將接收憑據的潛在目標實體，以及該目標實體定義的一個或多個角色名稱。
- target 是將接收憑據的實體的 DID。
- names 是一個包含一個或多個角色的數組，這些角色是目標實體認可的，並將由目標實體用於應用其自己的訪問控制策略。在示例中，我們使用了市場定義的 buyer 和 seller 角色。其他實體可以為其特定目的定義自己的角色。名稱在生態系統中由於目標屬性而變得唯一。
憑據中的其餘字段在標準 W3C 可驗證憑據數據模型中具有通常的含義。

頂層的 “id” 字段是憑據的標識，如果需要該功能，可將其用於撤銷。“ id ” 字段的基本要求是:

它在將要使用的範圍內是唯一的
它基於加密安全的隨機數生成器，因此很難被可能試圖撤銷給定憑據的潛在攻擊者 “猜測”。使用這樣的 id 可以將攻擊者猜測 id 的概率降低到與攻擊者猜測私鑰相同的水平，
它與證書中包含的個人資料沒有任何關係，以盡量減少相關性的風險。
UUID 版本 4 符合所有這些要求，但也可以使用其他模式。

3.2 Happy Pets 或 No Cheaper 員工憑據#

Happy Pets 和 No cheap 公司發給員工的員工證書實際上與上文所述的 Packet Delivery 公司的員工證書相同。主要區別在於分配給員工的角色集和在 “角色” 聲明中指定的角色集。

// Credential issued by HappyPets to its employees, providing access 
// to order creation in 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 Happy Pets 或 No Cheaper 顧客憑據#

Happy Pets 使用此憑據將訪問控制委託給希望訪問由 Packet Delivery 提供的服務的客戶，這些服務是 Happy Pets 過去購買的。

它遵循與員工憑據相同的模型：

憑據應由 Happy Pets 通過作為先前客戶註冊過程（KYC）一部分的安全和認證渠道向客戶發行。
憑據中包含的角色對應於客戶類型，角色名稱由服務提供者（在本例中為 Packet Delivery）定義和理解。

// Credential issued by HappyPets to a customer,
// providing access to Gold services at 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"] // Or P.Info.standard 
        } 
        ], 
        "name": "Jane Doe", 
        "given_name": "Jane", 
        "family_name": "Doe", 
        "preferred_username": "j.doe", 
        "email": "[email protected]" 
    } 
}

3.4 基於角色的訪問控制#

從上面的憑據中可以看到，它們包含指定角色的聲明。角色不是由憑據的頒發者定義的，而是由將要接收憑據並執行身份驗證和授權的提供者（即：依賴方）定義的，在本例子中，是 Packet Delivery。

提供者定義了一個具有特定名稱的角色，該角色映射到表示提供者希望執行（enforce）的某個策略集合（policy set）。平台上的一個產品就代表了某個角色（或多個角色）。在獲得對平台上產品的訪問權限時，這些角色會在提供者的授權註冊表中簽發給獲得訪問權限的組織。此外，獲得訪問權限的組織可以通過將這些角色嵌入到向其用戶簽發的VC中，將這些角色分配給他們的用戶。

在訪問服務時，由提供者的 PEP 代理（proxy）/PDP 組件獲取屬於分配角色的基於屬性的策略集合，並根據 NGSI-LD 請求進行訪問授權評估。

本文件的範圍不包括描述執行這些策略的實際策略語言和引擎（如 ODRL、Rego 等）。

3.5 組件部署#

除了第二節的各部分外，以下組件也是必須的：

可驗證數據註冊表 (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 應用程序，甚至是由生態系統中一個或多個高度可信賴的實體托管的 Web 應用程序。

4 詳細工作流程#

當使用帶有可驗證憑據的 SIOP 流時，可以觀察到 Marketplace 不需要查詢生態系統中的任何其他實體來驗證憑據，因為所需的所有信息都在員工提供的可驗證憑據和分散可驗證註冊表中（在我們的案例中使用區塊鏈網絡實現），通過通用解析器訪問。

也就是說，工作流程實際上是點對點的，不需要查詢集中式的 IdP，從而提供了一個高效、可擴展、私有和彈性的框架。

4.1 訂單創建#

在架構概述中展示了不同的交互：
create_architecture

4.1.1 用戶訪問#

1_3

1.Packet Delivery 員工訪問 Marketplace 門戶（由 BAE Logic Proxy 提供），以便登錄。

2.Marketplace 門戶顯示一個身份提供者列表，用於選擇所需的身份提供者進行登錄。其中一個登錄選項是 “使用可驗證憑據登錄”。Packet Delivery Co 員工選擇 “可驗證憑據” 登錄方法，這會導致 Marketplace 門戶生成一個 QR，其中包含 Marketplace 服務器的 / 身份驗證請求端點的 URL。

3. 員工啟用數字錢包中的掃描功能掃描 QR，手機調用 / 身份驗證請求端點。掃描的目的是啟動身份驗證流程，確保登錄用戶確實是擁有該憑證的員工。

4.1.2 啟動身份驗證流程#

456

4. 錢包會自動訪問 QR 包含的 URL 來啟動身份驗證流程。此步驟中，錢包發送一個 POST 請求到指定的身份驗證接口，向服務器請求驗證信息。

5.SIOP（Self-Issued OpenID Provider）是一種開放的身份驗證協議。這將啟動一個標準的 SIOP 的流程。
其中市場扮演依賴方（OpenID Connect 術語中的 RP）的角色，員工的移動設備充當 Self-Issued IDP。在此步驟中，Marketplace 創建 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參數中接收到的 Marketplace 的 DID 來驗證 Marketplace 是屬於生態系統的受信任實體。

為了解析 DID，錢包發送一個 GET 請求到 /api/did/v1/identifiers/did:elsi.EORI.NLMARKETPLA 可以實現通用解析器功能的幾個可信服務器端點之一。

通用解析器包括一個區塊鏈節點，根據需要可以有多個節點。它的任務是使用區塊鏈解析 DID 並返回相關的 DID 文檔。
DID 文檔（根據 W3C）包含關於 DID 實體所有者的相關信息。它包含其公鑰，用於驗證實體的數字簽名。它還包含實體在數據空間生態系統中的狀態。它是可擴展的，並且可以包含與用例相關的任何公共信息。通用解析器服務器必須由客戶的可信實體操作。可以有由不同實體操作的任意數量的節點。必須在員工的錢包中配置這些可信實體中的至少一個。

8. 錢包可以獲得 Marketplace 的 DID 文檔。文檔會提供市場的詳細信息，包括市場的數字簽名公鑰，確保錢包與合法的市場實體進行交互。其中包含有關實體的可信信息，包含有關實體的可信信息，以及 Marketplace 用於對 tokens 進行數字簽名的私鑰關聯的公鑰。例如：

{
    "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數組中包含一個或多個公鑰。鍵由數組中每個元素的id字段標識。員工錢包使用身份驗證請求（在 JWT 的受保護頭中）中接收到的kid字段來選擇相應的公鑰並驗證 JWT 的簽名。它還驗證 DID 文檔（“DID:elsi.EORI.NLMARKETPLA”）中的頂級id字段是否等於身份驗證請求的client_id參數。

4.1.5 創建身份驗證響應#

101112

10. 如果身份驗證請求被驗證為合法，錢包將生成一個身份驗證響應，並在步驟 5 中 Marketplace 指定的 redirect_uri 中發布。該響應中會包含一個可驗證憑據（VC），用來表明員工的身份和權限。

關鍵點：這個可驗證憑據由包裹遞送公司簽發，證明該員工確實是公司的一員，並且擁有相應的訪問權限。

11. 錢包將身份驗證響應發送到市場的 SIOP 會話接口。市場會根據接收到的響應來決定是否授予員工訪問權限。

SIOP 使用 “application/x-www-form-urlencoded” 編碼的 HTTP POST 請求將身份驗證響應发送到 redirect_uri 身份驗證請求參數中傳遞的端點。響應包含一個 ID token 和一個 VP（可驗證表示）token，如 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 包括可驗證的表示，它可以有兩種格式：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 文檔中的 DID，它可以驗證可驗證憑據的簽名，以及包交付公司是生態系統中的可信實體，並且它是活躍的。

14. 市場使用包裹遞送公司的公鑰來驗證身份響應的數字簽名，確保身份響應確實是由合法的公司生成的。

以上內容僅用於驗證可驗證證書。此外，Marketplace 還可以驗證包含可驗證憑據的可驗證演示文稿是由員工發送的，而不是由惡意代理發送的。為此，它在 “credentialSubject” 結構的 “verificationMethod” 中使用員工的公鑰。在 Packet Delivery Co 與其員工一起執行的入職過程中，該公鑰以加密方式綁定到員工 DID。

4.1.7 創建、獲取訪問 token#

151617

15. 完成所有驗證後，Marketplace 為員工創建一個訪問令牌，以便她將來可以使用它訪問 Marketplace 服務器中的服務。

16. 市場確認身份驗證成功，向錢包返回 HTTP 200 狀態碼，並包含生成的訪問令牌。

17. 員工的錢包顯示確認信息，表明身份驗證和令牌獲取過程順利完成。

18. 門戶頁面刷新後，員工可以看到新的服務選項，基於其身份和權限訪問相關內容。

4.1.8 請求訂單創建服務#

此時，Packet Delivery Co 員工已登錄到 Marketplace 應用程序。用戶現在可以創建目錄、產品和產品。

這時，市場了解到的信息：

該 Packet Delivery Co 屬於數據空間，並且可以頒發 EmployeeCredential 類型的憑據，因為它包含在可信發行者列表中並且是活動的，因為該信息在步驟 13 中檢索的 DID 文檔中。
那個 Packet Delivery Co 說用戶是它的雇員之一。此信息位於可驗證憑據內，該憑據由 Packet Delivery Co 進行數字簽名。

從這一點開始，Marketplace 可以向用戶顯示可用的服務，並在用戶有權這樣做的情況下執行這些服務。Marketplace 可以使用憑據中的所有聲明來執行 RBAC/ABAC 訪問控制和策略實施。
19_24

19. 展示可提供的服務。

21. 請求創建服務。

22. 市場提供 offer 細節。

23.Offer 可提供為 Standard, Gold。用戶進行選擇。

24. 創建成功，市場向錢包發送 200 OK 信息。

4.2 獲得權力 / 激活#

流程展示了 Happy Pets 員工如何通過使用去中心化標識符（DID）和可驗證憑據（VC），在 Marketplace 上獲得特定服務的訪問權限。整個流程旨在確保員工身份的安全驗證，並提供透明的訪問控制。

本流程與4.1的驗證流程完全相同。不同之處是，Happy Pets 或 No cheap 員工在 Marketplace 上的初始身份驗證是使用由這些公司頒發給其員工的可驗證憑據進行的，仅需將涉及的名稱修改即可。在此不過多贅述。

4.3 訪問數據服務#

以下詳細描述了 Happy Pets 客戶在使用可驗證憑據時更改 PTA 屬性的過程。

參與方：Happy Pets (Authorisation Registry, Identity Provider), User (Customer SLOP), Packet Delivery (Portal, Proxy, Authorisation Registry, Blockchain Node)

pets_1

1.Happy Pets 的客戶可以訪問快遞公司門戶網站或在智能手機上啟動快遞公司應用程序登錄。

2.Happy Pets 客戶被轉發到一個頁面，用於選擇所需的身份提供者進行登錄。其中一個登錄選項是 “可驗證憑據” 或類似的東西。

3.Happy Pets 客戶選擇 “可驗證憑據” 登錄方式，這將導致 Packet Delivery Co. 門戶生成一個 QR，其中包含包交付公司 IDP 的 / 身份驗證請求端點的 URL，發送給顧客的錢包。

4. 客戶用她的手機掃描 QR，手機發送 /authentication-requests 請求端點。

5.Packet Delivery 門戶在收到錢包發送的認證請求後，開啟一個標準的 SIOP 流程，生成一個請求令牌（Request Token），並將其返回給客戶的錢包。這個令牌不僅包含了 Packet Delivery 的 DID（去中心化標識符），還包括了一些其他關鍵信息。這個令牌的生成相當於給客戶的錢包發放了一張臨時通行證，錢包會使用它來繼續後續的驗證操作。請求令牌確保了接下來的驗證步驟具有唯一性和安全性。

6. 身份驗證請求作為 SIOP 返回給客戶錢包。SIOP 流使用一個新的響應模式 post，該 post 用於請求 SIOP 將身份驗證過程的結果傳遞到某個端點。參數response_mode用於攜帶該值。SIOP 交付身份驗證結果的端點在標準參數redirect_uri中定義。

返回 URI+Request Token，Request Token 包含一個 Packet Delivery 的 DID。

7. 在此步驟中，客戶的錢包使用 Universal Resolver 來解析 Packet Delivery 公司的 DID。解析在身份驗證請求的 client_id 參數中接收到的 Packet Delivery 公司的 DID，驗證數據包交付公司是屬於生態系統的受信任實體。
pets_2

8.Universal Resolver 返回 Packet Delivery 公司的 DID 文檔，該文檔不僅包含了 Packet Delivery 的公鑰，還包含了它在信任網絡中的狀態信息。這些信息幫助客戶的錢包確認 Packet Delivery 公司是一個可信的實體，並且它在整個數據生態系統中扮演著可靠的角色。通過檢查 DID 文檔中的信息，錢包可以進一步確認即將發送和接收的數據不會被篡改或偽造。

9. 客戶的錢包使用從 DID 文檔中獲得的信息來驗證 Packet Delivery 門戶的認證請求。首先，錢包會檢查認證請求的數字簽名，以確認請求確實是由 Packet Delivery 公司簽署的。這一步就像是檢查護照上的簽名是否與持有者的簽名一致，以確保請求的真實性和完整性。接下來，錢包會核對認證請求中的 DID 與之前解析的 DID 文檔中的信息是否匹配，從而確保請求沒有被篡改，並且確實來自於真正的 Packet Delivery 公司。

10. 客戶錢包創建一個身份驗證響應 (URI+id_token)，將在第 5 步中由 Packet Delivery 公司指定的 redirect_uri 中發布。id_token 需要包含客戶 DID，以及 VC 作為另外聲明，顧客的 VC 由 Happy Pets 授予。

11. 客戶的錢包將生成的認證響應提交給 Packet Delivery 門戶的特定 API 端點（如/siop-sessions），這相當於在安檢口提交了你的通行證。Packet Delivery 門戶會檢查這一響應，驗證客戶的身份以及與之關聯的可驗證憑據，以確保客戶有權訪問相應的服務。這一步驗證了客戶的數字身份和憑據的完整性，確保信息在傳輸過程中沒有被篡改或偽造。

12.Packet Delivery 門戶通過 Universal Resolver 解析 Happy Pets 的 DID。該 DID 位於可驗證演示中收到的可驗證憑據內。這個 DID 可以在上面的 “verifiableCredential” 結構的 “issuer” 字段中找到。

13.Packet Delivery 接收 Happy Pets 的 DID 文檔，其中包含有關公司的可信信息，包括與 Happy Pets 用於對客戶剛剛在可驗證表示中發送的可驗證憑據進行數字簽名的私鑰相關聯的公鑰，作為身份驗證流的一部分。使用公鑰和 DID 文檔中的 DID，它可以驗證可驗證憑據的簽名，並且 Happy Pets 是生態系統中的可信實體。

14. 以上內容僅用於驗證可驗證證書。此外，包交付公司還可以驗證包含可驗證憑據的可驗證表示是由客戶發送的，而不是由惡意代理發送的。為此，它在 “credentialSubject” 結構的 “verificationMethod” 中使用客戶的公鑰。在 Happy Pets 與客戶一起執行的入職過程中，該公鑰以加密方式綁定到客戶 DID

pets_3

15. 完成所有驗證後，Packet Delivery company 為客戶創建一個訪問令牌，以便她將來可以使用它訪問 Packet Delivery company 中的服務。

16. 錢包（SIOP）收到對 POST 請求的成功回覆。

17.Packet Delivery 公司代理通知 Packet Delivery 門戶客戶已成功通過驗證，門戶可以顯示該客戶可用的服務。用戶的瀏覽器接收到由分組交付（Packet Delivery）創建的訪問令牌（Access Token），使其無需經過前面的認證過程就可以請求服務。訪問令牌是一個標準的 OAuth 訪問令牌，它包含了數據包交付訪問其服務所需的信息。

此時，Happy Pets 客戶已登錄到包裹遞送公司門戶 / 應用程序，並看到可能提供的服務，包括更改其遞送訂單的 PTA 的選項。

pets_4

18.Happy Pets 客戶將看到 Packet Delivery 提供的可能服務，包括更改其交付訂單