「Yahoo! JAPANのアカウントがOpenIDとして利用可能に」記事へのコメント

目前に

[hishakuan (32621)]

見えない壁があったりして。

>OpenIDとは、webサイトのURL 形式で構成されたユーザーの身元確認をするためのIDです。
って説明があるけど、普通に言われる身元確認とは違うよね？クレジットカードで身元を担保することが多いけど、それに置き換わるものではなく、横断的に使えるIDだからあっちのイチローさんとこっちのイチローさんは同じ人らしいということがわかるだけでないの？

正直何度説明を読んでもURL形式など、特徴はほんの少し分かっても利点が理解できません。だ、誰か説明を。いや、それ以前に、分散されていたリスク(別の言葉でもいいけど)を個別に管理していたのがまとめられて一括管理するようになる、って理解でいいんだよね？これはインターネットに接木をしているだけで別の保障を持ち込もうとしているわけではないと読んだんだけど。
>自分のサイトのURLをOpenIDとして利用
という文章は、自分のサイトのURLが今までユーザー確認として用いられてきたものに変わるというわけではない、ということを理解するのに時間がかかったくらいなので何もかもに自信がもてない。

Re:目前に

[Anonymous Coward]

http://www.atmarkit.co.jp/fsecurity/rensai/openid01/openid01.html [atmarkit.co.jp]
ここから始まる「OpenIDの仕様と技術」という一連の記事が
極めて良い説明文章でした。
一連のバックナンバー(?)全部読むのをお勧め。

どれくらい良いかというと、
OpenIDどころかセキュリティ一般に疎いことを自認してる自分でも
OpenIDの特徴(や限界)が理解できたくらいに…。

で、原理は、

http://www.atmarkit.co.jp/fsecurity/rensai/openid02/openid02.html [atmarkit.co.jp]
＞ConsumerはEnd UserのUser-Agentを特定のクエリーパラメータを付与したIdPのエンドポイントURLに対してリダイレクトさせます。
(略)
＞いずれの手続きも正しく完了した場合、IdPは事前にConsumerが指定したURLにEnd UserのUser-Agentをリダイレクトさせます。

要するに、
「いわゆるログインページの
外観(基本的には)も、また機能も、
自サイトじゃなくよその認証サイトに委譲する仕組み」
ですよねこれ。

Re:目前に

[mistoffelees (22348)]

OpenIDの特徴は、IDそのものがIDをAuthenticateするServiceEndPointURLになっているか、それをあらわすXRDS文書のロケーションをあらわしている点にある。
つまりIDを見れば、どこの誰が認証を請け負ってくれるかがわかる。さらに、そのID(URL)を自身のブログサイトなどに張っておくと、AuthenticationのDelegationができたりする。

とまぁ、それはOpenID 1.0で対応できていたことで、2.0ではむしろXRI(eXtensible Resource Identifier)を採用したことにより、URL/IRIを一段抽象化した世界での識別子である、xri://=hogeとか、@company/dept/meという識別子に対する名前解決でXRDS文書を取得し、そのIDを認証する主体の場所を知ることができる点がウリ。yahooはこれに未対応。

ちなみに、OpenIDのFormにOpenIDを入れても良いが、OP Identifierも入れることができる。この場合は跳んでいった認証請負サイトでIDもパスワードも入力することになる。これはyahooでも対応してる。

OpenID 2.0の問題点は、
１．Associationを作ったとしてもMIM攻撃に弱い点
２．Associationを作ったRP-OPが確かな相手かどうかを確認できない点（Reputation問題）
３．SREG/AX等のPiggy Back方式で情報をOPから引っ張ってこれるが、SSLが使えないと全くセキュアじゃない点
４．インフラとして取得できる情報の型をそろえようとすると大変
５．そもそもAuthentication規格以外の規格に適当なものがある点
６．などなど

とはいえ、SAMLみたいな、密結合なSSOよりは世界に浸透していきそうな気はする。
超セキュアだけど広がりに欠けるSAML/WS-Securityに対して、セキュリティが甘いが疎結合の利点があるOpenIDの弱点が埋められて、結局疎結合の利点を持っているOpenIDのほうが世界には受け入れられるんでなかろうか。

Re:目前に

[Anonymous Coward]

使う側から見ればネットワーク上の人格を一つにしやすくするための仕組みという認識ぐらいでよいはず。

OpenIDの人たちはメールアドレスを怪しいサービス用、普段用、大事な事用と複数持つように、
TPOに合わせて複数のIDを使うのが自然とか言ってた気がする。

Re:目前に

[.mjt (13150)]

＞横断的に使えるIDだからあっちのイチローさんとこっちのイチローさんは同じ人らしいということがわかるだけでないの？

(今のOpenIDだとサイト間の情報交換を行うためのフレームワークがないので、)
「1つのアカウントで、複数のサイトにパスワードロックされた領域が持てる」
以上の意義は今のところ無いです。ニックネームなどの情報は共有できますが、積極的に活用されてるかは。。？

・　一カ所パスワードを変更したら他所のサイト全部のログインパスワードも同時に変更できるのは便利だよね
とか、
・　一度パスワードを入力したら、2週間(Yahoo!の場合)はキーボードに触れずに(適切なOpenID対応ブラウザを使用した場合)新しいサービスにログイン出来るのは便利だよね
程度の利便性しか提供しません。それでも十分に利便性はあると個人的には思ってますが。

あと、「特定のサイトのOpenIDプロトコルにだけ対応する」というサイトも幾つかあって、その場合、
・ (Yahooの方式では無理だけど)他所のサービスのアカウントIDと対応したログイン情報を持てる - 従来のはてな認証APIとかJugemKeyを代替する共通プロトコルとして使える
・ 信頼できるIdP(OpenIDのIDを実際に認証するプロバイダ)に対してだけサービスできる - いまのところこの目的が大半。はてな等。
という(サービス提供者から見た)利点があります。

Re:目前に

[M-FalconSky (8868)]

>(今のOpenIDだとサイト間の情報交換を行うためのフレームワークがないので、)
これはOAuthの領分になるんではないかと思われます。もうすこし発展しないとどうにも...というのは変らないかも。

>「特定のサイトのOpenIDプロトコルにだけ対応する」というサイトも幾つかあって、その場合、
これは実装がマズいだけの場合もあるみたいです(実体験)。

あと、副次的にですが、ログインID=アカウント名の束縛が弱くなるとかもあるんじゃないかなー。

サービス提供側としては、ライブラリがそれなりにあり、パスワード/メールアドレスの管理から開放されるので、作業や責任が軽くなり結果素早い開始や展開もできるのではないでしょうか。
# 内部のユニークIDは管理しないといけないのは変りませんが...

# まだ、「すごく便利」ほどには実感はないけど、そこそこなのでID

--
M-FalconSky (暑いか寒い)

Re:目前に

[hishakuan (32621)]

皆さん詳しい解説thx。礼を言うべき人数が多いのでここにつけときます。

アトラクションに乗るのにそこのお姉さんにチケットを渡すのではなくて、
遊園地の入り口でフリーパスポートを買っておくようなものかな？
遊園地の入り口は仕様にのっとれば勝手に作ることが出来るし、
アトラクションと入り口は、さらにアトラクション同士に入り口同士も関係なかったりするので、
そこはそれ、自分で注意するようにと。
OpenID.ne.jp [openid.ne.jp]の(親コメントで文章引っ張ってきておきながらリンク示すの忘れてたや)
>OpenIDは、何百万もの人々がオンラインで対話することを可能にする
は大言壮語というか美辞麗句で、そこから考えてわざわざ泥沼にはまる必要はないみたいですね。

Re:

[Anonymous Coward]

>アトラクションと入り口は、さらにアトラクション同士に入り口同士も関係なかったりするので、

いや、ちょっと違うんじゃないかな。
http://www.atmarkit.co.jp/fsecurity/rensai/openid01/openid01.html [atmarkit.co.jp]
(からの一連の連載)にも載っていますが、
認証プロバイダとコンシュマ(Webアプリとかを公開する側)とのあいだの
「信頼関係」は結局は重要になるみたいです。

どこのサイトが信頼できるか？を
「ホワイトリスト作って管理する」という
「OpenIDの精神を思えば残念な話だが、現実的な」運用を
してるところもある、と最後のほうで紹介されています。

遊園地の例を挙げたのは凄く適切だと思います。