Monday Jun 16, 2008

New College Graduates

大渕さんのエントリ 「大学四年生のみなさん、Sunで働いてみませんか?」 「Sun Japan の Blog ってどの部署の人が書いてるの?」 を読んで思い出したんだけど, Sun Japan で blogs.sun.com にブログ書いてる社員って, 新卒で入った人の割合がけっこう高い気がする. もしかしたらこういうのも 「企業文化」 のひとつなのかも (大げさ?).

ちなみにぼくも新卒の一人だったりする. 当初は米国系の IT システム・ベンダに就職することは想定してなくて, たまたま日本サン (当時) が出してた新卒募集の新聞広告を見た叔父から 「おい達雄, ここ話聞きに行ってみなよ」 と教えてもらって, 6 月半ばに用賀の説明会に参加したのがそもそものきっかけ. で内定出たのが 7 月 7 日 (七夕) だった, たしか. そしてぼくの hiring manager は増月さんだった (入社後, SunSoft (当時) に配属されてから知った).

...ということでとくにオチは無いけど, たとえば 「正社員になって OpenID.sun.com のアカウントをゲットしたい!」 とか, Sun のやってることに興味のある対象者は, とりあえず用賀での説明会に行ってみるといいと思った.

なにが縁になるかはわからないし.

新卒者向け説明会実施 7/3(木) 13:00~ 東京・用賀本社 詳細は近日中にお知らせします。

Thursday Jan 17, 2008

イルカが飛ぶのを手助けする

Sun が MySQL を買収という話は, (某社による某社の買収とは違って) まったくの寝耳に水だったから, 超びっくりした. あまりにびっくりしたので, 今朝新大阪に向かう新幹線の車中で Jonathan のエントリをざっくり訳してみた. 手元に辞書のたぐいが無かったのでかなり適当かもしれないし (とくに 「第二に...」 のくだりは自信ゼロ), たぶんそのうちプロ翻訳者による公式和訳が出ると思うけど (ひと月後くらいかも), よろしければどうぞ.

Helping Dolphins Fly

わたしたちは本日ビッグ・ニュースを発表した. ひとつは第二四半期の業績の暫定結果, そしてもうひとつ重要なのが, MySQL AB を買収するということである.

もし今四半期の業績の詳細に興味があれば, 電話会議を聴いてもらいたい (sun.com を参照). もちろん, 正式な結果は 1 月 24 日に発表する予定である.

しかし, 本日もっとも大きなニュースは... わたしたちが LAMP の M に 10 億ドルを出すということだ. 業界関係者の方であれば, これがどういう意味をもつかおわかりいただけることだろう. わたしたちは MySQL AB を買収する. この企業は MySQL を提供している. そして MySQL は, 世界で最も人気のあるオープンソースのデータベースなのだ.

数週間前, わたしがある顧客とのイベントについて書いたことをご記憶だろうか. そのイベントにおいて, わたしたちは世界的に注目されている Web 企業たちから, 彼らが抱えている技術的な課題について話を伺った. 同時にそのイベントには大手 IT 企業, そしてその CIO の方々にも参加していただき, 二日間同じ時間を過ごし, 彼らのビジョンとめざす方向についてお聞かせいただいた.

どちらの顧客層も, わたしたちがここ数年で得た知見を裏づけるものであった. それは MySQL が, 今日の開発者がネットワーク・サービスを創る上での, 最も人気のあるプラットフォームであるということだ. Facebook, Google, Sina.com から銀行, 通信会社に至るまで, アーキテクトは性能, 生産性, 革新性を追求する上で, MySQL を選択しているのだ. そしてそれは, 高校や大学でも, スタートアップ企業でも, ハイ・パフォーマンス・コンピューティングの研究機関でも, Global 2000 でも. MySQL の広まりは地球的規模であり, とどまることはない. 彼らは巨大な Web 経済圏の泉の, まさに起源なのである.

しかしわたしが指摘した通り, そのイベントでは同時に矛盾することも耳にした. スタートアップ企業の CTO や Web 企業は, フリー / オープンソースではない製品の使用を禁止している. 最適化と迅速な問題解決を実現するために, 彼らはソースコードへのアクセス権を求めており, かつ必要としているからだ (しかし一方, もしサポートに十分な価値を認めることができれば, 彼らは喜んで対価を支払う). ひるがえって, もっとトラディショナルな CIO は, 商業サポートが得られない製品の使用を禁止している. 彼らは Sun のようなベンダを信頼し, ミッション・クリティカルな基盤をグローバルに管理させることに満足しているのである.

このような状況において, MySQL のような製品は興味深いポジションにある. それらの製品はすべての Web 企業にとって, 間違いなく基盤の一部分である. そして一般的な企業 (自動車, 金融, 銀行, 小売など) もまた MySQL を使っているけれども, 彼らの多くは, ミッション・クリティカルなグローバル・サポートを提供する Fortune 500 ベンダの出現を待っているのだ.

そこで, わたしたちは今日何を発表するのか? MySQL の買収に加えて, MySQL 市場への新たなグローバル・サポートの提供を明らかにするのだ. わたしたちはコミュニティに投資し, 同時に市場に投資する. これにより, 業界を次の段階, すなわちプロプライエタリなテクノロジからオープンな Web プラットフォームへと, 移行を加速するのである.

良いことに, Sun はすでに MySQL の成功の根本であるビジネス・モデルにコミットしている. 彼らの成功とは, まず最初はユーザと開発者のコミュニティの成長に投資し, その後で, 対価を支払うことにやぶさかではない顧客に対して魅力的な (ロックインではない) 商業サポートを創ることによってもたらされた. 過去数年にわたり, わたしたちは数百万ライセンスを配布し, フリー・ソフトウェアの世界でも最大規模のコミュニティの構築に投資してきている. それは Java から ZFS, そして Lustre から Glassfish, NetBeans, さらに OpenOffice.org から OpenSolaris まで, 根気強く投資と貢献の両方を行なっている. フリーでオープンなソフトウェアは, Sun の生活様式となったのだ. MySQL のやりかたも同じように, 彼らのコミュニティ・プラットフォームの驚くべき広まりを牽引しており, 過去 10 年で 1 億を越えるダウンロードをもたらしている. MySQL のユーザは, Sun の顧客と同様に, MySQL をすべてのメジャーな OS 上で稼働させている. Linux, Windows, Solaris, そして Mac. さらにそれは IBM, Intel, AMD, Dell, Sun, HP といった, すべてのメジャーなシステム・プラットフォームを使って.

偶然ではないが, これらの企業はまさしく Sun が OEM 契約をむすんだ企業なのだ. よって, MySQL を Sun のエコシステムと販売チャネルに統合することは非常にやりやすい.

そして, わたしたちはこの新たな機会をどうやって活かしていくのか? いくつかの基本的な方法がある.

わたしたちは Sun のプラットフォームでの MySQL の最適化に取り組んできたという, 歴史的な経緯がある. それは初期の Oracle に対してわたしたちが行なってきたように, Sun のパフォーマンス・エンジニアリング部隊が MySQL 側の担当者と席を並べて (バーチャルな意味で), コミュニティ内で, ZFS や DTrace (これらは Oracle 時代には無かったけど) のようなテクノロジを活用し, Sakila を検証していくことになるだろう. そこには, そのほかの LAMP スタック (memcached や php から, MySQL に関係する広範な ISV コミュニティに至るまで) も一緒に. MySQL はすでに, さまざまなベンチマークにおいて性能的にリーダーである. わたしたちはこのパフォーマンス・リーダーシップを, 目についたすべてのアプリケーション (そして Sun だけではなくすべてのベンダのハードウェア・プラットフォームに. さらに Linux, Solaris, Windows, とにかくすべて) のディフォルトにするつもりだ. 技術的な観点から言えば, Falcon は間違いなく Niagara 上でさえずりを聞かせてくれるだろう... 夢のような組み合わせについて語ろうではないか.

第二に, わたしは社内チームに, 契約完了に先立ち, 公正な商取引について交渉するよう求めた. これによりわたしたちは, MySQL へのグローバル・エンタープライズ・サポートを提供できるようになる. プロプライエタリなデータベースに対して提供されるミッション・クリティカル・サポートと同様のサポート内容を求める一般的な企業が, MySQL を使う場合にも同じように心の平安を得られるのだ. このことは彼ら企業に対し, 新たな選択肢と市場競争のある世界をもたらす. 先に述べたが, 過去何年にもわたって顧客がわたしたちに求めている事項をひとつ選ぶとすれば, それはデータベース市場におけるさらなる革新であった. そして今, わたしたちはその要求に応えるポジションにいるのである.

第三に, わたしたちはとてつもなく魅力的なプラットフォームの提供を発表する. それは Lustre と ZFS の成功を活用し, 新たなシステム・プラットフォーム (新しい 48TB Thumper や 64 スレッドの Niagara2 マシンのような) とともに, 目玉が飛び出るほど優れた対価格パフォーマンスをもたらすものである. 最終的には, このような製品を顧客は望んでいるのだ. 本物の価値があり, グローバルなサポートを受けることができて, 品質と性能の伴った製品を. もっとも重要なことは, MySQL のパートナーはわたしたちのソリューションとその展開に関しての要となるということである. Solaris や Java でわたしたちが行なってきたように, マーケットを広げることで ISV の成功がさらに拡大するよう, わたしたちは一生懸命やっていくことになる. これまで数十年かけて構築した広範なパートナー・ポートフォリオは, 今では顧客が Sun に対して認識する価値の, 重要な要素となっている. そしてそれは MySQL でも同様であると, わたしたちは理解している.

そして最後に, この買収は学術コミュニティへの Sun の新たな投資の契機となるであろう. なぜ大学か? わたしたちは全世界でのオープンソース・ソフトウェアの開発への投資を継続して行なっているが, ほぼすべての道がアカデミックな環境につながっていることは明白である. そして (業界の一員たる) わたしたちが, その樹木の根元に水をやるときがきたのだ. 教育にコミットする, と口先で言うだけではなく, われわれは行動で証明していく. 60 日以内に Greg が, インターネットに関する工学を発展させるための, 新たなグローバルな研究奨学制度を発表する. (このブログや, Greg のブログにて今後お伝えする.)

さて, なぜこのことがインターネットにとって重要なのか? いままで, どのプラットフォーム・ベンダも, インターネットのための完全にオープンソースなオペレーティング・システムのコアとなる要素を組み上げることをしていなかったのだ. またいずれの企業も, リーダー的な位置にあるプロプライエタリな OS の包括的な代替品を出してこなかったのである. この買収によって, わたしたちはそれを成し遂げたつもりだ. Sun を Web の中心に, そして Web 経済圏のための高性能なプラットフォームを提供する最高のプロバイダとして位置づける. 対象はスタートアップ企業や Web 2.0 企業から, 政府機関や一般的な企業まで. このことは Sun のみならず, グローバルなフリ���・ソフトウェア・コミ��ニティや世界中のパートナー, お客様においても, ���てつもないポテンシャルを生むことになる. 至るところに機会が生まれるのである.

MySQL のみなさん (社員の方々だけではなく MySQL のお客様やパートナーも), ようこそ. わたしたちは, みなさんに加わっていただくことに大変興奮しています. この買収が, インターネットの新たな時代の始まりをつづることになるのです.

M という頭文字から.

Friday Aug 24, 2007

planets.sun.com/OpenSSO

なんかしらないうちに, planets.sun.comOpenSSO の Planet ができてたみたい.

OpenSSO Blogs

Saturday Apr 28, 2007

blogs.sun.com 三周年, その効果

Tim Brayblogs.sun.com (b.s.c.) の三周年に寄せて, それがもたらした効果をいくつか挙げている. 曰く,

  • 「顔の見えない大企業」 から, 「IT ビジネス / テクノロジ大好き人間の集まり」 へと, Sun に対する世間の認識が変わった
  • 経営層が, ジャーナリストやアナリストにフィルタリングされることなくメッセージを伝えられるようになった
  • フィールドにいる営業から, 「こないだ b.s.c. で読んだ誰かのエントリが役にたちました」 という話を聞くようになった
  • 世界中に散らばっている社員が自分の意見を表明することができ, かつそれを別の社員が発見しやすくなった. 「優秀な人はあなたのいるところ以外のどこかにいる」 (Bill Joy の例の言葉のもじり)
  • 全社員の 10% 弱が週に一本以上エントリを公開するようなブロガーになった

とのこと.

実際に b.s.c. に参加している立場からいうと, 直接コンタクトをもらう機会の増大がいちばんの大きな効果だと感じる. たとえば原稿の依頼や, IdM システムを検討されている方からの個人指名での引き合い, そして同業他社からの (自主規制) とか ;)

Friday Feb 16, 2007

http://www.sun.com/ が blogs.sun.com の新着エントリを表示

いつからかはわからないけど, sun.com のホーム・ページが blogs.sun.com をアグリゲートするようになってた. 下の Participate のわきにある, 右向き三角アイコンを一度クリックするとアクセス数上位のブログ一覧が, さらにもう一度クリックすると新着エントリの題名が表示される. (いまみたら hiroa ブログの 「自己紹介的なところ」 が載ってた. アクセス数増えた? > hiroa)

それにしても, まさか会社のトップ・ページに Employee-Generated Content をもってくるとは...

Thursday Jun 29, 2006

IdM 構築サービス市場

Ash's Identity Management Rantings「Identity Management Services Market」 というエントリが興味深い (ここの筆者の勤務先はどうやら競合他社の製品を使った IdM 構築やってるシステム・インテグレータのようだけど, それはそれとして). 後出しジャンケン的なんだけど, これとまったく同じことをぼくも考えていた.

What about services? I'm sure the folks in Deloitte, PWC, etc. have thoroughly researched the topic - unfortunately, I'm unable to find anything directly on the matter.
Ash's Identity Management Rantings: Identity Management Services Market

というのもちょうど今日 (昨日?) ITmedia エンタープライズに 市場に出回る主なID管理製品を紹介する 記事が載ってて, まあ IdM を取り上げてくれること自体はもちろん歓迎なんだけど, でもこれってまさに先日書いた

IdM 製品とはどういうもので, それはどういう機能が入ってて, どんなベンダがいてといった情報は, まったく必要ないとはいわないけど, もし本当に IdM プロジェクトを推進していくのであればこういった 「製品同士を突き合わせて○×表を書くためのネタ」 はオマケにすぎない. それよりも本当に重要なのは 「IdM プロジェクトとはどういうもので, それはどういう要素から構成されていて, 成功させるためにはどのように進めなくてはならないか」 を理解することだ.
tkudo's weblog about identity management: ガートナーの 「Sun はユーザ・プロビジョニング分野のリーダー」 リポートを読んで

「(めったに役に立たない) ○×表を書くためのネタ」 だと思うのだ. それよりも Ash 氏のエントリにあるように,

  • (構築期間は) どれくらいかかるのか?
  • 構築を行なうプロフェショナル・サービス会社の選定基準には、 各業種によってどのような傾向があるか?
  • 運用や保守をどの程度外部委託しているのか?
  • 社内リソースの活用状況は?
  • 構築会社を選定する上で鍵となる要素はなにか?

Ash's Identity Management Rantings: Identity Management Services Market

といったあたりをまとめた上で, 「現在国内で, 『市場に出回る主な ID 管理製品』 を使った IdM 構築ができるコンサルティング / SI 会社一覧」 を紹介してほしいなあ. そういった内容のほうが本当にターゲットとすべき読者に対する訴求力が高まるはずですので, IdM を特集される方におかれましては今後ぜひご検討いただければ幸いです.

Saturday Jun 24, 2006

Heads Up to 元社員: Sun Alumni Blog Aggregation

community.sun.com

Sun が元社員のブログを sun.com でアグリゲートしはじめたみたい. その名も community.sun.com. 社員ブログはいまではわりと一般的だけど, 卒業生ブログまで公式サイト経由で公開してしまうとは.

登録申請は以下からどうぞ.

Friday Jun 23, 2006

コリアン IdM ブログ

たまたまみつけた, Seung-Hyun Kim という人のブログがかなりいい. アイデンティティ管理, ユーザセントリック・アイデンティティ, フェデレーション, セキュリティ, Web 2.0 などのネタが満載で, かつタイムリーに更新されている. ぼくのブログを読んでくださっている方であれば, 即刻フィードを登録すること間違いなし. 原文は日本語ではないけど, 自動翻訳を通すと結構ふつうに読める.

Friday May 12, 2006

NetBeans Enterprise Pack 5.5 早期アクセスはアイデンティティ Web サービスの開発環境を同梱

NetBeans IDE 5.5 Beta Now Available

Bistro!: NetBeans 5.5 does security/identity too! 経由で知ったんだけど, 昨秋 JavaOne Tokyo 2005 にて Pat がデモしてた Liberty ID-WSF / JSR 196 の実装がどんなものか, いよいよ実際に試すことができるようになったらしい.

アイデンティティ管理

  • WSI-BSP のトークン・プロファイルに基づく, 相互運用可能なセキュア Web サービスの開発
  • Liberty 仕様準拠の (アイデンティティ) 連携 Web サービスの開発
  • 必要となるすべての実行環境, すなわち (Sun Java System) Access Manager, JSR 196 仕様ベースのプロバイダ, そして Sun Java System Application Server は, NetBeans Enterprise Pack の一部としてインストールされ, かつ完全に設定されます.

NetBeans Enterprise Pack Features

チュートリアルも公開されている. 最後のサマリにある, no detailed knowledge of SAML was needed! というのが重要だろう.

NetBeans Enterprise Pack 5.5 早期アクセスには, セキュアなアイデンティティ対応 Web サービス・クライアントとそのプロバイダ開発をはじめるうえで必要となる, ランタイムのすべてが同梱されています. この中には以下のランタイムが含まれています:

  • Sun Java System Application Server 9 Platform Edition
  • Sun Java System Access Manager 7.1 and Policy Agent 2.2 for Web Services Preview

本チュートリアルでは, Web サービス・クライアント / Web サービス・プロバイダ間での SAML ベースの認証を, 同梱の Access Manager および, WS-Security 標準のサポートが統合された Application Server の Web サービス・クライアントとサーバサイド・コンテナによって実現する方法を示します.

NetBeans Enterprise Pack 5.5 - Securing Web Services

Saturday Apr 15, 2006

WS-\* (実写版)

P@ Log 経由. WS-\* のスター (アスタリスク) はコレのことだったなんて! 超ベタネタなんだけど LOL.

Wednesday Mar 29, 2006

圧倒的な Sun Java System Web Server 技術情報

Sun Java System (SJS) Web Server の開発エンジニアである Chris Elving が, SJS Web Server ネタを blogs.sun.com で書き始めたみたい.

一本目のエントリからいきなり前振りなしに, Apache HTTP Server の XBitHack full 相当品を NSAPI フィルタで実装する例を解説している! すばらしい.

I thought this would be a good opportunity to demonstrate a new technology in Web Server 6.1, NSAPI filters. NSAPI lets you extend a web server with custom plugins, and its been part of Sun's Web Server for years.
elving's web server logs: Last-Modified and NSAPI Filters

I hope to share some other NSAPI plugins in the future. Have any of you done anything interesting with NSAPI? とのことなので, 作ってもらいたい NSAPI プラグインをリクエストしたり, あるいは 「NSAPI でこんなん作ったよ (岩片さん, これぜひお願いします!)」 と伝えてみるとおもしろいかも.

Monday Mar 27, 2006

圧倒的な Sun Java System Directory Server 技術情報 (その 2)

先日書いた, Neil の Sun Java System Directory Server ネタの超濃い blog に関するエントリの続き. 今回はとりあえず 2006 年 1 月末までの要約.

  • SSL over LDAP のアクセラレーション (高速化) ができない理由 (01/03/06)

    結論から言えば, SJS Directory Server をはじめとする LDAP サーバ・ソフトウェアの LDAP over SSL の処理性能を SSL アクセラレータで向上させることは基本的にできない. これは LDAP の使われ方 (HTTP と比べると接続が long-lived) によるもので, LDAP サーバの実装の優劣に関わる話ではない.

    高速化のためではなくセキュアな鍵ストレージとして SSL アクセラレータを使うというのであれば, それはそれで意味がある.

  • SLAMD はどうなった? (01/08/06)

    SLAMD の近況. 次期バージョン (CVS でチェックアウト + ビルドも可能) では以下の変更・拡張が入る予定:

    • 設定の保存先に LDAPv3 でなく Berkeley DB Java Edition を使う
    • SLAMD サーバとクライアントとの間のプロトコルを変更し拡張しやすくする
    • その他, 予想残り時間の出力, 改善したとみなす閾値の設定, MPStat や IOStat, NetStat などのリソース監視, HTTP クライアントの Cookie 管理の改良, 閲覧専用モードの追加など
  • Sun T2000 対 Dell 6850 再び (01/10/06)

    以前書いたベンチマークの追加試験結果. 格納するユーザ・エントリの数を変化させて, LDAP 認証性能を計測している.

  • RAID の重要性 (01/20/06)

    SJS Directory Server のディスク構成としては通常, RAID 1+0 (パフォーマンスと冗長性を重視) が適当. だけど RAID 5 (容量と冗長性を重視) のほうが向いていることもある. それは非常に大量のエントリを扱っている場合. 性能は落ちるけど, 何か障害が起こったとき長時間にわたるインポートをし直さなくてすむから.

  • あまり知られていない性能向上テクニックその 3: 参照整合性プラグイン (01/20/06)

    参照整合性プラグインに必要となる属性にはきちんとインデックスを設定すべし. さもないと削除 / 変更オペレーションのたびに長い時間待たされることになってしまう. また参照整合性の更新の遅延時間 (nsslapd-pluginarg0) も 0 以外の値, 1 ~ 10 (秒) にしたほうが良い. さらに参照整合性プラグインのログ・ファイル (nsslapd-pluginarg1) も, 適切な場所に設定すること.

  • Directory Server にコアをダンプさせる (01/23/06)

    タイトル通り, コアの吐かせ方のベスト・プラクティス. coreadm(1M) で適切に設定した後に kill -11 {PID}.

  • よく尋ねられる質問その 1: サイズの制限 (01/24/06)

    基本的に, なにか制限値が SJS Directory Server に埋め込まれていることはない. 初期値によって制限されることはあるけど, これらも変更可能.

    あとは ASN.1 エレメントの最大サイズ (32-bit signed integer, すなわち 2 GB マイナス 1 バイト) やエントリ ID (4,294,967,292 まで) があるけど, 実際の利用で問題になったと言う話はきいたことがない.

  • よく尋ねられる質問その 2: 非 SSL 接続を無効にする (01/26/06)

    これはいくつか方法がある. nsslapd-port を 0 にするのが一番てっとり早いけど, bak2db.pl などの管理スクリプトにちょっと改修を加えなくてはいけなくなる. おすすめは non-SSL のみループバックにすること. 具体的には nsslapd-listenhost を 127.0.0.1 とする.

  • よく尋ねられる質問その 3: ログ・ファイルのパーミッション (01/27/06)

    現行の SJS Directory Server 5.x は自身の出力するログ・ファイルの所有者を nsslapd-localuser の値に, パーミッションを 600 にセットする. これを 640 にしたいというリクエストが多くあって, その機能が次期バージョンの 6.0 に入る予定.

    5.x でのとりあえずの回避策としては cron で定期的にパーミッションを修正する方法がある. ただこれはシンプルだけど, あまり美しいとはいえない. Solaris なら以前書いたようにロールを使うとベター. usermod -K type=role dirsrv および usermod -R dirsrv {username} とかする.

  • よく尋ねられる質問その 4: 既定のアクセス制御 (01/27/06)

    既定のアクセス制御設定では cn=schema などへの anonymous アクセスを許可してるけど, これを無効化したいという話.

    技術的には ACI を ldap:///anyone から ldap:///all に変更するだけで認証済みユーザのみのアクセスに制限することができるけど, root DSE へのアクセス制御は変えないほうがいい. SJS Directory Server にどのようなケイパビリティがあるか, 未認証状態の LDAP クライアントからはわからなくなる. その結果たとえばどのような SASL メカニズムがサポートされているか, 外から判断できなくなってしまう.

    それと比較すると, cn=monitor にはアクセス制限をかけてもいいかもしれない. でも一般的にヘルス・チェックで使われることが多いから, いろいろ面倒くさいことになりそう.

    いずれの場合も, アクセスを制限をしたいのなら別の方法, たとえば IP アドレスで限定するとかのほうがおすすめ.

Friday Mar 24, 2006

社内連絡: 「ジョナサン・シュワルツの日本語ブログ」 の作業場所

(これは社内向けのエントリです. すみません.)

社内の某サイトに Japanese Translation: Jonathan Schwartz's Weblog社内ページを設けました.

和訳作業中のエントリ参加者のメールのやりとりなどを載せているので, 興味のある方, とくに和訳に赤ペンを入れたいとウズウズしてる方はぜひどうぞ.

「ユーザセントリック・アイデンティティ」 とリバティ・アライアンス

リバティ・アライアンス新しいホワイトペーパーを公開した. 表向きの主題は 「ユーザセントリック・アイデンティティとは利用者本人がアイデンティティ情報をコントロールすることであり, それはリバティ・アライアンスの仕様にすでに盛り込まれています」 だけど, その裏は 「Dick Hardt が俺らを指して Identity 1.5 とか言ってるけど, そんなことないよ!」 てことなんじゃないかと勝手に推測してみたり.

User-centric identity involves users in the management of their personal information and how that information is used, rather than to presume that an enterprise or commercial entity holds all the power. The open identity protocols of the Liberty Alliance have built-in user consent and privacy features, which are designed to work with a wide variety of network devices.
Liberty Alliance Project Whitepaper: Personal Identity, March 23, 2006

いわゆる某 2.0 やその類似品たちとリバティ・アライアンスとの根本的な違いのひとつは, 信頼関係をどう位置づけているかだろう. 前者は loosely-coupled な信頼関係, あるいは信頼関係の無い状態がディフォルトで, 必要になったら信頼関係を築いていく (あるいは既存の信頼関係を取り込む) というアプローチ. これに対し後者は, 確立された信頼関係に基づく運用が大前提. その結果できた仕様をみると, 前者は軽量で後者はヘビーになってる. しかし信頼関係を活用しようとすればするほど, いまは軽量を謳ってる前者も, 同じように複雑なものとなっていくはずだ.

どちらが正しいのかはわからない. いずれにせよ, もし 「リバティ・アライアンスはユーザセントリック・アイデンティティじゃないからイケてないよねー」 という人がいたらそれは全くの誤解 (protocol-rigidity と user-centricity は無関係) なので, ぜひこのホワイトペーパーを読んでほしいなあと思う.

Friday Jan 20, 2006

Jonathan's Blog の日本語版にエントリ追加

Jonathan's Blog昨年 12 月 9 日付のエントリ (Niagara / Galaxy ネタ)日本語に訳してみた.

おそらくみなさんは、 社会的公共インフラに進化をとげたテクノロジーとして、 私がしばしば電力を例に挙げることをご存知かと思います。 電力は当初ある大きな資産家の所有する高級品でしたが、 いつしか世界中の政府が市民に対しその提供を保証するようなテクノロジとなりました。 なぜでしょうか? それは、電力が生活を変革し機会を創出するからです。
Japanese translation: Jonathan Schwartz's WebLog: Let's Change This (Japanese Translation)

誤訳の指摘やもっとうまい表現などあれば, ぜひコメントくださいませ.

About

tkudo

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today