このシステムの仕様のまとめです。
まずはデータベースに定義されるテーブルを整理します。
あらゆる登場人物を管理するテーブルです。 登場人物には、一般市民やECサイト・集荷業者・配送業者・不動産屋などの法人が含まれます。 配送業者、不動産屋などの Read権/Write権 を持つ法人は、審査や契約などで縛られます。
住所トークン発行権を管理するテーブルです。 住所トークン発行権のリクエストも同時に管理します。
権利の所有者(ECサイトなど)・住所発行の対象者(一般市民)・永続か否かのフラグ、リクエストURLを構築するためのランダム文字列を持ちます。 また、リクエストの状況を表すステータスも持ちます。
住所発行の対象者が生成し、権利の所有者となる予定の人にURLを送り、権利の所有者がリクエストが完成させます。 その後、住所発行の対象者がリクエストを許可することでトークン発行権が付与されます。
実際に発行された住所トークンを管理するテーブルです。 トークン文字列・発行日時・発行者・利用者・住所発行の対象者・読み取り可能者の情報を持ちます。
発行者は実際にトークンを発行した人で、利用者は実際にトークンを利用する人を指定します。 具体的には、ECサイト上のマーケットプレイス業者など、発行権を持つ主体と商品を発送する主体が違う場合などに使います。
読み取り可能者は配送業者などを指定します。
認証/認可のシステムはOAuthを利用するので、そのOAuthアプリケーションを管理するテーブルです。 企業などに対して、審査や契約を経た上でアプリケーションIDが発行されます。 アプリケーションの所有者・可能なスコープの情報を持ちます。
OAuthのアクセストークンを管理するテーブルです。 アプリケーションID・対象ユーザ(リソースオーナー)・スコープとトークン文字列、トークンシークレットを持ちます。 一般的なアクセストークンの構成物ですね。
Read/Write権のスコープを持つアクセストークンは、特殊なアクセストークンです。 リソースオーナーは配送業者などのユーザで、アプリケーションIDもそのユーザに紐づくアプリケーションである必要があります。 ひとつのユーザが無限個のアクセストークンを発行でき、例えば配送員の端末ひとつひとつにすべて違うアクセストークンを設定します。
ECサイトなどOAuthアプリケーション利用契約が成立している場合は、ユーザのアクセストークンを取得し、住所トークン発行権を生成します。 一般市民の場合は、システムが用意するトークンリクエストの仕組みを使います。
住所トークン発行権が取得できたら住所トークンを発行します。 住所トークンには利用者と生成日時が記録されていて、トークンの検証に使われます。
住所トークンは、QRコードの形で表現でき、端末で読み取ったり印刷したりできます。 利用者は住所トークンを他者に転送することで、目的を達成します。 具体例として、荷物に貼り付けコンビニに持ち込み(他者に転送)、目的である荷物の配送を達成します。 住所トークンを読み取る/通過する側は、利用者や生成/印刷日時の検証をします。
最終的に住所トークンを受け取るのは Read権を持った業者です。 住所トークンを通過させる業者が一番不正を行いやすい ので、最終的な検証を厳重にします。 業者はシステムにトークンを問い合わせ、実住所を得ます。
このシステムに置いて非常に重要なのは、実住所にアクセスされないこと と IDを一致されないこと のふたつです。
実住所の読み取りは、住所トークンに指定された読み取り可能者と一致するデバイスでしか行えないので安全です。 リード権を持たない攻撃者には当然読めませんし、リード権を持っていても他者の荷物は読み取りできません。 唯一、デバイスの紛失・強奪には脆弱 ですが、端末自体の認証設定とアクセストークンの素早いRevokeで対処できます。
また、実住所にアクセスされないという点で、特定の人物のみアクセスを拒否できる必要があります。 具体例を挙げると、特に女性にとって 脳と下半身が直結しているような危険な配送員をブロックしたい という需要が確実に存在します。 配送員は特定のデバイスのアクセストークンと紐付いているので、アクセストークン単位でブロックできる仕組みを導入します。 ブロックされたデバイスで次の荷物の住所トークンを読み取ろうとすると、単純に読み取り不許可のエラーを返します。 重要なのは、逆恨み等を避けるため 誰かにブロックされているのはわかるが、誰にされているのかわからない 状態にすることです。1
IDの一致に関しては、ユーザを識別する識別子はランダムなアクセストークンのみであり、 生IDはおろか生IDから生成した識別子すらOAuthアプリケーションには見せないという方針にします。 信用できないECサイトで複数回買い物をする場合、OAuth認証画面が出るたびに別のアクセストークンが発行されるので、意図的にアクセストークンをRevokeすることでユーザ特定を不可能にします2。 ただし、この仕様から当システムのOAuthをIDプロバイダとして利用することはできません。