OpenID Summit Tokyo 2015


## Opening Keynote

### Identity Overview

様々なサービスが連携することで増えるリスクもある
番号盗用が偽造カードによる被害を上回った

ID連携が可能になる→なりすましなどができるようになる→普通のユーザーに見える→その振る舞いが不正かどうかを検知する技術が必要って流れだな。たぶん。
ここにグラフDBが使えるよねってところで繋がってるなあ。

今までパスワードを異なるように呼びかけてた。
これはユーザーに責任を移転してた。

fido使ってパスワードを覚えなくてもいいようにするとかのアプローチがある。

API保護の機能

IETFとコワーク
OAuthWG, JOSE WG

Open ID Connect → 10億人以上が使ってる（知らないで使われてる）

The Internet Identity Layer

### IoT時代の認証技術


増井俊之先生 (慶応)

UI観点の話

http://gyump.com/OpenID/

POBox、フリック入力作った人。

スマホに満足していますか
みんなジョブズにだまされている

認証の重要性が増している

例：Suica
電車に乗るために認証している。
Suica以前はネットワークなんてなかった

例：ドア開閉
スマホ当ててサムターンUI出てきてぐりっと回す。
手作り感満載。
最近はKickstarterで製品化されてきてるけどもっと前からやってた

色んな認証方法の紹介。

課題

- みんなが納得使えるものじゃないとダメ
- 今までのパスワードとGUIはなんとなくそれでみんな納得してたからいけてた

### Clouds + ID ~ クラウドビジネスにおけるIDの現在と今後 ~

KDDI 藤井さん

au ID と KDDI Business ID
2500万ID突破

ビジネスの観点での話

KDDIがOpenID Foundationへ参画

GoogleやめてKDDIへ…

クラウドはGoogle一強だとおもんない

昔は情報システム部門が押さえてたけど、現場が一番知ってるから現場が勝手にクラウドを使っていってる。

SaaSのレベルももう一層上になってきてる
もっとわかりやすくなってきてる
具体的なサービスに落とし込んでる
ベストプラクティスを提供している

従量課金型からパッケージングしたビジネス

マルチデバイス、マルチネットワーク、マルチクラウド

## Identity Tech UseCases

### Mobage Connect と Identity 関連技術への取り組み

山口 徹 — 株式会社ディー・エヌ・エー

- Mobage Connect の構築経験
	- CSRF Token JWT
	- Access Token JWT & Microservices

#### CSRF Tokenの話

よくあるCSRF Tokenの課題

- Cache Serverとのラウンドトリップが積み重なるとバカにならない
- Cache serverはデータロストする
- どのページで発行したトークン化検証してないケースが多い

これらを解消するためにJWTを使う

#### Access Token と Microservices

相性が悪い
RFC7662

JWTを使おう

#### Intent URI Schemeとブラウザ ネイティブアプリの連携

ネイティブアプリの認証は魔物。

よりましにする仕組み。

### Yahoo JapanのOpenID Connect対応と認定への道

ID連携黒帯

#### OpenID Connect

2011のOpenID SummitでOIDC/OAuth2.0対応を宣言
→2012/11 YConnectリリース
世界的にだいぶ早い対応

その後、各種SDK提供

2013年 公式アプリ対応

ad tech tokyo参加、ID連携でECサイトのコンバージョンを上げたい

Yconnectってなに…？

Yahooネームバリューを使った名前に！

**ID連携**

2014年 Yahoo! ID連携

#### Yahoo ID連携の注力実績

- Yahoo! Japanアプリ
	- Yahoo JAPAN ID利用率(ソーシャルログイン率) → 56.5%
	- 月間アクティブユーザーID数(月1回以上のログイン) → 3000万以上

#### 今後の注力量良い

ID連携がになう領域

- 広告出稿 → 購入者数増加
- つながりの部分
- フォームの属性情報保管
- シングルサインオン
- サイト再訪問率控除

#### OpenID Certificationに向けて

仕様が古いまま…
ドラフトをベースにしてた

##### 何が問題か？

- ID Token/User Info Endpointのユーザー識別子が違う user_id -> sub
- CheckID Endpointがある
	- 最新だとなくなってる
- response_typeで`code token`をサポートしていない…

独自の対応が必要になることも…

##### 提供したい機能

- OAuth2.0Multiple Response Type
	- ハイブリッドフロー
- ID Token
	- Signature RSA SHA-256
	- Payloadパラメータ追加
		- auth_time/amr/at_hash/c_hash

##### 最新仕様にするメリット

- RP側の導入コストが低くなる
	- OSS/RP製品が利用できる
- 様々なユースケースに対応できる
- セキュリティの強化
- Developer Friendly

##### 仕様の更新が難しいなら…

v2を作ればいいじゃない！！！

OpenID CertifiedなIDpを目指す。

#### 4年前の話…

今後の期待

- キャリアがOIDCサポート

## Trust Infrastructure


### Certification

OIDCのCertificationプログラムに関する話

Certification Programができたのは去年。
開始したのは2015/4

Google, MSなどが認定を受けている

#### OID Certificationとは何か？

プロファイルを満たしたIDp
5つのプロファイルに基づいて実装する。
全部満たす必要はない。
Basicから始める。

- Basic OpenID Provider
- Implicit OpenID Provider
- Hybrid OpenID Provider
- OpenID Provider Publishing Configuration Infomation
- なんか

#### どのようにCertificationを受けるか

自分自身で認定することができる。
しかし、その認証性は担保できる形になっている。

自分の実装に対して取っておく
全てのログを取っておき、公開する必要がある。

実装が他社から正しくないと言うことができる

総合接続性試験

### Instrumenting Trust in a Zero Trust Ecosystem

信頼関係の構築・醸成の仕方を考える必要がある。
相互運用性の担保

再現可能なフレームワーク
クレジットカードにはトラストフレームワークというもんがある

現在トラストフレームワークがサイロ化されてしまっている。

グローバルレジストリを作る

OIX

Open Identity Exchange
Trusted certification

Open ID Foundationと同じようにライバル企業とかが集まってできてる

日本もそのうち必要になるかもしれん。
オリンピックあるやろ。
世界中から来るぞ。
誰が信頼できるのか。
それを評価する仕組みが必要。

## ハンズオン

OP上でエラーにすべきパターン

リダイレクトURIが不正な場合
Providerで止めてエラー表示する。
テストツール側で検証するのが難しいのでスクリーンショット取って送る

## パネルディスカッション

### この4年間でできると思ってやり遂げたことなど振り返り

- 崎村さん
	- OIDCの仕様を去年リリースできた
	- 何故時間かかったか？
		- JSON/XMLどっちにするか問題
		- どっちが良いか聞いたら9割方JSON
		- でもJSONに暗号化の仕様とかなかったので最初から作り始めたせいで時間がかかった
	- 今後の課題
		- デジタルアイデンティティは社会の実態をデジタルに移し替える技術
		- 認証のプロトコルとだけ捉えられているので理解を広めたい。アシストしていく。
- 中村さん
	- ワイヤレスLANの国際連携
	- サーバー証明書の普及
	- 大学のID活用方法模索
	- 素地はできたけど活用はまだ
	- 民間企業がクラウド利用するようになるよりも先に大学関係でクラウドサービス使うようになってた
- 松本さん
	- 色んな条件が揃ったときにブレイクスルー

### セキュリティの話

フェデレーション張ってなくてもおかしなことにはなるし、IDの役割としてできてること、できてないことについて

- 崎村さん
	- リスクワーキンググループ（主要な企業）
	- お互いがお互いのアカウントがハックされてるかみたいな情報を共有しようという動きがある。（アメリカ）
	- 本来は企業毎にメッシュに繋がる世界になっていくべき
	- IDに欠けてるもの
		- API連携、API保護
		- マイクロサービス的に分離されていくと、リソースサーバーがAuthorizationされてるかを確認する仕様がまだない
- 中村さん
	- 企業間のフェデレーションはまだまだだけど学認だと進んでるんじゃないか？
	- 統一的な方法はやりたいけどまだない
- 松本さん
	- 医療について
	- 社会インフラが何もない時点ではID連携は難しい
	- 国と国の間にも同じ問題がある

### 国と国とのID連携について

- 崎村さん
	- 国と国とのID連携・相互乗り入れの前の段階
	- プロトコルを合わせましょうという感じ
	- 国民のIDはすでにある国もあって、そういうところが連携に乗り出してる
	- 在外邦人はスイートスポットではないか
	- 日本は住所が重要視されすぎてる感がある
	- 住所のフィクション性はいくらでもできる
	- 既存のフローから離れてデジタルに作り直した場合の事を考えるべきだ
- 松本さん
	- 戸籍につながる

### 2020年に向けて何をするか

- 松本さん
	- オリンピックどうのこうのな感じはあんま好きじゃない
	- 医療分野ではお金がないから変わらざるを得ない
	- 大きく変わる可能性がある
- 中村さん
	- お金が削られていくのでクラウド化を促進させていく
	- サービス連携とか考えられて使われていくと思う
- 崎村さん
	- 技術的な課題は色々解かれてると思う
	- またその時に新しい課題は出てきてるだろうけど
	- 日本の社会にどんなインパクトがあってどうなってるかを答えるのは難しい
	- 日本は保存的に動いてて何かのきっかけにガッと変わってたりする印象
	- どういうときに起きるか？もう限界だって言う状況の時に起きる
	- 素地としてはクラウドが普及してきている
	- 社会全体として変わるにはお金ない、苦しい！みたいなんないと変わらないと思う
	- ID連携してやってるかどうかで選別が行われるだろう