署名付きレシートは、正確で範囲の限られた記述です。有効なTrustviceのレシートが立証する3つのこと、立証しない多くのこと、お客様がなお当社を信頼している点、そして誰も過大に語らないようにレシートを提示する方法を、丁寧に説明します。
執筆：The Trustvice team約5分で読了
暗号による証拠は、過大な主張を招きがちです。「署名済み」は「真実」のように聞こえ、「改ざん検知可能」は「認証済み」のように聞こえます。どちらも正しくありません。監査、契約、紛争でTrustviceのレシートを使うなら、最も価値があるのは、それを正確に記述することです：示している以上のことも、それ以下のことも言わないことです。
この記事は、その記述です。慎重な弁護士、監査人、相手方がレシートに依拠する前に読んでほしいページであり、当社のドキュメントがすでに述べていることを、あえて繰り返しています。
公開されたTrustviceの鍵に照らして検証されたレシートは、3つのことを証明します。
出所。 エンベロープは、signatureKeyIdに対応する秘密鍵の保持者によって署名されています。それはTrustviceの署名鍵です。お客様を含め、ほかの誰も、その鍵に照らして検証されるレシートを作ることはできません。
完全性。 signature以外のエンベロープのすべてのメンバーが、署名されたとおりの状態です：type、body、issuedAtの時刻、そして鍵ID。1文字でも変えれば、検証は失敗します。
署名された時刻。 Trustviceは、レシートがissuedAtに作成されたと主張します。これは発行者自身の時計です。
この3つは誰でも、オフラインで、アカウントなしで、当社に問い合わせることなく確認できます。確認は決定的です：2つの独立した実装に同じレシートと同じ鍵を与えれば、同じ答えにたどり着きます。それがレシートの強みであり、それは本物です。
限界を挙げる前に、個々のレシートがどれだけの意味を持つかを左右する、1つの区別があります。
レシートが述べる事実には、誰かがTrustviceに提供した事実（提示されたことを示すために署名されたもの）と、Trustvice自身が実行した、または確認したことについての事実があります。申告された事実のレシートは、それらがissuedAtまでに提示されたことを証明し、観測された事実のレシートは、Trustviceが確認した内容を証明します。どちらの場合もレシートの見た目は同じなので、手元のレシートがどちらかはレシートの種類で確認してください。
これらは欠陥ではありません。主張の境界です。
ハッシュについてのレシートが対象にするのはハッシュです。虚偽の文書のハッシュも、真実の文書のハッシュとまったく同じように検証されます。プロンプトと応答のような申告されたやり取りについてのレシートは、そのやり取りがある時点で提示されたことを証明するものであり、記述どおりに起きたことを証明するものではありません。
それでも、申告された事実のレシートが与えてくれるものには価値があります：主張を時刻に固定するため、こっそり日付を遡らせることはできず、後からのどんな変更も検知できます。
エンベロープは、ワークスペースやアカウントの識別子も、個人の署名も持ちません。そのJSONを持っている人なら誰でも提示できます。ハッシュが特定するのはバイト列であって所有者ではありません：ほかの誰も同じコンテンツを持っていないことは示しません。作成者が重要なら、コンテンツの内部にご自身の署名を入れてください。
レシートが保持するのはハッシュです。文書が一致することを示すには、その文書をハッシュ化して本文と比較してください。レシートが役に立つのは、そのコンテンツを提出できる場所に保管している場合だけです。
issuedAtは、署名時点の当社の時計です。申告された事実の場合、出来事はレシートより前のある時点で起きています。レシートは、いかなる法制度における適格タイムスタンプでもありません。出来事とレシートの間隔よりも細かい精度を主張しないでください。外部の基点が必要な場合は、独自の信頼できる時計を持つ場所に、レシートの署名を公開してください。
レシートが証明するのは、そこに書かれていることであって、書かれていないことではありません。レシートの空白は、何も起きなかったことの証明にはなりません。それはお客様に有利にも不利にも働きません。
失効の仕組みはありません。発行時に検証されたレシートは、その署名鍵が公開されている限り検証され続けます。鍵の失効リストもありません。署名鍵が漏洩すれば、その保持者は検証に通るレシートを作れてしまい、署名の確認だけではそれを本物と区別できません。
検証によって、多くの点で当社を信頼する必要がなくなります：レシートが改変されたかどうか、どの鍵が署名したか、中の鍵がすり替えられたかどうかを、当社に教えてもらう必要はありません。残るのは、名前の付いた小さな集合です：
Trustvice 360
xの値を固定し、そのコピーに照らして検証してください。紛争で最も強い立場をとるには、レシートを、お客様ご自身が管理する記録と組み合わせてください。
レシートがお客様の手を離れるとき、短い添え状があれば、誤解のほとんどを防げます。よい添え状は5つのことを行います：
4d9a…7d62をTrustviceに提示した。」trustvice.comから自分で鍵を取得してもらいます。そうすれば、お客様が渡した鍵ファイルに頼らずに済みます。当社のガイド紛争のための証拠では、その全体の流れを紹介しています：紛争の前に、どの主張が必要になるかを決めておくこと、物事が起きた瞬間にレシートを残すこと、そして相手方がお客様を信頼せずに検証できる証拠一式をまとめることです。
ある裁判所、規制、契約の場面でレシートが証拠として認められるか、あるいは十分かどうかは、法域と事案によって異なります。レシートは、署名サービスに提示されたもの、または署名サービスが観測したものの技術的な記録です。法的助言でも、認証でも、法令遵守の証明でもありません。ご自身の弁護士に相談し、公開鍵に照らして検証されたレシートを、そこに記載された事実の証拠として双方が受け入れることを、契約に書き込むことも検討してください。
はっきり述べられた限界は、主張よりも多くの信頼を築きます。レシートの有用性は、人々がそれをどれだけ正確に説明するかで決まるからです。当社自身のページがレシートの証明する内容を誇張している箇所を見つけたら、/contactからお知らせください。修正いたします。
Trustviceのレシートは、お客様の文書、プロンプト、応答の本文ではなく、SHA-256ハッシュとメタデータに基づいています。その選択の背後にあるプライバシー設計、それが守るもの、そしてそれだけではお客様を守れない場面についてご説明します。
約3分で読了
Trustviceのレシートのエンベロープをフィールドごとに見ていきます。なぜ送信されたバイト列ではなくRFC 8785の正規形に署名するのか、鍵IDが鍵そのものからどのように導出されるのか、そして公開された鍵セットが何を約束するのかを解説します。
約6分で読了
Two correct RFC 8785 implementations can still disagree on key order, big numbers and unpaired surrogates. We walk through each edge case in JavaScript and Python, what our canonicalizers do, and how shared test vectors catch drift.
約8分で読了
Trustvice のレシートを検証ツールに貼り付けてください。公開鍵を使って、ブラウザ内で署名を確認します。アカウントは不要です。
