webid と比較した webid の主な長所と短所は何ですか?
この質問は this answer に触発されており、その質問のトピックについて非常にあいまいであるにもかかわらず、多数の賛成票を得ました。
Webidは基本的に、プロファイルURLが含まれているSSLクライアント側の証明書のファンシーな名前です。
いくつかのトピック:
注:WebID側のこれらの質問の多くは、 Foaf + ssl FAQ で回答されています。
BrowserId(詳細 spec )は、Mozilla labsでの実験であり、非常に新しく、完全に定義されていません(たとえば、電子メールサーバーの公開鍵を見つける方法が正確に指定されていないなど)、完全に実装されていません(それはブラウザのサポートを実際に配布する必要があります)。 WebIdプロトコル は W3Cインキュベーターグループ で開発されており、以前はfoaf + sslとして知られていたプロトコル に基づいて構築されています 。したがって、それも進化しています。これらのプロトコルは両方とも、2011年5月にカリフォルニア州のMozillaのオフィスで開催されたブラウザワークショップの W3C Identityで発表されました
さらに、両方のプロジェクトに互換性がないことは明らかではありません。そうでない場合は、セマンティクスの問題にすぎません。認証とシリアル化という2つの異なる側面を区別できます。
現在、BrowserIdはペア(証明書署名検証、JSON証明書)によって定義されており、WebID/foaf + sslはペア(ユーザー公開鍵検証、X509証明書)によって定義されています この電子メールに記載されています
しかし、他の2つの組み合わせも使用できない論理的な理由はありません。
または、証明書の種類ごとに両方の戦略を持つこともできます。つまり、最初に証明書の署名を確認し、次に必要に応じてWebIDも確認します。これは、ユーザーに関する詳細情報(RESTful属性交換)を取得するのに役立ち、キーが取り消されていないことを確認するのにも役立ちます。
したがって、ここで扱う問題は、「純粋な」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ラボでサポートされているため、展開される可能性があります。
それがどのように見えるかの例?
BrowserIdを使用して、証明書利用者は電子メールプロバイダーの公開キーを取得します。プロバイダーが知っておくべきことは、一部のサーバーがGET要求を行ったことだけです。これは、WebIDに統合する価値があるかもしれません。一方、依拠当事者は、スパムに悪用される可能性のある電子メールアドレスを取得します。
WebIDを使用-依拠当事者による要求がプロファイルページで行われます。このリクエストは、プロキシまたはip-proxyを介して匿名で行うことができます。
WebID over TLSでは、SSLサーバーを含め、証明書利用者用にセットアップする追加のものが必要です。そのサーバーは、クライアント側の証明書の通常の認証を行うべきではありません。一方、TLSを強制するため、より安全です。時間の経過とともにテストされ、テストされ続けているTLSツールはたくさんあります。
BrowserIdは証明書利用者にTLSを必要としないため、セットアップが簡単です。一方、TLSが設定されていない場合、中間者攻撃が発生する可能性があります。
(しかし、この時点で、BrowserIDとWebIDが新しく提案されたJSON証明書形式を使用できず、長所を組み合わせられないという深い理由がないことに気付くはずです。BrowserIdを実行することは十分に可能です)
インターネット端末は常に危険です。リスクを許容できるのは暗号鍵だけです。キーをハードウェアに完全に配置することにより、秘密キーが盗まれるリスクが取り除かれます。 WebIdおよび暗号スティック を参照してください。それ以外の場合、WebIDまたはBrowserIdのいずれかを使用する必要がある場合、存続期間の非常に短いキーは損傷制限ソリューションです。どちらのプロトコルも短期間のキーで機能します。
おそらくOpenIdの方が携帯電話から渡されるワンタイムパスワードと組み合わせる方が良いでしょう。
これが、クライアント側の証明書について私がいつも聞いてきた一般的な知識です。クライアント側の証明書は、現在のブラウザーでは十分にサポートされていません。 UIは一般ユーザーには簡単に理解できません。その結果、それは大衆にとって実際に実行可能なオプションではありません。
フェデレーションIDのセキュリティ、プライバシー、およびユーザビリティの要件 Michael HackettとKirstie HawkeyによるWebIDとMozilla Personaの比較を提供します。当時はまだBrowserIDと呼ばれていました。
表1に記載されている主な違いは次のとおりです。
詳細については、論文を読むことをお勧めします。オンラインで無料で利用でき、デジタルライブラリへのアクセスは必要ありません。