draft-ietf-tokbind-https-16.txt   draft-ietf-tokbind-https-17.txt 
Internet Engineering Task Force A. Popov Internet Engineering Task Force A. Popov
Internet-Draft M. Nystroem Internet-Draft M. Nystroem
Intended status: Standards Track Microsoft Corp. Intended status: Standards Track Microsoft Corp.
Expires: December 5, 2018 D. Balfanz, Ed. Expires: December 7, 2018 D. Balfanz, Ed.
A. Langley A. Langley
N. Harper N. Harper
Google Inc. Google Inc.
J. Hodges J. Hodges
PayPal PayPal
June 3, 2018 June 5, 2018
Token Binding over HTTP Token Binding over HTTP
draft-ietf-tokbind-https-16 draft-ietf-tokbind-https-17
Abstract Abstract
This document describes a collection of mechanisms that allow HTTP This document describes a collection of mechanisms that allow HTTP
servers to cryptographically bind security tokens (such as cookies servers to cryptographically bind security tokens (such as cookies
and OAuth tokens) to TLS connections. and OAuth tokens) to TLS connections.
We describe both first-party and federated scenarios. In a first- We describe both first-party and federated scenarios. In a first-
party scenario, an HTTP server is able to cryptographically bind the party scenario, an HTTP server is able to cryptographically bind the
security tokens it issues to a client, and which the client security tokens it issues to a client, and which the client
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 5, 2018. This Internet-Draft will expire on December 7, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 10, line 41 skipping to change at page 10, line 41
from the referrer and create a referred TokenBinding with it to from the referrer and create a referred TokenBinding with it to
include in the TokenBindingMessage on the redirect request. In other include in the TokenBindingMessage on the redirect request. In other
words, the Token Binding message in the redirect request to the Token words, the Token Binding message in the redirect request to the Token
Provider now includes one provided binding and one referred binding, Provider now includes one provided binding and one referred binding,
the latter constructed from the binding between the client and the the latter constructed from the binding between the client and the
Token Consumer. Token Consumer.
When a client receives the Include-Referred-Token-Binding-ID header, When a client receives the Include-Referred-Token-Binding-ID header,
it includes the referred token binding even if both the Token it includes the referred token binding even if both the Token
Provider and the Token Consumer fall under the same eTLD+1 and the Provider and the Token Consumer fall under the same eTLD+1 and the
provided and referred token binding IDs are the same. Note that the provided and referred token binding IDs are the same.
referred token binding is sent only on the request resulting from the
redirect and not on any subsequent requests to the Token Provider.
The referred token binding is sent only on the initial request
resulting from the HTTP response that included the Include-Referred-
Token-Binding-ID header. Should the response to that initial request
be a further redirect, the original referred token binding is no
longer included in subsequent requests. (A new referred token
binding may be included if the redirecting endpoint itself responded
with a Include-Referred-Token-Binding-ID response header.)
If the Include-Referred-Token-Binding-ID header field is received in If the Include-Referred-Token-Binding-ID header field is received in
response to a request that did not include the Token-Binding header response to a request that did not include the Token-Binding header
field, the client MUST ignore the Include-Referred-Token-Binding-ID field, the client MUST ignore the Include-Referred-Token-Binding-ID
header field. header field.
This header field has only meaning if the HTTP status code is a This header field has only meaning if the HTTP status code is a
redirection code (300-399), and MUST be ignored by the client for any redirection code (300-399), and MUST be ignored by the client for any
other status codes. If the client supports the Token Binding other status codes. If the client supports the Token Binding
Protocol, and has negotiated the Token Binding Protocol with both the Protocol, and has negotiated the Token Binding Protocol with both the
Token Consumer and the Token Provider, it already sends the Sec- Token Consumer and the Token Provider, it already sends the Sec-
skipping to change at page 23, line 29 skipping to change at page 23, line 29
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 11.2. Informative References
[fetch-spec] [fetch-spec]
WhatWG, "Fetch", Living Standard , WhatWG, "Fetch", Living Standard ,
<https://fetch.spec.whatwg.org/>. <https://fetch.spec.whatwg.org/>.
[I-D.ietf-tokbind-tls13]
Harper, N., "Token Binding for Transport Layer Security
(TLS) Version 1.3 Connections", draft-ietf-tokbind-
tls13-01 (work in progress), May 2018.
[OASIS.saml-core-2.0-os] [OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion "Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core- Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005, <http://docs.oasis- 2.0-os, March 2005, <http://docs.oasis-
open.org/security/saml/v2.0/saml-core-2.0-os.pdf>. open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.
[OpenID.Core] [OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0", August 2015, C. Mortimore, "OpenID Connect Core 1.0", August 2015,
 End of changes. 7 change blocks. 
7 lines changed or deleted 17 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/