質問

特定の実装については問いません。クロスサイトシングルサインオンメカニズムのグローバルな世界観については問いません。OpenIDの基礎となるユーザビリティについてコミュニティがどう考えているかを知りたいだけです。実際のユーザー名の代わりに(技術者ではないオブザーバーに対して)ランダムな種類のプロバイダーによって発行されたURLを使用することは、人々が好むものだと思いますか?そうでない場合、誰かがより良いメカニズムを持っていますか?十分な関心がある場合は、より一般的なSSOの質問でフォローアップします。

正しい解決策はありません

他のヒント

いいえ。

基本的に欠陥のあるシステムではないと思います。使いやすさの点では、標準からの逸脱であり、慣れるのが難しく、つまり、ユーザー名の代わりにURLを使用してプロバイダーを選択する必要があるため、欠陥があると思います。しかし、私はそれらが唯一の問題であり、それらを改善することが可能であり、現在行われていると思います(ログインページの使いやすさを調整し、YahooとGoogleがアイデアに対する認識を高めています)。

それ以外は、すばらしいシステムだと思います:

  • 1つのアカウントIDとパスワードの組み合わせを覚えています(多くのID->パスワードの問題に対するソフトウェアソリューションに依存する必要はありません)
  • 新しいWebサイトにアクセスするときにフォームに入力する必要はなく、登録メールで確認するのを待つ必要があります。
  • OpenIDプロバイダーを信頼していなければ、比較的簡単に自分のプロバイダーになることができます。個人的には、これは標準にとって素晴らしい成果だと思います。何かを非常に汎用性のあるものにすること、および(私の知る限り)簡単にすることは私にとって、本当に何かです。
  • 両方のジョブがますます困難になっているときに、パスワードの保存とセキュリティからWebサイトを構築する責任を分離します。
  • この次のポイントについてはあまり知りませんが、1つのOpenIDアカウントを使用して複数のペルソナをホストすることは非常に簡単だと思います。 "それが私の仕事のペルソナです。ilovemyjob.comにサインアップするときに提示するものです。これは私の友人のペルソナです。Facebookでそれを使用しています」ペルソナごとに異なる情報が関連付けられています。私が言うように、これがどのように行われるのか、またはなぜそれが有用であるのかについてはあまり知りませんが...

これは、OpenIDで得られる主な利点についてです。欠点の面では、ユーザビリティの側面がありますが、それは問題だと認めています。 OpenIDを批判するために人々が使用する他の主な点は、アカウントが侵害された場合、多くのログインが侵害されることです。私の意見では、これは、アカウントに結び付けられた電子メールを持つ現在のシステムより悪くはありません。アカウントは同様に危険にさらされ、「ユーザー名を忘れましたか?」多くのウェブサイトで機能します。また、OpenIDはその問題を解決するものではないことを指摘したいと思います。これは、複数のID /パスワードの問題の解決策です。ただし、パスワードを1つ持つことで、セキュリティを強化するためにパスワードを更新し続けるためのライセンスが大きくなります。ソフトウェアに覚えておく必要も、常に忘れることもありません。

したがって、OpenIDには問題がありますが、複数のID /パスワードの問題に対する優れたソリューションだと思います。

参照:
テーマに関する興味深いGoogleトーク

はい。

最初に、プロバイダーの選択は困難です。経験の浅いユーザーであれば、「Yが運営するサイトを使用するためにXと情報を共有する必要があるのはなぜですか?」そして、それを乗り越えたら、情報を信頼する人を選択する必要があります。私は個人的には、Verisignを信頼しているため、Verisignを使用しました。しかし、一部の人々はこれらのプロバイダーのいくつかを聞いたことがないかもしれず、情報に基づいた決定を下す立場にないでしょう。

第二に、ログインが困難です。ユーザー名を入力するのではなく、URLを入力する必要があります(ただしStackOverflowを使用すると、プロバイダーとプロバイダーのユーザー名を選択しやすくなり、URLが作成されます)。

第3に、OpenIDが侵害された場合、OpenIDを使用しているサイトのアカウントもすべて侵害されます。これを克服するために複数のOpenIDを使用することを提案する人もいますが、それはOpenIDの目的全体を無効にしていると思います。

OpenIDに対する不安を理解できません。

このサイトへのサインインの経験(明らかに、対処しなければならなかった唯一のオープンID)は簡単でした。 OpenIDが必要なものを見たので、サイトへのサインインが、信頼できて既にIDを持っている他の誰かに委任されることを理解していました。驚いたことに、私の現在のオンラインメールプロバイダーのプロバイダーへのリンクがありました。クリックして、覚えていないほど簡単なプロセスに従ってください。

オープンID接続が設定されたので、これは私が扱う他のどのサイトよりも難しくなく、魔法は、まだ別のアカウントを追加する必要がないということです。二度と使用するつもりがなかったので、おそらくユーザー名またはパスワードを忘れてしまうでしょう。

私はそれ、コンセプトと実行が好きです。

前にも言ったことがありますが、おそらくもう一度言いますが、URLのアイデアは根本的に欠陥のあるアイデアです。それらは、username @ service.comの電子メールアドレス形式またはJabber形式を使用する必要があります。これにより、既存のメールプロバイダーは、ユーザーが不可解なURLを覚えておく必要なくIDを提供できます。

いいえ、OpenIDに欠陥があるとは思いません。

OpenIDの履歴を見ると、元々は人々を許可するためのものでしたブログ全体で所有するURLを介して自分自身を関連付けます。このアイデアは拡張され、今日のシングルサインオンシステムになりました。

OpenIDは、基本情報を保持するユーザーアカウントを持たないWebサイトに最適であり、エンドユーザーにとってはバイタルとは見なされません。したがって、漫画本の評価に役立つ漫画本のサイトが良い例かもしれません。 OpenIDエンドユーザーとして(別のユーザー名/パスワードを作成せずにサイトにログインできます。これは、システム上の既存ユーザーのために作成した他のユーザー名/パスワードとは異なる場合があります)彼らが働きます。気に入ったら、システムを通常どおり使用し続けることができます。または、サイトに完全に夢中ではなく、後でチェックアウトすることに決めた場合、サイトに使用したユーザー名とパスワードの組み合わせを覚えようとする代わりに、あなたがそうでなければ戻らないかもしれないと思った場合、イライラする可能性があります。 OpenIDはそのような状況に完全に対応します。

そうは言っても、リダイレクトのセキュリティに関して多くのことが述べられているため、個人的にOpenIDを使用して銀行口座にログインすることはしません。ただし、その多くは変化しており、属性の交換(特に日本)。

多くの人が知らない別の注意点は、OpenIDを取得するためにURLを使用する必要がないということです。 i-names はユーザー名のように見えます。つまり、私のi-nameは" = true"です。これは" http://true.myopenid.com "。個々のi-nameには年間12ドルの費用がかかるため、最初は一部の人にとっては障壁になる可能性がありますが、無料あなたがそれらをいじりたいのであれば、代替案が存在します。

最後に、OpenIDは発見可能性のアイデアを推進しています(それが言葉である場合)。それは表面のすぐ下にあるように思えた概念です。発見可能性は、プロトコルレベルでのソーシャルネットワーキングのようなものです。 その地域で行われている仕事のトン、 OpenIDのより良い実装または少なくともOpenIDのアイデアにつながると思います。これが私たち全員にとってより良いインターネットにつながることを願っています。

免責事項私はXRI TC委員会に所属しており、XRIに関するサービスの販売と提供に焦点を当てたスタートアップを運営しています。

FreeXRIは私が関与しているスタートアップではありません。

Googleはそう考えているようです。 OpenIDスペースへの最近のエントリ、およびプロトコルの直後の分岐には、問題について2つのことを言う必要があります。

  1. OpenIDは、特に多数のユーザーをサポートできるサイトで使用するために非常に多数のユーザーがいるサイトに関連付けられている場合に便利です。 GoogleやOIDで働いている人が既にそれをカバーしているのに、なぜ認証システムで車輪を再発明するのですか?
  2. OpenIDの現状は複雑です。多くのユーザーが参加しているプロバイダーの多くとは異なるユーザー名を多数持っているためです。ただし、多くのユーザーは、GMailが自分の名前をメールアドレスとして取得し、作成できるアカウントの数がかなり無数になったときに大きな機会を得ました。 Googleは、自分のアカウントシステムだけですべてのOpen IDユーザーに十分であると考えているようです。私はおそらくこれに同意するでしょう。

この種のものをブラウザに組み込む方が良いと思いませんか?

たとえば、ブラウザの設定に個人データを入力します。その後、サイトはJavaScript呼び出しで個人データを要求でき、ブラウザーは確認を求めるダイアログを表示します。もちろん、JavaScript APIは標準化する必要があります。

この方法では、ユーザーはどこにもサインアップする必要がなく、個人情報はすべて自分のマシンに保存されます。さらに、確認メッセージは、信頼できない可能性のあるWebサイトのようではなく、オペレーティングシステムの残りの部分のように見えます。

私はそれが欠陥のある概念だとは思わない。私はそれが新しいと思います、そして人々はそれに慣れていません。

しかし、OpenIDはローカル登録システムとの conjunction で使用する必要がありますユーザーが選択できるようにします。 X.comにアクセスして登録し、その後サイトに戻るようにユーザーに指示するのは、ただの馬鹿げた混乱の元です。ただし、ユーザーが既にGMail / AOL / YMail / etcアカウントを持っている場合は、そのアカウントを使用させると非常に便利です。

私たちは、開発者として特殊なログインフォームを使用するべきだと思います。つまり、「OpenID URLを入力」の代わりに標準の「ユーザー名を入力」する必要があります。また、Gmail / AOL / YMail / etcを選択したり、URLを構築する舞台裏で選択したりできます。 URLがログイン名であるという考え方は少し逆であるため、移行を支援する人を歓迎します。

この種の質問では、一般的ではなく、より具体的になる方が良いと考えてください。

あなたの質問に対して、私はそれが欠陥であるとは思わないが、それはいくつかにアピールしないかもしれないことは正しい。しかし、いったん理解すると、人々はそれを理解すると、それをもっと使うようになるかもしれません。覚えておく必要があるパスワードの数が少なくなってしまうため、パスワードの数を減らす必要があるのは確かに良いことです。

このようなシナリオでは、一意のUserIDが必要です。他の選択肢としては有効なメールアドレスが考えられますが、スパムはどうでしょうか。

したがって、URLベースのUserIDを好みます。そして私にとって、OpenID(私の場合はmyOpenId)の使いやすさは素晴らしいです。

OpenIDの実装の中には、望まれるものがたくさんあると思います。

Yahooはそれを正しく理解するだろうと思っていましたが、彼らのOpenIDマイクロサイト(情報と実装)は私の意見ではごみです。レイアウトはわかりにくいため、open-idがユーザーの標準yahoo-accountとどのように関連しているかを明確にしません。

ログインリクエストを起動するためにどの画面が必要かを判断したら、yahooはランダム化された文字列を含むOpenID署名を発行しました。これはstackoverflowでは受け入れられませんでした。新しいエイリアスを作成する必要がありましたが、これもデフォルトのオプションにする必要がありました。同様に頑固に解決したいという欲求がなければ、多くのユーザーがgiveめたと思います。

私の意見では、実装のためのより厳しいガイドラインを作成する必要があり、潜在的なユーザーを教育するためにキャンペーンを大々的に宣伝する必要があります。

この技術をブラウザの実装に含めることができますか?

はい。

まだ複数のログインがあります。 OpenIDプロバイダーにログインしてからサイトにアクセスし、OpenID URLで再度ログインする必要があります。これ以上の作業を行う必要はありません。OpenIDはさらに多くの作業を行います。

OpenIDを使用するコンピューターの分野に誰もいません。 OpenIDはまだ複雑すぎます。平均的なユーザーは、抽象化の別のレイヤーと混同する必要はありません。

OpenIDユーザーがどこへ行くかを追跡する問題もあります。信頼できる名前のVeriSignを使用していますが、信頼性の低いプロバイダーを使用している人はどうでしょうか。いいえ、名前を付けて火炎戦争を始めるつもりはありません。

より良い回答があります。 RoboForm (または多くの偽物の1つ)。すべてのユーザーのパスワードと名前はマシン上に保持され、暗号化されます。使いやすく、より安全で、高速です。

OpenIDには、多くのユーザーに使いやすさの問題を引き起こす側面があると思いますが、おそらくUIの改善により解決できるでしょう。たとえば、 URL はほとんどのユーザーにとって本質的に使用不可能です。ただし、抽象化できない理由はないため、ユーザーは単にプロバイダーを選択し、そのプロバイダーで使用するユーザー名を入力するだけです。さらに、ログインするために別の場所に行かなければならないことはユーザビリティの大きな問題であり、ユーザーにどのデータを誰に提供しているのかについての赤い旗を正しく設定します。これを解決するのははるかに困難です。

これにより、個人が盗まれたり紛失したりしても、最終的に個人の身元が侵害されることはありませんか?これが私の主な関心事です。匿名性には、長所と短所があります。私は両方を持っていると信じています。Facebookコミュニティがとてもオープンであるという事実にFacebookコミュニティに参加することを恐れる親しい友人がいます。

アプリケーションのIDを他のシステムが所有することは望ましくありません。

ユーザーにとってよりシンプルで、より統一性のある概念が得られます。

ただし、UserIDはサイト訪問者のエクスペリエンスにとって非常に重要です。すべての卵を1つのバスケット(Microsoft Passport、OpenIDなど)に入れたくないのです。状況が変わると、すべてのユーザーアカウントが台無しになります。

コンセプトは問題ありませんが、設計ではセキュリティの悪用を格段に許可しています...

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top