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

先日日本語版のホワイトペーパーが公開されたTrusted Webですが、英語版がリリースされています。

https://trustedweb.go.jp/en/documents/

関連URL）

https://www.kantei.go.jp/jp/singi/digitalmarket/trusted_web/index.html

https://www.kantei.go.jp/jp/singi/digitalmarket/index_e.html

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

OpenID FoundationのExecutive DirectoryのGail HodgesがG20のDigital Government and Inclusion Workshopで話したビデオが公開されていますね。

ちなみにotio.aiにこのYoutube動画をインポートして要約をしたのがこちらです。

英語

Digital Government and Inclusion

Digital Public Infrastructure (DPI)

• DPI refers to solutions and systems that enable effective provision of essential society-wide functions and services in the public and private sectors
• DPI includes digital forms of identification, verification, authentication, civil registration, digital financial services, and information exchange systems
• DPI can create a foundation for more effective delivery of public and private sector services and enable inclusive, responsible, and sustainable digital transformation

Key Principles for DPI Governance

• User-centered and inclusive design to respond to user needs and minimize barriers to access
• Clear strategic approach and defined roles/responsibilities across the public sector ecosystem
• Norms to protect privacy, security, and enable interoperability across the public sector

Recommendations for Countries

• Adopt global open standards for DPI to enable interoperability, security, and scalability
• Invest in digital foundations like connectivity, digital skills, and accessible digital content
• Promote multi-stakeholder collaboration and knowledge sharing across countries
• Establish robust data protection and governance frameworks for DPI
• Measure and address digital inclusion gaps systematically

Country Experiences

• Brazil has made significant progress in providing public services through the Gov.BR digital identity platform, reaching over 158 million users
• Denmark has a high adoption of its digital identity system, used by 97% of the population 13 years and above, with a focus on user-centricity and cooperation across government levels
• India's Aadhaar digital ID system has enabled rapid expansion of financial inclusion and service delivery

The Role of the G20

• The G20 can play a key role in driving international cooperation and consensus on DPI governance principles and standards
• Collaboration within the G20 can help countries learn from each other's experiences and accelerate progress towards inclusive digital transformation

 DeepLで日本語にしたのがこちら

デジタル政府とインクルージョン

デジタル公共インフラ（DPI）

• DPIとは、公共および民間部門において、社会全体で必要とされる機能やサービスを効果的に提供するためのソリューションやシステムを指します。
• DPIには、デジタル形式のID、検証、認証、住民登録、デジタル金融サービス、情報交換システムなどが含まれます
• DPIは、公共および民間部門によるサービスのより効果的な提供の基盤を構築し、包括的かつ責任ある持続可能なデジタル変革を実現します

DPIガバナンスの主な原則

• ユーザーニーズに対応し、アクセス障壁を最小限に抑えるユーザー中心かつ包括的な設計
• 公共セクターのエコシステム全体における明確な戦略的アプローチと定義された役割/責任
• プライバシーとセキュリティを保護し、公共部門全体で相互運用性を実現するための規範

各国への提言

• 相互運用性、セキュリティ、拡張性を実現するために、DPI に関するグローバルなオープンスタンダードを採用する
• 接続性、デジタルスキル、アクセシブルなデジタルコンテンツなどのデジタル基盤への投資
• 各国間のマルチステークホルダーのコラボレーションと知識共有を促進する
• DPI に対する強固なデータ保護およびガバナンスの枠組みを確立する
• デジタル格差を体系的に測定し、対応していく

各国の経験

• ブラジルは、Gov.BRデジタルIDプラットフォームを通じて公共サービスを提供することで大きな進歩を遂げ、1億5,800万人以上のユーザーに利用されています
• デンマークでは、デジタルIDシステムの普及率が非常に高く、13歳以上の人口の97%が利用しています。このシステムは、ユーザー中心主義と政府レベル間の協力に重点を置いています
• インドの Aadhaar デジタル ID システムにより、金融包摂とサービス提供が急速に拡大した

G20の役割

• G20は、DPIガバナンスの原則と基準に関する国際協力と合意形成を推進する上で重要な役割を果たすことができます。
• G20内での協力により、各国は互いの経験から学び、包括的なデジタル変革に向けた進展を加速させることができる。

便利な世の中になりましたねぇ。。

なお、こちらがOpenID Foundationのホームページでのお知らせです。

https://openid.net/digital-identity-g20/

GailはSIDI Hubでもリーダーシップを担っており、今年の11月のG20リオデジャネイロでの提言を目標として活動を続けているので、その一部が先行して見えてきている、ということですね。

10月には日本でも会合が開催される見込みですし、今後も目が離せませんね。

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

慶應義塾の鈴木 茂哉先生がメインライターのDIDとVCに関する解説論文が出ています。

https://www.jstage.jst.go.jp/article/essfr/18/1/18_42/_article/-char/ja

Decentralized Identifiers (DID) とVerifiable Credentials (VC) は，ディジタルアイデンティティの新しい実装形態として注目されている．従来型のディジタルアイデンティティのモデルでは，アイデンティティサービスを提供する主体が，ユーザの同意の元，ユーザ情報を，その情報を必要としている主体に提供していたが，VCによるモデルでは，ユーザ自身が，自身に関する情報を提供できるようになり，ディジタルアイデンティティの繊細なコントロールを可能としている．このモデルの中心となるのは，データモデル，非対称鍵暗号，発行・検証プロトコルなどであり，技術開発と標準化が積極的に進められている状況にある．本論文では，VCによるモデルとそれをとりまく検討状況について，背景，標準化，関連プロトコル，応用事例，課題や論点について概説する．（JStageに記載の抄録より）

おそらく現時点では関連する技術仕様が一番コンパクトにまとまっている論文だと思いますので、ぜひ読みましょう。

（私も微力ながらお手伝いさせていただきました）

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

少し間が空きましたが引き続き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 スキーマへの参照により強化されており、以下のとおり、エンベロープ証明により保護することができます。

// 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の話ですね。慣れ親しんだ方法です。

eyJpc3MiOiJkaWQ6ZXhhbXBsZToyZzU1cTkxMmVjMzQ3NmViYTJsOTgxMmVjYmZlIiwiYWxnIjoiSFMyNTYiLCJjdHkiOiJ2YytsZCtqc29uIiwidHlwIjoidmMrbGQranNvbitqd3QifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy5leGFtcGxlLm9yZy92b2NhYnMvYWx1bW5pIl0sImlkIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvQ3JlZGVudGlhbDEyMyIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJFeGFtcGxlQWx1bW5pQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJkaWQ6ZXhhbXBsZToyZzU1cTkxMmVjMzQ3NmViYTJsOTgxMmVjYmZlIiwidmFsaWRGcm9tIjoiMjAxMC0wMS0wMVQwMDowMDowMFoiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJpZCI6Imh0dHBzOi8vd3d3LmV4YW1wbGUub3JnL3BlcnNvbnMvcGF0IiwibmFtZSI6IlBhdCIsImFsdW1uaU9mIjp7ImlkIjoiZGlkOmV4YW1wbGU6YzI3NmUxMmVjMjFlYmZlYjFmNzEyZWJjNmYxIiwibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSJ9fSwiY3JlZGVudGlhbFNjaGVtYSI6eyJpZCI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL0NyZWRlbnRpYWwxMjMtc2NoZW1hLWNyZWRlbnRpYWwiLCJ0eXBlIjoiSnNvblNjaGVtYUNyZWRlbnRpYWwifX0.Ic1SxIMuwAuTHVQ_2i3wzLvRTSP9EwIS6_G_nEAueVg

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

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

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

Universal ResolverやPresentation ExchangeやDecentralized Web Nodeで有名なDIF（Decentralized Identity Foundation）の日本支部であるDIF Japanが少し前から活動を開始しているのですが、8月1日に開発者向けのキックオフイベントをやります。

DIF本国のサイトより

DIF Japan #1 - 開発者集まれ！日本でもDIFが立ち上がったぞ！

日時：2024年8月1日（木）16時00分～19時00分

会場：CIC Tokyo／オンライン

主催：DIF Japan

後援：DIF（Decentralized Identity Foundation）

運営：Venture Café Thursday Gathering

参加費：無料

申し込みURL：https://peatix.com/event/4023247/

私も少しお話しさせていただきますのでぜひイベントに来場してDIF Japanでの活動にも参加してください。

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

少し前のニュースですがニュージーランドで今月からデジタルIDに関する規制を行う機関（要は認定機関）である「Trust Framework Authority」の活動が開始されているようです。

ニュースソース

https://www.biometricupdate.com/202407/new-zealand-digital-identity-regulator-opens-doors-ushering-in-era-of-digital-id

Trust Framework Authority（ニュージーランド政府のページ）

https://www.digital.govt.nz/standards-and-guidance/identity/trust-framework/trust-framework-authority/

導入の背景として行政サービス等のデジタル化があるようです。日本を含む他の国々と同じく、身分証明書のデジタル化（スマホ搭載等）によりオンラインでの身元確認ができるように、という話ですね。mDL（モバイル運転免許証）の導入も視野に入っているようです。

実際、日本においても身元確認書類（例えば免許証やマイナンバーカード）をスマホに搭載する話が進んでいますし、先日AppleもWalletにマイナンバーカードを搭載できるようにする、という発表が行われましたが、EUが一歩先でやっているように政府機関がある程度Walletプロバイダやサービスを認定できる状態にしておかないと、勝手にマイナンバーカードの券面読み取りAPIなどを使って「マイナンバーカードのコピー」をスマホに搭載してあたかも「公的な身分証明書」のように誤認されてしまう状態が大量に出来上がる、ということが懸念されます。（個人的な意見ですが）

そういう意味ではこのような認定機関をちゃんと作って運営をしていくことが日本にも求められてくると思います。

Trust Framework Authorityのページを見るとこの機関の責任は以下のように定義されています。

まだ7月1日に走り始めたばかりで公開されている情報も少ないですが少し追いかけてみたいと思います。

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

ようやく折り返しましたが引き続き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を見ていきます。

前回はEnvelop proof（JWS）だったので、今回はEmbedded Proof（VC Data Integrity）を見ていきます。

2. Embedded Proofs

2.1. Generic Data Integrity Structure

The operation of Data Integrity is conceptually simple. To create a cryptographic proof, the following steps are performed: 1) Transformation, 2) Hashing, and 3) Proof Generation.

データ完全性の操作は概念的には単純です。暗号証明を作成するには、次のステップを実行します。1) 変換、2) ハッシュ化、3) 証明生成。

図7. Generic view of the proof generation steps.

1. Transformation is a process described by a transformation algorithm that takes input data and prepares it for the hashing process. In the case of data serialized in JSON this transformation includes the removal of all the artifacts that do not influence the semantics of the data like spaces, new lines, the order of JSON names, etc. (a step often referred to as canonicalization). In some cases the transformation may be more involved.
2. Hashing is a process described by a hashing algorithm that calculates an identifier for the transformed data using a cryptographic hash function. Typically, the size of the resulting hash is smaller than the data, which makes it more suitable for complex cryptographic functions like digital signatures.
3. Proof Generation is a process described by a proof method that calculates a value that protects the integrity of the input data from modification or otherwise proves a certain desired threshold of trust. A typical example is the application of a cryptographic signature using asymmetric keys, yielding the signature of the data.

1. 変換とは、入力データを受け取り、ハッシュ化処理の準備をする変換アルゴリズムによって記述されるプロセスです。JSONでシリアライズされたデータの場合、変換には、スペース、改行、JSON名の順序など、データの意味に影響を与えないアーティファクトの除去が含まれます（正規化と呼ばれるステップ）。場合によっては、変換はより複雑になることがあります。
2. ハッシュ化は、暗号ハッシュ関数を使用して変換されたデータの識別子を計算するハッシュアルゴリズムによって記述されるプロセスです。通常、生成されたハッシュのサイズはデータよりも小さいため、デジタル署名のような複雑な暗号機能に適しています。
3. 証明生成とは、証明方法によって記述されるプロセスであり、入力データの整合性を改ざんから保護する値、または特定の信頼性基準を満たすことを証明する値を計算します。典型的な例として、非対称鍵を使用した暗号署名アプリケーションがあり、これによりデータの署名が生成されます。

このTransformにおける正規化（Canonicalization）がしばしば問題視されるところですね。

以前SAMLの脆弱性についてこのブログでも取り上げましたが、実際にシリアライズを正しく安全に行う、というのは難しいところです。OpenID Connectの設計思想としてIdentiverseでも取り上げられていたのはまさに「No canonicalization」でした。SAMLでの苦い思い出から正規化をせずにクレデンシャルを表現できる方式としてJWSを採用したわけです。

Verification of a proof involves repeating the same steps on the verifier's side and, depending on the proof method, validating the newly calculated proof value with the one associated with the data. In the case of a digital signature, this test usually means comparing the calculated signature value with the one which is embedded in the data.

証明の検証には、検証者側で同じ手順を繰り返す必要があり、証明方法によっては、新たに計算された証明値をデータに関連付けられた値で検証します。デジタル署名の場合、このテストは通常、計算された署名値とデータに埋め込まれた署名値を比較することを意味します。

2.2. VC Data Integrity

The Verifiable Credential Data Integrity 1.0 [VC-DATA-INTEGRITY] specification relies on the general structure and defines a set of standard properties describing the details of the proof generation process. The specific details (canonicalization algorithm, hash and/or proof method algorithms, etc.) are defined by separate cryptosuites. The Working Group has defined a number of such cryptosuites as separate specifications, see 4.2.3 Cryptosuites below.

The core property, in the general structure, is proof. This property embeds a claim in the Credential, referring to a separate collection of claims (referred to as a Proof Graph) detailing all the claims about the proof itself:

 検証可能な資格情報データ完全性 1.0 [VC-DATA-INTEGRITY] 仕様は、一般的な構造に依存し、証明生成プロセスの詳細を説明する一連の標準プロパティを定義します。具体的な詳細（正規化アルゴリズム、ハッシュおよび/または証明方法アルゴリズムなど）は、別の暗号スイートによって定義されます。ワーキンググループは、このような暗号スイートを別個の仕様として多数定義しています。詳細は、以下の4.2.3 暗号スイートを参照してください。

一般的な構造におけるコアとなる特性は「証明」です。この特性は、クレデンシャルにクレームを埋め込み、証明自体に関するすべてのクレームを詳細に説明する別個のクレーム集合（証明グラフと呼ばれる）を参照します。

VC Data Integrityの使用は別途策定されていますが、まだW3C勧告とはなっておらずCR（Candidate Recommendation）の状態です。

{
  "@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"
  },
  "proof": {
    "type": "DataIntegrityProof",…
    // All the details about the proof
    …"proofValue": "zQeVb…Wx"
  }
}

Note the proofValue property, whose object is the result of the proof generation process.

proofValue プロパティに注目してください。このプロパティのオブジェクトは、証明生成プロセスの結果です。 

実際のサンプルが示されています。proofのtypeに"DataIntegrityProof”、そしてvalueのところに計算された値が入ることになります。

The definition of proof introduces a number of additional properties. Some of these are metadata properties on the proof itself, like created, expires, or domain. Others provide the necessary details on the proof generation process itself, like cryptosuite, nonce (if needed), or verificationMethod that usually refers to cryptographic keys. The exact format of the public keys, when used for Credentials, is defined in the [CONTROLLER-DOCUMENT] specification, and is based on either the JWK [RFC7517] format or a Multibase [MULTIBASE] encoding of the keys, called Multikey. Details of the key values are defined by other communities (IETF, cryptography groups, etc.) and are dependent on the specific cryptographic functions they operate with.

It is possible to embed several proofs for the same Credential. These may be a set of independent proofs (based, for example, on different cryptosuites, to accommodate to the specificities of different verifiers), but may also be a "chain" of proofs that must be evaluated in a given order.

A proof may also specify its "purpose" via the proofPurpose property: different proofs may be provided for authentication, for assertion, or for key agreement protocols. These possible purposes are defined in the [CONTROLLER-DOCUMENT] specification. The verifier is supposed to choose the right proof depending on the purpose of its own operations, which is yet another possible reasons why the holder or the issuer may provide several proofs for the same Credential.

 証明の定義には、いくつかの追加プロパティが含まれます。その中には、証明自体のメタデータプロパティ（作成日、有効期限、ドメインなど）もあります。また、証明生成プロセス自体の詳細を提供するプロパティもあります（cryptosuite、nonce（必要な場合）、通常、暗号鍵を指す verificationMethod など）。クレデンシャルに使用される公開鍵の正確なフォーマットは、[CONTROLLER-DOCUMENT] 仕様で定義されており、JWK [RFC7517] フォーマットまたは Multikey と呼ばれる公開鍵の Multibase [MULTIBASE] エンコーディングのいずれかに基づいています。鍵値の詳細は、他のコミュニティ（IETF、暗号グループなど）によって定義されており、使用する特定の暗号機能に依存します。

同じクレデンシャルに対して複数の証明を埋め込むことが可能です。これらは独立した証明のセット（例えば、異なる検証者の特殊性に対応するために異なる暗号スイートに基づく）の場合もありますが、所定の順序で評価しなければならない証明の「チェーン」の場合もあります。

証明は、proofPurposeプロパティを通じてその「目的」を指定することもできます。異なる証明は、認証、アサーション、または鍵合意プロトコル用に提供されます。これらの可能な目的は、[CONTROLLER-DOCUMENT]仕様で定義されています。検証者は、自身の操作の目的に応じて適切な証明を選択することが想定されています。これが、同じクレデンシャルに対して複数の証明を提供する理由の1つです。

Data Integrityの特徴で便利だと思うのは複数のProofを埋め込むことができる点、そして目的を指定することができる点です。例えば、学修歴など複数の教員によって証明されることがあるクレデンシャルについてはこの機能は有用なのかもしれません。

長くなってきたので、続きのCryptosuiteからは次回に送りたいと思います。

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

引き続きW3C Verifiable Credentials Overviewを読んでいきます。

2.3. Cryptosuites

The Working Group publishes three cryptosuite documents: Data Integrity ECDSA Cryptosuites v1.0 [VC-DI-ECDSA], Data Integrity EdDSA Cryptosuites v1.0 [VC-DI-EDDSA], and Data Integrity BBS Cryptosuites v1.0 [VC-DI-BBS]. As their name suggests, the documents rely on existing cryptographic signature schemes: the Elliptic Curve Digital Signature Algorithm (ECDSA) specification [FIPS-186-5], the Edwards-Curve Digital Signature Algorithm (EdDSA) specification [RFC8032], and the BBS Signature Scheme [CFRG-BBS-SIGNATURE], respectively.

Figure 8 provides an overall view of the six cryptosuites defined by the three recommendations. They all implement the general structure of proofs as described in 4.2.1 Generic Data Integrity Structure. As shown on the figure, one axes of differentiation is the data transformation function, i.e., the canonicalization of the JSON serialization: two cryptosuites use JSON Canonicalization (JCS) [RFC8785], the others use RDF Dataset Canonicalization (RDFC-1.0) [RDF-CANON]. The other axis is whether the cryptosuite provides selective disclosure, which is the case for two of the six cryptosuites.

ワーキンググループは、3つの暗号スイート文書を公開しています。データ完全性ECDSA暗号スイートv1.0 [VC-DI-ECDSA]、データ完全性EdDSA暗号スイートv1.0 [VC-DI-EDDSA]、データ完全性BBS暗号スイートv1.0 [VC-DI-BBS]です。これらの文書はその名称が示すように、それぞれ、楕円曲線デジタル署名アルゴリズム（ECDSA）仕様書 [FIPS-186-5]、エドワーズ曲線デジタル署名アルゴリズム（EdDSA）仕様書 [RFC8032]、BBS 署名方式 [CFRG-BBS-SIGNATURE] といった既存の暗号署名方式に基づいています。

図 8 は、3 つの勧告で定義された 6 つの暗号スイートの全体像を示しています。これらはすべて、4.2.1 汎用データ完全性構造で説明されている証明の一般的な構造を実装しています。図に示されているように、差別化要因の1つはデータ変換機能、すなわちJSONシリアライズの正規化です。2つのcryptosuiteはJSON Canonicalization (JCS) [RFC8785]を使用しており、他のcryptosuiteはRDF Dataset Canonicalization (RDFC-1.0) [RDF-CANON]を使用しています。もう一つの軸は、暗号スイートが選択的開示機能を備えているかどうかです。6つの暗号スイートのうち2つは選択的開示機能を備えています。

図8. Generic view of the proof generation steps.

NOTE 

A common characteristics of all these cryptosuites is that keys must always be encoded using the Multikey encoding. The keys, whose exact formats are defined in the respective signature scheme specifications, also carry the choice of the hash functions to be used by the proof generation algorithm. This provides yet another differentiation axis among cryptosuites although, in practice, SHA-256 [RFC6234] is usually used.

注

これらの暗号スイートに共通する特徴は、キーを常にマルチキーエンコーディングでエンコードしなければならないことです。キーの正確なフォーマットは、それぞれの署名スキームの仕様で定義されていますが、証明生成アルゴリズムで使用されるハッシュ関数の選択もキーに含まれます。これにより、暗号スイート間の差別化要素がさらに1つ追加されますが、実際には通常、SHA-256 [RFC6234] が使用されます。

2.3.1. Full Disclosure Schemes

The two EdDSA cryptosuites, as well as ecdsa-rdfc-2019 and ecdsa-jcs-2019, follow the proof generation pipeline as described in 4.2.1 Generic Data Integrity Structure: the Credential is canonicalized (using either JCS or RDFC-1.0), the result is hashed (using the hash functions as defined by the signature key), and the proof is generated using that hash value. There is, however, an extra twist: the same pipeline is also used on a set of claims called "proof options", i.e., all the claims of the proof graph except proofValue. This set of claims is therefore also canonicalized and hashed, following the same process as for the Credential, yielding a second hash value. It is the concatenation of these two values that is signed by EdDSA or ECDSA, respectively, producing a value for the proofValue property.

2つのEdDSA暗号スイート、ecdsa-rdfc-2019およびecdsa-jcs-2019は、4.2.1で説明されている証明生成パイプラインに従います。一般的なデータ完全性構造：クレデンシャルは正規化され（JCS または RDFC-1.0 を使用）、その結果はハッシュ化され（署名鍵で定義されたハッシュ関数を使用）、そのハッシュ値を使用して証明が生成されます。ただし、さらに別の工夫がされています。同じパイプラインが「proof options」と呼ばれる一連のクレームにも使用されているのです。つまり、proofValue を除く証明グラフのすべてのクレームです。この一連のクレームも、クレデンシャルと同じプロセスに従って正規化およびハッシュ化され、2つ目のハッシュ値が算出されます。これらの2つの値の連結が、EdDSAまたはECDSAによってそれぞれ署名され、proofValueプロパティの値が生成されます。

署名対象となるクレデンシャルに加えてproof optionsに関しても変換・ハッシュ化・Proof作成というステップを踏むわけですね。

2.3.2. Selective Disclosure Schemes

The ecdsa-sd-2023 and bbs-2023 cryptosuites provide selective disclosures of individual claims. In both cases, the process separates the "Base Proof" (calculated by the issuer), and the "Derived Proof" (which is typically calculated by the holder when selectively presenting the credential claims to the verifier). The challenge is that the verifier should check that the holder can be trusted when verifying a partial value, without having access to the full original data.

To calculate the Base Proof, the Credential is supplemented with extra information that separates the "mandatory" and "non-mandatory" claims. Using that extra information, the transformation step described in 4.2.1 Generic Data Integrity Structure does not only canonicalize the Credential, but also transforms it by explicitly separating these two types of claims into their own sets. Furthermore, each non-mandatory claim must be signed individually, yielding a series of signatures. The final Base Proof is, conceptually, the concatenation of all these signatures and related informations like the separation of mandatory and non-mandatory claims.

The Derived Proof is generated by the holder, when presenting the (derived) Credential. These data are combined with the kind of selective disclosure requests the holder is prepared to honor; it is the combination of all these data that are used for the creation of a Derived Proof that is forwarded to the verifier.

ecdsa-sd-2023およびbbs-2023暗号スイートは、個々のクレームを選択的に開示します。いずれの場合も、プロセスは「ベースプルーフ」（発行者によって算出）と「派生プルーフ」（通常、検証者にクレデンシャルクレームを選択的に提示する際に保有者によって算出）を分離します。検証者は、元のデータ全体にアクセスすることなく、部分的な値を検証する際に、保有者が信頼できることを確認する必要があります。 

ベースプルーフを計算するために、クレデンシャルには「必須」と「非必須」の主張を区別する追加情報が追加されます。この追加情報を使用して、4.2.1 汎用データ完全性構造で説明されている変換ステップでは、クレデンシャルを正規化するだけでなく、これらの2種類の主張をそれぞれのセットに明示的に分離して変換します。さらに、各非必須の主張は個別に署名され、一連の署名が生成されます。最終的なベースプルーフは、概念的には、これらの署名と必須および非必須の主張の分離などの関連情報の連結です。

派生証明は、（派生）クレデンシャルを提示する際に、保有者によって生成されます。これらのデータは、保有者が応じる用意のある選択的開示要求の種類と組み合わせられます。検証者に送付される派生証明の作成には、これらのデータの組み合わせがすべて使用されます。

選択的開示をするためにベースプルーフと派生プルーフに分けるんですね。開示したくない属性を落としても全体として完全であるということを示さなければならないので、開示されない可能性のある派生クレームについては個別で署名をしていくということのようです。

2.4. Example: the Core Example Secured with ECDSA

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

例 1 の「Credential」の例では、例 3 の JSON スキーマへの参照を付加することで、次のように埋め込み証明を使用してセキュリティ保護することができます。

{
  "@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"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-rdfc-2019",
    "created": "2010-01-01T00:00:00Z",
    "expires": "2040-01-01T00:00:00Z",
    "verificationMethod: "did:example:2g55q912ec3476eba2l9812ecbfe#ecdsa-public-key""proofPurpose": "assertionMethod""proofValue": "zQeVb…Wx"
  } 

}

When dereferenced, the URL did:example:2g55q912ec3476eba2l9812ecbfe#ecdsa-public-key should return an ECDSA public key in Multikey format, for example:

dereferenced された URL、:example:2g55q912ec3476eba2l9812ecbfe#ecdsa-public-key は、例えば次のような Multikey 形式の ECDSA 公開鍵を返すべきです。

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/multikey/v1"
  ],
  "id": "did:example:2g55q912ec3476eba2l9812ecbfe#ecdsa-public-key",
  "type": "Multikey",
  "controller": "did:example:2g55q912ec3476eba2l9812ecbfe",
  "publicKeyMultibase": "z42twTcNeSYcnqg1FLuSFs2bsGH3ZqbRHFmvS9XMsYhjxvHN" 

}

Note that the value of the verificationMethod property may have been the public key itself, instead of a reference to a separate resource containing the key.

検証方法プロパティ（verificationMethod）の値は、キーを含む別のリソースへの参照ではなく、公開キーそのものである可能性があることに注意してください。

proof内のverificationMethodのプロパティに設定されたdidに関連するdid documentから公開鍵を取得するわけですね。（注意書きにもある通り公開鍵そのものが設定されるケースもある）

ということでこれでSecuring credentialsの章はおしまいです。

次から本文の最後となるbitstring statuslistの話です。要するにCredentilasのRevokeをした場合のステータスをどうやって表すのかという話ですね。

ではまた次回。

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

It is often useful for an issuer of Verifiable Credentials to link to a location where a verifier can check to see if a credential has been suspended or revoked. This additional resource is referred to as a "status list".

The simplest approach for a status list, where there is a one-to-one mapping between a Verifiable Credential and a URL where the status is published, raises privacy as well as performance issues. In order to meet privacy expectations, it is useful to bundle the status of large sets of credentials into a single list to help with group privacy. However, doing so can place an impossible burden on both the server and client if the status information is as much as a few hundred bytes in size per credential across a population of hundreds of millions of holders. The Bitstring Status List v1.0 [VC-BITSTRING-STATUS-LIST] specification defines a highly compressible, highly space-efficient bitstring-based status list mechanism.

Conceptually, a bitstring status list is a sequence of bits. When a single bit specifies a status, such as "revoked" or "suspended", then that status is expected to be true when the bit is set and false when unset. One of the benefits of using a bitstring is that it is a highly compressible data format since, in the average case, large numbers of credentials will remain unrevoked. If compressed using run-length compression techniques such as GZIP [RFC1952] the result is a significantly smaller set of data: the default status list size is 131,072 entries, equivalent to 16 KB of single bit values and, when only a handful of verifiable credentials are revoked, GZIP compresses the bitstring down to a few hundred bytes.

検証可能な資格情報の発行者は、資格情報が停止または取り消されたかどうかを確認できる場所へのリンクを張ることが有用な場合があります。この追加リソースは「ステータスリスト」と呼ばれます。

検証可能な資格情報とステータスが掲載されている URL との 1 対 1 の対応関係があるステータスリストの最も単純なアプローチは、プライバシーとパフォーマンスの両面で問題が生じます。プライバシーに関する期待に応えるためには、多数の資格情報のステータスを 1 つのリストにまとめてグループとしてのプライバシー保護に役立てる方法が有効です。しかし、数百万人規模の保有者に対して、1つのクレデンシャルにつきステータス情報が数百バイトにも及ぶ場合、サーバーとクライアントの両方に不可能なほどの負担がかかる可能性があります。Bitstring Status List v1.0 [VC-BITSTRING-STATUS-LIST] 仕様では、非常に圧縮率が高く、スペース効率に優れたビットストリングベースのステータスリストの仕組みが定義されています。

概念的には、ビット文字列ステータスリストはビットのシーケンスです。1つのビットが「無効」や「一時停止」などのステータスを指定する場合、そのビットが設定されているときはステータスが有効、設定されていないときはステータスが無効であると見なされます。ビット文字列を使用する利点の一つは、圧縮率が高いデータ形式であることです。平均的な場合、多数のクレデンシャルは有効のままであるからです。GZIP [RFC1952] などのランレングス圧縮技術を使用して圧縮すると、データセットが大幅に縮小されます。デフォルトのステータスリストサイズは 131,072 エントリで、16 KB の単一ビット値に相当します。検証可能なクレデンシャルのうちごく一部にのみ無効化処理が実行された場合、GZIP 圧縮によりビット文字列は数百バイトにまで縮小されます。

図9. A visual depiction of the concepts outlined in this section.

The specification introduces the credentialStatus property, as well as some additional sub-properties, that should be used to add this additional information to a Verifiable Credential.

Example 11 shows our example from Example 9, combined with the information on the credential status: the purpose of that status information, the reference to the bitstring, and the index into this bitstring for the enclosing credential:

この仕様では、Verifiable Credential にこの追加情報を追加するために使用されるべき、credentialStatus プロパティと、いくつかの追加サブプロパティが導入されています。

例 11 は、例 9 の例に、クレデンシャルのステータスに関する情報を加えたものです。ステータス情報の目的、ビット列への参照、およびこのビット列の、クレデンシャルを囲むためのインデックスを示しています。

{
  "@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"
  },
  "credentialStatus": {
    "id": "https://university.example/statuslist#123456",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "123456",
    "statusListCredential": "https://university.example/CredentialStatusList"
  },"proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-rdfc-2019",
    "created": "2010-01-01T00:00:00Z",
    "expires": "2040-01-01T00:00:00Z",
    "verificationMethod: "did:example:2g55q912ec3476eba2l9812ecbfe#ecdsa-public-key""proofPurpose": "assertionMethod""proofValue": "zQeVb…Wx"
  } 

} 

The statusListCredential property, when dereferenced, should return a separate Credential for the status list. The status list itself is the subject of that Credential (which, of course, can also be signed). An example is:

statusListCredential プロパティは、参照解除されると、ステータスリスト用の個別のクレデンシャルを返します。ステータスリスト自体がそのクレデンシャルの対象となります（もちろん、署名することもできます）。例：

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "id": "https://university.example/CredentialStatusList",
  "type": ["VerifiableCredential", "BitstringStatusListCredential"],
  "issuer": "did:example:2g55q912ec3476eba2l9812ecbfe"",
  "validFrom": "2005-01-01T00:00:00",
  "credentialSubject": {
    "id": "https://university.example/statuslist#list",
    "type": "BitstringStatusList",
    "statusPurpose": "revocation",
    "encodedList": "uH4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA"
  } 

}

The core property in this case is encodedList, which is a base64url encoded version of the GZIP compressed bitstring status list.

このケースで重要なプロパティはencodedListで、GZIP圧縮ビット文字列ステータスリストのbase64urlエンコード版です。

まぁ、この辺りを含め以前書いたポストでカバー済みなので省略します。

一応これで本編は終わりです。

追加リソース部分は解説するかもしれませんししないかもしれません。 

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

DS-500と言っても行政マニアにしか通じないんだろうなぁ、と思いつつ私も少しだけお手伝いさせていただいておりました「行政手続きにおけるオンラインによる本人確認の手法に関するガイドライン」の令和5年度の中間とりまとめが公開されました。

論文中の選択的情報開示の概念の説明図より

Digital credentials represent digital versions of physical credentials. They are the cornerstone of digital identity on the Internet. In order to enhance privacy, different authors implement selective disclosure in digital credentials, allowing users to disclose only the claims or attributes they want. This paper gives an overview of the most influential articles for selective disclosure, a chronology of the evolution of the methods, and a list of strategies and approaches to the problem. We identify the categories of approaches and their advantages and disadvantages. In addition, we recognize research gaps and open challenges and provide potential future directions.

デジタル証明書は、物理的な証明書のデジタル版です。これらは、インターネット上のデジタルIDの基盤です。プライバシーを強化するために、さまざまな著者がデジタル証明書に選択的開示を導入し、ユーザーが開示したいクレームや属性のみを公開できるようにしています。本論文では、選択的開示に関する最も影響力のある論文の概要、手法の進化に関する年表、およびこの問題に対する戦略とアプローチの一覧を示します。また、アプローチのカテゴリーとその利点と欠点を特定します。さらに、研究におけるギャップや未解決の問題点を認識し、今後の方向性についても提案する。 

選択的開示（Selective Disclosure）がメインテーマではありますが、デジタルクレデンシャルそのものについても突っ込んだ言及がされていて面白いです。

Intro部分から飛ばしていて面白いです。

Unfortunately, this term is still used confusingly in different fields of computer science, computer security and cryptography because it is still evolving. A simple password is sometimes considered a digital credential; other times, a signed certificate is a digital credential.

 残念ながら、この用語はコンピュータサイエンス、コンピュータセキュリティ、暗号化のさまざまな分野において、まだ発展途上であるため、依然として混乱を招くように使用されています。単純なパスワードがデジタル認証と見なされることもあれば、署名付き証明書がデジタル認証と見なされることもあります。

まさに選択的開示（笑）※拾い物です

アトミック・クレデンシャル

選択的開示署名

ハッシュ値

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

もうすぐパリ五輪ですね。あまりスポーツに興味はありませんが。

Trusted Web推進協議会の実証事業でも色々とユースケースを集めて実証をしたわけですが、結局のところVerifiable Credentialsって何にでも使えてしまうところがあり、かつユースケースごとに微妙に要件が異なるわけで、結局何に使えるの？？みたいにぼやけてしまいがちです。

これもその一つではありますが、Indicio社がアスリートの健康情報の保護にVerifiable Credentialsを使う、というユースケースについて書いています。

Indicio社のBlogより引用

https://indicio.tech/better-athlete-health-data-protection-through-verifiable-credentials/

アスリートがつけるウェアラブルデバイスから取得できるデータをVerifiable Credentialsを使って検証可能な状態でやり取りしましょう、という話で、以下の利点があると記載されています。

1. チーム、大学、医療提供者、およびこのデータを保存していたすべての人の責任が免除されます。

2. アスリートは情報を完全に管理できます。情報を見る必要がある関係者と情報を共有することはできますが、データの所有者に問い合わせる必要があり、所有者はデータのすべてを共有するか、特定の部分だけを共有するかを選択できます。

3. すべてのデータが 1 つの便利な場所にまとめられているため、要求されたときに情報のすべてのソースを追跡する必要がありません。

4. データはソースと同じくらい信頼できると想定できます。データに変更があった場合、分散型台帳に表示され、認証情報が「破られる」ため、ユーザーは発行元との二重チェックや検証に時間を費やす必要がありません。

5. データは、アスリートのエージェントなどの信頼できるパートナーと簡単に共有でき、必要に応じてアスリートに代わってデータを共有できます。

Trusted Webの実証事業でORPHEさんがやっておられたシューズの事例とかシミックさんがやっておられた治験データの事例に近いシナリオですね。

まぁ、データセキュリティに関する話なのでどの分野でも適用可能って言われたらそこまでですが、こうやって事例を増やしていくと見えてくるものもあると思うので、どんどんやっていけると良いですね。

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

昨日のアスリートの健康情報に続きプラスチック製品のリサイクルへの適用の事例の話です。

ご存知の通りEUでは諸々の排出量規制が厳しく、リサイクルも注力されている分野の一つです。

今週2024/7/18に既存のEcodesign Directive 2009/125/ECに変わる規制としてESPR（Ecodesign for Sustainable Products Regulation）が施行される予定ですが、その中には「Digital Product Passport」というものがあります。

どういうものか上記ESPRのサイトに記載があります。

The ESPR will introduce a Digital Product Passport (DPP), a digital identity card for products, components, and materials, which will store relevant information to support products’ sustainability, promote their circularity and strengthen legal compliance. 

This information will be accessible electronically, making it easier for consumers, manufacturers, and authorities to make more informed decisions related to sustainability, circularity and regulatory compliance. It will allow custom authorities to perform automatic checks on the existence and authenticity of the DPPs of imported products.

Information to be included in the DPP will be identified by the Commission, in close consultation with all relevant stakeholders, and will depend on the specific product in question. This information can include:

• Product’s technical performance
• Materials and their origins
• Repair activities
• Recycling capabilities
• Lifecycle environmental impacts

ESPRは、製品、部品、原材料のデジタルIDカードであるデジタル製品パスポート（DPP）を導入します。DPPには、製品の持続可能性をサポートし、循環利用を促進し、法的コンプライアンスを強化するための関連情報が保存されます。

この情報は電子的にアクセスできるため、消費者、メーカー、当局が、持続可能性、循環型経済、法規制遵守に関するより情報に基づいた意思決定を容易にします。また、輸入製品のDPPの存在と真正性を、税関当局が自動的に確認できるようになります。

DPPに記載される情報は、欧州委員会がすべての関係者と緊密に協議した上で決定し、対象となる特定の製品によって異なります。この情報には、次のようなものが含まれます。

• 製品の技術的性能
• 材料とその原産地
• 修理活動
• リサイクル能力
• ライフサイクルにおける環境への影響

要するにモノを対象としたデジタルIDカードであるデジタル・プロダクト・パスポート（DPP）はリサイクルを含むモノのトレーサビリティを担保するためのものになるようです。

モノのIDということでGS1を思い出すと思いますが、やはり既にGS1ヨーロッパがリリースを出していますね。

https://gs1.eu/activities/digital-product-passport/

GS1ヨーロッパのページより

既に一部の企業がAgro2Circularと連携してプラスチック製品のリサイクル分野でのDPP適用の実験なども行っているようです。

https://www.linkedin.com/pulse/piloting-digital-product-passport-plastic-recycling-dominique-guinard-sdu4e/

IOTAを使っているみたいです。

GS1標準スキーマをうまく使いつつデータ表現はVCみたいですね。

今後、日本においてもEUとの貿易を考えるとトレーサビリティ文脈でVCを利活用するケースも必要になってくるのかも知れませんね。