OpenIDファウンデーション・ジャパン

OpenID Connect の地図

（このエントリは、US OpenID Foundation の2011/4/29付エントリを翻訳したものです。）

IIW がもうすぐ開催されます。

その場を利用して、次のバージョンの OpenID に関してフェース・トゥ・フェースの議論を予定しています。

このエントリでは、IIWに参加する人たちや他の皆さんのために、今の OpenID の仕様策定のいくつかのポイントについて解説したいと思います。

OpenID 2.0 からの変更の一つは、新しい仕様はモジュール化されているということです。

下の図は OpenID ABC の各コンポーネントを示していて、それぞれの仕様にリンクが張られています。

（詳しい仕様を見たい方は、英文エントリの図をクリックしてみてください。）

全ては OAuth 2.0 と OAuth の Bearer Token Profile の上に作られていています。

また、異なるデバイスのために複数の OAuth フローをサポートしています。

抽象的なプロトコルを記述するコア仕様が、OpenID Connect の心臓部になります。
また、いくつかの OAuth フローのためのバインディングを作ってきました。

1. アーティファクト: URLの長さ制限のある携帯デバイスのためにフローを最適化
2. Web アプリケーション/コード認可: Web サーバーのための、分かりやすくシンプルなバインディング
3. スマートクライアント: スマート・ユーザー・エージェントのためのバインディング（開発中）

JSON Web Token は仕様にのコアに使われていて、以下の４つのパートから成っています。

1. JSON Webトークン: コアとなるトークン仕様
2. JSON Web Signature: 署名の仕様
3. JSON Web Encryption: 暗号化の仕様
4. JSON Web Key: 公開鍵を表現する簡易な方式

eメールアドレスや URI のようなユーザの識別子のディスカバリーは Simple Web Discovery のプロファイルによって実行されます。

セッション管理の仕様は今のところ分かれていますが、コア仕様に統合される予定です。

顕著な問題

我々は、以下の顕著な問題を解決するために、IIW 開催周辺でフェース・トゥ・フェースの時間を使いたいと思っています。

1. Claimed ID タイプ: 単体の URL のためのものと、user_ID と IdP/OP の識別子が分かれているような二つの識別子のためのもの
2. PAPE/認証コンテクスト: これは政府向けだったりよりセキュアなアプリケーション向けに必要なものです。
3. ユーザー情報エンドポイントとベースとなる属性のスキーマを定義するためのフォーマル仕様
4. 他の拡張仕様を追加するための方法の定義
5. 信頼されたソースからのクレームをリクエストするための構文定義

それから、皆さんが分割された仕様を苦労して解読しなくても済むように、クライアントをより簡単に開発するための実装ガイドを作成中です。

5月の IIW 後のアップデートを楽しみにお待ちください！

John B.