署名を失うことなく開示する

デジタル製品パスポートに表示される情報は、人によって異なります。購入者は公開データのみを確認できます。修理業者や再生業者はそれ以上の情報を確認できます。市場監視当局はすべての情報を確認できます。この点は明確化されており、欧州規格でも現在では明示的に規定されています。

興味深い疑問は、もっと控えめな形で提起されます。もし誰かが公開データ以外の保護されたフィールドを開示された場合、その人が「まさにこれらのフィールドこそが本物である」ということを証明できるのでしょうか？それとも、プラットフォームがそれらを正しく抽出し、変更を加えずに転送したと信頼するしかないのでしょうか？

ほとんどのプラットフォームにおいて、正直な答えは「信頼」です。私たちは、その答えが「証明」となるようにプラットフォームを構築しました。公開フィールドだけでなく、開示時に初めて追加されるあらゆるフィールドについても同様です。なぜこの違いが重要なのか、そしてなぜ私たちはそのために手間のかかる道を選んだのか。

アクセスルールはすべて同じ基準を満たす

DPPにおけるアクセス権、セキュリティ、機密性に関する欧州規格であるEN 18239 ## は、データ要素ごとのアクセス制御を要求しています。つまり、各フィールドについて、誰が閲覧できるかを定めたルールが存在します。これは適切な要件であり、満たすことは難しくありません。 これらの規格がそもそもどのような地位にあるかについては、調和規格で詳しく解説しています。

これを実現する一般的な方法は、サーバー側でのフィルタリングです。サーバーは、誰がリクエストしているかを把握し、そのユーザーが閲覧を許可されている内容を照会して、まさにその部分のみを返します。アクセス制御：完了です。規格が求めるのはこれだけです。

しかし、規格では触れられていない問題点が一つあります： そのデータは署名なしで届きます。読者は自分用にまとめられたビューを受け取り、サーバーが誠実に選択を行い、転送中に何も変更されていないと信じるしかありません。公開用の情報シートであれば問題ありません。しかし、データ処理者が中古バッテリーの価格設定の根拠とするような重要なデータの場合、それはあまりにも大きな信頼を強いることになります。

単一の署名には限界がある

当然の解決策は、データに署名することです。両極端のケースでは、通常の署名がうまく機能します。公開ビューに署名し、完全なデータセットに署名し、サーバーを介さずに公開鍵で双方を検証するのです。 その詳細な仕組みについては、DPPにおける署名と証明書に記載されています。

問題は中間にあります。文書全体に対する署名は、署名時に存在していたフィールドのセットを正確に1つだけカバーします。 権限のある読者に、保護されたフィールドを追加で公開した場合、そのフィールドは署名された範囲外となり、読者に届く際には保護されていない状態になります。代わりに最初からデータセット全体に署名すれば、署名はすべてをカバーしますが、その場合、すべての人に対してすべての内容を公開しなければならなくなります。

そのため、その中間にある段階――修理業者、保険会社、リサイクル業者――は網の目から漏れてしまいます。「誰が何を見るか」というあらゆる組み合わせを事前に署名しようとすれば、組み合わせごとに個別の署名済み文書が必要となり、アクセスグループが増えるごとに組み合わせの数は爆発的に増加してしまいます。 そんなことは誰も行わない。結局、署名のないサーバーフィルターに頼ることになり、中間段階は再び「信頼」に委ねられることになる。

各フィールドを個別に署名する

より優れた仕組みがあり、我々はそれに基づいてプラットフォームを構築している。 完成したドキュメントを1つのブロックとして署名する代わりに、発行者は1回の署名処理で各フィールドを個別に指定します（標準規格に詳しい方のために：W3Cのecdsa-sd-2023規格に基づく選択的開示）。

各ビューは公開コアから始まる

各ビューは、同じ ### 公開フィールドから始まります。読者がそれ以外に目にする情報は、フィールドごとに追加されていきますが、それらのフィールドのそれぞれは、オフラインで、再署名することなく、またビューを構成した機関への信頼を必要とせずに、発行者の公開鍵に遡ることができます。 権利を主張しないフィールドは、単に存在しません。黒塗りされているわけではなく、そもそも存在せず、それらに関する情報は一切漏れ出ません。

一例：修理業者

これが具体的にどのように機能するかは、実際の運用例でわかります。 ある修理業者が、バッテリーに関する正当な利害関係を登録しました。これは、バッテリー規制で明示的に規定されているアクセスレベルの一つです。その業者のワークショップシステムは、APIキーを使用して当社のインターフェースにログインし、パスを取得します。

返答として返ってくるのは、購入者にも表示されるのと同じ公開パスですが、そこに1つのフィールドが追加されています。それは、権限のある閲覧者にのみ開示される「分解手順」です。別の文書でも、特別版でもなく、同じパスに1つのフィールドが追加されただけです。

その事業者がこのフィールドを信頼する前に、同社のソフトウェアは、添付された証明情報を発行者の公開鍵と照合して検証します。検証が成功し、特に追加されたフィールドについても問題がないことが確認されれば、その事業者は「このマニュアルは文字一つまでメーカーから直接提供されたものであり、当社も、その過程に関わるいかなる者も内容を改変していない」と確信します。 検証に失敗した場合も、同様に確実にそれを把握し、そのビュー全体を却下します。

私たちの関与は意図的に最小限に抑えられています。ユーザーが正当に受け取るべきフィールドのみを受け取るようにすることは、私たちのアクセス制御の役割であり、これはどのサーバーフィルターでも同様に実現されています。 新しいのは、その次のステップだ。届いたものが本物かどうかは、私たちに確認することなく、彼自身が検証する。

なぜ「破損していない」ことが肝心なのか

公証人が、手紙全体ではなく、各段落を個別に認証すると想像してみてほしい。その公的な文書は誰もが受け取る。 それ以上の権利を持つ人には、追加の段落が渡され、そのそれぞれには引き続き同じ公証人の印章が押されています。

なぜ 「破損していない」ことが重要なのかについては、もう一言説明が必要です。無傷の印章は、内容が真実であることを示すものではありません。 それは、「発行者がまさにこれを書き、それ以来誰もその一文字も変更していない」ということを示しているに過ぎません。これにより、単に文書を転送しただけの者――中間保存先、ネットワーク、アーカイブ、そして私たち――は、信頼性の問題から除外されます。誰があなたにパスポートを渡したかは、もはや重要ではありません。

そして、封印は二値的です。有効か無効か、その中間はありません。もし封印が破られた場合、どの文が改ざんされたかは分かりませんが、その文書全体を信頼できなくなったことだけは分かります。したがって、追加の欄に封印が施された状態で届くか、そうでないかには、程度の差などありません： 印章がなければ、証拠の信頼性が多少低下するのではなく、そもそも証拠として成立しないのです。

両方の閲覧方法

誰でも自分で確認できます。「Transpareo Time Machine」は、製品パスポート用のオープンソース閲覧アプリです： このアプリは、パスのバージョン履歴を閲覧しながら、当社のサーバーに問い合わせることなく、閲覧者のブラウザ上で各署名を再計算します。2つのサンプルパスが公開されています。Tシャツのパスには文書全体に対する署名があり、電池のパスにはフィールドごとの開示が行われています。

いずれも公開されているW3C仕様です。文書全体に対する署名にはeddsa-jcs-2022、フィールドごとの開示にはecdsa-sd-2023が使用されています。希望する方なら誰でも実装可能です。 手間がかかることが、多くの人が実装しない理由です。文書全体への署名は、構築・運用コストがはるかに安く、公開データのみを提供する場合にはそれで十分です。

Time Machineが両方の方式に対応しているのは意図的なものであり、今後もそのままであります。Time Machineは特定のプラットフォームに属していません。 より高コストな方式のみを受け入れる検証者は、私たちにとっては有用であっても、それ以外の誰にとっても役に立たない存在となるでしょう。

保護されたフィールドが誰に開示されるのか

公開データ以外に、一体誰に何が開示されるのか、問う価値があります。 それは、たまたま立ち寄った購入者ではありません。彼女には公開パスが提供されるだけです。開示されるのは、中古バッテリーパックの価値を査定する処理業者、リスクの価格設定を行う保険会社、化学物質を分別するリサイクル業者、そして事件の立件を行う当局です。 これらは、金銭や安全が懸かった意思決定を行う読者たちです。

そして、まさにこれらの項目こそが、従来のアプローチでは開示されないままになっているのです。暗号化された証明を最も必要とする人々が、皮肉なことに、自らの意思決定の根拠となる項目についてのみ、その証明を得られないのです。

私たちは、認証マークは誰にとっても同じ意味を持つべきだと考えています。 「Transpareoにより検証済み」という表示は、修理業者の詳細画面においても、購入者の公開パスにおいても、同じ意味を持ちます。表示されているすべての情報は発行元から提供されたものであり、それ以降一切改ざんされていないということです。 公開フィールドのみに付与される認証マークは、不完全なものです。

規格が求める以上のもの

率直に申し上げますが ## 、これらはいずれも義務付けられているものではありません。EN 18239規格はアクセス制御を要求しており、サーバー側のフィルターによってアクセスは適切に制御されています。 公開フィールドを暗号学的に検証可能にすることも、私たちが追加で行っていることであり、規制によって義務付けられている要件ではありません。

まさにそれゆえ、これを明記する価値があるのです。署名付きパスポートの真の意義は、誰もプラットフォームを信頼する必要がないという点にあります。 中間段階を例外として除外することは、まさに署名が排除しようとしていた「信頼」を再び呼び戻すことになります。

同じ原理により、## あるフィールドが忘れ去られてしまう

各フィールドについて個別に規定することは、もう一つの特性をもたらしますが、これは実際に欧州法によって要求されているものです。 一般データ保護規則は、個人に個人データの削除を求める権利を認めています。 ブロックとして署名されたデータセットは、自身の署名を無効にすることなく、この要件を満たすことはできません。

ここでは各フィールドが独立しているため、個々のフィールドを削除しても、残りの部分は引き続き検証可能です。万が一、パスポートに個人データが誤って含まれてしまった場合でも、それらは完全に削除され、パスポートは有効なまま維持されます。再発行の必要もなく、履歴が途切れることもありません。 法律で保存が義務付けられている規制関連のフィールドはそのまま残され、削除可能なものは、要求があれば数年後であっても削除できます。

それでも、ごく普通のパスポートです

これらの機能によって、このパスポートが当社のツールでしか開けない特別なオブジェクトになるわけではありません。これは、Web標準の世界が目指すフォーマットであるJSON-LD形式の「検証可能クレデンシャル（Verifiable Credential）」であり、国連透明性プロトコル（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つが互いに独立して導出されます。単一の公開フィールドに対しても、2つの署名と2つの互いに独立した認証機関が存在するのです。

私たちにとって、この手間は正当なものです。 検証可能性は後付けで追加したものではなく、プラットフォームは最初のバージョンからその概念を中核として構築されています。各パスポートは公開時に署名され、前のバージョンにチェーンされます。改ざん不可能な10年間のアーカイブが構築されており、パスポートがEU-DPP-Registerに登録されるとすぐに有効になります。ブロック全体ではなく各フィールドごとに署名を行うことは、この中核機能の拡張であり、もともとその目的で設計されていなかったものに後付けで機能を追加したものではありません。

現状

私たちは、すべての読者に対してその有効性を証明することを選択しました。なぜなら、認証マークは、誰が確認しても同じ意味を持つべきだからです。その仕組みを確認したい方は、上記でリンクした2つのデモを、サーバーに問い合わせることなく、ブラウザ上で直接検証してみてください。