idcon13レポート - mad-pの日記

idcon13に行ってきました。今回はあまり追いてかれた感なかったです。
仕様の話もあり、啓蒙の話もあり、いいバランスだったんじゃないでしょうか。

イベントリンク: http://www.eventbrite.com/event/2417781650/
スライドまとめ https://www.facebook.com/idcon.org
つぶやきまとめ http://togetter.com/li/326813

以下、[]内は私の感想です。

(19:10)

「OAuth大捜査線」 @asyoulike007

鈴木理恵子@mixi
- mixi Graph API
- 毎回idconって、シーンとしていてコワイw
  - [今日は要求する前に拍手もらえてよかったですね]

OAuth2.0
- エンジニアが開発、一般ユーザーが認可画面を見て使う
- エンジニア向けの仕様解説や実装方法の記事はよくある
- ディレクタ、デザイナ、営業向けの解説はあまりない
- OAuthを使っていても、適切に実装できていない例がある
  - @ritou 椅子を投げたくなる件 d:id:ritou:20120619:1340101421
  - → まだまだ布教が足りないですよ
mixiのOAuth2.0対応
- draft10 (一部12)
- auth code, resouce owner credential, client credential

事件は現場でおこってるんだ!

現場その1: SAPさんからの問合せ例
(1)認可画面を表示しないようにして欲しいのですが…
- 認可の意味をおわかりいただけてないのでは?
  - 認可画面から50%のユーザーが離脱している
  - [要求されるスコープが広すぎたりすると、やっぱり離脱しちゃいますよね]
- 認可画面の出し方にも課題が
(2)AさんのアクセストークンをBさんに使い回していいでしょうか?
- 意味を知らない
- 意外とこういう問合せもある
- 保存しておけばどんどんデータが取れるという発想??
(3)問合せメールにconsumer secretが記載されている
- メールは開発者でなくディレクターが書く場合も
  - どのアプリについての問合せなのか特定できる情報として送ってしまう??
- メールが社内MLに転送されたり、チケットに貼られたりしている
- 返信するときに、秘密にしてくださいね、と啓蒙している

開発チームへ伝えるべき
- 何のために認可しているのか
- 取り扱いに注意が必要な項目は何か
- 認可画面の実践的な組み込み方
  - → ユーザーの混乱を少なくしたい
- 信用問題に関わる大事なこと

現場その2: 一般ユーザー様
- OAuthの主役はユーザー。開発者向けに語られることが多いが、ユーザーが最重要なはず
- なんとなく「許可」しているのではないか
  - みんなちゃんと理解しているのか?
なんとなく許可してしまう → スパムアプリが横行
- ユーザー側でpermission controlできることを知らない
- 後から止める方法を知らない

一般ユーザーへ伝えるべき
- 認可画面では何を許可しているのか
- 許可/拒否すべきアプリの見分け方
- 被害にあったときの解除方法
- 不要な認可を定期的に掃除すること

エンジニア向けだけでなく、ディレクター、一般ユーザー向けの解説記事も必要

Tech総研にて執筆中 http://bitly/Lmnzgo

Q&A
- _nat: 英語のスライドほしいです

[感想: 自分の情報をどこまで出すかっていうシンプルな話なんだけど、説明しようと思うと小難しくなってしまうのはどうしてなんでしょうね? イヤなものはイヤと言えばいい(言える仕組はある)、っていうのでは単純化しすぎですか]

(19:30)

「Identity First, Device Second」 @shingoym

山中しんご

いかりや長介 OAuth! 「おい〜っす」 [はずした…]
「Mobile First, PC Second」と言ってる会社がいる
- 懐疑的だと思っている
- デバイスなんかどうでもいい。IDの方が重要
  - 〜という話をしようと思ったけどやめました[やめるのかよ]
IdentityRola、みんな知ってますよね?
- [→ アカウントBANされてるじゃないか]
おっさんだけでIDについて話してるのはあきた
- うまくペルソナ使い付けてやろうぜ
- 前回のidconも男性ばっかりだった
- タコつぼ化イクナイ
女性のほうがプライバシーには敏感だったりする
- 海外にはIdentityWomanもいる
- twilog.log/shingoym/date-120410
- 許可しておっけ〜ペロペロ、みたいなノリがほしい
IdentityRola を始めた
- しばらく内緒でやるはずが、すぐ見つかっちゃった
- なみだぐましい努力w
なんでバレた?
- keijitakeda先生に返信したらRTされちゃった
Innovationとは元々「新結合」
- 交わることのない2つ(identity, Rola)の組み合わせ
いつのまにかフォロワー100人越え
IdentityRola の名前でいろいろつぶやく
アカウントbanくらってしまう[やはり]
- 30時間だけ
- Digital Death
なんでBANされたか?
- 本物ローラに対する質問に横取りして返事したら即攻BAN

教訓
identifierを変えてもわかる人にはわかる
- つぶやきなどの外縁情報である程度特定可能
- 他人になりすますことは難しい
- → ペルソナのコントロールは無理?
名誉毀損や肖像権の侵害
- verifiedアカウントの仕組みと価値
「なりすましなどのプライバシー侵害?」
- なりすましってプライバシー侵害?、という違和感のある表現だと思っていた。Rolaの件でなりすましによって自分の望まない自己像が作られることは、やはりプライバシー侵害だとわかった

次世界のための啓蒙プラットフォーム
- Identity × Rola
- → 次は?
- → @IdentityPamyu

Q&A
- lef: ぶっちゃけ本気でかくせると思ってた?
  - shingoym: 割と本気で。わかってもいいとは思っていた

[感想: IdentityRola知りませんでした。おバカなことをやっているようでいて、ちゃんと教訓が得られている点がすごいです]

(20:05)

「UMA - User Managed Access」 @ritou

いとうりょう
http://slideshare.net/ritou/usermanagedaccessidcon13-13415767

OAuth2.0はもうすぐ固まると言われながらなかなか出てないですが…
参考URL
- kantara Initiative UMA WG
- 情報セキュリティー技術動向調査 @tkudos

OAuth
- Resource serverとAuthorization serverは一意に結びついている
  - 認可管理はリソースの数だけ、たくさん発生する
- クライアントはResource ownerの代わりにリソースアクセスを行う
  - 自分が所有するデータにアクセスさせるためのしくみ
  - 第三者に共有する仕組みではない

UMA (うーま)
- Resource server と AuthZ serverを分離
  - 好みのAuthZ serverを利用可能
- 第三者へのリソース共有も可能
  - person-to-self
  - person-to-person
  - person-to-organization
- ポリシーはユーザーが決定

UMA Flow
- 用語が変わります。Authorizing User, Host, Requester, AuthZ Manager, Requesting Party
1. Protecting a Resource
- リソースを保護するAMを指定
  - HostがAMからトークンをもらってリソースを登録
  - scopeの集まりをresource setとして登録
- ポリシーを設定
2. Getting Authorization
- アリスはボブに画像URLを教える
- ボブはリソースを取りに行く
- まずはエラーとしてチケットを送信
  - AMが作成した認証要求チケットをRequesterに返す
- RequesterはRequesting Partyに対して同意を求める
  - Requesting Partyの情報をAMに開示していいかどうかの同意
- AMはpermissionのついていないトークン(RPT)をRequesterに渡す
- RequesterはさっきのチケットをつけてRPTを返す
- AMがボブさんであることを確認して認可
3. Accessing a Resource
- RPTを用いてHostにあるリソースをアクセス
- HostはAMにRPTの有効性をチェックしてもらう

UMA × OpenID Connect
- Claims-based Access Control
- Requesting Partyの属性情報によるアクセスコントロール
- OpenID Connectで属性を求める
  - RP=AM; OP=Requester; User=Requesting Party
UMA × SITF?
- 信頼情報の交換

これからの動き
- Interop
- 新しいユースケースの収集
- Trust Model Documentの精査

思ったこと
- リソースと認可の分離だけ見ても可能性を感じる
- コンテンツが強いところは認可管理をアウトソース
- スタートアップが安全にリソースアクセスを提供できる
- グループ企業内のAPI連携など
一緒に実装しませんか? いまならブルーオーシャンなんですぐ日本一になれるw

[感想: 正直難しい。UMA認証を受けるためには自分の身分を明かさないといけないから、それ自体に対しても認可を求めるようになっているなど、納得はできた]
[懇親会での話題: AM間でトラストして認証を回してやればいい話なんじゃない?]

(20:30)

休憩〜 Tシャツ配布

(20:40)

「SITF - Student Identity Trust Framework」 @tzmtk

まつおかさん
たなかさん
(先月OpenID Foundation Seminarの内容)

トラストフレームワークとは
- 何がうれしいの?
  - 安全に流通できる
  - IDP/RPが満たすべき基準をチェックできる
  - 与信の手間を減らせる
ユーザーもうれしくなるはずだよね?
- → 実証してみましょう
オンライン学割の課題
- 登録時: 本当に学生なの?　→ 学生証郵送?
- 利用時: いまも学生なの?　→ 定期的に確認?
- 正しく運用しようとするとコストがかかってしまう
- かと言って雑に運用すると、正規料金を支払っているユーザーが不公平に感じる
フレームワーク案: 策定しても利用されなければ意味がない!
- 学増: 学生には容量を多く (学生にはラーメンも多くw)
- サービスの例: 電子書籍、賃貸住宅、旅行、チケット、クラウド、ポイント、などなど
- 考えました → これから進めていきましょう
Attribute Provider
- IdP :== {discovery, authentication, attribute} provider
- APをIdPから分離することを考えてみよう
学認を使って学割
デモ
- デモサイト: http://sitf-rp2.openidconnect.info/ticket
- @shingoym このデモの台本を後で共有してくださいね
  - → http://tmblr.co/ZO4FEvNuPEot

宣伝
- 夏からphase2として具体的にやりたい
- 参加者募集 → @shingoym まで

Q&A
nov: デモでログインをtwitterでやったのは意味ないんだよね?
- tzmtk: mixiをIdPとして属性確認をするが、ログインIDは別IdPでもよい
  - tzmtk: mixi - 学認間で属性をひもづけておいた。違うIdPでも使えるというデモだった
- ritou: OpenID Connectで属性を取りに行ってるので、リロードした瞬間に最新の属性情報がすぐ反映されたというのが重要

[感想: ユースケースはたくさんありそう。共通する原理があるんだけど、一般の人が理解できるか。あるいは理解しなくても安心して使えるか、であればいいのでしょうか]

(21:00)

世界「Identity Firstでいきますから。」 JIPDEC 野村至さん

ポイント
- 1. 先進諸外国を見ると「Identity First」な潮流
- 2. 個人情報保護やプライバシーへの配慮
- 3. 先進諸外国はすでに取り組みを始めています
- 4. OECDのdigital identity management指針が発表されました
Id 1stの潮流
- 自国の情報経済を活性化させたい!!
- 安心・安全で信頼できる利便性の高い情報環境が必要
- 課題
  - 適切な身元確認ができない
  - 適切な認証環境になっていない
  - 適切なデータ利用ができていない
- 適切な運用が必要
ドイツのデジタル・アイデンティティ・マネジメント
- 紙の身分証明書に代わって電子的な新身分証明書(nPA)を導入した
- 官民共用の本人確認、プライバシー・個人情報保護
- ICチップ入りのクレジットカード大のカード
- 16歳以上のドイツ市民は義務として所有
- 機能
  - 電子的本人確認機能 → ネットショッピングで年齢確認、住所参照など
  - 電子署名機能
  - 電子的旅券機能
- 読み取るには
  - サービス業者が権限証明証を取得 (政府の監査によって)
- 他の特徴
  - 名寄せを禁止
  - Pseudonymer Zugang サービスごとに別のID → 名寄せできない
  - ドイツは名寄せに対して敏感
アメリカのデジタル・アイデンティティ・マネジメント
- 身元証明
- 行政サービスへのログイン → 民間IDを活用
  - 信頼できるのか? → トラストフレームワーク
- Open Identity Trust Framework
  - 信頼レベルを定義(Googleは自己申告のみなのでレベル1、など)
  - 監査人が監査して信頼性を担保
イギリスのデジタル・アイデンティティ・マネジメント
- 国民ID登録簿の廃止。プライバシーしん害が理由
- midata (マイデータ)
  - 企業に保存されている自分の情報を本人が利用できる
  - 経済の活発化。より良い選択・より良い取引 → 安心 → 消費up
  - 現在: 法律としてはあるが、実効性はあまりない
  - 閲覧はできるが、ダウンロードや第三者に利用させることはまだできない
  - 情報のコントロールへ
EUの一般データ保護規則案
- プライバシー・個人情報保護の観点を追加
- データポータビリティーの権利
  - あるサービスプロバイダから別へ移行できる
- 「忘れてもらう権利」
日本
- デジタル・アイデンティティ・マネジメントはあまり重要視されていない
- 余白が多い
OECDデジタル・アイデンティティ・マネジメント指針
- 国家戦略で!

[感想: ドイツの例は参考になります。名寄せに関して、日本は割と気にしてないような感じがありますが、もっと問題意識が共有されるといいなと思います]

(21:30 end)