こんばんは, ritouです。
本当は"話題の●●調べてみました""使ってみました"とかカコイイエントリ書きたいものですが、なかなかそうもいかないときもあります。
某社のシークレットIDとか調べてた時に、そういえばメールアドレスの扱いもなかなか難しいものがあるなとか思っていました。
リユース/リサイクルされる可能性があるメールアドレスってどうやって扱っていくのが良いのかという話です。
ずっと前から考えてました。
例えば、あるメールアドレスにWebFingerでアクセスして、IdPが現在のアカウントに紐づくランダムな文字列を返せば、それだけでアカウントユニークなメールアドレス管理が可能です。
メールアドレスを受け入れる側が、「このメアド、登録時とは別のユーザーっぽい」っていうのがわかるぐらいの情報なら、Publicな情報として出してもいいですよね？
ユーザー識別子として便利で不便なメールアドレス - r-weblife
私が考える課題
"ユーザーが登録したり属性情報として受け取ったりしたメールアドレスの状態変化への対応ってあまり考えられていないのでは？"ということです。
ここでいう状態変化ってのは
- メールアドレスが使えなくなった/変更した
- メールアドレスが他の人に再割り当てされた
- メールのプロバイダがなくなった
とかで、こういうときにサービス側で何ができるのかと。
"そういうものだと思ってサービス組み立てるしかない"が成り立たないほどの存在感がメールアドレスにはあると思うわけです。
現状行われている対策
- 定期的にメール配信して送信可能かどうか(有効かどうか)チェック
- 新規登録時にやるような"メールアドレス確認用メール送信"
とかですかね。
リンク踏ませてまずメールが到達したかどうかの確認、ログインさせるかログイン済みのブラウザでリンク開かせることで持ち主が変わってないかの確認ができると思います。
しかし、ここまでやらせるのはけっこう大変ではないかと。ログインしてこないユーザーもいそうですし。
提案（誰に対する提案かは不明）
あえて抽象的なレベルで提案します。
- メールアカウントのプロバイダはメールアドレスに対する現在のユーザーに紐づくフラグメント文字列を保持もしくはいつでも生成できるようにする
- サービスはそのフラグメント文字列をもらう
- サービスは保持しているメールアドレス＋フラグメント文字列をプロバイダに渡すことでメールアドレスが有効かどうか、ユーザーが変わっていないかどうかを問い合わせる
- プロバイダは結果を返す
で、メールアドレスが他の人になってたりしたらサービス側でメールアドレス再登録フラグとか立てて次回ログイン時に再登録させるみたいな感じでいいのではないかと。
割と誰でも考えつきそうな内容です。
考えないといけないこと
- フラグメントの中身(Global Unique or PPID)
- これをさせるにあたり、ユーザーの同意を求めるか否か(2legged or 3legged)
- 果たしてメールプロバイダが実装してくれるかね
あんまりOpenID Connect/OAuth使うみたいなのも堅苦しい気もしますが、とはいえ識別子の話なのでこのあたりの考慮は必要なのかなと思うわけです。
具体的にWebFinger使ってどうこうすればいいかもまで考えたのですが、今日はやめておきます。
このあたり整理されたら開発者としてもうれしい部分ありそうなんだけどそうでもないんですかね。
今日はこの辺で。
ではまた。
