ACSのプレーンテキストまたは署名付きトークンの要求方法を選択しようとしています（http://msdn.microsoft.com/en-us/library/ee706734.aspx）。
これら2つの方法を区別するために私が思いついた唯一のことは、誰かが私のパスワードを取得するためにHTTPSトラフィックを復号化しようとしたときに、Signedメソッドが盗聴者に対する追加の緩和策を提供することです。署名付きの場合、HTTPSを復号化する以外に、（署名キーを学習するために）署名を破る必要があるため、より困難になります。
HTTPSは十分に強力であると見なされており、誰も私のメッセージを読めないようにするために追加のものを必要とすべきではないというのは正しいですか？
プレーンテキストと署名付きの間でACSのトークン要求方法を選択する際の私の主張は何でしょうか？
プレーンテキストと署名されたリクエストは両方ともHTTPSトランスポートによって保護されます。ACSによって発行されたトークンは、証明書利用者（スコープ）用に構成されたWebトークン形式に準拠し、発行されたACSトークンのクレームには、変換ルールエンジンによって生成されたクレームの結果が含まれます。
プレーンテキスト要求には、サービスIDのユーザー名とパスワードをACSに送信することが含まれます。スコープは、アクセストークンの受信を希望する証明書利用者を示します。このシナリオでは、呼び出し元はトークンを受信するためにサービスIDクレデンシャルを知る必要があるだけです。プレーンテキストリクエストでは、クレーム変換エンジンで使用できるクレームは名前識別子クレームのみです。
一方、署名された要求は、サービスの利用者がクレーム変換エンジンに豊富なクレームのセットを提供したい場合です。サービスコンシューマーは、指定されたアサーション形式（通常はSWTまたはJWT）を使用してエンコードされたアサーションを作成することで一連のクレームをアサートし、対称または非対称の署名キーを使用してアサーションにデジタル署名します。
SWTはHMACSHA-256アルゴリズムを使用した対称署名のみをサポートしますが、JWTは対称署名アルゴリズムと非対称署名アルゴリズムの両方をサポートします。このシナリオでは、サービスコンシューマーは、アサーションにデジタル署名するために使用される署名キーを所有している必要があります。ACSは、アサーションのデジタル署名を検証して、呼び出し元が信頼されていること（署名キーを所有していること）、およびアサーションが改ざんされていないことを確認します。次に、クレーム変換エンジンは、証明書利用者ルールを適用してアクセストークンを生成します。
クレーム変換エンジンに提示される豊富なクレームのセットが必要ない場合（名前識別子で十分）、またはサービスコンシューマーがアサーションの暗号化署名をサポートしていない場合は、プレーンテキスト要求を使用します。
クレーム変換ルールが出力クレーム計算を実行するために複数のクレームを必要とする場合、またはサービスコンシューマーが使用したいSAMLアサーションをすでに持っている場合は、署名されたリクエストを使用します。
OAUTH WRAPプロトコルのより完全な説明が必要な場合は、OAuthWRAPを参照してください。