Re:OpenID再利用問題 - 日向夏特殊応援部隊
Young risk taker.: OpenID再利用問題 この話は非常に興味深いですね。 もしも、私達が利用しているOpenIDプロバイダがドメインの更新を忘れて、第三者にドメインが取得された場合、私達のアカウントがこの第三者により不正に使用される可能性が出てくる。 事業者としてやりきる覚悟が無いならば OpenID Provider にはなって欲しくないし、まぁさすがに全うなネット事業者ならまずそういう事はあり得ないとは思いますけど。 ユーザは、セキュリティ的、高可用性の両方の側面からRelying Partyでのユーザ登録に、OP-Local Identifierを使用すべきではない。 言わんとしている内容は理解出来ますが、普及の点からすれば多くのユーザーは自分のドメインでdelegateしているなんて考えにくく OP-Local Identifier をそのまま使っているであろう
OpenID Overview - Seoul July 2007
Overview presentation on OpenID and VeriSign's OpenID Provider given by David Recordon at AhnLab in Seoul, Korea.Read less
OpenIDにノレない５つの理由 - YAMDAS現更新履歴
5 reasons I won't be getting on the open id train - Warpspire ソーシャルグラフ、Open ID、そして Data Portability といったあたりの解説記事をよく見るが、Kyle Neath が Open ID の現状について問題点を挙げている。 実装のほとんどがナイーブ（もちろん悪い意味。誰でもサービスを開始、終了できるあたりを指している） モバイルウェブで使えない インターネットが善人ばかりと想定している OpenIDでも結局1個のIDでは済まない ユーザフレンドリーさに欠ける 記事の最後に Kyle Neath は、こういう文章を書けば、「それはこういう回避策があるよ」というコメントがいっぱいくるのだろうが、回避策ぐらい自分だって知っている。結局 OpenID は自分を制約し、少しも人生をシンプルにはしてくれない、と
OpenID はシングルサインオンサービス、URL 認証はその構成技術、と割り切った件（ホワイトリスト容認派に転向しますた報告） - 観測所日誌
前に「ホワイトリストやめてくれぇぇ」というエントリを書いたのですが宗旨替えしました。 OpenID はシングルサインオンサービスとして、付帯情報も多分有った方が良くて、ホワイトリストも有りでいいと思ってます。 ここに挙げた方法が best だと言っているわけでなく、シングルサインオンサービスとして良くなるために、必要な事をやればいいという考えです。 今は SSO が実際に必要とされる時期に来ており、OpenID にそこを担って欲しいと思っています。 で、例えば分散 SNS のように URL をリソースとした URL 認証のような仕組みが必要になる場合は OpenID の構成技術を切り出して使う、と。 OP 実装の公開も シングルサインオンを構築したい人向け（イントラやサービスローカル） Yadis や URL 認証のような OpenID の構成技術を単独で使いたい人向け を想定しています。
APIアクセス権を委譲するプロトコル、OAuthを知る ― ＠IT
クロスドメインでのデジタルアイデンティティを守る APIアクセス権を委譲するプロトコル、 OAuthを知る 作島 立樹 NRIパシフィック 2008/1/21 マッシュアップと呼ばれる仕組みで、既存のWebサービスが次々とつながり、新たなサービスが登場している。しかし、メールアドレスなど重要な個人情報が意図せずに「つながれてしまう」可能性もある。そこで登場したのがアクセス権の「委譲」を目的としたプロトコル、OAuthである。本記事ではOAuthの仕組みとともに、なぜそれが登場したのかという背景にも触れる（編集部） マッシュアップの犠牲になるユーザーのアイデンティティ GETなどのHTTPメソッドをもちいてURLへリクエストする、いわゆる「RESTful」【注1】なWeb APIを使ったアプリケーション同士の交流は、いままさに隆盛を極めている。「マッシュアップ」と呼ばれているこのサービス形態
認証APIとOpenIDの違いを説明して、OpenID導入を説得する - tzmtkのブログ
最近、認証APIとOpenIDの違いについて説明する機会が増えてきた。 ※Flickrの画像を入れているのは、近年の認証APIのなかでFlickr Authentication APIがいろいろな意味でも象徴的な存在だからだ。 OpenIDが盛り上がってきていることもあり、自社のサービスへOpenIDの導入（Relying Partyとして）を考えていても、関係者へ理解してもらい導入を決めるまでの説明が難しいと感じている方々が多いのではないだろうか。 ここでは、私がよく聞く質問として一番多い、「認証APIとOpenIDはどう違うのか？」という質問へのベストな回答を考えてみる。 人は何か新しいモノについて説明されてそれがよく分からないとき、それとよく似たしくみを例にあげてそれと比較した説明を求めることが多い。すでに理解しているものから、その差分だけで考えた方が手っ取り早いからだ。 それはそれ
Re: OpenID Tech Night Vol.1 - Yet Another Hackadelic
tkudoさんに早速色々とパクって引用して頂いたので、レスって事で。 http://blogs.sun.com/tkudo/entry/openid_tech_night_vol_1 が元ネタです。 RP Discovery の件 ぼくも, この RP Discovery のネタがセッションの中で出てきたときには, そこまで話すのかーと思ってニヤニヤしてしまった. ちなみに資料では 「利用している OP は殆ど無い」 となってるけど, 少なくとも一社, Yahoo! がやってるらしい. このRP Discoveryって良い仕組みかもなと思いました。 事前にRPが自分の return_to と realm を指定しておいて、おかしなリクエストが来ていたら弾くってのは、 リダイレクトベースの認証プロトコルでは安全性が増すのかなと。 Yahoo! の OP としての実装はさすがに手堅いと思わせる
Simple Registration ExtensionとAttribute Exchangeの違いについて - Yet Another Hackadelic
id:machuさんのブクマコメントより。 Simple Registration ExtensionとAXの違いがよく分かってないです。 同じように違いの分からない方もいらっしゃると思うので簡単に解説。 Simple Registration Exchange OpenIDのメインのspecが2.0になった事により、namespaceが適用されるので、 それに対応したOpenID Simple Registration Extension 1.1 - Draft 1をテキストにした方が良いでしょう。 でAbstractから引用。 Abstract OpenID Simple Registation is an extension to the OpenID Authentication protocol that allows for very light-weight profile
OpenID Providerのオプション機能 一般的なユーザーは理解できるか - tzmtkのブログ
某所のOPをやろうとしている人と雑談したときに、 「myopenidはOPで相当がんばってるので、OPやるならこれを参考にしたほうがいいかもね」 みたいなことを話していたのだが、そこで 「ペルソナとか、一般的なユーザーが果たして理解できますかね？というか、果たしてここまで必要なんですかね？」 といわれて考えた。 https://www.myopenid.com/ myopenid.com の機能を列挙してみる - KazusaAPI開発日誌 - KDRIグループ うーん、たしかにそうかなと。いくら高機能でも理解できないものは使われないので、がんばって作っても実際サッパリ使われないこともありえる。 でも、David Recordonも、「OpenIDは用途によってメールアドレスのように使い分けていくようになるのでは」的なことを言っていて、myopenidはそのなかの認証レベルの高い多機能OP
ここギコ！: OpenIDセキュリティ周りの雑考察
先のエントリにいただいたコメント 「Man-in-the-Middle攻撃をされたらひとたまりもない ( http://sho.tdiary.net/20051021.html#p01 )」ということですね。 httpsでも、どの認証局を信用するかという問題が残りますね。 おっともう言及されてたんですね…。 セキュリティ素人なのでMan-in-the-Middleという言葉がなんか背伸びし過ぎてる気がしてつかえませんでした(びびり)。 でも一応、認証局の問題はおくとしても、各認証サーバのアカウントページを使う限りは（http://kokogiko.videntity.org/とかhttp://profile.typekey.com/kokogiko/とかの）、これらがhttps化されれば（今のところされてないけど）、問題はなくなると考えていいんでしょうか？ もしそうなら、問題はope
OpenIDとセキュリティ――経路の安全性をどう担保するか
OpenIDについて少しづつ理解してきたつもりなのですが、OpenIDを使うに当たってセキュリティ上の課題や問題などについてまだ理解が十分でなく、少し心配です。OpenIDのセキュリティについてその仕組みのほか、推奨される対策などがあれば教えてください。 この話題はなかなか難しい話で、少し説明が長くなりそうなので複数回にわたって取り扱いたいと思います。多少難しい解説でも構わない方は、わたしが以前＠ITで書いたOpenID のセキュリティに関する記事も参考にして参照ください。 OpenIDのセキュリティを語る上で最も重要な点 まずOpenID認証プロトコルで定義されているセキュリティに関連する登場人物をあらためて復習しましょう。それぞれの用語の理解が十分でないとお感じの場合は、過去の「ZIGOROuのOpenID Short Clinic」をさっと読んでおくとよいでしょう。 End User
『OpenID Engine』のβ版を公開しました - 株式会社ディノ
※認証サーバ用プラグイン …β版：2008年6月19日 ※安定版：2008年7月公開予定 OpenIDとは 1つのIDで、対応する様々なウェブサイトを安全に利用できるURL形式のIDです。サイトやサービスごとに新たなアカウントを作成したり、ログインする必要がありません。 OpenIDについて詳細 OpenID Engineとは 「OpenID Engine」は、OpenID2.0とRails2.0で開発され即時にシングルサインオンサービスを開始できるプラグインです。MIT Licenceで公開されています。 開 発 者：株式会社ディノ 技術部 城戸総史 (ブログ:英語) 問い合わせ：株式会社ディノ 広報担当 塚原 openid@dino.co.jp 下記個人情報の取り扱いについて確認いただき、同意の上で上記メールアドレスへお問合せください。 お預かりした個人情報は、お問合せに対して弊
OpenID再利用問題
ドメインの更新忘れもOpenIDにおける脆弱性の一つ。 URLやXRIを入力するだけで、Yadisプロトコルに基づきOpenIDプロバイダーやi-Brokerを発見し、認証が行えるシステムは、とてもシンプルでありながら、WWWの分散アーキテクチャの上に構築された強力なエコシステムだ。しかし、問題は、私達自身の識別子として利用可能なURLやXRIは、永遠ではないことだ。 もしも、私達が利用しているOpenIDプロバイダがドメインの更新を忘れて、第三者にドメインが取得された場合、私達のアカウントがこの第三者により不正に使用される可能性が出てくる。myOpenIDや、多くのプロバイダでは、単純なルールに基づいた、Human FriendlyなOP-Local Identifierを提供してくれているが、ユーザは、セキュリティ的、高可用性の両方の側面からRelying Partyでのユーザ登録に、
OpenID Tech Night ＃1で話してきました - 日向夏特殊応援部隊
本日、OpenID Japanの技術イベントにてスペシャルゲスト(笑)として登場しました。 いやー、なんかみんなこうあれですよね、とにかく物凄い緊張しました（ぇ で、今日の感想とかとか。 OpenID Authentication 2.0 〜概要とシーケンストレース〜 =natさんこと崎村さんと=katsuさんによるプロトコルのガチ解説。 curlでディスカバリの話をしているときはともかくしてパケットキャプチャしだした辺りからガチ過ぎて面白かったｗ 9.2. Realms 11.2. Verifying Discovered Information もきちんと話していて素晴らしいーと思った。 Realmとreturn_to辺りの話とか、RP Discoveryとかの話は＠ITの連載とかでいつか真面目に話そうかなと思います。 Building Relying Party Best Pract
押さえておきたいOpenIDとSAML３つの大きな違い : やむにやまれず
2007年09月19日17:41 by 山崎泰宏 押さえておきたいOpenIDとSAML３つの大きな違い カテゴリネタ Tweet sparklegate Comment(5) 技術的にどうかという話はあちこちに書かれているので割愛しますが、これらのクロスドメイン認証はどんなものなのかをもう少しザックリとまとめてみました。 もっと良いまとめができるかも知れないけど、現在勉強中なのでひとまずこのレベルで。 何か思いついた方はぜひコメントなりトラックバックなりください。 以下は、OpenID 1.1と、SAML 2.0を前提に書きます。 1. ユーザが利用する認証システムを静的に固定しているのがSAML/動的に決定できるのがOpenID システム間で事前に準備するものに注目してみましょう。 SAMLでは認証のサービスを開始する前に、相互のシステムへメタデータと言う連携先の情報を記録したプロパテ
@IT西村さんのOpenIDの記事が秀逸過ぎる件 - 日向夏特殊応援部隊
いやー、凄い良い記事でした。 OpenIDに欠けている「評判情報」 − ＠IT OpenIDでログインまたはサービスが利用できるWebサイトは、ユーザー認証のプロセスをほかのサイトに頼っているという意味で「リライング・パーティ」（Relying Party）と呼ばれるが、読者はいくつのリライング・パーティをご存じだろうか？確かに数だけは多いと喧伝されているが、自分が使いそうもないWebサイトがいくら対応していても意味がない。 その通りなんですよね、これ。 OpenIDのIdentityはもう相当数の人が実質的に持っていると言う状況なのに対して、RPとしてのキラーサイトが無いので恩恵に授かれない。 声高にして言いたいが、いわゆる会員サイト的な物を作ろうと思ってる方は、真っ先にOpenID対応(RPとして)を考えて頂きたいと思う。 それが普及と言う点で最も大切な事だと僕は思います。 ブランドや
delegateとIdentifierの冗長性・ロードバランシング - 日向夏特殊応援部隊
今は delegate とは言わず OP-Local Identifier の方が妥当なのかな。 多くの人が既にご存知かと思いますが、実際の OP にある Identifier (つまり OP-Local Identifier) を Claimed Identifier とせずに、 自分が既に持っているドメインなどを Claimed Identifier として OP-Local Identifier に対して delegate を行う事が出来ます。 具体的に言えば、 Claimed Identifier art-code.org OP-Local Identifier zigorou.myopenid.com みたいにする。 Claimed Identifier は URL の場合は Yadis Protocol or HTML Based Discovery に則って OP EndPo
認証と認可の違い
OpenIDを解説する際にしばしば登場する「認証」「認可」の言葉はそれぞれどういった意味で利用しているのでしょうか。両者は明確に区別しなければならないものなのでしょうか。また、OpenID Authenticationについても教えてください。 「認証」「認可」は、OpenID以外でもセキュリティ関連のトピックではしばしば登場する単語です。いったん理解してしまえばさほど難しいものでもありませんが、多くの人が混同されているようですのでこの機会にしっかり覚えてしまいましょう。認証・認可は英語では以下のような単語になります。 認証（Authentication） 認可（Authorization） 認証（Authentication）とは 関連記事 実は簡単なOpenIDの認証手続き OpenIDにかんするさまざまな疑問を解消していく本連載。今回は、OpenIDではどのような流れで認証手続きが行
OpenID勉強会inドリコム - snippets from shinichitomita’s journal
OpenID勉強会のお知らせ - Hello, world! - s21g OpenID勉強会レポート - Hello, world! - s21g 土曜に行ってきました。１時間ほど遅刻。 最初は2.0のプロトコルの詳細解説をしていたみたい。正直昔から仕様って全然読めないのです。翻訳しようとか、そういうパワーがあるのは怠惰な自分から見たらすごいことです。もっとも、仕様を読みつつ、さらに手を動かすということが重要なのだと思います。このように、仕様がオープンというだけでなく、手を動かしさえすれば動く物が手に入る状況にしておけたのが、ある意味OpenIDの普及（少なくとも開発者コミュニティ内における）の理由であると思います。 続いてzigorouさんのLTプレゼン＆第２回アイデンティティ勉強会の時の資料（XRI周り）。個人的に前回の時は聞いてなかったので貴重（SlideShare資料は見ていたけ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20080430/p01/