ECサイトから一旦離れて、個人間のやり取りを考えてみます。 個人間なので、個別のシステムなどを持つことはまずできません。 当システム内のみで完結した住所トークンの発行フローが必要です。
荷物を出す側です。
荷物を受け取る側です。
荷物を運ぶ業者です。
プライバシーに対してリスクがあるのは住所を教える側なので、当然 教える側がリクエストに対して許可を出す という構図になります。
その一手前を考えると、 送信者 が リクエストのURL を伝えるか、 または 受信者 が リクエストを生成するためのURL を伝えるかのどちらかになります。
送信者 がリクエストのURLを勝手に作れてしまう前者の場合1、スパム的な運用がなされてしまう可能性があるので、
ここは 受信者 のタイミングでリクエスト生成を抑制できる後者の方法を使ったほうが安全でしょう。
一般人同士のやり取りでは、互いに面識も信用もない相手とやり取りする可能性を考えなくてはなりません。 なので、相手が特定できるIDや名前やアイコンなどがお互いに見えるべきではありません。 その条件では相手が本物かどうか完全に判定するの原理的に不可能ですが、プライバシーの保護を優先するべき だと思います。
送信者と受信者が荷物を送るという需要が発生します。リアルの知り合いかもしれませんし、twitterで知らない人とガチャのダブリを交換する目的かもしれません。送信者と受信者がメッセージをやり取りします。通信経路はメールやtwitterのDMなどの既存のものを使います。受信者は当システムでリクエスト生成URLを取得し、送信者に送ります。2送信者がリクエスト生成URLにアクセスすると、送信者と受信者が組になったリクエストが生成されます。3受信者はリクエストを受け取り、認可/拒否の判断をして、認可されれば送信者と受信者が組になった、配送業者だけが読める住所トークンが発行されます。受信者は送信者に住所トークンを伝え、送信者は配送業者に住所トークンを使って配送を依頼します。
この方式の最大の問題点は、リクエストを作成した人間が本物の 送信者 かどうか確定しないところです。
送信者 が第三者にリクエスト生成URLを横流ししたり、メッセージの通信経路が盗聴されている場合、
第三者が不正にリクエストを生成し、受信者 がそれを認可するとトークンが不正に取得されます。
実際、受信者 はリクエストの相手が本物か 全く判定ができない ので、実は認可作業をする意味はありません。
せいぜい、面と向かってやり取りをした場合にタイミングが正しいか確認できる程度です。
とはいえ、一度きり知らない人から何かが送られてくる程度の実害しか無いので、たいして気にしなくていいかと思います。 互いのIDを特定できないほうが遥かに重要です。