spモードを試した。初期所見

Hiromitsu Takagi @HiromitsuTakagi

spモードを試した。以下、初期所見。①設定のために https://t.co/m33JKWZL に行くことになるが、この時点で既にユーザ識別されている。URLパラメタもPOSTデータもなく直にアクセスしても、cookieをクリアしOFFに設定していても識別される。

Hiromitsu Takagi @HiromitsuTakagi

②HTTPSなのでGWでヘッダに何か挿入することはできないし、ブラウザが端末識別番号を送信しているとは考えにくい。③そうすると、この時点で既に、Webサーバでユーザ識別する手段は、IPアドレスを用いるしかないのではないか。

Hiromitsu Takagi @HiromitsuTakagi

④ユーザ識別はこの図 http://t.co/m8MHkG0C の「パケット交換機」で電話網の信号からIPパケットが再構成される際にはIMSIか何かで可能となるが、それを他のサーバに伝えたくともIPパケットに載せる手段はない。よって、IPアドレスの登録と参照を使うことになったと。

Hiromitsu Takagi @HiromitsuTakagi

⑤iモードでは、「パケット交換機」がHTTPストリームを再構成する際にその場で直接、（IMSI等で識別しているユーザに対応する）ユーザ識別子（uid又はiモードID）を埋め込んで、他のサーバにHTTPで送信することができた。（そのためHTTPSでは使えなかったのだが。）

Hiromitsu Takagi @HiromitsuTakagi

⑥spモードはスジが悪い。目的がアプリレイヤでのend-to-endの認証済み識別であるはずなのに、下のレイヤの中継地点で認証と識別の提供をしようとしている。（もし「パケット交換機」でHTTPSを解くなら一般的なリバースプロキシと同様で変ではない。⑤のヘッダ挿入もそれに類する。）

Hiromitsu Takagi @HiromitsuTakagi

⑦正しい設計はこう。「パケット交換機」上で接続のIMSIが確認された際にセッションIDを発行して端末側アプリに（何らかのプロトコルで）返す機能を用意。アプリはそのIDをHTTPSなどアプリレイヤでend-to-endの通信に載せてサーバに送信。サーバはIDからユーザ識別子を得る。

Hiromitsu Takagi @HiromitsuTakagi

⑧auのスマホはそれ（⑦のこと）っぽいことをやっている感じに見える。（未確認）（「au one-ID設定」のとき） ⑨結局、「一般にシングルサインオンの実現方式は、ID連携方式かリバースプロキシ方式」と言われるように、どっちかしかないところ、spモードはどっちでもない斬新方式。

Hiromitsu Takagi @HiromitsuTakagi

⑨スマホから使う https://t.co/m33JKWZL はインターネットから接続できないようにされている。このことがカスであることの証と言ってよい。これが解消されたらば（つまり、Webの隠し画面など存在しなくなったとき）、抜本的な問題解決が図られたと見てよいだろう。

Hiromitsu Takagi @HiromitsuTakagi

⑩その暁には、何らかのアプリが⑦のセッションIDを取得してWebブラウザに引き回して https://t.co/m33JKWZL にパラメタ付きでアクセスするようになるはず。（よって、その画面はインターネットから見えていて何ら問題ない。）

Hiromitsu Takagi @HiromitsuTakagi

以上、こんなところではないかと推測。