#idcon8レポート - mad-pの日記

11月19日に秋葉原の産総研で行われたidcon8に行ってきました。今回もなかなかディープな話で、はっきり言ってついていけてません。間違っているところがあると思いますので、ご指摘お願いします。

懇親会ではリアルに仮名が必要な場合ってあるのか、などの話題が。あと名刺にtwitterアカウントを書いて渡すというのをみんなでやっていました。@stomitaさんはtwitterアイコンとidを印刷したシールを作っているそうです(今日は忘れたとか)。それはいい方法ですね。

@hiroki : Liberty Alliance ID-WSF 2.0 についてざっくりとした話を (20分)

伊藤宏樹 @hiroki NTT情報流通プラットフォーム研究所
WSF: NTTが標準化の過程でコメントした

ID-WSFとは

属性交換: サイト間でユーザーの属性情報を流通させる仕組
コンシューマが情報を要求するときに、誰がその情報を持っているかディスカバリーするサービスを置く

ID関連技術
- SSO、属性記述方式、属性共有方式、ユーザ合意、通信+セキュリティー
- 今日の話は属性共有方式

WSFのスペックは膨大。1000ページくらい
- 今日の話はdiscoveryとpeople service

自分属性操作

自分属性操作 vs 他人属性操作
使い方
- 通販サイトで住所入力のときに「他サイトから持ってくる」ボタンを押す
- 他の通販サイトに入っている情報を使い回せる。ただしユーザ同意確認が必要
ユーザーが情報を入力したら、WSPとなってDSに情報を持っていることを登録する
WSC (consumer)はDSにWSP (provider)の場所を聞く
WSC, WSPの間でアクセストークンを交換
ユーザー同意もトークンにして渡す

People Service (他人属性)

WebサイトAでユーザーがソーシャルグラフを持っている。他のサイトBでも使いたい
- いまはメアドリストなどを取ってきて使う → 匿名化したい
ユースケース: AliceがBobに写真を見せたい
- 写真共有サイトにAliceとBobが別々のIdPからログインしている
- ソーシャルグラフ上でAliceのコンタクトリストにBobがない場合
- Aliceが写真アクセスリストにBobを加えたい
  - ワンタイム要求URLをAlice→Bobと送る
  - Bobがアクセスすると「Aliceさんの写真を見ますか」→ yes
  - BobはAliceのリストに加えられることを承諾する
    - BobはAliceのソーシャルサイトで自分を認証した上、リストに追加される
  - Friends, Photos, IdPの間で3通りのトークンを使うが、IDを分離しておけば名よせできなくなる
「一見難しいですが……やっぱり難しいですね」

Q&A

高木さん: (1)どれくらい使われそうか。(2) 難しいのは実装する人なのか使う人なのか。(3) 仮名使わなくてもいいと言うとみんな使わないのでは? そのときの懸念は?
- 伊: (1)どこで使われてるかというのは言えない。コンシューマサービスに入れたという話は聞いていない
  - 高: コンシューマ相手でないのにこういう仕組が必要?
  - 伊: 大手が一般の人向けに出している例があるらしい
- 伊: (2)仕様のボリュームに比例していて、実装が難しい
  - 高: 実装は技術者ががんばればいい。しかし消費者が理解できないと使われなくなってしまう。そのあたりの懸念は?
  - 伊: 今回の説明では一番複雑な例を出しているせいかな
  - 高: せっかく複雑な場合を考えて仕様を決めたのにそこまで使われないという意味?
  - 伊: 一部分だけ切り出して使えばよいと考えている
- 伊: (3)名寄せの心配がある
  - 高: せっかく仮名を使っているのに使わなくていいと言ったときに誰も使わないのではもったいない。後でまた
真武さん: 属性が後で変更されたときはどうなる?
- 伊: Subscription/Notificationのレイヤで通知する機能がある
- 伊: さっきの例だとWSP→DS方向の通知。WSCは教えてもらえない
??さん: (1)WSF 1.0から2.0になってパッケージの普及が遅いようだ。(2)1.0と2.0の間で相互接続性がない。なぜそんなことに?
- 伊: (1)下道さんとこにがんばってもらいたいwww
- 伊: (2)上位互換がないという認識は正しい。その理由は何だったっけ……。仮名のメカニズムを導入するための大きな障害がどこかに……
  - 下道: SAML2.0のassertionを取り込むとき
  - 伊: ……のSOAPメッセージの順序に不整合があったような

19:40

@tzmtk : OAuth Multiple Access Tokenほか (20分)

Y!のまつおかさん
今日の話: サービスレベルとそれぞれに最適なセキュリティー

ヤバゲーの件

9月末にサービス停止の件 → 今日はスルー
OAuth連携 Y=SP, D=C
- Payment, Social, BuddyList APIをY!側に書き込む
- 開発はほぼDeNA様。シングルログアウトなど
- でもY!サービスでもある。見た目もcopyrightもY!あり
  - ロゴもY!モバゲー、ドメイン名もyahoo-mbga.jp
問題点
- 1. Y!のOAuthの認可画面は基本毎回出ることにしていた
- 2. ログイン有効期限
- 3. refresh tokenの有効期限
- 4. シングルログアウト: Y!でログアウトしたのにYMでログインしたままになっちゃう
解決
- 1. 同意画面はスキップ
- 2. 最長のログイン有効期限を両者で揃えた 4w
- 3. refresh tokenも同じにした 4w
- 4. リダイレクト形式のシングルログアウト
考察
- 同意画面は初回だけでも出すべきかも
- 決裁APIを提供しているのにRefresh Tokenが4wは長すぎる(Social APIとしては短かすぎる)
  - いちばんキビシイところに合わさざるを得ない
- リダイレクト方式のシングルログアウトは、どこかひとつが落ちているとY!もログアウトできない。ビーコンかSAMLでやるべき?
サービス上ではリソースの機密性に合わせてセキュリティーも変えられるが、APIだと難しい
- → OAuth Multiple Access Token
- scope, tokenを空白で区切って並べる

Q&A

下道さん: シングルログアウトはSAML仕様を決めるときに結構考えた。しかし「ログアウトを能動的にするのか」。ユーザーって本当に使うの?
- ログアウトしないでブラウザ落としちゃう人がいる。そうするとクッキーが片方だけ残ってしまったりする。少なくともログアウトしたい人はさせてあげないといけない。Y!のサービスに見えるので、問題が大きいというところで、やっている。いまの方法で万全とは考えていない。課題はあると思っている。
真武さん: Multiple Access Tokenについて: scopeひとつに対してひとつトークンが来るの? 誰がまとめるのかどうか
- Y!ではconsumer keyと結びついている
- 真: OAuth2だとtoken要求時にscopeを送るし、複数のscopeをグルーピングしないと使えないAPIもある。Facebookもリストで送る。twitterもコンシューマキーに結びついている
高木さん: クレジットカードでの本人確認ってのはアリなんですか? カード会社に何のメリットもないのによく使わせてますね

20:03

@kthrtty : 3GPPにおけるOpenID/SAMLの活用 (20分)

かつはらさん@野村総研
Introduction of Bridging IMS and Internet Identity
- http://www.slideshare.net/kthrtty/101117-introduction-ofimsandinternetidentity
OAuth 2.0邦訳出ました
- mixi echo/checkの実装をしてる人も参加

結論

将来のキャリアネットワークで加入者特定のために使われるIDと、Webの世界でのユーザ特定のIDをうまく関連づけたい

IMS

IP Multimedia Subsystem: キャリアネットでの通信は全部IP化してしまおう
- キャリアネットワーク: NGNなど
- 外のネット → インターネット

ユースケース

IMSの認証結果をWebに通知
- 電話しながらFlickrから写真を取ってきて、友人の電話にSIPで送付
- 電話の認証を使ってWebを認証
出品者が連絡先をオークションサイトに登録しなくても落礼者から連絡が行く
- twitter IDで年賀状送れます的な
- 「出品者に連絡」で電話がつながる(通話のルーティング)
サービスがユーザーのプレゼンス状態に応じて適切なデバイスに通知
- 携帯が圏内になりました → ニュースは携帯に配信

実現方法

IMSの世界での回線認証(GBA)
端末の中に入っているGBAクライアントがやる
- 通信はHTTPベースでやっている。UAが特殊
- HTTP Digest AuthNがない → 401
- 耐タンパ性を持ったISIMカードを使った認証をする → Digest AuthN
- 200 ペイロードにセッションキー

つなげるのは

IdPから端末に対してGBA認証をinvoke
Web ClientとGBA Clientの連携形態
- 同じ端末の中に両方ある
- つながっている: PCのWebブラウザで認証が必要になると机の上の携帯がブルブルする
- 分離されている場合: (よくわかんない。人間連携?)

まだまだ面白い

SAMLもGBAを使える
- SIP binding
- ID-WSF
2G/3Gでもできるそうです
docomoがLTE時代に入った。音声通信もVoIPでやる

Q&A

高木さん: 一番知りたいのはこれで問題でないのかな、って点。今のユースケースだと電話と連携するのでなければ必要ないの?
- 一番最初のFlickrの例で電話がつながってる相手は認証が取れているということを利用する場合
- 高: 電話以外の便利さがわからない。電話の回線契約にひもづいたIDだけで全部やろうという話になるとイヤだが、本人がひも付けているのであればOK?
高: 端末IDと仮名IDの話、技術者は本当に気をつけている感じか?
- ISIMからIdPに渡すIDは違うとは書いてあるが、いろんなSPにそれぞれ違うのを渡すかどうかは仕様からは自明ではない。イヤな予感がする

20:30

@HiromitsuTakagi

高木浩光自宅の日記2010/6/19参照

IDシステムのセキュリティーとプライバシー
問題領域
- セキュリティーの問題
  - IDだけによる認証
- プライバシーの問題
  - 名寄せの問題

セキュリティー

一般の方法
- 臨時のID(セッションID)の秘匿性で担保するセキュリティー
- 素人の誤解: IDが偶然当たるリスク
  - 例: セッションIDが衝突しないようにチェックするコードを書くやつがいる → 当たるわけがない乱数を使うべきであって、チェックコードが必要ということは理解が足りていない
  - セッションID衝突の漠然とした不安から、IPアドレス使っとけばと流れちゃうんじゃないか
ガラケー界の方法
- 使用する識別子は事実上公開情報
- 接続元の制限により担保しようとするセキュリティー

プライバシーの話

ガラケー界の話
- 「iモードID」「EZ番号」等の件
- 相手もわかんないうちにいきなり送りつけちゃう
- 架空請求で使われちゃったら?
OpenIDでは?
- 「PPID」Private Personal Identifier (pseudonym)
- せっかく考えたのに使われないのでは意味がない
- GoogleでさえデフォルトはPPIDでない方にしようとしている
  - → Google IDがデファクトで席巻しちゃうとガラケーIDのようになっちゃうのかなあ
- PPIDはrealmがドメイン名になってるのでドメインが変わると引き継げない。マッピングを持つなどすると、IdPがレジストラの仕事までかかえ込むことになってムリ

ガラケーIDに相当する海外事例

「世界の端末固有番号」でぐぐれ
いま世界でこれは使われているのか、プライバシーの懸念は話題になっていないのか?
- 知ってたら教えてね

iPhone/Android

WebだとIDの問題はクッキーの問題に集約される
- 3rd-partyクッキーの問題
それが固別に作ったアプリで何でもやるとなると、端末のUDIDやANDROID_IDで問題が起こる
- 日本のガラケーで育った人達だけですよと思っていると、海外でも事例がある
アプリインストール時の許可画面に実はUDID/ANDROID_ID取得もちゃんと出ているが、たくさんの取得情報に混じって出るので気づかないだろう

行動ターゲティング広告

仕組 → 使い方の話
2001年のdoubleclick社を相手どった集団訴訟
- 和解: 住所は使わない。3rd-partyクッキーで集める。オプトアウト可能でなければダメ
最近またもり上がり。FTCが業界に自主的なガイドラインをうながしている
- 公正取引委員会の景品表示法に似た仕組でFTCがコントロールできる
- 日本にはそういう仕組がない。個人情報保護法があるが、それに引っかからないと何やってもいい状態。日本ではプライバシーポリシーは意味のない状態。「何でもやります」と書いてあってみんな気にしない

日本での総務省の動向
- まずいものだとしても、すでに広まって使われているモノをおいそれと規制できない

行動ターゲティング広告業界の動向
- (米国)「Data Exchange」
- 化粧品サイトのビーコンを使うと女性であることがわかる
  - 女性である → 女性向け広告
  - IDの属人情報を使って広告を出す
- 日本でもやらないと出遅れちゃう!
  - 何をやってよくて何がダメなのかわからないので困っている状態

今後の戦術

「かんたんログイン」撲滅
- そもそもUIが変なんだからやめちゃえば?
- かんたんログインはみんな使っているんだから、と人質に取られちゃってる
- 発注者が「かんたんログインでやって」と言う場合が多い
- クッキーでも同じことはできるので、技術者としてはそっちに移行してほしい
docomo IDがOpenID対応 → すごい
- でもiモードIDが取れるようになっている
- 「取得していません」バナーを流行らせればよい
- 高度に政治的な話なので、技術者主導でなんとかしたい

ガラケーで年齢送信(認証)?

総務省「利用者視点……諸問題研究会」
青少年保護のため
年齢によるチャット制限
- 子供が大人になりすましたい
- 大人が子供になりすましたい
サービスで何とかできている「ことにしたい」
キャリアが携帯契約時に年齢情報を取っている
- 「コンテンツプロバイダーに出したらどうですか」と総務省が言っている
- どうやるかもよくわからないままの話なのがコワイ
  - エライ人に言われるまま、よく知らないシタッパ技術者が作っちゃってX-Ageとか送り始めたらイヤだ。そういうのを止めるのは技術者の役目
- 話としては流れたように見えているがどうなってるかは不明

21:05 終了