自定義可驗證的憑證

發行項
12/14/2024

可驗證的認證（VC）定義是由兩個元件所組成，顯示定義和規則定義。顯示定義控制憑證的品牌化和宣告的樣式。在使用者收到可驗證的認證之前，規則的定義會決定他們需要提供哪些資料。

本文說明如何修改這兩種類型的定義，以符合貴組織的需求。

顯示定義：錢包憑證影像

Microsoft Entra 驗證標識碼提供一組有限的選項，可用來反映您的品牌。本文提供如何自訂您的認證的指示，以及設計認證的最佳實踐，確保這些認證在發放給用戶後看起來更佳。

Microsoft Authenticator，身為分散式身分識別錢包，以卡片的形式向用戶顯示可驗證的認證。身為 VC 系統管理員，您可以選擇卡片色彩、圖示和文字字串，以符合組織的品牌。

Authenticator 中已驗證認證卡的螢幕快照，指出重要元素。

卡片也包含可自定義的欄位。您可以使用這些欄位讓使用者知道卡片的用途、它所包含的屬性等等。

建立認證顯示定義

顯示定義是簡單的 JSON 檔，描述錢包應用程式應如何顯示可驗證認證的內容。

注意

此顯示模型目前僅供Microsoft Authenticator 使用。

顯示定義具有下列結構。如果指定為 URL，則標誌 URI 必須是因特網中公開提供的 URL。

{
    "locale": "en-US",
    "card": {
      "title": "Verified Credential Expert",
      "issuedBy": "Microsoft",
      "backgroundColor": "#000000",
      "textColor": "#ffffff",
      "logo": {
        "uri": "https://didcustomerplayground.z13.web.core.windows.net/VerifiedCredentialExpert_icon.png",
        "description": "Verified Credential Expert Logo"
      },
      "description": "Use your verified credential to prove to anyone that you know all about verifiable credentials."
    },
    "consent": {
      "title": "Do you want to get your Verified Credential?",
      "instructions": "Sign in with your account to get your card."
    },
    "claims": [
      {
        "claim": "vc.credentialSubject.firstName",
        "label": "First name",
        "type": "String"
      },
      {
        "claim": "vc.credentialSubject.lastName",
        "label": "Last name",
        "type": "String"
      }
    ]
}

如需屬性的詳細資訊，請參閱 displayModel 類型。

規則定義：使用者的需求

規則定義是簡單的 JSON 檔，描述可驗證認證的重要屬性。特別是，它描述了如何使用聲明來填充可驗證憑證及其類型。

{
  "attestations": {
      ...
  },
  "validityInterval":  2592000,
  "vc": {
    "type": [
      "VerifiedCredentialExpert"
    ]
  }
}

證明

下列四種證明類型目前可在規則定義中設定。提供宣告的方式有多種，Microsoft Entra Verified ID 發行服務用這些方式將宣告插入可驗證的憑證，並使用您的分散式標識碼（DID）來驗證該資訊。規則定義中可以使用多個證明類型。

識別碼令牌：設定此選項時，您必須提供 OpenID Connect 組態 URI，並包含應包含在可驗證認證中的宣告。系統會提示使用者在 Authenticator 應用程式上「登入」，以符合此需求，並從其帳戶新增相關聯的宣告。若要設定此選項，請參閱此操作指南
ID token 提示：範例應用程式和教學課程會使用 ID token 提示。當設定此選項時，信賴方應用程式需要在請求服務 API 的發行請求中，提供應該包含在可驗證憑證中的宣告。信任端應用程式從何處取得宣告取決於應用程式本身，但可能來自目前的登入會話、後端 CRM 系統，甚至是來自自行聲明的使用者輸入。若要設定此選項，請參閱此使用指南
可驗證的認證：發行流程的最終結果是產生可驗證的認證，但您也可以要求使用者出示可驗證的認證，以發出認證。規則定義能夠從所呈現的可驗證認證取得特定宣告，並將這些宣告包含在您組織新發行的可驗證認證中。若要設定此選項，請參閱此如何引導
自我證明宣告：選取此選項時，使用者可以直接將資訊輸入 Authenticator。目前，字串是唯一能支援自我驗證宣告的輸入。若要設定此選項，請參閱此操作指引

如需規則 JSON 模型的詳細資訊，請參閱 rulesModel 類型。

認證類型

所有可驗證的認證都必須在其規則定義中宣告其類型。認證類型會區分可驗證的認證架構與其他認證，並確保簽發者和驗證程序之間的互操作性。若要指出認證類型，請提供認證滿足的一或多個認證類型。每個類型都以唯一字串表示。 URI 通常用來確保全域唯一性。 URI 不需要是可尋址的。它會被視為字串。例如，Contoso 大學簽發的文憑認證可能會列出下列類型：

類型	目的
`https://schema.org/EducationalCredential`	宣告 Contoso University 發出的文憑包含由 schema.org `EducationaCredential` 物件定義的屬性。
`https://schemas.ed.gov/universityDiploma2020`	宣告 Contoso 大學頒發的文憑包含美國教育部所定義的屬性。
`https://schemas.contoso.edu/diploma2020`	宣告 Contoso University 發出的文憑包含 Contoso University 所定義的屬性。

藉由宣告三種類型的文憑，Contoso 可以發出符合驗證程式不同要求的認證。銀行可以要求使用者提供一組EducationCredential；而文憑可以用來滿足這個要求。或者 Contoso 大學校友會可以要求 https://schemas.contoso.edu/diploma2020類型的認證，並且文憑也可以滿足該要求。

為了確保認證互操作性，建議您與相關組織密切合作，以定義認證類型、架構和 URI，以供產業使用。許多業界機構提供官方文件結構的指引，這些檔可用於定義可驗證認證的內容。您也應該與您憑證的驗證者密切合作，以了解他們打算如何請求和使用您的可驗證憑證。

後續步驟

現在您已進一步瞭解可驗證的認證設計，以及如何建立您自己的認證，請參閱：

共用方式為