Skip to content

Latest commit

 

History

History
46 lines (32 loc) · 2.96 KB

policy.md

File metadata and controls

46 lines (32 loc) · 2.96 KB

システムの方針

システムで解決すると言っても、本当にそのようなことができるのかまず検討してみないといけません。 前章でまとめられた住所の問題点をおさらいしましょう。

  • 個人ではなく場所に紐付いていること
  • 使い分けができないこと
  • 変更ができないこと
  • 公開情報であること

個人ではなく場所に紐付いていること

これは単純に個人に対して住所を発行すればいいだけです。 すべての人間に対して個別のアカウントを払い出す必要があります。 よくあるログイン機能を付けるだけで可能です。

使い分けができないこと

使い分けとは、例えばECサイトAとECサイトBに違う住所が使いたいという需要です。 これは一人のユーザに対して 複数個の住所を生成する 事ができれば可能です。 コンピュータの非常に得意なことですね。

変更ができないこと

無限に住所を生成できるなら変更ができないなんて悩みもなくなります。 もういっそのこと、すべて ワンタイム住所 にしてしまいましょう。 ワンタイム住所が実装できると、宅配便を取り扱うコンビニ店員が「いつも送る場所」などの情報を得ることができなくなります。 住所が 一度利用されたら無効化する という処理は、コンピュータでなければできない処理でしょう。

公開情報であること

公開情報というのは、誰もがその情報を 理解できる ということです。 例えばECサイトに登録した住所が流出したとき、その住所を使って郵便が送れてしまうのは、郵便局が住所を理解できるからです。 住所は 完全ランダムな文字列 を、 閲覧可能対象を指定して 発行し、閲覧者を認証し、閲覧可能対象かどうか認可する必要があります。 つまり、 アクセス権の制御 なのでまさにコンピュータの得意分野です。

まとめ

システムは本物の住所を隠し、アクセス制御されたトークン を発行します。 人類はそのトークンをやり取りすることで、安全に実住所を伝えることができます。

さらに、トークンにはRead権限だけでなく、 Write権限 の概念も拡張できます。 例えば不動産屋にWriteさせることにより、 自分の住所を全く知らないで済む 世界が実現できます。

アカウント登録、住所の自動生成、認証・認可などはどのWebサービスでも使われているのでもはや説明するまでもないでしょう。 本書では、様々な目的を持った登場人物に対して、実際どのような 認可フロー を設計すれば、住所のやり取りが自動化できるかを検討します。