Cookieはトークンバインディングとどのように連携しますか？
トークンバインディング は、クライアントが署名済みトークンをサーバーに送信するメカニズムです。このトークンは秘密鍵に基づいているため、セッションCookieよりも盗むのは困難です。私が理解していないのは、トークンバインディングトークンがセッションCookieとどのように連携するかです。
トークンバインディング 実装する意図 は次のように述べています。
トークンバインディングを使用すると、Cookieは（セッション資格情報ではなく）クライアントに発行された証明書のように機能し、トークンバインド秘密鍵は実際のセッション資格情報になります。
トークンバインディングによって提供される署名済みトークンをセッショントークンとして使用することはできますか？その場合でも、クッキーが必要ですか？ Cookieが証明書のように機能するということはどういう意味ですか？
編集：実装する意図はもはやこれを言っていません。
私が理解している限り、トークンバインディングは、PKIを必要とせずに、証明書を使用してユーザーを識別するために使用できます。使い方：
クライアントは、サーバーに署名する必要なく、ローカルでキーペアと証明書を生成します。次に、HTTPSサーバーに接続すると、生成された秘密鍵を使用してtls_unique値（tlsハンドシェイク中にサーバーから送信）に署名し、署名されたtls_uniqueと公開鍵で構成されるトークンを「構築」します。この情報は、Token-BindingヘッダーとしてHTTPリクエストに追加されます。さらに、初めて、HTTPリクエストには、ユーザー名/パスワードなどの別の認証情報が含まれます。この一連のデータはサーバーに送信されます。サーバーは渡された資格情報を検証し、それが正しい場合は、トークンバインディング（主に証明書）をローカルに保存して、さらに認証します。さらに、あらゆる情報を格納できるトークンを生成しますが、バインディングリクエストの署名に使用された秘密鍵である公開鍵も格納します。このトークンは特定の証明書にバインドされ、特定のユーザーを一意に識別します。そして、このトークンはCookieを使用してクライアントに配信されます。
他のリクエストの間、サーバーはすでに生成されたトークンにバインドされたユーザー証明書を持っているので、資格情報は必要ありません。クライアントはトークンを別の署名されたtls_unique値と一緒に送信し、サーバーはBinding-Token情報と一緒にCookie内のトークンをチェックし、ユーザー（トークンが有効）を知っていて、提示された証明書が以前と同じで、認証が行われます。
この場合、完全に自動的に実行できる既知のメカニズムであり、Cookieが静かに保護されているという理由だけで、トークンはCookieによって送信されます。ただし、トークンは、GETリクエスト（ http：//service.domain/？token = .. 。）など、他の方法で両側に配信できることに注意してください。これは、ドメイン間でCookieを渡すことが機能しないため、特にフェデレーションサービスで使用されます。
セッションはどうですか？このトークンはセッションの識別にも使用できますが、混同しないでください。トークンは主に認証に使用されますが、セッションは、ステートレスセッションに関する情報を一定時間保持するために使用されます。ユーザーが開く新しいセッションごとに個別のセッションIDを使用します。これは私の個人的な感情であり、その理由を正確に説明することはできません。確かに、認証情報はヘッダー（Token-Binding/Cookie）ペアで新しいリクエストごとに個別に渡されるので、セッションに保存する必要はありません;）
それを終えるためだけに。私はCookieとは言いませんが、トークン（Cookieによって、またはGET/POST要求/またはデータによって送信できます）は、実際にはPKIを必要とせずに、認証に使用されるクライアント証明書としてサーバーとして機能します。秘密鍵サーバーを使用して暗号化（署名）されたデータと一緒に証明書をトークンで渡すからです。次に、サーバーはそれを使用してユーザーを認証します。