W3C Verifiable Credentials Overviewを読む（７）

こんにちは、富士榮です。

少し間が空きましたが引き続きW3C Verifiable Credentials Overviewを読んでいきます。

1. Introduction
2. Ecosystem Overview
3. Verifiable Credentials Data Model
4. Securing Credentials
5. Bitstring Status List
6. Additional Publications

今回は4番目のSecuring Credentialsです。

1. Enveloping Proofs

Enveloping proofs of Credentials, defined by this Working Group, are based on JSON Object Signing and Encryption (JOSE), CBOR Object Signing and Encryption (COSE) [RFC9052], or Selective Disclosure for JWTs [SD-JWT]. These are all IETF specifications, or groups of specification like JOSE that refers to JWT [RFC7519], JWS [RFC7515], or JWK [RFC7517]). The Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] recommendation defines a "bridge" between these and the Verifiable Credentials Data Model v2.0, specifying the suitable header claims, media types, etc.

In the case of JOSE, the Credential is the "payload" (to use the IETF terminology). This is preceded by a suitable header whose details are specified by Securing Verifiable Credentials using JOSE and COSE for the usage of JWT. These are encoded, concatenated, and signed, to be transferred in a compact form by one entity to an other (e.g., sent by the holder to the verifier). All the intricate details on signatures, encryption keys, etc., are defined by the IETF specifications; see Example 6 for a specific case.

このワーキンググループが定義する資格証明書の包括的な証明は、JSON Object Signing and Encryption (JOSE)、CBOR Object Signing and Encryption (COSE) [RFC9052]、または Selective Disclosure for JWTs [SD-JWT]に基づいています。これらはすべて IETF 仕様、または JOSE のような仕様グループ（JWT [RFC7519]、JWS [RFC7515]、または JWK [RFC7517] を参照）です。Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] 勧告は、これらの仕様と Verifiable Credentials Data Model v2.0 間の「ブリッジ」を定義し、適切なヘッダークレームやメディアタイプなどを指定しています。

JOSE の場合、クレデンシャルは「ペイロード」（IETF の用語を使用）です。これは、JWT の使用方法として JOSE および COSE を使用した検証可能なクレデンシャルの保護で詳細が規定されている適切なヘッダーに先行します。これらはエンコードされ、連結され、署名され、1 つのエンティティから別のエンティティにコンパクトな形式で転送されます（例えば、保有者から検証者に送信されます）。署名や暗号化キーなどに関する複雑な詳細はすべて、IETF 仕様で定義されています。具体的な例については、例 6 を参照してください。 

以前も書きましたがエンベロープ証明はJOSE/COSE/SD-JWTのデジタル署名ですので、特にJOSEについてはOpenID Connectにおけるid_tokenと共通する点も多く、以前からOpenID Connectをやっている人にはとっつき易いと思います。

COSEですか？個人的にバイナリは好きですが万人受け（特に最近は）はしないでしょう。ただFIDO関連やmDLな人は通らないとダメな道だと思います。頑張りましょう。

The usage of COSE [RFC9052] is similar to JOSE, except that all structures are represented in CBOR [RFC8949]. From the Credentials point of view, however, the structure is similar insofar as the Credential (or the Presentation) is again the payload for COSE. The usage of CBOR means that the final representation of the Verifiable Credential (or Presentation) has a significantly reduced footprint which can be, for example, shown in a QR Code.

The [SD-JWT] is a variant of JOSE, which allows for the selective disclosure of individual claims. Claims can be selectively hidden or revealed to the verifier, but nevertheless all claims are cryptographically protected against modification. This approach is obviously more complicated than the JOSE case but, from the Credentials point of view, the structure is again similar. The original Credential is the payload for SD-JWT; and it is the holder's responsibility to use the SD-JWT when presenting the Credential to a verifier using selective disclosure.

COSE [RFC9052] の使用法は JOSE と似ていますが、すべての構造が CBOR [RFC8949] で表現されている点が異なります。しかし、クレデンシャルという観点から見ると、クレデンシャル（またはプレゼンテーション）が COSE のペイロードであるという点では、構造は似ています。CBORの使用により、検証可能なクレデンシャル（またはプレゼンテーション）の最終的な表現は、例えばQRコードで表示できるほど、フットプリントが大幅に削減されます。

[SD-JWT] は JOSE のバリエーションであり、個々のクレームの選択的な開示を可能にします。 検証者に対して、クレームを選択的に非表示または表示することができますが、それにもかかわらず、すべてのクレームは暗号技術によって改ざん防止が保護されています。 このアプローチは JOSE の場合よりも明らかに複雑ですが、クレデンシャルという観点から見ると、構造は再び似ています。SD-JWTのペイロードがオリジナルクレデンシャルであり、選択的開示を使用して検証者にクレデンシャルを提示する際にSD-JWTを使用するのは、所有者の責任です。

はい、CBORを使うメリットはやはりサイズの問題でしょうね。ただ結局はOpenID for Verifiable Credential Issuanceのcredential_offer_uriの様に、間接的にクレデンシャル発行を行う場合ばかりだと思いますので、Wallet to Walletの様なシナリオ以外ではあまり出番はないのかもしれません。

4.1.1 Example: the Core Example Secured with JOSE

The Credential example, shown in Example 1, and enriched with a reference to a JSON Schema in Example 3, can be secured via an enveloping proof as follows:

例 1 の「Credential」の例は、例 3 の JSON スキーマへの参照により強化されており、以下のとおり、エンベロープ証明により保護することができます。

EXAMPLE 6: A Simple Credential in JWT (unencoded)

// Header
{
  "iss": "did:example:2g55q912ec3476eba2l9812ecbfe",
  "alg": "HS256",
  "cty": "vc+ld+json",
  "typ": "vc+ld+json+jwt"
}

---

// Payload
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.example.org/vocabs/alumni"
  ],
  "id": "https://university.example/Credential123",
  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
  "issuer": "did:example:2g55q912ec3476eba2l9812ecbfe",
  "validFrom": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "https://www.example.org/persons/pat",
    "name": "Pat",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": "Example University"
    }
  },
  "credentialSchema": {
    "id": "https://university.example/Credential123-schema-credential",
    "type": "JsonSchemaCredential"
  } 

} 

まぁ、ここはサンプルですが、ヘッダに記載の方式でデジタル署名が打たれる、ということを覚えておけば良いと思います。

As a next step, the header and the payload is encoded, concatenated, and then signed using the methods defined by JWS [RFC7515]. The encoded and signed Credential could look like (using the string "VC Overview" as the signature's secret):

次のステップとして、ヘッダーとペイロードは、JWS [RFC7515] で定義された方法を使用して、エンコード、連結、そして署名されます。 エンコードおよび署名されたクレデンシャルは、次のようになります（署名用の秘密鍵として「VC Overview」という文字列を使用）。

ここもJWSの話ですね。慣れ親しんだ方法です。

EXAMPLE 7: A Simple Credential Enveloped using JOSE

eyJpc3MiOiJkaWQ6ZXhhbXBsZToyZzU1cTkxMmVjMzQ3NmViYTJsOTgxMmVjYmZlIiwiYWxnIjoiSFMyNTYiLCJjdHkiOiJ2YytsZCtqc29uIiwidHlwIjoidmMrbGQranNvbitqd3QifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy5leGFtcGxlLm9yZy92b2NhYnMvYWx1bW5pIl0sImlkIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvQ3JlZGVudGlhbDEyMyIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJFeGFtcGxlQWx1bW5pQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJkaWQ6ZXhhbXBsZToyZzU1cTkxMmVjMzQ3NmViYTJsOTgxMmVjYmZlIiwidmFsaWRGcm9tIjoiMjAxMC0wMS0wMVQwMDowMDowMFoiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJpZCI6Imh0dHBzOi8vd3d3LmV4YW1wbGUub3JnL3BlcnNvbnMvcGF0IiwibmFtZSI6IlBhdCIsImFsdW1uaU9mIjp7ImlkIjoiZGlkOmV4YW1wbGU6YzI3NmUxMmVjMjFlYmZlYjFmNzEyZWJjNmYxIiwibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSJ9fSwiY3JlZGVudGlhbFNjaGVtYSI6eyJpZCI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL0NyZWRlbnRpYWwxMjMtc2NoZW1hLWNyZWRlbnRpYWwiLCJ0eXBlIjoiSnNvblNjaGVtYUNyZWRlbnRpYWwifX0.Ic1SxIMuwAuTHVQ_2i3wzLvRTSP9EwIS6_G_nEAueVg

これがサンプルですが、みんな大好きeyJですね。

次回はEmbedded Proof（VC Data Integrity）を見ていきます。