PP-TSAは、ファイルや記録のハッシュに署名付きデジタルタイムスタンプを発行するサービスです。元データをPP-TSAへ送ることなく、そのデータが記録時刻までに存在し、後から提示されたデータが当時のものと同じであることを確認できる証拠を残します。
元データはお客様の手元に残します。
自社システムで固有の指紋を作ります。
PP-TSAがハッシュと記録時刻に署名します。
返却tokenを元データと対応付け、必要なときに検証します。
連携方式：新しく自社実装するならREST API、対応済みの文書・署名ツールならRFC 3161。同じアカウントで両方利用できます。
送るのはハッシュだけです。PP-TSAは内容を見られず、データそのものはお客様の管理下に残ります。
署名付きタイムスタンプが指紋と記録時刻を結び付けるため、その時点は自社ログの記載だけに頼りません。
署名、証明書のつながり、公開台帳への登録は、年月が経ってからでも確認できます。
複製・差し替え・上書きは、ほとんど痕跡を残しません。監査、取引上の争い、成果物の引き渡しで説明が必要になったとき、自社では動かせない時刻に結び付いた正確なデータが必要になります。
更新日時、画面のスクリーンショット、自社だけが管理するログは、対象データと一緒に変更できる場合があります。
争いや引き渡しの場面で問われるのは、いま提示されたものが当時のものと同じかどうかです。ファイル名やサイズでは答えられません。
発行側の仕組みが変わったあとに再検証できない証拠は、いざ必要になった時点で役に立ちません。
1行ごとにひとつの主張と、その範囲外を明記しています。行をクリックすると詳細が開きます。
データのハッシュを、PP-TSAが記録した時刻とともに署名します。主張はその時点までの存在についてであり、作成者や内容の正しさについてではありません。
日付の遡り、そして保持者が書き換えられるファイル日時やスクリーンショットだけに頼った主張。
タイムスタンプが示すのは、記録時刻までにそのデータが存在したこと、そしていま提示されたものが同じデータであることです。誰が作成したか、内容が正しいか、権利が誰にあるかは示しません。台帳への包含は発行直後には保留の場合があり、pending・overdue・unknownを完了として扱うことはありません。
メールアドレスで登録すると、その場で組織用の環境が作られます。
月間の発行量に合わせて選択します。あとから変更できます。
完全なキーは発行時にしか表示されません。組織で決めた方法で記録してください。
ハッシュをローカルで計算し、HTTPSで呼び出します。返却tokenを元データと対応付けて保管し、独立して検証します。
自社システムでハッシュを計算し、JSONで /v1/timestamps へ送ります。Base64のtokenとmetadataが返ります。backend、Web service、CI pipelineに向きます。
TimeStampReqを /tsr へ送り、TimeStampRespを受け取ります。PDF、電子署名、archive製品がRFC 3161に対応済みの場合に選びます。
業種の問題ではなく、「その時点で存在したか」「提示されたものが当時のものと同じか」を示す場面で必要になります。
契約、見積、請求の確定版を固定し、後の争いが「どちらの控えが新しいか」ではなくデータそのもので判断されるようにします。
結果や図面、設計記録を、内容を誰にも開示せずに、生まれた時点でタイムスタンプします。
公開したbuildとその一覧を時刻に結び付け、出荷したものと後から作り直したものを区別できるようにします。
写真、測定値、点検logを検証できる形で残し、真正性が管理システムの表示だけに依存しないようにします。
証拠が信用されるかどうかは、何を預かるか、結果をどう返すかで決まります。どちらも最初から狭く定めています。
サービスが扱うのは指紋、algorithm、requestのmetadataです。元データの内容がPP-TSAへ届く経路はありません。
完全なAPIキーは発行時にしか表示されず、以後は再表示されません。紛失した場合は新しいキーを発行し、古いキーを失効します。
署名、証明書のつながり、timestampの状態、台帳への包含、失効状態を個別に返します。pendingやunknownを検証済みとして示すことはありません。
requestには必ずidempotency keyを含めます。結果が不明なときの再試行は、保存済みのrequest bytesと同じkeyを使い、発行を繰り返しません。