<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>OAuth 2.0 POST Response Types </title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
a.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";3
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents"/>
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction"/>
<link href="#rfc.section.1.1" rel="Chapter" title="1.1 Requirements Notation and Conventions"/>
<link href="#rfc.section.2" rel="Chapter" title="2 OAuth Response Types"/>
<link href="#rfc.section.3" rel="Chapter" title="3 POST Response Type"/>
<link href="#rfc.section.4" rel="Chapter" title="4 Registration of POST Adorned Multiple-Valued Response Type Combinations"/>
<link href="#rfc.section.5" rel="Chapter" title="5 IANA Considerations"/>
<link href="#rfc.section.5.1" rel="Chapter" title="5.1 Registry Contents"/>
<link href="#rfc.references" rel="Chapter" title="6 Normative References"/>
<link href="#rfc.appendix.A" rel="Chapter" title="A Acknowledgements"/>
<link href="#rfc.appendix.B" rel="Chapter" title="B Document History"/>
<link href="#rfc.authors" rel="Chapter"/>
<meta name="generator" content="xml2rfc version 2.4.0 - http://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Campbell, B." />
<meta name="dct.identifier" content="urn:ietf:id:oauth-v2-post-response-types-00" />
<meta name="dct.issued" scheme="ISO8601" content="2013-5-13" />
<meta name="dct.abstract" content="This document defines a form auto-submit POST encoding of responses to OAuth 2.0 Authorization Requests (including OpenID Connect requests) as well as several new response types to indicate when the POST encoding is to be used." />
<meta name="description" content="This document defines a form auto-submit POST encoding of responses to OAuth 2.0 Authorization Requests (including OpenID Connect requests) as well as several new response types to indicate when the POST encoding is to be used." />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">Ping Identity Research and Development</td>
<td class="right">B. Campbell</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">Ping Identity</td>
</tr>
<tr>
<td class="left">Intended status: Experimental</td>
<td class="right">May 13, 2013</td>
</tr>
<tr>
<td class="left">Expires: November 14, 2013</td>
<td class="right"></td>
</tr>
</tbody>
</table>
<p class="title">OAuth 2.0 POST Response Types <br />
<span class="filename">oauth-v2-post-response-types-00</span></p>
<h1 id="rfc.abstract">
<a href="#rfc.abstract">Abstract</a>
</h1>
<p>This document defines a form auto-submit POST encoding of responses to OAuth 2.0 Authorization Requests (including OpenID Connect requests) as well as several new response types to indicate when the POST encoding is to be used.</p>
<h1 id="rfc.status">
<a href="#rfc.status">Status of This Memo</a>
</h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
<p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
<p>This Internet-Draft will expire on November 14, 2013.</p>
<h1 id="rfc.copyrightnotice">
<a href="#rfc.copyrightnotice">Copyright Notice</a>
</h1>
<p>Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a></li>
<li>1.1. <a href="#rfc.section.1.1">Requirements Notation and Conventions</a></li>
<li>2. <a href="#rfc.section.2">OAuth Response Types</a></li>
<li>3. <a href="#rfc.section.3">POST Response Type</a></li>
<li>4. <a href="#rfc.section.4">Registration of POST Adorned Multiple-Valued Response Type Combinations</a></li>
<li>5. <a href="#rfc.section.5">IANA Considerations</a></li>
<li>5.1. <a href="#rfc.section.5.1">Registry Contents</a></li>
<li>6. <a href="#rfc.references">Normative References</a></li>
<li>Appendix A. <a href="#rfc.appendix.A">Acknowledgements</a></li>
<li>Appendix B. <a href="#rfc.appendix.B">Document History</a></li>
<li><a href="#rfc.authors">Author's Address</a></li>
</ul>
<h1 id="rfc.section.1"><a href="#rfc.section.1">1.</a> Introduction</h1>
<h1 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1.</a> <a href="#rnc" id="rnc">Requirements Notation and Conventions</a></h1>
<p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a href="#RFC2119">[RFC2119]</a>. It would be really surprising if anyone reads this far in the section after all of the <a href="#RFC2119">[RFC2119]</a> words such as "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", etc., I know I never do.</p>
<h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> OAuth Response Types</h1>
<p id="rfc.section.2.p.1">Section 3.1.1 of <a href="#RFC6749">OAuth 2.0</a> <cite title="NONE">[RFC6749]</cite> defines the <samp>code</samp> and <samp>token</samp> response types and section 8.4 defines an extension mechanism that allows for new response types to be defined and used. The <a href="#OAuth.Responses">OAuth 2.0 Multiple Response Type Encoding Practices</a> <cite title="NONE">[OAuth.Responses]</cite> document utilizes that extension mechanism and defines a number of new OAuth response types in support of a variety of use-cases including OpenID Connect SSO. </p>
<p id="rfc.section.2.p.2">This document builds on the aforementioned specifications to defines new response types and a new response type encoding using HTTP POST.</p>
<h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> POST Response Type</h1>
<p id="rfc.section.3.p.1">This section defines the following new response type response-name in accordance with the ABNF in Section 8.4 of <a href="#RFC6749">OAuth 2.0</a> <cite title="NONE">[RFC6749]</cite>.</p>
<p/>
<dl>
<dt>x_post</dt>
<dd style="margin-left: 8">The <samp>x_post</samp> response-name effectively adorns other response types or multiple-valued response type combinations and indicates that the client wants the response POSTed to it. The <samp>x_post</samp> response-name part SHOULD NOT be used alone but rather in conjunction with other established response-name parts to indicate that the response should be POSTed to the client.</dd>
</dl>
<p id="rfc.section.3.p.3">These response types work by encoding the Access Token Response parameters into HTML form controls that are auto-submitted in the user-agent and thus are transmitted via the HTTP POST method to the client. The action attribute of the form MUST be the client's redirect URI. The method of the form attribute MUST be <samp>POST</samp>.</p>
<p id="rfc.section.3.p.4">Any technique supported by the user agent MAY be used to cause the submission of the form, and any form content necessary to support this MAY be included, such as submit controls and client-side scripting commands. However, the client MUST be able to process the message without regard for the mechanism by which the form submission is initiated.</p>
<h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> Registration of POST Adorned Multiple-Valued Response Type Combinations</h1>
<p id="rfc.section.4.p.1">This section defines and registers combinations of the <samp>x_post</samp> response-name with other previously registered response types. Conceptually <samp>x_post</samp> only qualifies the response type to indicate that HTTP POST form encoding should be used but the nature of the response type extension mechanism mandates that each individual response type be explicitly defined. The following defines the subset of all potential combinations, which provide the most utility (in the ever humble opinion of the author anyway). </p>
<p/>
<dl>
<dt>x_post id_token</dt>
<dd style="margin-left: 8">When supplied as the value for the <samp>response_type</samp> parameter, a successful response MUST include an ID Token as defined in <a href="#OpenID.Messages">OpenID Connect</a> <cite title="NONE">[OpenID.Messages]</cite>. Both successful and error responses SHOULD be form-encoded as described in this document.</dd>
<dt>x_post token</dt>
<dd style="margin-left: 8">When supplied as the value for the <samp>response_type</samp> parameter, a successful response MUST include an Access Token as defined in the OAuth 2.0 specification. Both successful and error responses SHOULD be form-encoded as described in this document.</dd>
<dt>x_post code id_token</dt>
<dd style="margin-left: 8">When supplied as the value for the <samp>response_type</samp> parameter, a successful response MUST include an Authorization Code and an ID Token. Both successful and error responses SHOULD be form-encoded as described in this document.</dd>
<dt>x_post id_token token</dt>
<dd style="margin-left: 8">When supplied as the value for the <samp>response_type</samp> parameter, a successful response MUST include an ID Token and an Access Token. Both successful and error responses SHOULD be form-encoded as described in this document.</dd>
</dl>
<p id="rfc.section.4.p.3">Below is a non-normative request/response/request example as issued/received/issued by the User-Agent (with extra line breaks for display purposes only) demonstrating an auto-submit POST encoded response:</p>
<p id="rfc.section.4.p.4">Authorization Request to the token endpoint at the AS:</p>
<pre>
GET /as/authorization.oauth2?response_type=x_post%20id_token
&client_id=some_client
&scope=openid
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcallback
&state=DcP7csa3hMlvybERqcieLHrRzKBra
&nonce=2T1AgaeRTGTMAJyeDMN9IJbgiUG HTTP/1.1
Host: server.example.com</pre>
<p class="figure"></p>
<p/>
<p id="rfc.section.4.p.6">After authentication and approval by the end-user, the AS issues the Authorization Response:</p>
<pre>HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
<html>
<head><title>Submit This Form</title></head>
<body onload="javascript:document.forms[0].submit()">
<form method="post" action="https://client.example.org/callback">
<input type="hidden" name="state" value="DcP7csa3hMlvybERqcieLHrRzKBra"/>
<input type="hidden" name="id_token" value="eyJhbGciOiJSUzI1NiIsImtpZCI6I
jEifQ.eyJzdWIiOiJqb2huIiwiYXVkIjoiZmZzMiIsImp0aSI6ImhwQUI3RDBNbEo0c2YzVF
R2cllxUkIiLCJpc3MiOiJodHRwczpcL1wvbG9jYWxob3N0OjkwMzEiLCJpYXQiOjEzNjM5MD
MxMTMsImV4cCI6MTM2MzkwMzcxMywibm9uY2UiOiIyVDFBZ2FlUlRHVE1BSnllRE1OOUlKYm
dpVUciLCJhY3IiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYX
Nzd29yZCIsImF1dGhfdGltZSI6MTM2MzkwMDg5NH0.c9emvFayy-YJnO0kxUNQqeAoYu7sjl
yulRSNrru1ySZs2qwqqwwq-Qk7LFd3iGYeUWrfjZkmyXeKKs_OtZ2tI2QQqJpcfrpAuiNuEH
II-_fkIufbGNT_rfHUcY3tGGKxcvZO9uvgKgX9Vs1v04UaCOUfxRjSVlumE6fWGcqXVEKhtP
adj1elk3r4zkoNt9vjUQt9NGdm1OvaZ2ONprCErBbXf1eJb4NW_hnrQ5IKXuNsQ1g9ccT5DM
tZSwgDFwsHMDWMPFGax5Lw6ogjwJ4AQDrhzNCFc0uVAwBBb772-86HpAkGWAKOK-wTC6ErRT
cESRdNRe0iKb47XRXaoz5acA"/>
</form>
</body>
</html>
</pre>
<p class="figure"></p>
<p/>
<p id="rfc.section.4.p.8">Which results in an HTTP POST to the client:</p>
<pre>
POST /callback HTTP/1.1
Host: client.example.org
Content-Type: application/x-www-form-urlencoded
id_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJzdWIiOiJqb2huIiwiYXVkIjoiZmZzM
iIsImp0aSI6ImhwQUI3RDBNbEo0c2YzVFR2cllxUkIiLCJpc3MiOiJodHRwczpcL1wvbG9jYWxob3
N0OjkwMzEiLCJpYXQiOjEzNjM5MDMxMTMsImV4cCI6MTM2MzkwMzcxMywibm9uY2UiOiIyVDFBZ2F
lUlRHVE1BSnllRE1OOUlKYmdpVUciLCJhY3IiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6
YWM6Y2xhc3NlczpQYXNzd29yZCIsImF1dGhfdGltZSI6MTM2MzkwMDg5NH0.c9emvFayy-YJnO0kx
UNQqeAoYu7sjlyulRSNrru1ySZs2qwqqwwq-Qk7LFd3iGYeUWrfjZkmyXeKKs_OtZ2tI2QQqJpcfr
pAuiNuEHII-_fkIufbGNT_rfHUcY3tGGKxcvZO9uvgKgX9Vs1v04UaCOUfxRjSVlumE6fWGcqXVEK
htPadj1elk3r4zkoNt9vjUQt9NGdm1OvaZ2ONprCErBbXf1eJb4NW_hnrQ5IKXuNsQ1g9ccT5DMtZ
SwgDFwsHMDWMPFGax5Lw6ogjwJ4AQDrhzNCFc0uVAwBBb772-86HpAkGWAKOK-wTC6ErRTcESRdNR
e0iKb47XRXaoz5acA&state=DcP7csa3hMlvybERqcieLHrRzKBra
</pre>
<p class="figure"></p>
<p/>
<h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a href="#IANA" id="IANA">IANA Considerations</a></h1>
<p id="rfc.section.5.p.1">This section would register the <samp>response_type</samp> values defined by this specification in the IANA OAuth Authorization Endpoint Response Types registry <a href="#RFC6749">[RFC6749]</a>, if this document is ever considered for standardization. </p>
<h1 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1.</a> Registry Contents</h1>
<p/>
<ul>
<li>Response Type Name: <samp>x_post id_token</samp></li>
<li>Change Controller: [[ me ]]</li>
<li>Specification Document(s): [[ this one ]]</li>
</ul>
<p> </p>
<ul>
<li>Response Type Name: <samp>x_post token</samp></li>
<li>Change Controller: [[ me ]]</li>
<li>Specification Document(s): [[ this one ]]</li>
</ul>
<p> </p>
<ul>
<li>Response Type Name: <samp>x_post code id_token</samp></li>
<li>Change Controller: [[ me ]]</li>
<li>Specification Document(s): [[ this one ]]</li>
</ul>
<p> </p>
<ul>
<li>Response Type Name: <samp>x_post id_token token</samp></li>
<li>Change Controller: [[ me ]]</li>
<li>Specification Document(s): [[ this one ]]</li>
</ul>
<p> </p>
<h1 id="rfc.references"><a href="#rfc.references">6.</a> Normative References</h1>
<table>
<tbody>
<tr>
<td class="reference">
<b id="RFC2119">[RFC2119]</b>
</td>
<td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, "<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, March 1997.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC6749">[RFC6749]</b>
</td>
<td class="top"><a>Hardt, D.</a>, "<a href="http://tools.ietf.org/html/rfc6749">The OAuth 2.0 Authorization Framework</a>", RFC 6749, October 2012.</td>
</tr>
<tr>
<td class="reference">
<b id="OAuth.Responses">[OAuth.Responses]</b>
</td>
<td class="top"><a title="Google">de Medeiros, B.</a>, <a title="Google">Scurtescu, M.</a> and <a title="Facebook">P. Tarjan</a>, "<a>OAuth 2.0 Multiple Response Type Encoding Practices</a>", November 2012.</td>
</tr>
<tr>
<td class="reference">
<b id="OpenID.Messages">[OpenID.Messages]</b>
</td>
<td class="top"><a title="Nomura Research Institute, Ltd.">Sakimura, N.</a>, <a title="Ping Identity">Bradley, J.</a>, <a title="Microsoft">Jones, M.B.</a>, <a title="Google">de Medeiros, B.</a>, <a title="Salesforce">Mortimore, C.</a> and <a title="Illumila">E. Jay</a>, "<a>OpenID Connect Messages 1.0</a>", January 2013.</td>
</tr>
</tbody>
</table>
<h1 id="rfc.appendix.A"><a href="#rfc.appendix.A">Appendix A.</a> Acknowledgements</h1>
<p id="rfc.section.A.p.1">Folks. Lots of folks. But definitely not Paul Madsen.</p>
<h1 id="rfc.appendix.B"><a href="#rfc.appendix.B">Appendix B.</a> Document History</h1>
<p id="rfc.section.B.p.1">[[ To be removed from the final specification ]]</p>
<p id="rfc.section.B.p.2">-00 </p>
<ul>
<li>Initial draft</li>
</ul>
<h1 id="rfc.authors">
<a href="#rfc.authors">Author's Address</a>
</h1>
<div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Brian Campbell</span>
<span class="n hidden">
<span class="family-name">Campbell</span>
</span>
</span>
<span class="org vcardline">Ping Identity Corp.</span>
<span class="adr">
<span class="vcardline">
<span class="locality"></span>
<span class="region"></span>
<span class="code"></span>
</span>
<span class="country-name vcardline"></span>
</span>
<span class="vcardline">EMail: <a href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a></span>
</address>
</div>
</body>
</html>