=katsu/(+blog)

hatenaへ

2008-10-25T12:22:00.000+09:00

tkudoさんの指令？で、もっと発信しなくてはと思ったけど、
続くんだろうか。

http://d.hatena.ne.jp/kthrtty/

OpenIDの商標。

2008-07-18T22:53:00.004+09:00

OpenIDの技術ばかり見ている傾向がありますが、たまには権利関係の話でもしてみましょうか。
# かくいう僕は、OpenIDの攻撃方法ばかりに思いを巡らせている、嫌なやつと化していますが。

OpenIDの権利関係って殆ど知ってる人っていないと思うのでそれなりに有益でしょう。

まず、OpenID Foundation(OIDF)のしていること

Specificationに関わる権利を保有して、フリーであり続けるように維持しています。
Specificationに誰かのPropertyが紛れ込まないように、仕様策定のProcessを定めたり、縛ったりしています。
雰囲気は・・・やめておきます。

次に、OIDFがしていないこと。

openid.netはOIDFのものじゃないです。現時点では。SixApartのものです。
Yadisの権利は持ってないです。誰が管理しているのか明確には知らないので、逆に教えて頂きたいです。
OpenIDのトレードマーク(商標)はOIDFは管理していないです（なんと！後述。）

今回のテーマでもある商標。では誰が管理しているのでしょうか。

答えは、OpenID Europe Foundation(OIDE)が管理しています。
代表のSnorri氏は、OIDFの規約整備などで多大な功績が認められ、EU代表としてOIDFのBoardに任命されています。

では、OIDEのTrademark Policyについて確認してみます。
http://www.openideurope.eu/policies/openid-trademark-policy/

"OpenID"という単語そのものにTMを付与しなければならない国がたくさんありますね。
日本はリストに入っていませんが・・・既にWIPOにたいして国際出願の依頼がなされており、先願権が発生しています。

正式に認可されるまでは何しても良いわけですが、普通の企業活動をしているのでしたら、当然先願した団体のポリシーに従った運用に備えて置くべきだと思います。

そうなると、気になるのはどの様なTrademark Policyなのかですよね。

「OpenID」という表記は、基本的にフェアユースです。
OpenIDというトレードマークを利用する場合は、「OpenID」という表記でなければならず、「Openid」とか「OPEN ID」とかいう表記はダメです。
「OpenID」をOpenID Patent Policyと乖離がある製品名やサービス名に使っちゃダメです。
ドメイン名にOpenIDの一部でも利用したいなら、OIDEの認可を受けないとダメです。
ライセンス供与を受けていないならば、社名・製品名・サービス名にOpenIDを使っちゃダメです。
OpenIDが有害な使われ方をしちゃダメです。
OpenIDロゴは、サーバーがEUにあったり、ドメインがEUだったら、OIDEにリンクしなくちゃダメです。それ以外はOIDFにリンクしなくちゃダメです。
OpenIDロゴのフォントとか色とかは、あんまり変えるべきじゃないです。
OpenIDロゴはTMマークを含んでいなければなりません。

ふー、やっと、２．４まで来ましたがまだまだありますね。

これだけでも分かりますが、世の中の、日本のいろんなサイトは、潜在的にOIDEに訴えられる可能性をはらんでいるわけですね。大きな企業すら正しく守っていないと思われます。

皆さんも気をつけてください。

#近いうちに追記します。

idcon#2へ行ってきた

2008-06-22T16:11:00.002+09:00

Identity Conference #2へ行ってきました。

エンジニアの勉強会ってこんな感じのノリなんですね。

昔に、COINSコンパイラでPartial Redundancy EliminationとInstruction Schedulingの組合わせアルゴリズムの発表とかしたときの、飲み会での話題がGeekだったのを思い出しました。

=natさんの、XRIやらOASIS ORMS話やら、W3C TAGとのカラミの話を聞きました。
id:lopnorさんの、openid4u.netとか、Apache2::AuthenOpenIDとかみました。
ZiGoRouさんのAXに対するSucksを聞きました。AXの未来は・・・どうなるんでしょうね。
ITOさんから、ID-WSFについての話。SAML分かってないからムズイ。

あと、飲み会が残ってますが、一旦公開。

Discovery on the RPの本当の意味

2008-06-12T23:34:00.004+09:00

OpenIDの2.0Finalで突然追加された仕様に、Discovery on the RPというものがあって、こいつ何してんの？といっつも思っていた。

で、昨日Apple Store, Ginzaでやったイベントのプレゼンテーションを作っていて、
それに触れなければならなかった。

そのとき触れた内容は、

認証応答が返る場所がRPとして妥当かをXRDSを見てチェックする
EV-SSLなどエンドポイントの情報からユーザーへの警告に利用する

とかにしました。

でも、なんか納得いかないなーと思って、過去MLを調べてみたら、やっぱりあった。

MLを探ってみたところ、2007-2のsecurity@openid.netに投げられていたコメントを見つけた。
http://openid.net/pipermail/security/2007-February/000241.html

サマリは下記。
---
realmとreturn_toを共にspoofすることで、アサーションの検証はクリアしつつも、あさってのRP Endpointに認証応答をブラウザリダイレクトできるのは、クリックトレース用にリダイレクトを挟むようなページに対して問題だとある。

http://x.go.com/cgi/x.pl?goto=http://www.jyte.com
http://www.aol.com/ams/clickThruRedirect.adp?1,2,http://www.jyte.com

悪意のあるRPは、上記の例では、go.com/aol.comのふりをして、自身のIdentityを隠蔽すことができる。何を言っているかというと、通常のOPでは、「認証しますか？」画面に戻り先としてURIオーソリティー部分だけを表示するので、ユーザーにとっては"www.aol.com"に認証応答を返しているように見えるから。(実際にはリダイレクトされて、悪意のあるRPに情報がリダイレクトされるにも関わらず。)

---

・・・ということで、OPが直接RPのEndpointを検証する必要があるという論理展開。
これを強制すれば、OPが表示する認証要求元が、比較的正しい物になると言えると思う。

これって前提があって、「引数無しでreturn_to_urlにアクセスする」際、アクセス先は信頼性の置けるサイトなので、そこに悪意のある機能改修を入れることはないと思う。つまり、Redirectするサイトは信頼性の置ける由緒正しいサイトで、Redirect先は悪意のあるRPという前提。

リダイレクトするサイトが悪意のある場合は、spoofingしたreturn_to_urlも"aol.com"のような正しそうなものではなく、怪しげなURLになる気がしてる。

RP Discoveryで用意するXRDSの中に、最初からリダイレクトを介す偽装済みのURIが入っていたら、RP Discoveryしても偽装が成立するようにも聞こえますが、RPドメイン名との比較を同時に行ったり、Yadisが勝手にHTTP30xリダイレクトをFollowしないようにすればいいのかな。

Yadisの仕様をみた限りでは、Redirectを自前で解決してコンテンツを取りに行くとは書いていないので、しないと思っているんだけど。。。

以上。

誰でも分かるOpenID入門～第3回「OpenIDの基本認証フロー」

2008-03-11T17:35:00.002+09:00

グアムにてPADIアドバンスライセンスを取得してきました。これで水深40mまで潜れるようになりました。しかしグアムという場所は変なところで、日本語にあふれていました。かなりの違和感。以前シェラトン＠フィジーに行ったことがありますが、あっちは日本人はアウェイ感に溢れていたのとは大違い。

まぁ、それは置いといて、OpenIDを。

OpenIDの基本認証フロー

OpenID Authentication 2.0の基本的な認証フローを図にしてみました。Finalに準拠しているので、RP Discovery(後述)についても触れたいと思います。

図、「OpenID Authentication 2.0 基本認証フロー」

OpenID入力（Inputting OpenID identifier）
OP発見（Discoverying OP-Endpoint url）
アソシエーション確立要求（Requesting an association）
アソシエーション確立応答（Responding an association request）
認証要求（Requesting an authentication assertion）
RP発見（Discoverying and verifing RP's return-to-url）
パスワード入力（Inputting your credential: maybe password）
認証応答（Responding an authentication assertion request）
認証結果の検証（Verifing assertion）
結果の直接検証要求（Requesting verification）
結果の直接検証応答（Responding verification request）

誰でも分かるOpenID入門～第2回「認証依存サイトと認証サーバ」

2008-03-01T12:52:00.005+09:00

OpenID Foundation Japan設立へ

第一回から相当な時間が経過してしまった。その間に先日はOpenID Foundation Japan(仮称)設立へ向けての報道記者発表があったりした。その時僕はオフィスでIT系メディアを見ながら喜んでいたわけですが。みなさんがDavidと握手してたね。Davidは20歳らしい。本当に若くてアイデアにあふれてる！

認証依存サイトと認証サーバ

第二回は、OpenIDをはじめ様々な技術パラダイムである、認証依存サイトと認証サーバの関係について簡単に説明し、OpenIDの簡単な動作の流れを見てみようと思います。

従来の認証パラダイム

アカウント（ユーザーIDとパスワード情報を含む）をサイトに登録し、サービスを利用するときにログインするのは、インターネットの世界では当たり前の概念だと思う。肝心なのは、IDとパスワードを入力するのは、あなたがログインしようとしているサイトに対して行われるという点。認証情報はそのサイト独自のものであって、別サイトで同じIDパスワードでアカウント登録したところで、その2のアカウントは紐付いていないので、一方でパスワード変更してももう一方は更新される訳ではない。

認証機能を特定サイトから分離する

認証機能は世の中の多くのサイトが持っているが、どこのサイトも同じような機能を実現していている。しかしながら乱暴に言ってしまうと、認証とは特定のユーザーIDに対するパスワードが正しく入力されたかという認証結果を得るのが目的であり、この部分を代理してあげる全く別のサイトがあっても良い訳である。これが、認証依存サイトと認証サーバの関係であり、OpenIDもこの考え方をとっている。

図：従来の認証と、OpenIDでの認証の違い

上の図で、事前準備としてユーザーはOpenID認証サーバからOpenIDを取得する。ユーザーはOpenID認証依存サイトに取得したOpenIDを入力し、実際のパスワードはOpenID認証サーバに入力することで認証を行う。

イントラネットを主な利用範囲とするSAMLといった他のプロトコルと比べて大きく違う点は、OpenIDはインターネット上に散らばるありとあらゆる認証依存サイトと認証サーバが連携することができるという点である。もちろん一長一短あるのだが、その辺はそのうちまとめたいと思う。

あとがき

鋭いか方なら違和感を感じているだろうが、OpenIDを入力しただけでどうやってOpenID認証依存サイトから認証サーバの場所を知って移動できるの？とか、セキュリティーはどの様に守られるの？とか様々な疑問点があるだろう。また、OpenIDとしては、通常のURL形式の他にXRI形式と呼ばれるものもあるが、その点については順次説明していく(予定）。

誰でも分かるOpenID入門～第1回「そもそもIDってなんなの？」

2008-02-09T02:47:00.002+09:00

はじめに

新人エンジニアの僕は、それはもう突然にOpenIDに関わることになりました。そこそこ勉強もしましたが、まだまだ不十分で詳しい方の足元にも及ばない。とはいえ、OpenIDの可能性に触れて、その普及に協力したい。

OpenIDには驚くほどの可能性がありますが、解決すべきセキュリティの問題と、普及の妨げとなりうる誤解や価値観などの問題が山積しています。詳細に技術を書くこともできますが、まずは誰でも「分かった！」という気持ちでOpenIDを使ってもらえるような解説を目指したいと思います。

第一回は私に深いインパクトを与えてくださっている、Digital Identity業界に関わらず、あらゆることに深い知見を持つ=natさんの受け売りです。OpenIDの規格の一部として取り込まれているXRIを策定したOASIS XRI TCのCo-chairでもいらっしゃいます。

そもそもIDってなに？

IDは"Identity"の略と言われたりします。しかしIdentity自体は単なる文字列ではなく、むしろその人をその人と特定する情報（属性）の総体と言ったほうが適切です。情報社会において、そのようなIdentityを広くDigital Identityなどと呼ばれています。

Theirdentity? Ourdentity? Mydentity!

ところで皆さんはいくつIDを持っていますか？そして、いくつのパスワードを覚えて（忘れて）いるでしょう。IDに紐付くアカウントには様々な情報を登録していますよね。名前？電話番号？住所？人によってはクレジットカード番号だったりすることもあるでしょう。様々な場所に異なるIDで自分自身の情報を切り取って保管しているわけです。

本来は全て自分の情報なのにもかかわらず、あるタイミングで他人（企業など）に切り取られ、プライバシー保護の下などに許可が無ければ参照も変更もできないという矛盾は当たり前に見られます。はたまたパスワードも登録したことすらも忘れて、数年前の古い情報を更新する機会も無いまま残っていることはありませんか？自分の情報とはいえ、様々なところに分散して保存されており、互いに関連もないため、更新処理などは非常に面倒になります。引越しをしたら住所の登録情報を10サイト分も変更するなんて疲れてしまいます。それでも情報が残っているだけで良いほうで、そもそも社会保険番号が表す私が存在しないなんてことが起こってしまっている現状です。

たしかDI業界の重鎮の方が言ったと思ったのですが、Theirdentityは他人（銀行など）に切り取られて自身が自由にコントールできないIdentity、Ourdentityは自身が所属する団体（学校、会社）などが保管して最終的には取り上げられてしまうIdentity、そしてMydentityは自分自身が自分自身でコントロールし自由に変更・第3者への提供を許可することができるIdentityを表しています。現在の世の中はTheirdentityとOurdentityに溢れており、自分のIdentityが切り取られて自身でコントロールできない状態にあります。

One IDという考え方

Mydentityが体現した世界はどうなるのでしょうか？自分自身のOne IDを手に入れ、自分の大切な個人情報を信頼できる機関に預け、集中管理する（様に見える）ことで、覚えるべき一つのIDとパスワードを極めて厳重な方法で管理していけば良いということになります。また、住所や電話番号といった個人情報（属性）を変更する場合は、中央の一箇所を変更することで、それを参照する全てのサイトに最新の情報を提供できます。

集中管理するということは、今までは分散していた個人情報を集約（aggrigation）する意味もあります。例えば、yahooショッピングで年間1000円しか買い物しないAさんが、amazonでは10万円の買い物をする優良顧客だったとします。この情報を集約することで「Aさんは年間10万1000円ネットショッピングする超優良顧客」だという情報をyahooが取得し、効果的なマーケティングなどを行なうこともできるでしょう。

もちろん属性提供をどうやって許可するか？範囲はどうするか？などの問題はありますが、One ID（と集中管理される属性情報）の意義はお分かりいただけたと思います。

ちょっと時間がなくなってしまいました。明日から3連休なので新潟にスノボに行くんです。今冬5回目です。

では、肝心のOpenIDなどについては、また後日。

OpenID(XRI)取得しました。

2008-02-07T01:16:00.000+09:00

誰でも簡単に取れるURL basedなOpenIDも良いと思うけど、どうせなら短いXRI i-nameを取得したいよね。

ということでXRIのi-name取得しました。ブログ名にもあるように、"=katsu"です。

inames.netにはXRI Authority一覧がありますので、この中から選びます。
http://www.inames.net/

私は既にlinksafeにて別i-nameを取得していますが、これは仕事用に使っているので秘密。

=katsu/(+blog)
ブログのURLを示すabstruct identifierで、http://xri.net/=katsu/(+blog)でこのブログに到達できる。

=katsu/(+contact)
contactをとるためのI/Fサービスのロケーションを示すabstruct identifierで、http://xri.net/=katsu/(+contact)でメールアドレス・連絡先を知らなくても私に連絡を取ることができる。

今日はこんなところでおしまい。