5. 認証サービス English
認証サービスの目的は、単に名前を検証すること、もしくは、より緻密には「メッセージ」の起点を検証することです。これは、認可（authorization）サービスとは異なります。認可サービスは、認証された名前に対してどのサービスが利用可能であるかを判定します。我々は、認証は、インターネット規模のサービスとなる一方、認可（authorization）は、 各資源について、どのアクセスが認可されるかについて特定のものであることを期待します。
この「識別（identification）」機能は、いくつかの状況において使うことができます。例えば、次のとおりです。：
- ワンタイム パスワード： 「このチャレンジに応答しているのは、本当に <huitema@inria.fr> である。」
- ファイアウォールへのアクセス： 「ホスト A においてポート a でデータを送信しようとしているのは、本当に <huitema@inria.fr> である。」
我々が命名したくなるインターネット オブジェクトが多くあります。
例：ドメイン名： sophia.inria.fr
マシン名： jupiter.inria.fr
サービス名： www.sophia.inria.fr
（実際には、データベース）ユーザ： huitema@sophia.inria.fr
プロセス： p112.huitema@sophia.inria.fr
p112.sophia.inria.frURL：
http//www.sophia.inria.fr:222/tmp/foobar「認証サービスは、人間のみが「根拠をもつ」ので、人間に命名することにのみ関する」と信じてしまう可能性があります。； プロセスは、人の代わりに活動しているので、何らかのアクセス権限を得ます。しかし、これは、あまりに矮小的であり、潜在的に誤解を招きます。我々は、「マシン」もしくはハードウェア構成要素を認証する必要がある可能性があります。
例：
- マシンが起動するとき、自身を設定するために、資源にアクセスする必要がありますが、まだ、人によって「使われている」わけではありません。； ユーザは、いません。
- 「分散プロセッサ」において、構成要素の CPU は、相互に認証する必要がある可能性がある。
マシンは、ユーザとは異なります。； マシンは、人間が「秘密」を保つようには保つことができません。しかし、シンプルかつ拡張可能な名前空間をもつことには、大きな価値があります。
我々は、「認可サービスは、通常、「アクセス コントロールリスト（ACL）」を使う」、すなわち、「認可されたユーザ群の何らかの定義」と仮定します。 そのような群を表現するためのコンパクトなやり方は、「ワイルドカード」認可を認めることです。（例： 「<Bellcore.com>にいる誰でも」または「<INRIA.FR>にある、あらゆるマシン」 。）認証サービスは、認可サービスの実現を容易にするように設計される必要があり、「ワイルドカード」をサポートする必要があります。
しかし、ワイルドカードは、一般的であるとはいえません。「我々は、階層的な名前空間をもつ」と仮定すると、ワイルドカード化された項目は、その命名階層 に制限されます。例えば、<huitema@sophia.inria.fr> のような名前は、ワイルドカード（<*@sophia.inria.fr> または <*.inria.fr> または <*.fr>）によって突き合わされる可能性があります。このことは、人が INRIA にいる限り有用ですが、その一般的な問題を解決しません。「CNRI にある IETF ファイル サーバーが、すべての IAB メンバーによってアクセス可能である」と想定します。： その ACL は、メンバーを明示的に名前で掲載します。
例えば、X.500 モデルのように、古典的な命名アプローチは、人々は「DN（distinguished names）」をもつと考えます。一旦、誰かが、何らかの「ホワイトページ」サービス を通じて、そのような名前を発見した場合、それをグローバルなディレクトリ サービスにおけるアクセス鍵として使うことができます。
個人は、認可を様々な源泉から得る可能性があります。純粋に身元に基づくアクセスコントロール システムを使うとき、そのユーザは、それぞれのサービスにアクセスすることが許されている役割に応じて、複数の身元（すなわち、DN）を得る必要があります。我々は、このアプローチを次 節において検討します。
代替的アプローチのひとつは、ユーザについて非常に少数の身元をもち、（ユーザの ID と結びつけられた権限を授与する）認可の授与者が（署名した）クレデンシャルをもつことです。このように追加的な署名がなされたクレデンシャルは、「ケイパビリティ（capabilities）」として知られています。こうして、ユーザは、一般的な身元クレデンシャル（例： X.509 証明書）を通じて彼女の身元を確立することができ、要求されるケイパビリティを提示することによって認可を確立することができます。これは、何となく、運転免許証上の名前に結びつけられたクレジットカードを取得しようとしている人が、適切なクレジットカードに加えて、身元の写真検証のためのライセンスを提示することになぞらえることができます。
平均的な個人の財布を開いたとしましょう。： 我々は、その中に、いくつかの「クレジットカード」を見つけます。我々は皆、多くの「クレジットカード」（例： 会社職員カード、クレジットカード、航空会員証、運転免許証）をもっています。これらの各カードは、実際には、関係の存在を言明しているトークンです。： 銀行は、「持参人による小切手が支払われること」を認定し、運輸機関は、「持参人が運転方法を学んだこと」を認定する 等。これは、身元に基づく認可の一例です。ここでは、個人には、その個人に資格が与えられる異なる関係に対応して、異なる名前が与えられます。
我々が「名前空間が DNS 名（ドメイン名）に基づいている」と想定する場合、例えば、上述の人は、名前について認証される可能性があります。：
customer@my-big-bank.com
customer@frequent-flyer.airline.com
我々がここで使ったモデルは、「名前は、関連性（association）である」というものです。これは、ある者が、ユーザと「資源エージェント」 の間の「信頼の鎖」を構築する、名前検証手順と整合しています。信頼パス中の特定のパスに従うことによって、人は、信頼を確立することと、ユーザが「認可されたグループ」に属することを見せることの両方ができます。
ひとりの人間について「複数の名前」の存在は、「証拠」の関連の存在を意味する可能性があり、意味しない可能性もあります。「<huitema@sophia.inria.fr> と <huitema@iab.isoc.org> は、同一人物について 2つの名前ですが、ユーザが、すべての彼のトークンが見えることを望まない場合が多くあること」を知ることは、有用です。
再度、CNRI にあるファイルにアクセスしようとしている Christian Huitema さんの例を検討してみましょう。彼は、INRIA の出方向ファイアウォールと、また、CNRI の入り方向制御と、相互作用する必要があります。「認可がケイパビリティに依存するか、または、複数の関係性名称に依存するか」に関わらず、異なるクレデンシャルがパス上の各ファイアウォールにおいて 、必要とされる可能性があります。例えば、複数の名前が使われると想定すると、彼は、INRIA によってネットワーク資源を使うことが認可されるために INRIA の名前 <huitema@sophia.inria.fr> を使い、彼は、ファイルサーバーにアクセスするために IAB の名前 <huitema@iab.isoc.org> を使います。それゆえ、明らかな問題が起きます。： どのように彼は、特定のファイアウォールに適切なクレデンシャルを選択するのか？より詳細には、どのように、そのコンピュータ プログラムは、INRIA のファイアウォール チャレンジ用に、あるクレデンシャルを使う必要があり、CNRI のリクエスト用に、その他のものを使う必要があることを発見するように、接続を管理するのか？多くの可能性ある答えがあります。プログラムは、シンプルに、すべてのユーザのクレデンシャルを転送し、遠隔マシンに選択させる可能性があります。しかし、この作業は、いくつかの効率性問題を提起します。： すべての可能性ある名前を転送することは、大量であり、多くの名前を読み通すことは、長くかかります。また、多くの名前を広告することは、プライバシーとセキュリティの理由から、非常に望まれないことです。： 人は、「遠隔サーバーが、特定のユーザがもつ可能性があるクレデンシャルのすべてについての統計を集めること」を望みません。
その他の可能性は、認可を要求する者に、許可されることを望む一式のクレデンシャルを転送するようにすることです。（例： 「私は、CNRI 従業員と IAB メンバー として働く準備ができています。」）このことは、程度は、以前の解決策より低いですが、同様なプライバシーとセキュリティ問題を提起します。事実、名前の選択の問題は、一般的な 「信頼パス」モデルと同様です。名前の選択は、めったに認証グラフ中のパスではなく、ネットワーク専門家には、「どのようにグラフ中のパスを見つけるか」を知っていることが期待されています。
短期において、おそらく、少なくともローカルなトランザクションについては、「デフォルト名」または「主たる名前」を使い、遠隔サービスによって要求されるクレデンシャルを「推測」することをあてにする可能性があります。ローカル環境を離れるために、我々は、ローカル クレデンシャルのみを必要とします。； 遠隔サーバーに接続するためには、我々は、宛先のクレデンシャルのみを必要とします。それゆえ、我々は、1つ、もしくは、おそらく 2つのクレデンシャルを必要とします。クレデンシャルは、宛先から配布される可能性があります。一般的なクレデンシャル； ワイルドカード； 「FTP 提供の」トークンで十分であることは、よくあることでしょう。；