oidfj

[oidfj]

[Openid-specs-ab] Spec Call note 8-Aug-2013 (一部和訳)

Spec Call notes 8-Aug-2013 参加者  Nat Sakimura  Brian Campbell  John Bradley  Edmund Jay  George Fletcher  Justin Richer アジェンダ:     IETF     オープン中の課題     仕様再構成の実験     インタロップ     次の月曜日の会議のスケジューリング IETF     OAuth Dynamic Registration および Phil Hunt による SCIM ベースの代替案の状況について議論 オープン中の課題    議論すべき新たな課題は無し    署名アルゴリズムとして "none" の利用を許容することについて、John が課題として登録する必要あり スペック再構成     Nat が 2 種類の再構成案を作成中     ひとつはモノリシック、もう一方はコンポーネント化     今後完成版を WG でレビューし、どちらの方向に仕様をまとめていくか決定する予定     John が、issuer をヘッダに入れて opaque token をラップし、それをイントロスペクション・エンドポイントに送付することについて、Internet Draft を書くことを検討している インタロップ     Mitre に SSL 証明書つきのサーバーが存在する     そのサーバーは https://mitreid.org.     ログイン情報:         User name is user         Password is password     RP は https://mitreid.org/rp 今度の月曜日の会議     今度の月曜日の会議の後に、関連する JOSE の会議がある     みんなに JOSE の会議に参加してもらいたい

[oidfj]

[Openid-specs-ab] Spec Call note 5-Aug-2013 (一部和訳)

Spec Call notes 5-Aug-2013 ============================== 参加者 ----------- * Nat Sakimura * Edmund Jay * John Bradley Agenda: ---------- * JWT および JOSE 仕様における新たな例示 * オープン中の課題 * 仕様の再構成の試みに関する状況報告 * 電話会議の日程調整 JWT および JOSE 仕様における新たな例示 ----------------------------------- Edmund が電話会議後に作業開始予定 オープン中の課題 ----------------- 存在するいくつかの課題を John が登録する予定 電話会議後に 仕様の再構成の試みに関する状況報告 ---------------------------------------------- Nat が、再構成したドキュメントを 2 種類作成している。 ひとつはコンポーネント化したもの、もう一つはモノリシックなもの。 前者について議論したのは、おそらくセキュリティとプライバシーに関する考察については、独立した一本のドキュメントにまとめたほうが、実装をチェック��る人にとっては役立つだろう、ということ。 いずれにしても、たとえもしその考察が大元のドキュメントと一緒になっていたとしても、開発者が読んでくれることはなさそう。なので、開発者ではなくセキュリティおよびプライバシーの担当者向けに準備すべき。 Torsten から、MTI についても独立させることができるのではないかという意見。 John 曰く、それはあまりいい考えではないのではと思うものの、まずは具体例を見てから判断したいとのこと。 電話会議の日程調整 -------------- Starting next week, this call time slot will be taken up by JOSE interim every other week.

[oidfj]

[Openid-specs-ab] Spec call notes 1-Aug-13 (一部和訳）

Spec call notes 1-Aug-13 Nat Sakimura Brian Campbell Mike Jones Edmund Jay John Bradley Agenda:                JWT および JOSE 仕様における新たな例示                オープン中の課題                OpenID 会合 at IETF でのトピックス                Nat's experiment                仕様に関する次のステップ JWT および JOSE 仕様における新たな例示                Mike が「ネストした JWT と鍵共有の例」を最新の JWT および JOSE 仕様に追加した                Edmund, Brian をはじめとする皆に、例をチェックするようお願いした オープン中の課題:                #863 - Stateless Registration Discovery/Messages                               John がひきつづき、別のやりかたについてコメント募集中                                              client_id の値に registration state をエンコードして返却することについて                #864 - Native Client code leakage                               nonce を HTTP Basic のパスワードとして利用することが native apps に与える影響                                              Google は自社の native apps にすでに適用している                               Brian 曰く、これは OAuth レベルのソリューションであることが望ましい (OpenID Connect レベルではなく)                                              もしくは、別パラメーターとして送るのはどうか。パスワードではなく                               John が、Brian の指摘 (レイヤを混ぜることへの懸念) についてコメント追加予定                John が、Code フローを利用するクライアントが “alg":"none" を登録する可能性について、バグ登録予定 OpenID 会合 at IETF でのトピックス:                MTI に関する議論                               Torsten から、クローズドな環境においては implicit フローを必須にしないでほしいという要望                                              そのように変更することに、みんな同意した                                                                       Mike がバグ登録予定                                              John から、クローズドな環境において implicit flow のみ、というのも許容するのはどうかという意見                                                             これについてもみんな同意                               Torsten から、response_types について section 8 MTI list に入れてはどうかという意見                                              対応予定。エディトリアルな変更であり、仕様変更ではない 仕様に関する次のステップ:                可能性としては、仕様の再構成                Nat が Messages と Standard のマージを試してみた                Messages と Standard を、機能単位でグループにわけるのはどうか:                               コア                               個別のクレーム                               分散 & 集約クレーム                               UserInfo                               Self-Issued                               JSON ベースのリクエスト                               (このうちいくつかは一緒にできるかも)                               (もしくは単に Messages と Standard を一緒にするだけでもよいかも)                We could make the uses of the definitions links                各クレームの定義を、各節の冒頭に記述                Possibly give each definition its own section heading                               Then link from the first use of each term in a section to its definition

[oidfj]

OpenID Connect の実装者向け第二ドラフトが承認されました

OpenID (Foundation) メンバーによる投票（held from July 23 and July 30, 2013）の結果、以下の仕様が OpenID (Connect) 実装者向けドラフトとして承認されました。

Basic Client Profile – OAuth の認可コードフローを用いる、Web ベースの RP（リライング・パーティ）向けの、シンプルかつ、必要なことが全て盛り込まれたプロファイル

Implicit Client Profile – OAuth の implicit フローを用いる、Web ベースの RP（リライング・パーティ）向けの、シンプルかつ、必要なことが全て盛り込まれたプロファイル

Messages – OpenID Connect にて利用するメッセージの定義

Standard – Messages の、HTTP バインディングの定義。RP と OpenID プロバイダの双方に適用

Discovery – RP が OpenID プロバイダの情報を動的にディスカバリするための方法を定義

Dynamic Registration – RP が（自身の情報を）OpenID プロバイダに動的に登録するための方法を定義

Session Management – OpenID Connect におけるセッションの管理方法を定義。ログアウト機能を含む

Multiple Response Type Encoding –OpenID Connect が使用する、OAuth 2.0 の “response_type” の値の登録

以下は投票結果です:

Approve (55 votes)

Disapprove (0 votes)

Abstain (2 votes)

Total Votes: 57 (out of 245 members = 23% > 20% quorum requirement)

実装者向けドラフトとは、仕様の安定版であり、これを実装する方々に、知的財産権の保護をもたらします。（同仕様の）ワーキング・���ループは、最終的な仕様について、今回の実装者向けドラフトと互換性を保つつもりです。

今回承認された実装者向けドラフトは以下から入手可能です:

http://openid.net/specs/openid-connect-basic-1_0-28.html

http://openid.net/specs/openid-connect-implicit-1_0-11.html

http://openid.net/specs/openid-connect-messages-1_0-20.html

http://openid.net/specs/openid-connect-standard-1_0-21.html

http://openid.net/specs/openid-connect-discovery-1_0-17.html

http://openid.net/specs/openid-connect-registration-1_0-19.html

http://openid.net/specs/openid-connect-session-1_0-15.html

http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html

OpenID Connect については http://openid.net/connect/ をご参照ください。 （同仕様の）ワーキング・グループのページは http://openid.net/wg/connect/ です。

[oidfj]

[Openid-specs-ab] Spec call notes 25-Jul-13 (一部和訳）

Spec call notes 25-Jul-13 Mike Jones Brian Campbell John Bradley Edmund Jay Agenda:                実装者ドラフト投票                オープン中の課題                JOSE の、JWK に関する課題                OpenID 会合 at IETF                Nat のブログ投稿 実装者ドラフト投票:                現時点で 20 票 （必要票数 48）                We may have to send individual reminders to some people オープン中の課題:             ��  #863 - Stateless Registration Discovery/Messages                               John が別のやりかたについてコメント追加予定。                                              client_id の値に registration state をエンコードして返却                #864 - Native Client code leakage                               nonce を HTTP Basic のパスワードとして利用することが native apps に与える影響                                              Google は自社の native apps にすでに適用している                               Brian 曰く、これは OAuth レベルのソリューションであることが望ましい (OpenID Connect レベルではなく)                                              もしくは、別パラメーターとして送るのはどうか。パスワードではなく                               John が、Brian の指摘 (レイヤを混ぜることへの懸念) についてコメント追加予定                John が、Code フローを利用するクライアントが "alg":"none" を登録する可能性について、バグ登録予定 JOSE の、JWK に関する課題:                #30: Align key usages with WebCrypto                               Would make usage multi-valued                               It's not clear what practical value this actually provides                               Typically use is there to restrict usage to a single usage - not to support multiple uses                               Multiple uses seems like a bad idea                #31: Add extractability field for JWK                               It's not clear what the intended semantics are OpenID 会合 at IETF:                People should register at http://openid-ietf-87.eventbrite.com/                We have 13 people registered currently Nat のブログ投稿:                People are encouraged to review Nat's post for accuracy                http://nat.sakimura.org/2013/07/25/write-openid-connect-server-in-three-simple-steps/

[oidfj]

the OpenID Connect Update presentation that I gave today during the OpenID Workshop at the European Identity and Cloud Conference

Mike Jones: self-issued » OpenID Connect Update Presentation

[oidfj]

◆Session3- ケーブルテレビサービスにおけるJ:COMのOpenIDへの取り組み -J:COMでは、OpenID Connectを活用した、新たな顧客ID基盤を構築した。本セッションでは、導入に至った背景や、顧客ID基盤が担う役割、そして将来の活用の方向性について紹介する。株式会社ジュピターテレコム プラットフォーム企画部 担当部長 笠井 康伸氏

OpenID ファウンデーション・ジャパン - 会員企業様向けビジネスセミナー「OpenID BizDay」開催いたします。 ジュピターテレコム様の講演概要が決定しました!

[oidfj]

今回は以下の３つのテーマで意見交換などできればと思います。 (1) OpenID 2.0 AuthNからOpenID Connectのスムーズな移行について(40min) 対象 : OpenID 2.0のOP/RPを実装している人 平行運用、移行と課題など by ritou(5min) + 意見交換 (2) OpenID ConnectのDistributed/Aggregated Claimsについて(40min) 対象 : Connectに興味ある人 仕様紹介 by ritou(5min) + ユースケース紹介LT(誰か) + 意見交換 (3) Account Chooserを理解しよう(30min) 対象 : (自前IdP/外部IdP問わず)ユーザー認証機能を実装している人 簡単な実装紹介 by ritou(10min) + 意見交換 ritouが作った資料はこちらです。 → idcon mini Vol.1 11/29開催のお知らせ

idcon mini Vol.1 : ATND (via idcon)

[oidfj]

会員企業様向けビジネスセミナー「OpenID BizDay」を12/18（火）に開催する事となりました。 「顧客ID情報の活用がビジネスを加速する」をテーマに、ヤフー様、楽天様、ジュピターテレコム様より、顧客IDがもたらす新たなビジネス拡大のチャンス・活用事例・最新トレンドを、以下のテーマを中心にご紹介いただきます。 ◆各社が自社サービスの拡充に向けて「顧客ID情報」をどう位置づけているか? ◆他事業者とのパートナーシップや自社を中心とするエコシステム確立に向けて「顧客ID情報」が果たす役割とは? ◆M&Aやグローバル展開において自社の「顧客ID情報」をどう統合していくか? ◆Webアイデンティティ標準（OAuth / OpenID Connect）が自社のビジネス拡大にもたらす価値とは? 多数のご参加お待ちしております。

OpenID ファウンデーション・ジャパン - 会員企業様向けビジネスセミナー「OpenID BizDay」開催いたします。

[oidfj]

OpenID Connect をはじめとしたIdentity API 標準技術の動向や、クラウド分野でのアイデンティティ管理の最新トレンドについて、その分野のエキスパートたちがお話します。是非ご参加ください。【お申込みは以下のATNDからお願いします】http://atnd.org/events/31320※会員企業活動者様は、席をご用意しておりますので、参加ご希望の方は、 contact@openid.or.jp までご連絡下さいませ。■ 日時 / 場所2012年8月28日（火） 19:00 ～ 21:00（開場 18:30 ～）＠ 株式会社インターネットイニシアティブ 17F 大会議室（東京都千代田区神田神保町1-105 神保町三井ビルディング）http://www.iij.ad.jp/company/about/map/head-office.html

OpenID ファウンデーション・ジャパン - 技術者向け無料セミナー "OpenID TechNight Vol.9" を開催いたします。

[oidfj]

ドミノ・ピザのサイトが OpenID 対応しました

2012年6月13日、ドミノ・ピザのサイト (https://www.dominos.jp ) が OpenID 対応しました。OpenIDを使えば、普段使っている Yahoo!, Google, mixi のアカウントでドミノ・ピザにログインして注文などをすることができるようになります。

ドミノ・ピザのサイトで OpenID を使うには、設定が必要です。

まず、ドミノ・ピザのユーザID、パスワードでログインしてください。

お客様情報ページ ( https://www.dominos.jp/order/account/ ) に行ってください。

画面をスクロールすると、右下の方に OpenID の設定画面があります。ここの [ログイン設定する] ボタンを押して、お好みのIDでログインしてください。

これで設定完了です。次回からは、OpenIDでログインできるようになります。

ログインするには、右上の「Login」ボタンを押して、次の画面でYahoo! などを選びます。

パスワードを使わないで済むので便利ですね！

[oidfj]

June 23, 2012 OpenID Connect リリース

来月のインタロップに向けて、OpenID Connect仕様群がアップデートされました。preferred_username クレームと、クレームの唯一性に関するセクションが追加され (issue #603 による)、そして誤って使用されていた request_url が request_uri に変更されています (issue #602)。

アップデートされた仕様群は以下です:

http://openid.net/specs/openid-connect-basic-1_0-20.html

http://openid.net/specs/openid-connect-implicit-1_0-02.html

http://openid.net/specs/openid-connect-messages-1_0-12.html

http://openid.net/specs/openid-connect-standard-1_0-12.html

これらの編集を行ってくれた John Bradley に感謝します。

                                                                               -- Mike

[oidfj]

European Identity Awards 2012 (by kuppingercole)

OpenID Connect は 24:21 から

[oidfj]

新しい OpenID Connect ドラフトが公開されました

AB/Connect ワーキング・グループが OpenID Connect 仕様のアップデートをリリースしました。本アップデートには、 4 月 30 日に Yahoo! に集まって行ったワーキング・グループ会合での決定が取り込まれています。それ以外に issue に挙がっている変更については、別個のリリースとする予定です。会合で議論した通り、これらは主に簡素化のための変更であり、Torsten Lodderstedt が挙げてくれた issue が役に立ちました。実装者のみなさんには、これらの新機能・変更された機能をベースに実装を行い、フィードバックしていただくようお願いします。 規定 (normative) の変更で、主要なものは以下の通りです:

Basic Client Profile では "code" response_type を "token id_token" の代わりに利用 (issue #567 による)

新規に Implicit Client Profile を作成 (同じく issue #567 による)

scope の値として claims_in_id_token を追加。これは UserInfo クレームを ID Token に含んで返却すべきかどうかを示すスイッチとなる (issue #561 による)

Check ID エンドポイントを削除 (issue #570 による)

verified を email_verified に変更 (issue #564 による)

Basic Profile から ID Token の署名検証の要件を削除 (issue #568 による)

Basic Profile から nonce の使用を削除 (issue #569 による)

オプショナルなクレーム・リクエスト���パラメーターを削除し、基本となるパラメーターで置き換え (issue #577 による)。用語として、"optional" を "voluntary" に、"required" to "essential" に変更し、プライバシー・ポリシーの要件に対しての適合性を向上

OpenID プロバイダの MTI となるための、"id_token" レスポンス・タイプを追加

OpenID リクエスト・オブジェクトと、OAuth 2.0 認可リクエストの両方に含まれるパラメーターが完全に一致しなくてはならない (MUST) ことを表記 (issue #575 による)

OpenID リクエスト・オブジェクトは JWT であると表記していたのを、JWS によって署名された base64url encoded JSON オブジェクトであるという表記に変更 (issue #592 による)

既定の ID Token 署名アルゴリズムを RS256 に変更 (issue #571 による)

既定の OpenID リクエスト・オブジェクト署名アルゴリズムを RS256 に変更 (issue #571 による)

implicit フローを用いる場合の nonce の利用を REQUIRED にし、code フローの場合は OPTIONAL に (issue #569 による)

対称アルゴリズムの場合の署名および暗号化鍵の計算方法を追加 (issue #578)

rotate_secret を別個の登録リクエスト・タイプとし、レスポンス毎にクライアント・シークレットが変わるのを防止 (issue #363 による)

登録エンドポイントへの認可に関し、記述を追加 (issue #587 による)

OAuth および JOSE 仕様群のアップデートに追随するために、OpenID Connect 仕様群もアップデートされました。JWT については、今は standards-track の版を利用しています。 今回の新バージョンは http://openid.net/connect/ もしくは以下から入手可能です。

http://openid.net/specs/openid-connect-basic-1_0-18.html

http://openid.net/specs/openid-connect-implicit-1_0.html

http://openid.net/specs/openid-connect-discovery-1_0-09.html

http://openid.net/specs/openid-connect-registration-1_0-11.html

http://openid.net/specs/openid-connect-messages-1_0-10.html

http://openid.net/specs/openid-connect-standard-1_0-10.html

http://openid.net/specs/openid-connect-session-1_0-07.html

John B.

@ve7jtb

[oidfj]

OpenID Connect, ふたつのトークンの物語

「なぜ OpenID Connect にはトークンが二種類あるの?」という質問を、たびたびもらいます。そこにはいくつかの設計上の要件があり、わたしたちは仕様策定のなかで議論してきました。 1 - RP (リライング・パーティ) からの要件は、ログイン後のユーザー・インタフェースの簡便なカスタマイゼーションです。

そこでは、ユーザーへのレスポンスを一秒以下で行うことが求められました。つまり、ユーザー ID を取得するための、IdP へのさらなるラウンドトリップ (問い合わせ) は許されなかったのです。パスワードによる認証に加えて数秒の遅延が発生するようでは、実際に使うことはできな��と、多くの RP が考えています。

Facebook は署名つきリクエスト (signed request) を用いて、ユーザー ID をレスポンスに格納して返却しています。クライアント (RP) は署名を検証し、ユーザー・インタフェースを即座に表示することが可能です。

2 - Salesforce や他の IdP には、既にユーザー情報 (user-info) エンドポイントとその他保護リソースが存在しており、これらに対するアクセスをスコープとしてアクセス・トークンに追加したいと考えています。

ここでの要件は、異なるアクセス・トークンの形式が強制されることで、既存の実装を変更しなくてはならなくなるようなことは避けたい、ということでした。

3 - T-Mobile 他では、署名つきトークン (signed token) にスコープを含め、エンドポイントに渡しています。

彼らの要件は、トークンに必要な情報だけを格納し、保護リソースに渡す、ということです。リソースは第三者に管理されていることもありうるため、ユーザー ID を送信することは、プライバシー情報の漏洩につながりかねません。

4 - Google 他の要件は、Connect が複数種類のクライアント、とくにブラウザ内の Ajax をサポートすることでした。 5 - リソースごとに毎回ユーザーに認可を求めることはできない、ということには、全員が同意しました。 まず、要件 1 を満たすには、RP に対して user_id の入った署名つきトークンを送る必要があり、そして、そのトークンは認可サーバー (Authorization Server) からのレスポンスに含まれていなくてはないことがわかります。 よって、id_token が必要なのです。Facebook には、署名つきリクエスト (signed request) という独自形式のしくみがあります。わたしたちコミュニティは、JWT という、より汎用的でオープンな標準を考案しました。これは署名つきリクエストと似ており、加えて暗号化もサポートします。 OAuth 2.0 の手法のひとつとして、異なる保護リソースに対して複数のトークンを生成することを、ダウンスコーピング (down-scoping) といいます。各リソースごとに、認可リクエストにおいて、複数のスコープを要求するのです。 認可サーバーは、すべてのスコープに対して有効なリフレッシュ・トークン (Refresh Token) を提供します。そしてこのトークンをトークン・エンドポイントに提示し、全てではなく一部のスコープに対する新しいトークンを要求することになります。 ダウンスコーピングにはいくつか問題がありますが、最も大きなものは、これが code フローでしか使えないため、要件 1 と 4 を満たせないということです。 これに対し、いくつかの選択肢があります:

id_token をアクセス・トークンとして用いる

アクセス・トークンを id_token に含める

ふたつのトークンを返却する

id_token をアクセス・トークンとして用いる方法では、要件 2 を満たせませんし、長い期間有効となるアクセス・トークンがセッション・クッキーとなってブラウザーに保管されるかもしれないという、新たなセキュリティ上の懸念が生じます。 アクセス・トークンを id_token に含めるやりかたは、Facebook Connect が選択した方法と同じです。要件 1 と 2 に対してはうまくいきますが、やはりいくつか問題があります。それは、id_token をセッション管理に用いたいと RP が考えた場合です。そのためにはセッション・クッキーに長期間有効なアクセス・トークンを埋め込むことになりますが、id_token のサイズがかなり大きくなってしまいます。要件 3 は満たせたとしても、アクセス・トークンにはその他のユーザー情報を載せることができません。 認可サーバーからのレスポンスとしてふたつのトークンを返却することで、すべての要件を満たすことができます。

 認証されたユーザーの情報が、アクセス・トークンから切り離される

 id_token のサイズをかなり小さくすることができる

 id-token をセッション・クッキーとして用いる場合にも、アクセス・トークンは漏洩しない

 アクセス・トークンを署名つきトークンにすることができ、さらに必要な情報だけを含めることができる

 code フローを用いる場合に、引き続きダウンスコーピングを行うことができる

 id_token をユーザー・セッションの生存期間と結びつけることが可能であり、一方、アクセス・トークンの生存期間とは切り離すことができる

 ふたつのトークンの受け手 (audience) を分けることができるため、それぞれの受け手に合わせた暗号化を行うことが容易となる

一般的に、 OAuth 2.0 の implicitフローを用いる RP では、あらかじめ登録されたリダイレクト・エンドポイントに認可サーバーから返却されたレスポンスの中から、id_token を取り出します。次に署名を検証し、そこに含まれる user_id を用いて Web ページをカスタマイズする一方、もし必要であればさらに、OAuth 2.0 によって認証されたリクエストを user_info エンドポイントに対して行います。これにより、再度アクセスしてきたユーザーのログイン処理を、RP が許容することのできる時間内に行うことができるようになります。新規ユーザーの場合であっても、比較して少し時間はかかりますが、プロファイル情報を取得することが可能です。 OpenID Connect に関連して、新規の OAuth 2.0 response_type が複数登録されています。これによって、クライアントからの様々な要求を満たすためのトークンの返却方法に、いくつかの選択肢が生まれることになります。 id_token を活用した、セッション管理およびシングル・ログアウト拡張についても、現在検討中です。 トークンを分離することについては、現在 OASIS の SAML WG がセッション・トークン・プロファイルの公開レビューを行っており、おそらくそこで部分的にですが検証が行われることになるでしょう。 トークンをひとつにすることは一見魅力的ですが、たくさんの理由から、わたしたちのユースケースの多くに対してはうまくいきません。わたしも単一の JWT トークンを主張していた一人ですが、結局負けました。 近いうちに、OpenID Connect  の response_typeについて投稿したいと思います。 John B.

[oidfj]

NETWORKWORLD の NSTIC に関する記事

NETWORKWORLD に、米国 NSTIC (National Strategy for Trusted Identities in Cyberspace) に関する二つのコラムが掲載されていたので、紹介しておきます。

Can the Obama Administration fix your identity management problems?  （オバマ政権はID管理に関する問題を解決できるか？）

オバマ大統領は、NSTIC のドキュメントの冒頭で、ID窃盗やプライバシー侵害を防ぐたために、セキュアじゃないパスワードをなんとかし、オンライン取引をもっと信頼性の高いものにしたいと謳っている。また、これは米国政府の負債削減という意図も。

NSTIC のワークショップでは、民間のベンダー団体の Open Identity Exchange (OIX) や、Kantara Initiative が参加しており、パイロットプロジェクトが行われる予定。OIX は、OpenID Foundation の姉妹企業。

OIX のメンバーである Verizon 曰く。NSTIC の目的は、オンラインのビジネスが誰にとっても簡単になること。例えば、Best Buy のサイトで買い物するときに、Verison の ID でログインし、さらに必要であれば、ワンタイムパスワードを携帯電話に発行し、それでアクセスできるようになる。

Verizon は長年政府に対して PKI の証明書を発行する仕事をしてきたが、今回 Identity Ecosystem を構成するメンバーの一社と、その立場を変えた。

NSTIC director: 'We're trying to get rid of passwords'  （NSTIC担当高官 「我々はパスワードを無くすことに注力している」）

NSTIC の担当官である、Jeremy Grant 曰く。パスワードだけに頼らない高度な認証サービスを提供している民間事業者と作業している。目下、彼らと標準ガイドラインに関して合意を取ることに注力中。

17.5百万ドル（約14億円）の予算を今年度 NSTIC のパイロット・プロジェクトとして計上。

Identity Ecosystem では、発行された ID を監査するが、その基準や仕様については、NIST 自身が書かない。NIST は民間企業がコンセンサスを取れるような標準づくりを支援する立場に徹する。これは、大変なチャレンジだけども。

NSTIC には政府による中央集権的データベースは存在しない。政府は、NSTIC に認定されたサービスを採用する。但し、そのための監査はやる。

パスワードというものは脆弱なため、政府は業務をオンライン化できていない。

OIX の会長である Don Thibeau 曰く。パスワードはセキュアではない。Google をはじめとした OIX のメンバーは、政府の NSTIC プログラムに参加している。

OIX は OpenID と OAuth の仕様をベースに、インターネット・スケールのアイデンティティ標準を実現しようとしている。

OIX のメンバーで、NSTIC のパイロットの他に、民間だけでのパイロットも計画。 (Google, AOL, Hotmail 間で)

NSTIC は新しい考えにもとづいたセキュリティ設計に挑戦しようとしている。

[oidfj]

Follow The (OpenID) Money

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

Cloud Identity Conference 期間中で開催された OpenID Summit (PingIdentity 社主催)や、Gartner の Catalyst カンファレンス(Identity Management で最も高名なイベントの一つ) で最もホットな話題は、「エンタープライズのコンシューマーサービス化」でした。OpenID は、技術面の牽引役としてこの話題の中心にあり、エンタープライズ及びコンシューマーの両方の利用ケースにおいてどのような価値を果たすのか議論されました。

ついさっきまでインターネットのほんの片隅にいたのに、今メインストリームへ適用されようとしている OpenID の進化は、インターネット・アイデンティティの世界に革新をもたらしたと、ひょっとすると後に理解されるかもしれません。Salesforce.com の Chuck Mortimore 氏の「Does OpenID work for the Enterprise?（OpenID は企業向けで使えるか？）」というお題のプレゼンテーションを見ると、OpenID のユーザ中心的な発想が、事業者中心的なアーキテクチャーをどのように変化させるか、最前線にいるプレーヤーの大胆な考察が伺えます。

OpenID が流行るか流行らないかを判断するには、"follow the money" いわゆる「お金の匂い」がするかどうか嗅いでおくこと、つまりは、リーダー的企業の動きを追っかけっていればいいでしょう。OAuth 2.0 と同じく、OpenID Connect は、数ある技術標準の中でも、Google と Microsoft、Facebook の三社が���んで技術的関与をしているという点で、類を見ない標準です。

これらの企業や、リライング・パーティがどうしていくのかは、誰も予想出来ないけども、彼らがどこに投資しているのかについては見ておくことができます。関連するカンファレンスやパイロットで、JanRain や PingIdentity のような業界のリーダー的企業が、OpenID プロトコルに対して、数年掛けて数億円の投資を行っているわけです。

このような投資の動きを見てると、今日の Web におけるソーシャルへのログインやシングルサインオン以上の価値がありそうだと判断できます。投資アナリスト達は、世界的に Identity Management ソリューションに大きな需要があると言っていて、Ping Identity や Janrain のような会社は、ファンドからの大規模の投資を受け、このビジネス機会をものにしようとしています。

もちろん不安要素もあるわけで、それはChuck Mortimore 氏が言うような新しいマーケット環境に適応するために、OpenID が過去1、2年ずっと静かだったという点です。だけども、標準というものをつくることは、そんなに簡単ではなく、時間とお金がかかります。業界のリーダー的企業によって率いられるボランタリーのコミュニティは、OpenID のような基本技術を再設計するには、いろいろと配慮する必要があるわけです。

一方で、Symantec や PayPal、Google などの OpenID ファウンデーションのメンバーは、OpenID Summit や様々なイベントを共催し、OpenID の進化について議論し、さまざまな分野でどう適用していくか計画を立てています。OpenID は、将来の確固たる技術的な基盤として、シリコンバレーのある意味寵児になりつつ��ります。

OpenID Foundation と Google が携わってきた、Account Chooser の仕組みを見てもらえればと思います。これは、分散型の相互運用可能なアイデンティティ・ソリューションの考え方を踏襲しながら、OpenID 技術をマス向けに分かりやすく拡張可能にしたものです。

OpenID が再び流行るかどうかを見極めるためには、どうしたらいいでしょうか。9月12日と13日にカリフォルニアのマウンテンビューの Microsoft のオフィスで実施される「OpenID Summit」にて、OpenIDファウンデーションは、技術的インターロップとテストのためのワークショップを開催します。OpenID Connect に興味を持っている、技術者・開発者向けになります。

ここでは、Webサイトの運営をしている企業が、パスワードを自社で管理するべきでなく、IDプロバイダーとの連携をとるべきである理由について、いろいろと学べるセッションを用意しています。OpenIDの進化が、上昇基調にあるのかないのか是非目で見て確かめて頂ければと思います。乞うご期待！