<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Draft: OpenID Connect
Token Bound Authentication 1.0 - draft 00</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Connect
Token Bound Authentication 1.0 - draft 00">
<meta name="generator" content="xml2rfc v1.37pre1 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Draft</td><td class="header">M. Jones</td></tr>
<tr><td class="header"> </td><td class="header">Microsoft</td></tr>
<tr><td class="header"> </td><td class="header">J. Bradley</td></tr>
<tr><td class="header"> </td><td class="header">B. Campbell</td></tr>
<tr><td class="header"> </td><td class="header">Ping Identity</td></tr>
<tr><td class="header"> </td><td class="header">July 4, 2016</td></tr>
</table></td></tr></table>
<h1><br />OpenID Connect
Token Bound Authentication 1.0 - draft 00</h1>
<h3>Abstract</h3>
<p>OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
protocol. It enables Clients to verify the identity of the End-User based
on the authentication performed by an Authorization Server, as well as to
obtain basic profile information about the End-User in an interoperable and
REST-like manner.
</p>
<p>
This specification enables OpenID Connect implementations to apply
Token Binding to the OpenID Connect ID Token.
This cryptographically binds the ID Token to the TLS connections
over which the authentication occurred.
This use of Token Binding protects the authentication flow
from man-in-the-middle and token export and replay attacks.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#Introduction">1.</a>
Introduction<br />
<a href="#rnc">1.1.</a>
Requirements Notation and Conventions<br />
<a href="#Terminology">1.2.</a>
Terminology<br />
<a href="#Representation">2.</a>
OpenID Connect Token Binding Representation<br />
<a href="#Actions">3.</a>
OpenID Connect Token Binding Actions<br />
<a href="#Phasing">4.</a>
Phasing in Token Binding and Preventing Downgrade Attacks<br />
<a href="#Metadata">5.</a>
Token Binding Metadata<br />
<a href="#RPMetadata">5.1.</a>
Token Binding RP Metadata<br />
<a href="#OPMetadata">5.2.</a>
Token Binding OP Metadata<br />
<a href="#Security">6.</a>
Security Considerations<br />
<a href="#IANA">7.</a>
IANA Considerations<br />
<a href="#CnfReg">7.1.</a>
JWT Confirmation Methods Registration<br />
<a href="#ClaimsContents">7.1.1.</a>
Registry Contents<br />
<a href="#DynRegRegistration">7.2.</a>
OAuth Dynamic Client Registration Metadata Registration<br />
<a href="#DynRegContents">7.2.1.</a>
Registry Contents<br />
<a href="#DiscRegistration">7.3.</a>
OAuth Authorization Server Discovery Metadata Registration<br />
<a href="#DiscContents">7.3.1.</a>
Registry Contents<br />
<a href="#rfc.references1">8.</a>
References<br />
<a href="#rfc.references1">8.1.</a>
Normative References<br />
<a href="#rfc.references2">8.2.</a>
Informative References<br />
<a href="#Acknowledgements">Appendix A.</a>
Acknowledgements<br />
<a href="#Notices">Appendix B.</a>
Notices<br />
<a href="#TBD">Appendix C.</a>
Open Issues<br />
<a href="#History">Appendix D.</a>
Document History<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
</p>
<br clear="all" />
<a name="Introduction"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
Introduction</h3>
<p>
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
<a class='info' href='#RFC6749'>[RFC6749]<span> (</span><span class='info'>Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
protocol. It enables Clients to verify the identity of the End-User based
on the authentication performed by an Authorization Server, as well as to
obtain basic profile information about the End-User in an interoperable and
REST-like manner.
</p>
<p>
This specification enables OpenID Connect implementations to apply
Token Binding
<a class='info' href='#I-D.ietf-tokbind-protocol'>The Token Binding Protocol Version 1.0<span> (</span><span class='info'>Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. Hodges, “The Token Binding Protocol Version 1.0,” May 2016.</span><span>)</span></a> [I‑D.ietf‑tokbind‑protocol]
<a class='info' href='#I-D.ietf-tokbind-https'>Token Binding over HTTP<span> (</span><span class='info'>Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. Hodges, “Token Binding over HTTP,” March 2016.</span><span>)</span></a> [I‑D.ietf‑tokbind‑https]
to the OpenID Connect ID Token
defined by <a class='info' href='#OpenID.Core'>OpenID Connect Core 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” November 2014.</span><span>)</span></a> [OpenID.Core].
This cryptographically binds the ID Token to the TLS connections
over which the authentication occurred.
Token Binding is applied to OpenID Connect in the manner described in
Section 3 (Federation Use Cases) of
<a class='info' href='#I-D.ietf-tokbind-https'>Token Binding over HTTP<span> (</span><span class='info'>Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. Hodges, “Token Binding over HTTP,” March 2016.</span><span>)</span></a> [I‑D.ietf‑tokbind‑https].
As described in Section 4.4 (Securing Federated Sign-On Protocols) of
<a class='info' href='#I-D.ietf-tokbind-https'>Token Binding over HTTP<span> (</span><span class='info'>Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. Hodges, “Token Binding over HTTP,” March 2016.</span><span>)</span></a> [I‑D.ietf‑tokbind‑https],
this use of Token Binding protects the authentication flow
from man-in-the-middle and token export and replay attacks.
</p>
<a name="rnc"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.1"></a><h3>1.1.
Requirements Notation and Conventions</h3>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a class='info' href='#RFC2119'>RFC 2119<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> [RFC2119].
</p>
<p>
In the .txt version of this specification,
values are quoted to indicate that they are to be taken literally.
When using these values in protocol messages,
the quotes MUST NOT be used as part of the value.
In the HTML version of this specification,
values to be taken literally are indicated by
the use of <tt>this fixed-width font</tt>.
</p>
<a name="Terminology"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.2"></a><h3>1.2.
Terminology</h3>
<p>
This specification uses the terms
"Authorization Endpoint", "Authorization Server",
"Client", "Response Type", and "Token Endpoint"
defined by <a class='info' href='#RFC6749'>OAuth 2.0<span> (</span><span class='info'>Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a> [RFC6749],
the terms "Claim", "JSON Web Token (JWT)",
and "JWT Claims Set"
defined by <a class='info' href='#JWT'>JSON Web Token (JWT)<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.</span><span>)</span></a> [JWT],
the term "User Agent" defined by <a class='info' href='#RFC7230'>RFC 7230<span> (</span><span class='info'>Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing,” June 2014.</span><span>)</span></a> [RFC7230],
the terms "Provided", "Referred", "Token Binding" and "Token Binding ID"
defined by <a class='info' href='#I-D.ietf-tokbind-https'>Token Binding over HTTP<span> (</span><span class='info'>Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. Hodges, “Token Binding over HTTP,” March 2016.</span><span>)</span></a> [I‑D.ietf‑tokbind‑https],
and the terms defined by
<a class='info' href='#OpenID.Core'>OpenID Connect Core 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” November 2014.</span><span>)</span></a> [OpenID.Core].
</p>
<a name="Representation"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
OpenID Connect Token Binding Representation</h3>
<p>
Section 3 (Federation Use Cases) of
<a class='info' href='#I-D.ietf-tokbind-https'>Token Binding over HTTP<span> (</span><span class='info'>Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. Hodges, “Token Binding over HTTP,” March 2016.</span><span>)</span></a> [I‑D.ietf‑tokbind‑https]
outlines how Token Binding is used with federation protocols in the abstract.
This section defines the concrete data structures for using Token Binding
with OpenID Connect.
</p>
<p>
Section 3.2 of
<a class='info' href='#I-D.ietf-tokbind-https'>Token Binding over HTTP<span> (</span><span class='info'>Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. Hodges, “Token Binding over HTTP,” March 2016.</span><span>)</span></a> [I‑D.ietf‑tokbind‑https]
suggests placing the public key of the Token Binding
used to communicate with the Relying Party in the ID Token.
A representation of this key is communicated to the OpenID Provider
in its Referred Token Binding ID.
This specification utilizes a variant of this approach in which
a cryptographic hash of the Token Binding ID
using the SHA-256 hash function <a class='info' href='#SHS'>[SHS]<span> (</span><span class='info'>National Institute of Standards and Technology, “Secure Hash Standard (SHS),” March 2012.</span><span>)</span></a>
is instead added to the ID Token.
This has the benefit of significantly reducing the size of the information
added to the ID Token from what it would otherwise have been were the
Token Binding ID to be included directly - particularly in the RSA key case.
</p>
<p>
The recipient MUST verify that the SHA-256 hash
of the Provided Token Binding ID
matches the SHA-256 hash contained in the ID Token.
</p>
<p>
This specification defines the new JWT Confirmation Method
<a class='info' href='#RFC7800'>RFC 7800<span> (</span><span class='info'>Jones, M., Bradley, J., and H. Tschofenig, “Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs),” April 2016.</span><span>)</span></a> [RFC7800]
member <tt>tbh</tt> (token binding hash)
to represent the SHA-256 hash of a Token Binding ID
in an ID Token.
The value of the <tt>tbh</tt> member is the
base64url encoding of the SHA-256 hash of the Token Binding ID.
</p>
<p>
The following example demonstrates the JWT Claims Set of an ID Token
containing the base64url encoding of the SHA-256 hash of a Token Binding ID
as the value of the <tt>tbh</tt> (token binding hash)
element in the <tt>cnf</tt> (confirmation) claim:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
{
"iss": "https://server.example.com",
"sub": "0f6LkoE3KsPyxQ",
"aud": "0d8f597e-bc45-46b2-97cf-043c88aa5ecc",
"iat": 1467151051,
"exp": 1467151651,
"nonce": "1KjVsFnQRd4V2XC6",
"cnf":{
"tbh": "l1X0aVlpikNqDhaH92VwGgrFdAY0tSackYis1r_-fPo"
}
}
</pre></div>
<a name="Actions"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
OpenID Connect Token Binding Actions</h3>
<p>
This specification maps the abstract Token Binding actions specified in
Section 3 (Federation Use Cases) of
<a class='info' href='#I-D.ietf-tokbind-https'>Token Binding over HTTP<span> (</span><span class='info'>Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. Hodges, “Token Binding over HTTP,” March 2016.</span><span>)</span></a> [I‑D.ietf‑tokbind‑https]
into concrete actions added to the authentication steps specified in
Section 3 (Authentication) of
<a class='info' href='#OpenID.Core'>OpenID Connect Core 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” November 2014.</span><span>)</span></a> [OpenID.Core].
Mapping the terminologies used in the two specifications,
the Relying Party is the Token Consumer and
the OpenID Provider is the Token Provider.
</p>
<p>
For OpenID Connect flows returning the ID Token directly from the Authorization Endpoint --
the Implicit Flow defined in Section 3.2 of
<a class='info' href='#OpenID.Core'>OpenID Connect Core 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” November 2014.</span><span>)</span></a> [OpenID.Core]
and the Hybrid Flow defined in Section 3.3 of OpenID Connect Core 1.0 when using the
<tt>code id_token</tt> or
<tt>code id_token token</tt> Response Types --
the actions described in Section 3.5 of
<a class='info' href='#I-D.ietf-tokbind-https'>Token Binding over HTTP<span> (</span><span class='info'>Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. Hodges, “Token Binding over HTTP,” March 2016.</span><span>)</span></a> [I‑D.ietf‑tokbind‑https]
are performed as described.
The one difference, as previously described, is that
a cryptographic hash
using the SHA-256 hash function <a class='info' href='#SHS'>[SHS]<span> (</span><span class='info'>National Institute of Standards and Technology, “Secure Hash Standard (SHS),” March 2012.</span><span>)</span></a>
of the Token Binding ID is instead added to the ID Token,
rather than the Token Binding ID itself.
</p>
<p>
For OpenID Connect flows returning the ID Token from the Token Endpoint --
the Authorization Code Flow defined in Section 3.1 of
<a class='info' href='#OpenID.Core'>OpenID Connect Core 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” November 2014.</span><span>)</span></a> [OpenID.Core]
and the Hybrid Flow defined in Section 3.3 of OpenID Connect Core 1.0 --
an additional step is necessary beyond those in the previous case.
That step is for the RP to record the Token Binding ID
used when communicating between the User Agent and the RP,
saving it for later use after the Token Response containing the ID Token
returned from the Token Endpoint is received.
This is needed because the ID Token will contain Token Binding information
from the TLS connection between the User Agent and the Relying Party --
not information from the TLS connection between the RP and the Token Endpoint.
In this case, even though the ID Token is returned from the Token Endpoint,
the Token Binding validation steps are performed using
the saved Token Binding ID,
rather than the Token Binding ID
used when communicating with the Token Endpoint.
</p>
<a name="Phasing"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
Phasing in Token Binding and Preventing Downgrade Attacks</h3>
<p>
Many OpenID Connect implementations will be deployed in situations in which
not all participants support Token Binding.
Any of combination of the Relying Party, the OpenID Provider,
and the User Agent may not yet support Token Binding,
in which case it will not work end-to-end.
</p>
<p>
It is a context-dependent deployment choice whether to allow
authentications to proceed in which Token Binding is not supported
or whether to treat Token Binding failures at any step as fatal errors.
In dynamic deployment environments in which End Users have choices
of Relying Parties, the OpenID Providers, and/or User Agents,
it is RECOMMENDED that authentications using one or more components
that do not implement Token Binding be allowed to successfully proceed.
This enables different components to be upgraded to supporting Token Binding
at different times, providing a smooth transition path for
phasing in Token Binding.
However, when Token Binding has been performed,
any Token Binding key mismatches MUST be treated as fatal errors.
</p>
<p>
If all the participants in an OpenID Connect authentication
support Token Binding and yet one or more of them does not use it,
this is likely evidence of a downgrade attack.
In this case, the authentication SHOULD be aborted with an error.
For instance, if the RP knows that the OP and the User Agent both
support Token Binding and yet the ID Token received does not contain
Token Binding information, this is almost certainly a sign of an attack.
</p>
<p>
The OP and RP can determine whether the other supports Token Binding
using the metadata values defined in the next section.
They can determine whether the User Agent supports Token Binding
by whether it negotiated Token Binding for the TLS connection.
</p>
<a name="Metadata"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.
Token Binding Metadata</h3>
<a name="RPMetadata"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.1"></a><h3>5.1.
Token Binding RP Metadata</h3>
<p>
Relying Parties supporting Token Binding that also support
<a class='info' href='#OpenID.Registration'>OpenID Connect Dynamic Client Registration 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” November 2014.</span><span>)</span></a> [OpenID.Registration]
use this metadata value to register their support for Token Binding:
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>rp_id_token_token_binding_supported</dt>
<dd>
OPTIONAL.
Boolean value specifying whether the Relying Party supports Token Binding of ID Tokens.
If omitted, the default value is <tt>false</tt>.
</dd>
</dl></blockquote><p>
</p>
<a name="OPMetadata"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.2"></a><h3>5.2.
Token Binding OP Metadata</h3>
<p>
OpenID Providers supporting Token Binding that also support
<a class='info' href='#OpenID.Discovery'>OpenID Connect Discovery 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” November 2014.</span><span>)</span></a> [OpenID.Discovery]
use this metadata value to register their support for Token Binding:
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>op_id_token_token_binding_supported</dt>
<dd>
OPTIONAL.
Boolean value specifying whether the OpenID Provider supports Token Binding of ID Tokens.
If omitted, the default value is <tt>false</tt>.
</dd>
</dl></blockquote><p>
</p>
<a name="Security"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.
Security Considerations</h3>
<p>
OpenID Connect implementations employing Token Binding benefit from the protections
described in Section 8 (Security Considerations) of
<a class='info' href='#I-D.ietf-tokbind-protocol'>The Token Binding Protocol Version 1.0<span> (</span><span class='info'>Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. Hodges, “The Token Binding Protocol Version 1.0,” May 2016.</span><span>)</span></a> [I‑D.ietf‑tokbind‑protocol].
Obtaining these protections requires performing the proofs of possession
described in Section 4.4 (Securing Federated Sign-On Protocols) of
<a class='info' href='#I-D.ietf-tokbind-https'>Token Binding over HTTP<span> (</span><span class='info'>Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. Hodges, “Token Binding over HTTP,” March 2016.</span><span>)</span></a> [I‑D.ietf‑tokbind‑https].
</p>
<p>
It is largely the RP's responsibility to detect attempted man-in-the-middle attacks.
This is possible after the RP first determines that all parties support Token Binding.
When all parties support Token Binding and there is either a Token Binding mismatch
or if Token Binding information should be present but is missing,
either in the TLS information or in the ID Token,
then the RP SHOULD reject the authentication.
</p>
<a name="IANA"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.
IANA Considerations</h3>
<a name="CnfReg"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.1"></a><h3>7.1.
JWT Confirmation Methods Registration</h3>
<p>
This specification registers the following confirmation method member
in the IANA "JWT Confirmation Methods" registry
<a class='info' href='#IANA.JWT.Claims'>[IANA.JWT.Claims]<span> (</span><span class='info'>IANA, “JSON Web Token Claims,” .</span><span>)</span></a>
for JWT <tt>cnf</tt> member values
established by <a class='info' href='#RFC7800'>[RFC7800]<span> (</span><span class='info'>Jones, M., Bradley, J., and H. Tschofenig, “Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs),” April 2016.</span><span>)</span></a>:
</p>
<a name="ClaimsContents"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.1.1"></a><h3>7.1.1.
Registry Contents</h3>
<p>
</p>
<ul class="text">
<li>
Confirmation Method Value: <tt>tbh</tt>
</li>
<li>
Confirmation Method Description: Token Binding Hash
</li>
<li>
Change Controller: IESG
</li>
<li>
Specification Document(s): <a class='info' href='#Representation'>Section 2<span> (</span><span class='info'>OpenID Connect Token Binding Representation</span><span>)</span></a> of [[ this specification ]]
</li>
</ul><p>
</p>
<a name="DynRegRegistration"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.2"></a><h3>7.2.
OAuth Dynamic Client Registration Metadata Registration</h3>
<p>
This specification registers the following client metadata definition
in the IANA "OAuth Dynamic Client Registration Metadata" registry
<a class='info' href='#IANA.OAuth.Parameters'>[IANA.OAuth.Parameters]<span> (</span><span class='info'>IANA, “OAuth Parameters,” .</span><span>)</span></a>
established by <a class='info' href='#RFC7591'>[RFC7591]<span> (</span><span class='info'>Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, “OAuth 2.0 Dynamic Client Registration Protocol,” July 2015.</span><span>)</span></a>:
</p>
<a name="DynRegContents"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.2.1"></a><h3>7.2.1.
Registry Contents</h3>
<p>
</p>
<ul class="text">
<li>
Client Metadata Name: <tt>rp_id_token_token_binding_supported</tt>
</li>
<li>
Client Metadata Description:
Boolean value specifying whether the Relying Party supports Token Binding of ID Tokens
</li>
<li>
Change Controller: OpenID Foundation Extended Authentication Profile (EAP) Working Group
- openid-specs-eap@lists.openid.net
</li>
<li>
Specification Document(s): <a class='info' href='#RPMetadata'>Section 5.1<span> (</span><span class='info'>Token Binding RP Metadata</span><span>)</span></a> of [[ this specification ]]
</li>
</ul><p>
</p>
<a name="DiscRegistration"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.3"></a><h3>7.3.
OAuth Authorization Server Discovery Metadata Registration</h3>
<p>
This specification registers the following discovery metadata definition
in the IANA "OAuth Authorization Server Discovery Metadata" registry
established by <a class='info' href='#OAuth.Discovery'>[OAuth.Discovery]<span> (</span><span class='info'>Jones, M., Sakimura, N., and J. Bradley, “OAuth 2.0 Discovery,” March 2016.</span><span>)</span></a>:
</p>
<a name="DiscContents"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.3.1"></a><h3>7.3.1.
Registry Contents</h3>
<p>
</p>
<ul class="text">
<li>
Discovery Metadata Name: <tt>op_id_token_token_binding_supported</tt>
</li>
<li>
Discovery Metadata Description:
Boolean value specifying whether the OpenID Provider supports Token Binding of ID Tokens
</li>
<li>
Change Controller: OpenID Foundation Extended Authentication Profile (EAP) Working Group
- openid-specs-eap@lists.openid.net
</li>
<li>
Specification Document(s): <a class='info' href='#OPMetadata'>Section 5.2<span> (</span><span class='info'>Token Binding OP Metadata</span><span>)</span></a> of [[ this specification ]]
</li>
</ul><p>
</p>
<a name="rfc.references"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8"></a><h3>8.
References</h3>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>8.1. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="I-D.ietf-tokbind-https">[I-D.ietf-tokbind-https]</a></td>
<td class="author-text">Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. Hodges, “<a href="http://tools.ietf.org/html/draft-ietf-tokbind-https-03">Token Binding over HTTP</a>,” draft-ietf-tokbind-https-03 (work in progress), March 2016 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-tokbind-https-03.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="I-D.ietf-tokbind-protocol">[I-D.ietf-tokbind-protocol]</a></td>
<td class="author-text">Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. Hodges, “<a href="http://tools.ietf.org/html/draft-ietf-tokbind-protocol-06">The Token Binding Protocol Version 1.0</a>,” draft-ietf-tokbind-protocol-06 (work in progress), May 2016 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-tokbind-protocol-06.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="IANA.JWT.Claims">[IANA.JWT.Claims]</a></td>
<td class="author-text">IANA, “<a href="http://www.iana.org/assignments/jwt">JSON Web Token Claims</a>.”</td></tr>
<tr><td class="author-text" valign="top"><a name="IANA.OAuth.Parameters">[IANA.OAuth.Parameters]</a></td>
<td class="author-text">IANA, “<a href="http://www.iana.org/assignments/oauth-parameters">OAuth Parameters</a>.”</td></tr>
<tr><td class="author-text" valign="top"><a name="JWT">[JWT]</a></td>
<td class="author-text">Jones, M., Bradley, J., and N. Sakimura, “<a href="http://tools.ietf.org/html/rfc7519">JSON Web Token (JWT)</a>,” RFC 7519, DOI 10.17487/RFC7519, May 2015.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Core">[OpenID.Core]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “<a href="http://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core 1.0</a>,” November 2014.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Discovery">[OpenID.Discovery]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., Jones, M., and E. Jay, “<a href="http://openid.net/specs/openid-connect-discovery-1_0.html">OpenID Connect Discovery 1.0</a>,” November 2014.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Registration">[OpenID.Registration]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., and M. Jones, “<a href="http://openid.net/specs/openid-connect-registration-1_0.html">OpenID Connect Dynamic Client Registration 1.0</a>,” November 2014.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text">Bradner, S., “<a href="http://www.rfc-editor.org/info/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC6749">[RFC6749]</a></td>
<td class="author-text">Hardt, D., Ed., “<a href="http://www.rfc-editor.org/info/rfc6749">The OAuth 2.0 Authorization Framework</a>,” RFC 6749, DOI 10.17487/RFC6749, October 2012.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC7230">[RFC7230]</a></td>
<td class="author-text">Fielding, R., Ed. and J. Reschke, Ed., “<a href="http://www.rfc-editor.org/info/rfc7230">Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</a>,” RFC 7230, DOI 10.17487/RFC7230, June 2014.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC7800">[RFC7800]</a></td>
<td class="author-text">Jones, M., Bradley, J., and H. Tschofenig, “<a href="http://www.rfc-editor.org/info/rfc7800">Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)</a>,” RFC 7800, DOI 10.17487/RFC7800, April 2016.</td></tr>
<tr><td class="author-text" valign="top"><a name="SHS">[SHS]</a></td>
<td class="author-text">National Institute of Standards and
Technology, “<a href="http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf">Secure Hash Standard (SHS)</a>,” FIPS PUB 180-4, March 2012 (<a href="http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf">PDF</a>).</td></tr>
</table>
<a name="rfc.references2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>8.2. Informative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="OAuth.Discovery">[OAuth.Discovery]</a></td>
<td class="author-text"><a href="mailto:mbj@microsoft.com">Jones, M.</a>, <a href="mailto:n-sakimura@nri.co.jp">Sakimura, N.</a>, and <a href="mailto:ve7jtb@ve7jtb.com">J. Bradley</a>, “<a href="http://tools.ietf.org/html/draft-ietf-oauth-discovery-02">OAuth 2.0 Discovery</a>,” draft-ietf-oauth-discovery-02 (work in progress), March 2016.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC7591">[RFC7591]</a></td>
<td class="author-text">Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, “<a href="http://www.rfc-editor.org/info/rfc7591">OAuth 2.0 Dynamic Client Registration Protocol</a>,” RFC 7591, DOI 10.17487/RFC7591, July 2015.</td></tr>
</table>
<a name="Acknowledgements"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.A"></a><h3>Appendix A.
Acknowledgements</h3>
<p>
The OpenID Community would like to thank the following people for
their contributions to this specification:
</p>
<p>
</p>
<blockquote class="text">
<p>Dirk Balfanz (balfanz@google.com), Google
</p>
<p>John Bradley (ve7jtb@ve7jtb.com), Ping Identity
</p>
<p>Brian Campbell (bcampbell@pingidentity.com), Ping Identity
</p>
<p>William Denniss (wdenniss@google.com), Google
</p>
<p>Michael B. Jones (mbj@microsoft.com), Microsoft
</p>
<p>Andrei Popov (Andrei.Popov@microsoft.com), Microsoft
</p>
<p>Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute, Ltd.
</p>
</blockquote><p>
</p>
<a name="Notices"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.B"></a><h3>Appendix B.
Notices</h3>
<p>Copyright (c) 2016 The OpenID Foundation.
</p>
<p>The OpenID Foundation (OIDF) grants to any Contributor, developer,
implementer, or other interested party a non-exclusive, royalty free,
worldwide copyright license to reproduce, prepare derivative works from,
distribute, perform and display, this Implementers Draft or Final
Specification solely for the purposes of (i) developing specifications,
and (ii) implementing Implementers Drafts and Final Specifications based
on such documents, provided that attribution be made to the OIDF as the
source of the material, but that such attribution does not indicate an
endorsement by the OIDF.
</p>
<p>The technology described in this specification was made available
from contributions from various sources, including members of the OpenID
Foundation and others. Although the OpenID Foundation has taken steps to
help ensure that the technology is available for distribution, it takes
no position regarding the validity or scope of any intellectual property
or other rights that might be claimed to pertain to the implementation
or use of the technology described in this specification or the extent
to which any license under such rights might or might not be available;
neither does it represent that it has made any independent effort to
identify any such rights. The OpenID Foundation and the contributors to
this specification make no (and hereby expressly disclaim any)
warranties (express, implied, or otherwise), including implied
warranties of merchantability, non-infringement, fitness for a
particular purpose, or title, related to this specification, and the
entire risk as to implementing this specification is assumed by the
implementer. The OpenID Intellectual Property Rights policy requires
contributors to offer a patent promise not to assert certain patent
claims against other contributors and against implementers. The OpenID
Foundation invites any interested party to bring to its attention any
copyrights, patents, patent applications, or other proprietary rights
that may cover technology that may be required to practice this
specification.
</p>
<a name="TBD"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.C"></a><h3>Appendix C.
Open Issues</h3>
<p>
</p>
<ul class="text">
<li>
How should we support crypto agility for the hash function?
</li>
</ul><p>
</p>
<a name="History"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.D"></a><h3>Appendix D.
Document History</h3>
<p>[[ To be removed from the final specification ]]
</p>
<p>
-00
</p>
<ul class="text">
<li>
Created initial version.
</li>
</ul><p>
</p>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Michael B. Jones</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Microsoft</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:mbj@microsoft.com">mbj@microsoft.com</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="http://self-issued.info/">http://self-issued.info/</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">John Bradley</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Ping Identity</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="http://www.thread-safe.com/">http://www.thread-safe.com/</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Brian Campbell</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Ping Identity</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:brian.d.campbell@gmail.com">brian.d.campbell@gmail.com</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="https://twitter.com/__b_c">https://twitter.com/__b_c</a></td></tr>
</table>
</body></html>