case-7.md

ケース7: 配送依頼(大規模)

ECサイトのような大規模な配送依頼を考えてみましょう。 もちろん自動化がとても重要です。

登場人物

ケース6と同じです。ただし、送信者 は 集荷業者 を兼ねます。

ポイント

ケース6と違い、送信者 は印刷装置を持っていて、送り状 を自ら印刷します。 また、送信者 は 配送業者 に直接配送の依頼します。 ケース6で 集荷業者 がやっていた本人確認は、配送業者 が直接行うことになります。

シーケンス

1. 送信者 は住所トークンを取得します。
2. この住所トークンは、送信者 がECサイトなら自ら作り、マケプレ業者 ならECサイトが作ったものが転送されます。いずれにせよ、住所トークンの 発行者名義 は 送信者 自身になります。
3. 送信者 は住所トークンを印刷し、荷物に貼り付けます。
4. 送信者 は 配送業者 に荷物の引取を依頼します。またはルート集荷のような仕組みが既に構築されているかもしれません。
5. 配送業者 は 住所トークンの発行者名義が 送信者 であることを確認して、荷物を集荷します。

懸念点

配送業者 は トークンの発行名義と 送信者 の一致を確認するので、不正に取得した(送信者 が違う)住所トークンを紛れ込ますことはできません。 ただ、この確認作業の効率を考えると、 配送業者が荷物を集荷しに行く という構図が事実上強制されます。 なぜなら荷物を持ってきた人間は身元確認が必要ですが、荷物を集荷しに行けばそれはほとんどの場合保証されるからです。

ケース6の 集荷業者 に集められた個人の荷物も、同じように ルート集荷 で 配送業者 が集荷していくことになると予想されますが、ひとつ問題点があります。 ケース6の荷物は それぞれ本人の発行者名義 なので、 配送業者 は本人確認できません。 そのため、 集荷業者 の本人確認を信頼して 配送業者 は無条件で荷物を受け入れるしかありません。 この抜け道から、 攻撃者 が 集荷業者 になりすまし¹、不正な荷物を紛れ込ませることが可能です。

この問題は、システム的に解決するのは難しいですが、相手はコンビニなどの業者なので 契約と裁判 で解決可能です。 どれほど作り込まれたシステムよりも 契約と裁判 は有効なセキュリティです。

Footnotes

1. コンビニのバイトに応募し採用されればなりすましが成立する ↩