鹿島神宮参拝証明書(ダミー)

あなたが、X年X月X日に参拝したことを証明します。


ここに確認用のQRコードを貼り付け。CLIPで読み込むと確認情報が表示される。

[url] ?check=[証明書ID]:[有効期限]:[ハッシュ値]

===

[url] → おそらくCLIPをさすのかな。
間違えてノーマルカメラで読み込んだらCLIPが自動起動するとか。

[証明書ID]
証明書の情報をあらわすユニークID。32桁程度の英数字。
CLIPユーザに証明書が登録される毎に発行される。
このIDは、ユーザID+カウンター でも良いし、
ユーザID+発行者ID+カウンター でも良さそう。
セキュリティ的にはハッシュ等が良さそう

証明書ファイルには、
所有者ID、発行日、登録日、証明日時、発行者、説明文・依頼文・契約内容、
有効期限、変更履歴、証明補強履歴 などが格納されるが、
証明書ファイル中に、別サーバ(証明書発行団体)からのデータ取得指示(たとえば管理コードでの指示)があれば、指定サーバから取得して内容を表示する。

CLIPでの確認者へは、上記のデータを元にして、確認に必要な事項が表示される。

[有効期限][ハッシュ値]

これらは、証明書を紙に印刷して、そこにあるQRで確認するなどの場合に使用する。
もしくは、CLIPで表示中、確認者から後ほどに悪用されないように、
一時的な確認で良い場合には、証明書ファイルIDを一時的に変更し、元の証明書ファイルIDを外部に漏洩しないようにした上で、有効期限・ハッシュ値などで制限する。

CLIPで確認が終了した場合、チケットなど消し込みが必要だったり、確認者と被確認者の両側で、証明書ファイルの内容を変更したり、ギフトカードが発生したりする場合もある。コンサート等で入場用のチケットとして利用した後、自動的に「参加証明書」になったり。
※チケットシステムの場合は、別途業者側には、発行システム・消し込みシステムが必要と思われる。
※「相手の何かを保証する」「誰かに保証してもらう」となると、別の手順が必要。
たとえば、100名山等の登山証明の場合、自分で現地に行って自分で登録した場合は良いが、過去に踏破したことを「誰かに証明してもらう」となると、たとえば、相手に写真やなにかを見せて、「客観的に見ても確かにx年X月X日に踏破したと認められる」と証明してもらう。
※名刺交換・データ交換の場合は、自分のQRを見せて、相手が読み込むと、「出会い証明書」「お友達証明書」などが生成されるとか。ついでにSNSや電話番号や住所など、公開可能であれば、その証明書に記載OKにしておくと、のちほど、電話帳など他のアプリに転送できるとか。