- From: vanupam <notifications@github.com>
- Date: Thu, 16 Mar 2017 11:17:22 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Thursday, 16 March 2017 18:17:55 UTC
vanupam commented on this pull request. > +It maintains <a for=/>token binding ID</a>s at the granularity of +effective top-level domain (public suffix) + 1 (eTLD+1). +If the user agent and server agree to use Token Binding +and a <a for=/>token binding ID</a> does not already exist for that server, +the user agent generates a <a for=/>token binding ID</a> (essentially, a public-private key-pair) +for use with the server, +using TLS connection metadata saved at the end of the Token Binding Negotiation, +and saves it in the Token Binding key store. +Later, the user agent simply looks up the a <a for=/>token binding ID</a> whenever needed. +When the user agent sends a <a for=/>request</a> to the server over the TLS connection, +it proves possession of its <a for=/>token binding ID</a> to the server. +The server associates credentials that it issues to that user agent with that +<a for=/>token binding ID</a>, +and verifies if credentials presented to it by a user agent match the +<a for=/>token binding ID</a> used when the credentials were issued to that user agent. +<p class="note no-backref"> Fixed. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/pull/325#discussion_r106494093
Received on Thursday, 16 March 2017 18:17:55 UTC