web-dev-qa-db-ja.com

browseridと比較したwebidの主な長所と短所は何ですか?

webid と比較した webid の主な長所と短所は何ですか?

この質問は this answer に触発されており、その質問のトピックについて非常にあいまいであるにもかかわらず、多数の賛成票を得ました。

Webidは基本的に、プロファイルURLが含まれているSSLクライアント側の証明書のファンシーな名前です。

いくつかのトピック:

  • 侵害されたキーはどのように無効化されますか?
  • マルチデバイス/ブラウザのサポートはどのように機能しますか?それらが複数の公開鍵をもたらす場合、それらはどのようにリンクされますか?リンクはすべての消費者に対して行われる必要がありますか?
  • 現在のブラウザでのサポートはどうですか?ユーザーインターフェイスは、平均的なユーザーが理解できるほど簡単ですか(作成、選択、現在のコンピューターからの取り消し、IDのグローバルな取り消しなど)?
  • ユーザーを追跡できる中央組織はありますか?ユーザーを追跡できる分散型組織はありますか?追跡はどの程度詳細にできますか?
  • 消費者が実装を正しく行うのはどれほど簡単ですか? (遅延実装にセキュリティ問題が含まれている可能性はどれくらいありますか?)
  • ソフトウェアのインストールが許可されていないインターネット端末では、どのように機能しますか(侵害されるリスクを受け入れた場合)。
21

注:WebID側のこれらの質問の多くは、 Foaf + ssl FAQ で回答されています。

BrowserID対WebID:区別は本当ですか?

BrowserId(詳細 spec )は、Mozilla labsでの実験であり、非常に新しく、完全に定義されていません(たとえば、電子メールサーバーの公開鍵を見つける方法が正確に指定されていないなど)、完全に実装されていません(それはブラウザのサポートを実際に配布する必要があります)。 WebIdプロトコルW3Cインキュベーターグループ で開発されており、以前はfoaf + sslとして知られていたプロトコル に基づいて構築されています 。したがって、それも進化しています。これらのプロトコルは両方とも、2011年5月にカリフォルニア州のMozillaのオフィスで開催されたブラウザワークショップの W3C Identityで発表されました

さらに、両方のプロジェクトに互換性がないことは明らかではありません。そうでない場合は、セマンティクスの問題にすぎません。認証とシリアル化という2つの異なる側面を区別できます。

  • ID検証:証明書署名検証(BrowserId)またはサブジェクト公開鍵検証(WebId/foaf + ssl)
  • certificate format:証明書のJSON(BrowserId)またはX509(foaf + ssl)形式

現在、BrowserIdはペア(証明書署名検証、JSON証明書)によって定義されており、WebID/foaf + sslはペア(ユーザー公開鍵検証、X509証明書)によって定義されています この電子メールに記載されています

しかし、他の2つの組み合わせも使用できない論理的な理由はありません。

  • (証明書の署名検証、X509証明書)-つまり、TLSで実行されるBrowserId認証
  • (ユーザー公開鍵の検証、JSON証明書)-つまり、JSON証明書で行われるWebID認証。

または、証明書の種類ごとに両方の戦略を持つこともできます。つまり、最初に証明書の署名を確認し、次に必要に応じてWebIDも確認します。これは、ユーザーに関する詳細情報(RESTful属性交換)を取得するのに役立ち、キーが取り消されていないことを確認するのにも役立ちます。

したがって、ここで扱う問題は、「純粋な」BrowserId認証と「純粋な」WebID(foaf + sslとも呼ばれる)認証の利点と欠点は何ですか。この回答の残りの部分では、そのことを覚えておいてください。

純粋なBrowserIdとWebId/foaf + sslの比較

2011年7月の状況を説明する回答。

侵害されたキーはどのように無効化されますか?

WebIDでは、プロファイルページから削除されます。優れたユーザーインターフェイスは、これをワンクリックで行うことができます。ユーザーはログイン後にソーシャルネットワークにアクセスし(おそらく携帯電話経由で送信されたワンタイムキーを使用して)、侵害された公開キーを削除します。これは、名前、彼が生成したコンピューター、またはその他の何かで識別できます。物事を覚えやすくする方法。

BrowserIdは現在、有効期間付きのJSON証明書を使用しています。プロトコルは現在、非常に短い期間に制限することを望んでいます。 |(JSON)証明書の有効期間を非常に短くする必要があるのは、現在のBrowserID仕様の証明書利用者が、電子メールプロバイダーの公開キーで署名を確認することによってのみ証明書を検証できるためです。証明書の有効期間が長いほど、意味が間違っている可能性が高くなります。たとえば、ユーザーのコンピューターが盗まれた可能性があります。

ただし、BrowserIdをWebIDと組み合わせる場合(つまり、JSON証明書にhttp(s)のサブジェクト名が含まれる場合)は、より長期間有効なキーを使用できます:証明書利用者は、ユーザーのパブリックプロファイルをチェックして、キーが侵害されていないことを確認できます。

マルチデバイスブラウザーサポートはどのように機能しますか?

WebIDとBrowserIdの両方に複数の公開鍵を含めることができます。

WebID/foaf + sslを使用すると、 「WebIdの作成と4分での使用」のビデオ で確認できるように、各公開キーがプロファイルページで公開されます。各デバイス/ブラウザは、同じWebIDに対して独自の証明書を持つことができます。ユーザーの認証は、証明書の公開鍵がWebIDプロファイルページに公開されている公開鍵の1つと一致することを確認することによって行われます。

BrowserIdは、そのパーツがブラウザーに統合されると、ブラウザー/ OSキーチェーンにキーを保存します。証明書利用者は、証明書のバイトごとの比較ではなく、発行者が実際に証明書に署名したことを確認することによって証明書を検証します。したがって、署名が本物である限り、任意の証明書を使用できます。

それらが複数の公開鍵をもたらす場合、それらはどのようにリンクされますか?

BrowserIdでは、ユーザーの証明書の公開鍵は、クライアントが認証プロセスで対応する秘密鍵を持っていることを確認するためにのみ使用されます。リンクは行われていません。

WebIDを使用すると、さまざまな公開鍵をプロファイルページで公開し、これをそこでリンクできます。それらの鍵のいくつかは、長持ちするものとして説明できるため、署名と復号化にも使用されます。

リンクはすべての消費者に対して行われる必要がありますか?

純粋なWebIDでは、すべてのプロファイルがすべての公開鍵を公開する必要があります。プロファイルは、そのキーの公開にすぎません。

BrowserIDは、電子メールサーバーが公開鍵を公開することのみを要求します。

現在のブラウザでのサポートはどうですか?

すべてのデスクトップブラウザは、1998年以降のX509証明書の選択をサポートしています。 (初期バージョンのChromeのようないくつかの例外を除いて)携帯電話はよりパッチに対応しています。 wikiページ

BrowserIdが分散型で機能するには、ブラウザのサポートが必要です。これは現在欠落していますが、Mozillaラボでサポートされているため、展開される可能性があります。

ユーザーインターフェイスは、平均的なユーザーが理解できるほど簡単ですか(作成、選択、現在のコンピューターからの取り消し、IDのグローバルな取り消しなど)?

  • 作成:どちらの場合も、これはワンクリックの作業です。 WebID X509証明書を使用すると、html5 keygen要素とIE ActiveXの回避策を使用して証明書を生成できます。ユーザーは大きなボタンをクリックするだけです- WebID&Browsersビデオ を参照してくださいまたは、上記の「webIdの作成と使用」の1つです。もちろん、より優れたWebデザイナーを使用することで、ユーザーインターフェイスを改善できます。
  • 選択
    • WebId:選択はChrome、Safari、OperaおよびIEで優れていますが、Firefoxで使用することは不可能ではありませんが、問題を修正しないのはなぜですか。それは謎です。投票してください バグ396441-SSLクライアント認証UIを改善する 。UIを改善するためにできることはたくさんありますが、不完全なブラウザは創造的なWebの人々が創造的にそれを使用することを妨げていません。
    • BrowerId:選択はWebサイトで設計できますが、これによりセキュリティリスクが高まる可能性があり、サイト間で一貫した認証UIが提供されません(そのため、フィッシングリスクの可能性があります)。
  • 現在のコンピュータからの取り消し
    • WebID:X509証明書を現在のコンピューターから削除することは避けなければならないことであり、確かにそのためのUIを改善する必要があります。
    • BrowserId:現在のコンピューターからの失効は実装されていないため、まだ定義されていません。
  • IDのグローバルな取り消し
    • WebID:これは、IDを完全に削除する必要がある場合はHTTPエラーコードの1つを返すこと、またはプロファイルが移動する場合はHTTPリダイレクト、古いIDと新しいIDの間のセマンティックID関係、または単に証明書が盗まれた場合、プロファイルから公開鍵の1つを削除する。
    • BrowserIdは、有効期間が短い(JSONベースの)証明書で自身を保護します

ユーザーを追跡できる中央組織はありますか?

  • WebID:完全に分散化できます。 FreedomBoxにWebIdを配置して、すべての友達を配置することができます。そのサービスを信頼している場合は、匿名サーバーに配置することもできます。
  • BrowserId:JSON証明書ストアがブラウザーと統合され、browserid.orgを使用する必要がなくなった場合、各電子メールプロバイダーが参加できます。フリーダムボックスは電子メールプロバイダーにもなるため、当局にもなります。

ユーザーを追跡できる分散型組織はありますか?

それがどのように見えるかの例?

追跡はどの程度詳細にできますか?

BrowserIdを使用して、証明書利用者は電子メールプロバイダーの公開キーを取得します。プロバイダーが知っておくべきことは、一部のサーバーがGET要求を行ったことだけです。これは、WebIDに統合する価値があるかもしれません。一方、依拠当事者は、スパムに悪用される可能性のある電子メールアドレスを取得します。

WebIDを使用-依拠当事者による要求がプロファイルページで行われます。このリクエストは、プロキシまたはip-proxyを介して匿名で行うことができます。

消費者が実装を正しく行うのはどれほど簡単ですか?

WebID over TLSでは、SSLサーバーを含め、証明書利用者用にセットアップする追加のものが必要です。そのサーバーは、クライアント側の証明書の通常の認証を行うべきではありません。一方、TLSを強制するため、より安全です。時間の経過とともにテストされ、テストされ続けているTLSツールはたくさんあります。

BrowserIdは証明書利用者にTLSを必要としないため、セットアップが簡単です。一方、TLSが設定されていない場合、中間者攻撃が発生する可能性があります。

(しかし、この時点で、BrowserIDとWebIDが新しく提案されたJSON証明書形式を使用できず、長所を組み合わせられないという深い理由がないことに気付くはずです。BrowserIdを実行することは十分に可能です)

ソフトウェアのインストールが許可されていないインターネット端末では、どのように機能しますか(侵害されるリスクを受け入れた場合)。

インターネット端末は常に危険です。リスクを許容できるのは暗号鍵だけです。キーをハードウェアに完全に配置することにより、秘密キーが盗まれるリスクが取り除かれます。 WebIdおよび暗号スティック を参照してください。それ以外の場合、WebIDまたはBrowserIdのいずれかを使用する必要がある場合、存続期間の非常に短いキーは損傷制限ソリューションです。どちらのプロトコルも短期間のキーで機能します。

おそらくOpenIdの方が携帯電話から渡されるワンタイムパスワードと組み合わせる方が良いでしょう。

21
bblfish

これが、クライアント側の証明書について私がいつも聞いてきた一般的な知識です。クライアント側の証明書は、現在のブラウザーでは十分にサポートされていません。 UIは一般ユーザーには簡単に理解できません。その結果、それは大衆にとって実際に実行可能なオプションではありません。

4
D.W.

フェデレーションIDのセキュリティ、プライバシー、およびユーザビリティの要件 Michael HackettとKirstie HawkeyによるWebIDとMozilla Personaの比較を提供します。当時はまだBrowserIDと呼ばれていました。

表1に記載されている主な違いは次のとおりです。

  • ペルソナキーは有効期間が短いため、パスワードで保護する必要があります。 WebIDキーは長期間有効ですが、パスワードで保護されたプロファイルから簡単に無効にすることができます。
  • 現在のPersonaの実装は標準のブラウザーウィンドウを使用しているため、なりすましを見つけるのは困難です(ブラウザーがネイティブのPersonaサポートを取得すると変更される可能性があります)。 WebIDはブラウザのネイティブ証明書選択UIを使用しているため、フィッシングの可能性はありません。
  • 所有者の電子メール/ URIに対する制御が失われると、ペルソナとWebIDの両方のIDが危険にさらされる可能性があります。
  • ペルソナIdPは、IDを使用するSPを認識していません。 WebID IdPは、IDを使用するすべてのSPを知っています。
  • ペルソナSPにIdPの公開キーのキャッシュがあり、ブラウザーに有効な証明書がまだある場合でも、IDを確認することができます。WebIDプロファイルにアクセスできる必要があります。そうでない場合、IDは使用できません。
  • ペルソナは優れたUXデザインを備えていますが、WebIDはその逆です。

詳細については、論文を読むことをお勧めします。オンラインで無料で利用でき、デジタルライブラリへのアクセスは必要ありません。

4
Daniel