SITFのWGにて技術面で検討したことと今後やっていくこと

こんばんは、ritouです。

さっきまで、このセミナーに参加していました。
http://www.openid.or.jp/modules/news/details.php?bid=49

OpenIDファウンデーション・ジャパンとその他の企業で構成されたWGでは、学認が持つ学生情報を民間サービスに流通させるために技術面/ポリシー面の検討を進めてきたというわけです。
私もこのWGに参加させていただいて、デモを裏で操りました。残念ながらUSTやらなかったので残っていませんが。。。

デモ作った以外に、下記の検討等を行いました。

  • ユースケースに対して技術的に厳しい部分がないか
  • 既存の標準化仕様をどのように適用すると実装コストを抑えられそうか
  • デモ作成から実装面の課題を洗い出し

実際はポリシーから決めていこうか的な空気の中で違う方向いて実装どうするか考えていった感もありますが、結果としてユースケース検討の材料とデモそのものを使えて良かったかなと思っています。

ユースケース検討とともに上がってきた要件

説明には含まれていませんでしたが、こんな要件が出てきました。

  • データのやりとりに関わる登場人物はAtP(Attribute Provider), IdP(Identity Provider), RP(Relying Party), End Userの4者
  • End Userの許可のもと、AtPの属性情報をIdP経由でRPに渡す
  • IdPとRP一緒でもいい
  • RPは複数のIdPと接続できる
  • RPはいつでもAtPの最新の属性情報を取得できる

今後細かいいろいろが出てくると思いますが、プロトコルレベルの話でいうと、それほど難しいものではありません。
なぜAtPからRPに直接属性を渡さずにIdPが間に挟まっているのかが気になるかもしれませんが、
単純に学認経由の大学をIdPとして利用してね!よりも、既にOPになっているところに属性を提供することで敷居を下げる狙いなどいろいろあります。

デモ時点で考えたこと

OpenID Connectを多段にして接続
  • AtP-IdP, IdP-RP間でそれぞれOpenID Connectでつなぐ
  • UserInfo APIで最新の属性情報を取得(RP→IdP→AtP)
  • Dynamic Registrationいらない
  • SITF IdPが増えたらDiscoveryも需要出てくるかもしれないけどまだいらない
シーケンス

まずはAtP-IdP間

次はIdP-RP間

ConnectのSpec的には、IdPからDistributed Attributesを使い、RPからAtPのAPIをたたく方式もありかと思いました。
しかし、あえてRP-AtP間を直接結び付けない2段構成が良いのかなと思って提案しました。

デモ

今回、こんな感じのデモ環境を用意しました。

デモでは1,2,4あたりを使いました。
くわしくはこちらhttps://gist.github.com/2520183

WGでこれから決めていくこと

データの流れや細かいリクエスト/レスポンスに関しては、トラストフレームワークの要であるポリシー面の精査とともに決めていかなければなりません。

  • AtP-IdP間の属性情報の渡し方、リクエスト/レスポンスの内容
  • IdP-RP間の属性情報の渡し方、リクエスト/レスポンスの内容
  • トークンの扱い(expire, revoke)

あまりにガチガチに決めてもIdPの持つそもそものポリシーと合わずに参入の障壁となってしまうだろうし、あまりにフリーダムだとIdP単位で実装が変わる残念仕様となる。
ConnectのSpec的にはOpenID Request Objectを利用すれば認証のポリシーから欲しい属性の指定まで細かい指定ができるわけだけど、RPの実装コストを考えると落としどころを見つけてScopeでなんとかする方が良いのかもしれません。

デモの後の質問やパネルディスカッションの質問にもありましたが、このあたりはもう少し詰めが必要です。

学生属性の新鮮度

今回のWGではリアルタイムにAccess Tokenを用いて最新の属性情報を取得するような前提条件で進めました。
ただし、大学側のSLAにも関わってきます。
基本的にリアルタイムにアクセスしつつ返答がない場合はキャッシュしようというやりかたもあるかと思います。

ユーザー識別子の扱い

崎村さんからの質問にもありましたが、ユーザー識別子の扱いは検討が必要です。

  • AtPから一意なユーザー識別子が提供される : おひとり様1アカウントのみというサービスが可能
  • AtPからIdP単位で一意(PPID)なユーザー識別子が提供される : 名寄せができない
  • AtPからユーザー識別子が提供されない

興味がある方は

こんな感じで技術面の話をあーだこーだ言いながら引き続き検討を進めていければと思っています。
技術面で興味をもたれた方も、OpenID ファウンデーション・ジャパンの誰かまで!(とか言っていいのかな?)