デジタル製品パスポートに表示される情報は、人によって異なります。購入者は公開データのみを確認できます。修理業者や再生業者はそれ以上の情報を確認できます。市場監視当局はすべての情報を確認できます。この点は明確化されており、欧州規格でも現在では明示的に規定されています。
興味深い疑問は、もっと控えめな形で提起されます。もし誰かが公開データ以外の保護されたフィールドを開示された場合、その人物は、まさにそのフィールドが本物であることを証明できるのでしょうか？それとも、プラットフォームがそれらを正しく抽出し、変更を加えずに転送したと信頼するしかないのでしょうか？
ほとんどのプラットフォームにおいて、正直な答えは「信頼」です。私たちは、その答えが「証明」となるようにプラットフォームを構築しました。公開フィールドだけでなく、開示時に初めて追加されるあらゆるフィールドについても同様です。なぜこの違いが重要なのか、そしてなぜ私たちがより手間のかかる道を選んだのか。
アクセスルールはすべて同じ基準を満たす
DPPにおけるアクセス権、セキュリティ、機密性に関する欧州規格であるEN 18239 ## は、データ要素ごとのアクセス制御を要求しています。つまり、各フィールドについて、誰が閲覧できるかを定めるルールが存在します。これは適切な要件であり、満たすことは難しくありません。 これらの規格がそもそもどのような地位にあるかについては、調和規格で詳しく解説しています。
これを実現する一般的な方法は、サーバー側でのフィルタリングです。サーバーは、誰がリクエストしているかを把握し、そのユーザーが閲覧を許可されている内容を照会して、まさにその部分のみを返します。アクセス制御：完了です。規格が求めるのはこれだけです。
しかし、規格では触れられていない問題点が一つあります： そのデータは署名なしで届きます。読者は自分用にまとめられたビューを受け取り、サーバーが誠実に選択を行い、転送中に何も変更されていないと信じるしかありません。公開用の情報シートであれば問題ありません。しかし、データ処理者が中古バッテリーの価格設定の根拠とするような価値あるデータの場合、それは過度な信頼を強いることになります。
単一の署名には限界がある
当然の解決策は、データに署名することです。両極端のケースでは、通常の署名がうまく機能します。つまり、公開ビューに署名し、完全なデータセットに署名し、サーバーを介さずに公開鍵で双方を検証するのです。 その詳細な仕組みについては、DPPにおける署名と証明書に記載されています。
問題は中間にあります。文書全体に対する署名は、署名時に存在していたフィールドのセットを正確に1つだけカバーします。 権限のある読者に、保護されたフィールドを追加で公開した場合、そのフィールドは署名された範囲外となり、読者に届く際には保護されていない状態になります。代わりに最初からデータセット全体に署名すれば、署名はすべてをカバーしますが、その場合、すべての人に対してすべての内容を公開しなければならなくなります。
そのため、その中間にある段階――修理業者、保険会社、リサイクル業者――は網の目から漏れてしまいます。「誰が何を見るか」というあらゆる組み合わせを事前に署名しようとすれば、組み合わせごとに個別の署名付き文書が必要となり、アクセスグループが増えるごとに組み合わせの数は爆発的に増加してしまいます。 そんなことは誰も行わない。結局、署名のないサーバーフィルターに頼ることになり、中間段階は再び「信頼」に委ねられることになる。
各フィールドを個別に署名する
より優れた仕組みがあり、我々はそれに基づいてプラットフォームを構築している。 完成したドキュメントを1つのブロックとして署名する代わりに、発行者は1回の署名処理で各フィールドを個別に指定します（標準規格に詳しい方のために：W3Cのecdsa-sd-2023規格に基づく選択的開示）。
すべてのビューは公開コアから始まる
すべてのビューは、同じ ### 公開フィールドから始まります。読者がそれ以外に目にする情報は、フィールドごとに追加されていきますが、それらの各フィールドは、オフラインで、再署名することなく、またビューを構成した機関への信頼を必要とせずに、発行者の公開鍵に遡ることができます。 アクセス権のないフィールドは、単に存在しません。黒塗りされているわけではなく、そもそも存在せず、そこから情報が漏れることも一切ありません。
なぜ「途切れない」ことが肝心なのか
公証人が、手紙全体ではなく、各段落を個別に認証すると想像してみてください。公開された手紙は誰もが受け取ります。 それ以上の権利を持つ人には、追加の段落が渡され、そのそれぞれには引き続き同じ公証人の印が押されています。通常のやり方では、プラットフォームがこれらの段落をあなたのために書き起こし、あなたの手元に届くものには、プラットフォームの言葉だけが記されているのです。
なぜ「破損していない」ことが重要なのか、もう一言説明しましょう。破損していない印章は、内容が真実であることを示すものではありません。それは、「発行者がまさにこれを書き、それ以来誰もその一文字も変更していない」ということを示しているのです。 これにより、単に文書を転送しただけの者――中間保存先、ネットワーク、アーカイブ、そして私たち――は、信頼性の問題から除外されます。誰があなたにパスポートを渡したかは、もはや重要ではありません。
そして、印章は二値的です。有効か無効かのいずれかであり、「半分破損している」という状態は存在しません。 シールが破られた場合、どの文が変更されたかはわかりません。ただ、その文書全体をもう信頼できないということだけがわかります。したがって、追加のフィールドがシール付きで届くか、シールなしで届くかというのは、程度の問題ではありません。シールがなければ、そのフィールドの信頼性が多少低下するのではなく、そもそも信頼性が全くないのです。
両方の確認方法
これは誰でも自分で確認できます。「Transpareo Time Machine」は、製品パスポート用の当社のオープンソース表示アプリです。このアプリは、パスポートのバージョン履歴を閲覧しながら、当社のサーバーに問い合わせることなく、閲覧者のブラウザ上で各署名を再計算します。 このアプリでは、2つのサンプルパスが公開されています。Tシャツのパスには文書全体に対する署名があり、電池のパスにはフィールドごとの開示情報が含まれています。
いずれも公開されているW3C仕様です。文書全体に対する署名にはeddsa-jcs-2022、フィールドごとの開示にはecdsa-sd-2023が使用されています。希望する方なら誰でも実装可能です。 手間がかかることが、多くの人が実装しない理由です。文書全体への署名は、構築・運用コストが大幅に安く、公開データのみを提供する場合にはそれで十分です。
Time Machineが両方の方式に対応しているのは意図的なものであり、今後もそのままであります。Time Machineは特定のプラットフォームに属していません。 より高コストな方式のみを受け入れる検証者は、私たちにとっては便利なツールとなるかもしれませんが、それ以外の誰にとってもそうではありません。
保護されたフィールドが誰に開示されるのか
公開データ以外に、一体誰に何が開示されるのか、問う価値があります。 それは、たまたま立ち寄った購入者ではありません。彼女には公開パスが提供されるだけです。開示されるのは、中古バッテリーパックの価値を査定する処理業者、リスクの価格設定を行う保険会社、化学物質を分別するリサイクル業者、そして事件の立件を行う当局です。 これらは、金銭や安全が懸かった意思決定を行う読者たちです。
そして、まさにこれらの項目こそが、従来のアプローチでは開示されないままになっているのです。暗号化された証明を最も必要とする人々が、皮肉なことに、自らの意思決定の根拠となる項目についてのみ、その証明を得られないのです。
私たちは、認証マークは誰にとっても同じ意味を持つべきだと考えています。「Transpareoにより検証済み」という表示は、修理業者の詳細画面においても、購入者の公開パスにおいても、同じ意味を持ちます。表示されているすべての情報は発行元から提供されたものであり、それ以降一切改ざんされていないということです。 公開フィールドのみに付与される認証マークは、不完全なものです。
規格が求める以上のもの
率直に申し上げますが ## 、これらはいずれも義務付けられているものではありません。EN 18239規格はアクセス制御を要求しており、サーバー側のフィルターによってアクセスは適切に制御されています。 公開フィールドを暗号学的に検証可能にすることも、私たちが追加で行っていることであり、規制によって義務付けられている要件ではありません。
だからこそ、これを明記する価値があるのです。 規格の条文を文字通り満たし、サーバーフィルターを提供して、この段階を完了したと宣言するのは簡単です。しかし私たちは、その認証マークが表示されるすべての場所で、その約束が守られることを望んでいます。なぜなら、署名付きパスポートの真の意義は、誰もプラットフォームを信頼する必要がないという点にあるからです。 中間の段階を例外として除外することは、まさに署名が排除しようとした「信頼」を再び呼び戻してしまうことになります。
同じ原則により、ある分野が忘れ去られてしまう
各分野について個別に規定を設けることには、もう一つの特徴が伴い、これは実際に欧州法によって求められているものです。 一般データ保護規則は、個人に個人データの削除を求める権利を認めています。 ブロックとして署名されたデータセットは、自身の署名を無効にすることなく、この要件を満たすことはできません。
ここでは各フィールドが独立しているため、個々のフィールドを削除しても、残りの部分は引き続き検証可能です。万が一、パスポートに個人情報が誤って含まれてしまった場合でも、それらは完全に削除され、パスポートは有効なまま維持されます。再発行の必要もなく、履歴が途切れることもありません。 法律で保存が義務付けられている規制関連のフィールドはそのまま残され、削除可能なものは、要求があれば数年後であっても削除できます。
それでも、ごく普通のパスポートです
これらの機能によって、このパスポートが当社のツールでしか開けない特別なオブジェクトになるわけではありません。これはJSON-LD形式の「検証可能なクレデンシャル（Verifiable Credential）」であり、Web標準の世界が目指す形式であると同時に、国連透明性プロトコル（UN Transparency Protocol）やその他のW3C環境でも採用されている形式そのものです。
つまり、購入者がブラウザでスキャンするパスポートは、データルームのパートナーが読み取ることができるものと同じオブジェクトであり、当社だけでなく、規格に準拠したあらゆる検証者がそれを検証することができます。この追加のセキュリティ機能は、読み取る側に一切のコストを課すものではなく、誰をも当社に縛り付けるものでもありません。
なぜ技術的に難しいのか
まず、誤解を招かないように前置きしておきますが、この手法を私たちが考案したわけではありません。ecdsa-sd-2023はW3Cの公開仕様であり、その基盤となる暗号技術は当社が開発したものではなく、実装を希望する方は仕様書を参照すれば確認できます。 アイデアを思いつくこと自体は難しくありません。難しいのは、10年後もパスポートが検証機能を維持できるように構築することです。そこに労力が費やされており、それについて有益なことが言えます。
その違いは些細に聞こえるかもしれませんが、根本的な部分を変えます。通常の署名は、文書のバイト単位で計算を行います。 一方、選択的開示は、その記述内容に基づいて計算を行います。パスポートは署名前に標準化された形式に変換され、各情報が独立した文として扱われます。これにより初めて、残りの情報を損なうことなく、特定の文を省略することが可能になります。
これにより、バイト単位の署名にはない問題が生まれます。つまり、10年後もまったく同じ標準化された形式が再現されなければならないのです。おおよそではなく、文字単位で正確に再現されなければ、証明として成立しなくなります。これを妨げる要因が3つあり、そのすべてが目立たないものです。
数値は型を失います。数値を単なるJSONとして記述すると、それがどのような数値であったかが途中で失われてしまいます。2.0のような値は、JSONを経由すると2として戻ってきます。人間にとっては同じ値でも、標準化された形式にとっては別の文となり、検証に失敗します。
名称だけでは意味にはなりません。標準化された形式を確立するためには、各フィールド名が一意の意味に解決されなければなりません。一つでも欠けると、変換の際にそのフィールドは黙って消えてしまいます。パスには記載されていても、証明ではカバーされず、誰もそれに気づかないのです。
意味は通常、ネット上に存在します。この対応関係は用語集に記載されており、ほとんどのツールは検証時にネット経由でそれを読み込みます。これを行う場合、パスポートの検証可能性は、10年後も外部のアドレスが変更されることなく応答し続けることに依存することになります。
私たちがどのように解決したか
私たちは、後で対処するのではなく、根本的な3つの ## 問題を解決しました。
型。すべての値はその型とともに記述され、標準化された形式に型のない数値が1つでも現れた時点で、公開は中断されます。 これにより、エラーは数年後に原因不明の検証違反として表面化するのではなく、1行分のコストで済む段階で検出される。
用語集。パスが参照するすべての用語集は、当社内にローカルに存在しており、ネットワーク経由で取得されることは決してない。 未知のアドレスは、署名処理の即座の中断を意味し、結果が空になるような静かな失敗にはなりません。
識別子。ドキュメント内の各ノードには安定した識別子が割り当てられており、これにより標準化された形式が再現可能になります。実行のたびに新しい補助名を割り当てる必要はありません。
最もデリケートな部分は「Bring Your Own Key（鍵の持参）」にあります。発行のたびに、公開可能なフィールドを個別に署名するための追加の一時的な鍵が必要となります。この鍵は発行者自身が生成し、使用後に破棄します。 もしその鍵が私たちの手元にあれば、後から個々のフィールドをでっち上げることも可能になり、発行者の署名の独立性は単なる主張に過ぎなくなってしまう。返送されてきた証明については、信頼する前に、登録済みの公開鍵と照合して検証を行う。
各パスには、発行者によるものとTranspareoによるものの2つの証明が含まれており、読者が閲覧する際には、これら2つが互いに独立して導出されます。1つの公開フィールドに対しても、2つの署名と2つの互いに独立した認証機関が存在するのです。
私たちにとって、この手間は正当なものです。 検証可能性は後付けで追加したものではなく、プラットフォームは最初のバージョンからその概念を中核として構築されています。各パスポートは公開時に署名され、前のバージョンにチェーンされます。改ざん不可能な10年間のアーカイブが構築されており、パスポートがEU-DPP-Registerに登録されるとすぐに有効になります。ブロック全体ではなく各フィールドごとに署名を行うことは、この中核機能の拡張であり、もともとその目的で設計されていなかったものに後付けで機能を追加したものではありません。
現状
要約すれば、選択肢は単純です。保護されたフィールドを公開し、読者にあなたのフィルタを信頼するよう求めることもできます――これでも基準は満たされます。あるいは、それらを公開すると同時に証明も併せて提供することもできます――これは、私たちの考えでは、これらのフィールドにふさわしい、より高い水準を満たすものです。
私たちは、すべての読者のために「証明」という道を選びました。なぜなら、認証マークは、誰が見ても同じ意味を持つべきだからです。その仕組みを確認したい方は、上記でリンクした2つのデモをご覧ください。これらはブラウザ上で直接、オフラインで、公開鍵のみを用いて検証されます。