<!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 Artifact Binding 1.0 - RC2</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Artifact Binding 1.0 - RC2">
<meta name="generator" content="xml2rfc v1.35 (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"> openid-specs-ab@openid.net</td></tr>
<tr><td class="header"> </td><td class="header">September 29, 2010</td></tr>
</table></td></tr></table>
<h1><br />OpenID Artifact Binding 1.0 - RC2</h1>
<h3>Abstract</h3>
<p>OpenID Authentication 2.0 defines the method to move Authentication and associated extension requests among the User, Relying Party, and the OpenID provider through HTTP POST or GET, i.e., it defines the POST and GET binding for OpenID messaging. This specification defines the Artifact Binding that sends the OpenID message directly from the Relying Party to the OpenID Provider and passes only a small reference data called Artifact through the browser so that large payload can be moved between the Relying Party and the OpenID Provider without hitting the browser URL and HTTP header size limitation. It also has value that it is more secure. In addition, by requiring HTTPS for the direct communication, it removed the requirement for symmetric signature on the assertion as well as the DIffie-Hellman association that are required in OpenID Authentication 2.0 (POST/GET binding) making it dramatically simpler to implement. As higher security options, it introduces asymmetric signature and a variable to hold public key of the user so that it can also be used to send holder-of-key assertion. It also optionally encrypts the assertion for end-to-end security which is not always granted by SSL. If the relying party desires, it may also request other type of assertion.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#rnc">1.</a>
Requirements Notation and Conventions<br />
<a href="#terminology">2.</a>
Terminology<br />
<a href="#overview">3.</a>
Protocol Overview<br />
<a href="#parameters">4.</a>
Parameters<br />
<a href="#anchor1">5.</a>
Data Formats<br />
<a href="#oje">5.1.</a>
OpenID JSON Encoding<br />
<a href="#rpf">5.2.</a>
Request File<br />
<a href="#pa">5.3.</a>
Positive Assertion<br />
<a href="#signed_format">5.4.</a>
Signed Format<br />
<a href="#encrypted_format">5.5.</a>
Encryption<br />
<a href="#anchor2">6.</a>
Communication Types<br />
<a href="#anchor3">7.</a>
Common Processing<br />
<a href="#initiation">7.1.</a>
Initiation<br />
<a href="#normalization">7.2.</a>
Normalization<br />
<a href="#discovery">7.3.</a>
Discovery<br />
<a href="#association">7.4.</a>
Association<br />
<a href="#protocol_flows">8.</a>
Protocol Flows<br />
<a href="#rf_prep">8.1.</a>
RP prepares an Request File<br />
<a href="#rurl_create">8.2.</a>
RP Obtains the URL of the Request File<br />
<a href="#art_req">8.3.</a>
RP sends a request to OP via redirect<br />
<a href="#art_res">8.4.</a>
OP Sends the user back to the RP <br />
<a href="#id_req">8.5.</a>
RP requests Assertion directly to the OP<br />
<a href="#id_res">8.6.</a>
RP receives Assertion in the response body<br />
<a href="#veri">8.7.</a>
Verifying Assertion<br />
<a href="#anchor8">8.8.</a>
Signed Assertion<br />
<a href="#enc_ass">8.9.</a>
Encrypted Assertion<br />
<a href="#hok">8.10.</a>
Holder of Key<br />
<a href="#oth_atypes">8.11.</a>
Other assertion types<br />
<a href="#data_req">9.</a>
Accessing the Protected Resource<br />
<a href="#extensions">10.</a>
Extensions<br />
<a href="#security_considerations">11.</a>
Security Considerations<br />
<a href="#assertion_manufacture">11.1.</a>
Assertion manufacture/modification<br />
<a href="#assertion_disclosure">11.2.</a>
Assertion disclosure<br />
<a href="#assertion_repudiation">11.3.</a>
Assertion repudiation<br />
<a href="#assertion_redirect">11.4.</a>
Assertion redirect<br />
<a href="#assertion_reuse">11.5.</a>
Assertion reuse<br />
<a href="#artifact_manufacture">11.6.</a>
Secondary authenticator manufacture<br />
<a href="#artifact_capture">11.7.</a>
Secondary authenticator capture<br />
<a href="#assertion_substitution">11.8.</a>
Assertion substitution<br />
<a href="#auth_req_disclosure">11.9.</a>
Authentication Request Disclosure<br />
<a href="#anchor9">11.10.</a>
Timing Attack<br />
<a href="#authn_proc_threats">11.11.</a>
Authentication Process Threats<br />
<a href="#iana">12.</a>
IANA Considerations<br />
<a href="#oauth_params">12.1.</a>
OAuth Parameters Registry<br />
<a href="#anchor10">Appendix A.</a>
Acknowledgements<br />
<a href="#rfc.references1">13.</a>
Normative References<br />
<a href="#rfc.authors">§</a>
Author's Address<br />
</p>
<br clear="all" />
<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"></a><h3>1.
Requirements Notation and Conventions</h3>
<p>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 class='info' href='#RFC2119'>[RFC2119]<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> .
</p>
<p>Throughout this document, 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.
</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.2"></a><h3>2.
Terminology</h3>
<p>In addition to the terminology used in <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication‑2.0]<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> , following terms are used.
</p>
<p></p>
<blockquote class="text"><dl>
<dt>Artifact</dt>
<dd>An Artifact is a small text associated with the larger payload that identifies the payload.
</dd>
<dt>Base64url</dt>
<dd>Base 64 Encoding <a class='info' href='#RFC3548'>[RFC3548]<span> (</span><span class='info'>Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” July 2003.</span><span>)</span></a> with URL and Filename Safe Alphabet without padding
</dd>
<dt>client identifier</dt>
<dd>An unique identifier that the client to identify itself to the authorization server.
</dd>
<dt>client secret</dt>
<dd>A shared secret established between the authorization server and client.
</dd>
<dt>end-user endpoint </dt>
<dd>The authorization server's HTTP endpoint capable of authenticating the end-user and obtaining authorization.
</dd>
<dt>token endpoint</dt>
<dd>The authorization server's HTTP endpoint capable of issuing tokens.
</dd>
<dt>OP Endpoints</dt>
<dd>end-user endpoint and token endpoint.
</dd>
<dt>RP Endpoints</dt>
<dd>The endpoint to which the OP responses are returned through redirect.
</dd>
<dt>client registration endpoint</dt>
<dd>The authorization server's HTTP endpoint capable of issuing client identifiers and optional client secrets.
</dd>
<dt>request registration endpoint</dt>
<dd>The authorization server's HTTP endpoint capable of registering the request file and return request_url.
</dd>
<dt>user info endpoint</dt>
<dd>A protected resource that when presented with a token by the client returns authorized information about the current user.
</dd>
</dl></blockquote>
<a name="overview"></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.
Protocol Overview</h3>
<p></p>
<ol class="text">
<li>The Relying Party (RP) learns the OpenID Provider Endpoints (OP Endpoints) either out-of-band or through the discovery process defined elsewhere such as <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication‑2.0]<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> . Exact mechanism for the discovery is out of scope of this specification.
</li>
<li>The relying party prepares a file that contains all the request parameters and registered at a 'request_url'. OP may provide the service that allows the RP to register the file and obtain a OP accessible 'request_url' for the request. If the RP is not registered with the OP by then, the RP may register with the OP and obtain 'client_secret'.
</li>
<li>The Relying Party redirects the end user's User-Agent to the end-user endpoint with the 'request_url' to obtain the end-user authorization.
</li>
<li>The OP establishes whether the end user is authorized to perform OpenID Authentication and wishes to do so. The manner in which the end user authenticates to their OP and any policies surrounding such authentication is out of scope for this document.
</li>
<li>The OP redirects the end user's User-Agent back to the RP with 'code' which stands for an Artifact of the Assertion.
</li>
<li>The RP requests the assertion from the token endpoint through direct communication (Direct Assertion Request and Response) through HTTP POST.
</li>
<li>The Relying Party verifies the information received from the OP. If the assertion is signed, the signature MUST be checked first. If the verified claimed_id belongs to the OP's domain, the assertion is deemed valid. Otherwise, a discovery MUST be performed at the 'claimed_id' to make sure that the OP really is delegated authoritatively.
</li>
</ol>
<p>Note that this specification does not use <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication‑2.0]<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> type signature. The message integrity that <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication‑2.0]<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> provides are provided by the TLS/SSL. Thus, in the most basic case, the assertion does not have to be signed at all. On the other hand, the messages MAY be signed using the OP's signing key that supports non-repudiation to mitigate the assertion-repudiation attack.
</p>
<a name="parameters"></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.
Parameters</h3>
<p>Followings are parameters used in this specification. Most of them are specific to a particular profile and optional.
</p>
<p>
</p>
<p></p>
<ul class="text">
<li>ns
<blockquote class="text">
<p>Value: "http://openid.net/specs/ab/1.0". Discovery of the Artifact Binding service is achieved via the mechanism described in <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication‑2.0]<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a>. This namespace SHOULD be listed as an <xrd:Type> child element of the <xrd:Service> element in the XRDS discovery document.
</p>
</blockquote>
</li>
<li>type
<blockquote class="text">
<p>Value: The URI that expresses the class of the JSON message.
</p>
</blockquote>
</li>
<li>id
<blockquote class="text">
<p>Value: Value of type xs:string that identifies the instance of the JSON message.
</p>
</blockquote>
</li>
<li>mode
<blockquote class="text">
<p>Signifies the mode of this request / response.
</p>
<p>Value: "direct_assertion_req" / "direct_req" / "id_res" / "art_req" / "art_res" / "client_associate" / "req_reg" / "req_reg_res"
</p>
</blockquote>
</li>
<li>request_uri
<blockquote class="text">
<p>Value: (OPTIONAL) URL <a class='info' href='#RFC3986'>[RFC3986]<span> (</span><span class='info'>Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.</span><span>)</span></a> of the Request File. Optionally, one can put the SHA256 <a class='info' href='#FIPS180-2'>[FIPS180‑2]<span> (</span><span class='info'>U.S. Department of Commerce and National Institute of Standards and Technology, “Secure Hash Signature Standard,” .</span><span>)</span></a>hash of the file after "#". "#" MUST be escaped.
</p>
</blockquote>
</li>
<li>refresh_uri
<blockquote class="text">
<p>Value: (OPTIONAL) URL <a class='info' href='#RFC3986'>[RFC3986]<span> (</span><span class='info'>Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.</span><span>)</span></a> of the Assertion Refresh Endpoint, from which client can obtain the refreshed assertion. The presence of this parameter in the assertion indicates that the permission was granted by the user to refresh the assertion.
</p>
</blockquote>
</li>
<li>code
<blockquote class="text">
<p>Value: A unique short string less than 400 characters, also known as "Artifact".
</p>
</blockquote>
</li>
</ul>
<p></p>
<ul class="text">
<li>op_endpoint
<blockquote class="text">
<p>Value: The OP Endpoint URL.
</p>
</blockquote>
</li>
</ul>
<p></p>
<ul class="text">
<li>claimed_id
<blockquote class="text">
<p>Value: An URI that corresponds to the user in question. The value in the request is either user supplied identifier or the string "http://specs.openid.net/auth/2.0/identifier_select" which tells the OP to chose the identifier that belongs to the user.
</p>
<p>Type: A String of type xs:AnyURI.
</p>
</blockquote>
</li>
<li>identity
<blockquote class="text">
<p>Value: The OP-Local Identifier, an identifier that corresponds to the user's Local Identifier at the OP. If a different OP-Local Identifier is not specified, the claimed identifier MUST be used as the value for identity.
</p>
</blockquote>
</li>
<li>user_id
<blockquote class="text">
<p>Value: A unique HTTPS URI of the currently signed in user, from which one may obtain profile data.
</p>
</blockquote>
</li>
<li>redirect_uri
<blockquote class="text">
<p>Value: URL to which the OP SHOULD return the User-Agent with the response indicating the status of the art_res.
</p>
<p>If this value is not sent in the request it signifies that the Relying Party does not wish for the end user to be returned. It used to be "return_to" in the OpenID 2.0. "return_to" MUST NOT be used.
</p>
</blockquote>
</li>
<li>client_id
<blockquote class="text">
<p>Value: A unique identifier issued to the client to identify itself. It MUST be the domain name of the RP or the URL assigned by the party that the OP trusts. It SHOULD be the URL from which the metadata about this entity can be obtained.
</p>
</blockquote>
</li>
<li>server_id
<blockquote class="text">
<p>Value: A unique identifier that identifies the OP. It SHOULD be the URL that the metadata about this entity can be obtained.
</p>
</blockquote>
</li>
<li>client_secret
<blockquote class="text">
<p>Value: A token of type xs:String that can be used by the OP to identify and authenticate the RP.
</p>
</blockquote>
</li>
<li>immediate
<blockquote class="text">
<p>Value: (OPTIONAL) "true" or "false". If set to "true", the authorization server MUST NOT prompt the end-user to process the request. If the OP does not support an immediate check or if it is unable to establish the end-user's identity or approval status, it MUST deny the request without prompting the end-user. Defaults to "false" if omitted. It overrides what was expressed in the request file.
</p>
</blockquote>
</li>
<li>pubkey
<blockquote class="text">
<p>Value: Base64url encoded DER format X.509 Certificate without private key. (<a class='info' href='#RFC1421'>RFC1421<span> (</span><span class='info'>Linn, J., “Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures,” February 1993.</span><span>)</span></a> [RFC1421] - <a class='info' href='#RFC1424'>RFC1424<span> (</span><span class='info'>Kaliski, B., “Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services,” February 1993.</span><span>)</span></a> [RFC1424]) Format.
</p>
</blockquote>
</li>
<li>certs_uri
<blockquote class="text">
<p>Value: A URL from which one can retrieve PEM format X.509 certificate. One may add the sha256 hash of the content as a fragment to signify if the file has changed.
</p>
</blockquote>
</li>
<li>certs_uri_alt
<blockquote class="text">
<p>Value: Alternative 'certs_uri'. If it is specified, this URL SHOULD be checked in the event of certs_uri failing.
</p>
</blockquote>
</li>
<li>state
<blockquote class="text">
<p>Value: (OPTIONAL) An opaque value used by the RP to maintain state between the request and callback. The OP includes this value when redirecting the user-agent back to the client.
</p>
</blockquote>
</li>
<li>code
<blockquote class="text">
<p>Value: The Artifact value corresponding to the Assertion is created. The Artifact value MUST include the string constructed from a cryptographically strong random or pseudorandom number sequence <a class='info' href='#RFC1750'>RFC1750<span> (</span><span class='info'>Eastlake, D., Crocker, S., and J. Schiller, “Randomness Recommendations for Security,” December 1994.</span><span>)</span></a> [RFC1750] generated by the OP.
</p>
<p>If the <a class='info' href='#rpf'>Request File<span> (</span><span class='info'>Request File</span><span>)</span></a> was invalid, it MUST be a string "INVALID".
</p>
</blockquote>
</li>
<li>atype
<blockquote class="text">
<p>Value: Type of assertion to be returned at the end. Values are one of the following: </p>
<ul class="text">
<li>openid2json : (Default) OpenID Artifact Binding's default assertion format, which is JSON.
</li>
<li>openid2jsonp : openid2json wrapped in "openidjsonp();" so that it will be a JSONP format.
</li>
<li>openid2json-enc: openid2json assertion encrypted.
</li>
<li>saml2: SAML ver.2 assertion.
</li>
<li>wss : WS-Security assertion.
</li>
</ul>
</blockquote>
</li>
<li>proofkey
<blockquote class="text">
<p>Value: X.509 public key certificate presented by the user to the OP during authentication.
</p>
</blockquote>
</li>
</ul>
<p></p>
<ul class="text">
<li>response_type
<blockquote class="text">
<p>Value: The requested response: an access token, an authorization code, or both. The parameter value MUST be set to "<tt>token</tt>" for requesting an access token, "<tt>code</tt>" for requesting an authorization code, or "<tt>code_and_token</tt>" to request both. The authorization server MAY decline to provide one or more of these response types.
</p>
</blockquote>
</li>
<li>grant_type
<blockquote class="text">
<p>Value: The access grant type included in the request. Value MUST be one of "authorization_code", "password", "assertion", "refresh_token", or "none".
</p>
</blockquote>
</li>
<li>access_token
<blockquote class="text">
<p>Value: The access token issued by the OP. The Authorization header field uses the framework defined by <a class='info' href='#RFC2617'>RFC2617<span> (</span><span class='info'>Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</span><span>)</span></a> [RFC2617]
</p>
</blockquote>
</li>
<li>access_token_secret
<blockquote class="text">
<p>Value: The corresponding access token secret as requested by the client.
</p>
</blockquote>
</li>
<li>issued_at
<blockquote class="text">
<p>Value: A unix timestamp of when this signature was created.
</p>
</blockquote>
</li>
<li>expires_in
<blockquote class="text">
<p>Value: The duration in seconds of the access token lifetime.
</p>
</blockquote>
</li>
<li>refresh_token
<blockquote class="text">
<p>Value: The refresh token used to obtain new access tokens using the same end user access grant as described in Section 4.
</p>
</blockquote>
</li>
</ul>
<p>
</p>
<a name="anchor1"></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.
Data Formats</h3>
<p>
</p>
<a name="oje"></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.
OpenID JSON Encoding</h3>
<p>Key-Value form encoding is a special file format defined in defined in <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication‑2.0]<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> section 4. It is used as a direct response in this specification. It SHOULD only contain the OpenID parameters. OpenID JSON Encoding is the embodiment of Key-Value form encoding parameters in JSON. The parameters are serialized into a JSON object as a sequence of name/value pairs. The JSON object is represented as the value of the "openid" name.
</p>
<p>Following is a non-normative example. </p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"openid": {
"type": "http://openid.net/specs/ab/1.0#req",
"mode": "direct_req",
"redirect_uri": "https://example.com/rp/endpoint_url"
}
}
</pre></div><p>
</p>
<a name="rpf"></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.
Request File</h3>
<p>Request File is a UTF-8<a class='info' href='#RFC3629'>[RFC3629]<span> (</span><span class='info'>Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.</span><span>)</span></a> <a class='info' href='#RFC4627'>JSON<span> (</span><span class='info'>Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.</span><span>)</span></a> [RFC4627] format file that captures the parameters that the RP would like to send to the OP to obtain an artifact.
</p>
<p>Following is the list of OpenID variables are to be sent under the key "openid":
</p>
<p></p>
<ul class="text">
<li>type - "http://openid.net/specs/ab/1.0#req"
</li>
<li>immediate - (OPTIONAL) "True" or "False". Default is "False".
</li>
<li>claimed_id - (OPTIONAL) The claimed_id as in <a class='info' href='#OpenID.authentication-2.0'>OpenID 2.0<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> [OpenID.authentication‑2.0]
</li>
<li>identity - (OPTIONAL) The local id as in OpenID 2.0.
</li>
<li>server_id - (OPTIONAL) The intended recipient of this request.
</li>
<li>pubkey - (OPTIONAL) The base64url encoded DER format X.509 certificate of the RP.
</li>
</ul><p>Note that these are to be serialized into JSON and then represented as a value of the key "openid".
</p>
<p>Following is the list of variables to be sent as the top level keys:
</p>
<p></p>
<ul class="text">
<li>response_type - value: "code".
</li>
<li>client_id - The client identifier recognized by the authorization server.
</li>
<li>redirect_uri - The absolute URI to which the OP asks the User-Agent to come back with an artifact ("code").
</li>
<li>scope - value: "openid".
</li>
<li>state - OPTIONAL.
</li>
</ul>
<p>Following is a non-normative example.
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"type": "http://openid.net/specs/ab/1.0#env,
"openid": {
"type": "http://openid.net/specs/ab/1.0#req",
"server_id": "http://example.com/op/",
"immediate": "true",
"claimed_id":"http://specs.openid.net/auth/2.0/identifier_select",
"identity": "http://specs.openid.net/auth/2.0/identifier_select",
"ns.ax": "http://openid.net/srv/ax/1.0",
"ax.mode": "fetch_request",
"ax.type.fname": "http://example.com/schema/fullname",
"ax.type.gender": "http://example.com/schema/gender",
"ax.required": "fname,gender"
},
"redirect_uri": "https://example.com/rp/endpoint_url",
"response_type":"code",
"cliend_id": "http://example.com/rp/",
"scope": "openid",
"state": "af0ifjsldkj"
}
</pre></div><p>
</p>
<a name="pa"></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.3"></a><h3>5.3.
Positive Assertion</h3>
<p>Positive Assertion is a set of data that an OP sends out to the RP on successful Authentication. The default format is the <a class='info' href='#oje'>Section 5.1<span> (</span><span class='info'>OpenID JSON Encoding</span><span>)</span></a> .
</p>
<p>Following is the list of variables to be included under the key "openid".
</p>
<p></p>
<ul class="text">
<li>type - "http://openid.net/specs/ab/1.0#id_res"
</li>
<li>mode - "id_res"
</li>
<li>op_endpoint - OP Endpoint URL from which this assertion was returned.
</li>
<li>cilent_id - The RP's unique identifier.
</li>
<li>server_id - The Server's unique identifier
</li>
<li>claimed_id - The verified identifier of this user.
</li>
<li>identity - The Local ID that this user was verified against.
</li>
<li>user_id - (OPTIONAL) A unique HTTPS URI of the currently signed in user.
</li>
<li>issued_at - A unix timestamp of when this signature was created.
</li>
</ul><p>Any other extension and other variables can be included.
</p>
<p>Following is the list of variables to be included at the top level.
</p>
<p></p>
<ul class="text">
<li>access_token - The access token issued by the authorization server.
</li>
<li>state - REQUIRED if the state parameter was present in the client authorization request. Set to the exact value received from the client.
</li>
</ul>
<p>Following is a non-normative example.
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"openid": {
"type": "http://openid.net/specs/ab/1.0#id_res",
"mode": "id_res",
"op_endpoint": "https://op.example.com/op_endpoint",
"client_id": "http://rp.example.com/",
"server_id": "http://op.example.com/",
"claimed_id": "https://example.com/alice#1234",
"identity": "alice",
"issued_at": 1274889460,
"ax.mode": "fetch_response",
"ax.type.fname": "http://example.com/schema/fullname",
"ax.fanme.value": "John Doe",
"ax.type.gender": "http://example.com/schema/gender",
"ax.gender.value": "M",
"ax.required": "fname,gender"
}
}
</pre></div><p>
</p>
<a name="signed_format"></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.4"></a><h3>5.4.
Signed Format</h3>
<p>Artifact Binding does not use symmetric signature as it adds no value over the mandatory TLS connection to the OP.
</p>
<p>To mitigate assertion repudiation attack, the assertion may be digitally signed by the OP using a key that supports non-repudiation as in <a class='info' href='#json_sig'>JSON Simple Sign<span> (</span><span class='info'>Bradeley, J. and N. Sakimura, “JSON Simple Sign,” September 2010.</span><span>)</span></a> [json_sig] where parameters are as follows.
</p>
<p></p>
<blockquote class="text">
<p>"type":"http://openid.net/specs/ab/1.0#signed_format"
</p>
<p>"data_type":"application/json"
</p>
<p>"data":base64url encoded JSON representation of the assertion.
</p>
<p>"algorithm":"RSA-SHA256"
</p>
</blockquote>
<p>Following is the non-normative illustration of a signed response. (Note: Line wraps in the values are only for the display purpose. New lines MUST be escaped in JSON values.)</p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"type": "http://openid.net/specs/ab/1.0#signed_format",
"data_type": "application/json",
"data": "eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsIjAiOiJwYXlsb2FkIn0",
"sigs": [
{
"signature": "vlXgu64BQGFSQrY0ZcJBZASMvYvTHu9GQ0YM9rjPSso",
"certs_uri": "https://example.com/mycerts.pem"
}
]
}
</pre></div><p>
</p>
<a name="encrypted_format"></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.5"></a><h3>5.5.
Encryption</h3>
<p>In the response, the payload may be encrypted by RP's public key for additional security. If it is encrypted, the data is formatted as <a class='info' href='#json_enc'>JSON Encryption Envelope<span> (</span><span class='info'>Bradeley, J. and N. Sakimura, “JSON Simple Encryption,” September 2010.</span><span>)</span></a> [json_enc]. The following parameter MUST be set as follows:
</p>
<p></p>
<ul class="text">
<li>data_type - "http://openid.net/specs/ab/1.0#openid2json-enc"
</li>
</ul><p>Following is a non-normative example of encrypted payload.
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"type":"http://jsonenc.info/json-encryption/1.0/",
"data_type":"http://openid.net/specs/ab/1.0#openid2json-enc",
"enc_data":"b5guwzFgvrIUd7XcXI0bAFrg-....O69VKhY",
"enc_type_asy":"http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p",
"enc_type":"http://www.w3.org/2001/04/xmlenc#aes256-cbc",
"enc_key":"mHM2ongmZlPVexe....2lsBNdw",
"enc_iv":"_b4INfYIRwLPZdxB2L7wJg",
"enc_ref":"https://rp.example.com/certs.pem",
"enc_thumbprint":"511e7a9cfe5eda16fa70f553c2dfa3c473e06423"
}
</pre></div><p>
</p>
<a name="anchor2"></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.
Communication Types</h3>
<p>Communication Types are the same as in <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication‑2.0]<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> section 5 apart from the fact that we call "indirect" in the above as "redirect" to avoid confusion in the terminology used at NIST SP800-63. In addition to those defined, the Artifact Binding uses Direct Communication for sending and receiving authentication message. All Direct Communication MUST be over SSL/TLS encrypted channel.
</p>
<a name="anchor3"></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.
Common Processing</h3>
<p>There are certain processing that are common to all usage patterns, namely, Initiation, Normalization, and Discovery. Steps are as follows:
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>User->UA: Click Login
UA->RP: Login with identifier
RP->RP: Normalize identifier
RP->OP: Get XRDS
RP->RP: Find OP Endpoint</pre></div><p>
</p>
<a name="initiation"></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.
Initiation</h3>
<p>Initiation is done as in <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication‑2.0]<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a>
</p>
<p>Following is the non-normative explanation of the process.
</p>
<p>To initiate OpenID Authentication, the Relying Party SHOULD present the end user with a form that has a field for entering a User-Supplied Identifier.
</p>
<p>The form field's "name" attribute SHOULD have the value "openid_identifier", so that User-Agents can automatically determine that this is an OpenID form. Browser extensions or other software that support OpenID Authentication may not detect a Relying Party's support if this attribute is not set appropriately.
</p>
<a name="normalization"></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.
Normalization</h3>
<p>Normalization is done as in <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication‑2.0]<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> Following is a non-normative, simplified explanation of the Normalization process.
</p>
<p></p>
<ol class="text">
<li>If the user supplied identifier string starts with "xri://", strip it.
</li>
<li>If the user supplied identifier string starts with "=", "@", "+", "$", "!", or "(", add https://xri.net/ to the string.
</li>
<li>If the user supplied identifier string does not start yet with "http://" or "https://", add "http://".
</li>
<li>If the user supplied identifier starts with http:// or https:// do nothing.
</li>
</ol>
<a name="discovery"></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.
Discovery</h3>
<p>Discovery is the process where the Relying Party uses the Identifier to look up ("discover") the necessary information for initiating requests, especially the OP Endpoint. When OP Endpoint and other meta-data is known out of band, discovery is unnecessary. Discovery should be performed as in Section 7.3 of <a class='info' href='#OpenID.authentication-2.0'>OpenID Authentication 2.0<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> [OpenID.authentication‑2.0] .
</p>
<p>Optionally, if the RP does not wish to use RSA signature to authenticate itself, RP may obtain the secret dynamically in the following manner.
</p>
<a name="association"></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.4"></a><h3>7.4.
Association</h3>
<p>In Artifact Binding, the OP endpoint MUST be HTTPS endpoint. Therefore, the symmetric signature between the servers that were used in <a class='info' href='#OpenID.authentication-2.0'>OpenID Authentication 2.0 (POST/GET binding)<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> [OpenID.authentication‑2.0] is unnecessary. Instead, for the RP authentication against the OP, 'client_secret' is used. The 'client_secret' is either the bearer token assigned by the OP or the RSA signature, which will be discussed later.
</p>
<a name="bearer_secret"></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.4.1"></a><h3>7.4.1.
Obtaining bearer token 'client_secret'</h3>
<p>If the RP opted for the bearer token (note: in this mode, there will be no possibility of non-repudiation of the request), then RP must somehow obtain the secret. This can be achieved in the following manner.
</p>
<p>Issue HTTPS "POST" <a class='info' href='#RFC2616'>[RFC2616]<span> (</span><span class='info'>Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.</span><span>)</span></a>request to the Client Regsitration Endpoint with the following REQUIRED parameters:
</p>
<p></p>
<ul class="text">
<li>type - "push"
</li>
<li>client_name - A human-readable name of the client.
</li>
<li>client_uri - The URL of the homepage of the client.
</li>
<li>client_desc - A text description of the client.
</li>
<li>client_icon - OPTIONAL. A URL for an icon for the client. As Most OP will display an AuthN/AuthZ page on HTTPS, the client_icon which RP registers should have HTTPS URL.
</li>
<li>redirect_uri - The URL to which the OP should send its response.
</li>
</ul>
<p>The client MAY include additional metadata in the request and the authorization server MAY ignore this additional information.
</p>
<p>
<p>Following is a non-normative example of such request.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre> POST /register HTTP/1.1
Host: server.example.com
Content-Type: application/json
{
type: "push",
client_name: "Online Photo Gallery",
client_uri: "http://onlinephotogallery.com",
client_desc: "Not only uploading, but also editing capabilities!",
client_icon: "http://onlinephotogallery.com/icon.png",
redirect_uri: "https://onlinephotogallery.com/client_reg"
}
</pre></div>
<p>
</p>
<p>If the redirect_uri was not pre-registered out-of-band, then he server should issue the following response parameters in JSON format.
</p>
<p></p>
<ul class="text">
<li>client_id
</li>
<li>client_secret
</li>
<li>server_id - OPTIONAL. Specifies the URI that represents the server.
</li>
<li>issued_at - OPTIONAL. Specifies the timestamp when the identifier was issued. The timestamp value MUST be a positive integer. The value is expressed in the number of seconds since January 1, 1970 00:00:00 GMT.
</li>
<li>expires_in - OPTIONAL; if supplied, the issued_at parameter is REQUIRED. Specifies the valid lifetime, in seconds, of the identifier. The value is represented in base 10 ASCII.
</li>
</ul><p>The parameters are included in the entity body of the HTTP response using the "application/json" media type as defined by <a class='info' href='#RFC4627'>JSON<span> (</span><span class='info'>Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.</span><span>)</span></a> [RFC4627]. The parameters are serialized into a JSON structure by adding each parameter at the highest structure level. Parameter names and string values are included as JSON strings.
</p>
<p>The authorization server MUST include the HTTP Cache-Control response header field with a value of no-store in any response containing client_secret.
</p>
<p>
<p>Following is a non-normative example of such response.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
client_id: "5UO9XcL4TQTa",
client_secret: "WdRKN3zeTc20"
}
</pre></div>
<p>If the request for registration is invalid or unauthorized, the authorization server constructs the response by adding the following parameters to the entity body of the HTTP response with a 400 status code (Bad Request) using the “application/json” media type:
</p>
<p></p>
<ul class="text">
<li>error
</li>
<li>description - OPTIONAL.
</li>
</ul>
<p><p>Following is a non-normative example of such response. Note that the line wraps are for display purpose only.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
{
"error": "unauthorized_client",
"description": "This client is not on the
white list of this Authorization Server"
}</pre></div>
<p>
</p>
<a name="pubkey_exchange"></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.4.2"></a><h3>7.4.2.
Exchanging the public key</h3>
<p>If the OP desires evidential quality / non-repudiation possibility of the request from the RP through public key cryptography, then it MUST use the RSA signature mode or EC-DSA signature mode. Unless the OP has the public key by some out-of-band mechanism, the RP MUST send its Public Key as described in <a class='info' href='#json_sig'>JSON Simple Sign<span> (</span><span class='info'>Bradeley, J. and N. Sakimura, “JSON Simple Sign,” September 2010.</span><span>)</span></a> [json_sig].
</p>
<p>If the RP desires evidential quality / non-repudiation possibility of the response from the OP thorugh public key cryptography, then it MUST use the RSA signature mode or EC-DSA signature mode. Unless the RP has the public key of the OP by some out-of-band mechanism, the OP MUST send its Public Key as described in <a class='info' href='#json_sig'>JSON Simple Sign<span> (</span><span class='info'>Bradeley, J. and N. Sakimura, “JSON Simple Sign,” September 2010.</span><span>)</span></a> [json_sig].
</p>
<p>
</p>
<a name="protocol_flows"></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.
Protocol Flows</h3>
<p>All steps in the following profiles are preceded by the common processing. The assertion returned may vary in the following five ways depending on the security characteristics that RP wishes to have.
</p>
<p></p>
<ol class="text">
<li>Plain Text Assertion.
</li>
<li>Signed Assertion.
</li>
<li>Signed and Encrypted Assertion.
</li>
<li>Holder of Key
</li>
<li>Other Assertion Types
</li>
</ol>
<a name="rf_prep"></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.1"></a><h3>8.1.
RP prepares an Request File</h3>
<p>The RP prepares a static file with a globally reachable URL. Optionally, it may contain other extension parameters. It MAY be signed as in <a class='info' href='#signed_format'>Section 5.4<span> (</span><span class='info'>Signed Format</span><span>)</span></a>
</p>
<a name="rurl_create"></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.2"></a><h3>8.2.
RP Obtains the URL of the Request File</h3>
<p>RP then records the Request File either locally or remotely and obtains the URL, "request_url". The URL MUST be accessible from the OP.
</p>
<p>Optionally, an OP may provide the Request File registration service at the request registration endpoint. This is especially useful for the cases such as the RP is behind the firewall or lives on a client device that cannot be accessed from the OP.
</p>
<p>When an OP provides the Request File registration service, it SHOULD publish the registration endpoint in the XRDS where the <Type> is "http://openid.net/specs/ab/1.0#request_regist" or in the XRD where "rel" is "http://openid.net/specs/ab/1.0#request_regist".
</p>
<p>To register the Request File, the following parameters are sent as HTTPS POST request to the request registration endpoint as query parameters.
</p>
<p></p>
<ul class="text">
<li>request - The Base64url encoded JSON request file.
</li>
<li>client_secret - (OPTIONAL) client secret assigned to the RP.
</li>
</ul>
<p>Following is a non-normative example of such request.
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>POST /rfstore HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
request=wfjsil2wjf...awQfs_w&client_secret=very_secure_secret</pre></div><p>
</p>
<p>If the request is valid, the OP returns the following variables as the OpenID JSON in the HTTP response body using the “application/json” media type:
</p>
<p></p>
<ul class="text">
<li>type - "http://openid.net/specs/ab/1.0#req_req_res"
</li>
<li>request_url - The request URL that corresponds to the request file.
</li>
</ul>
<p>It should be noted that if the Request File includes user's attribute values, it MUST NOT be revealed to anybody but the OP before the user's authentication and authorization. As such, the request_url MUST have larger entropy than the user authentication credential.
</p>
<p>Following is a non-normative example of the response.
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"type":"http://openid.net/specs/ab/1.0#req_req_res",
"request_url":"http://example.com/op/request_url_wfjdokaosidu"
}
</pre></div><p>
</p>
<a name="art_req"></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.3"></a><h3>8.3.
RP sends a request to OP via redirect</h3>
<p>When the user wishes to access an RP resource, and the user is not yet authorized to do so, the RP sends the user to the OP Endpoint through the HTTP 302 redirect with the following parameters. The entire URL MUST NOT exceed 512 bytes.
</p>
<p></p>
<ul class="text">
<li>response_type - "code"
</li>
<li>request_url - The URL of the Request File.
</li>
<li>immediate - (OPTIONAL) "true" or "false". Used to override what was written in the Request File.
</li>
<li>claimed_id - (OPTIONAL) claimed_id MAY be sent as flow parameter to override what is written in the Request File.
</li>
<li>state - (OPTIONAL) An opaque value used by the RP to maintain state between the request and callback. If provided, the OP MUST include this value when redirecting the user-agent back to the RP. RPs are strongly advised to use this variable to relate the request and response.
</li>
</ul><p>Following is a non-normative example. Note: Line wraps are for display purpose only.
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found
Location: https://rp.example.com/rp.php?response_type=code
&request_uri=https://rp.example.com/rf.js%23Qfsoe2F
</pre></div><p>
</p>
<a name="art_res"></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.4"></a><h3>8.4.
OP Sends the user back to the RP </h3>
<p>Upon receipt of the Request, the OP MUST send a GET request to the 'request_url' to retrieve the content and parse it to recreate the request parameters. Once this is done, the OP MUST determine that an authorized end user wishes to complete the authentication in the manner described in Section 10 of the <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication‑2.0]<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> . Once it is determined, the OP creates either positive or negative assertion and associated artifact and returns the response to the RP Endpoint specified in "redirect_uri" URL specified in <a class='info' href='#rpf'>Section 5.2<span> (</span><span class='info'>Request File</span><span>)</span></a> with following parameters respectively in the follwing cases:
</p>
<a name="authz_ok"></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.4.1"></a><h3>8.4.1.
End-user Grants Authorization</h3>
<p></p>
<ul class="text">
<li>code - The artifact Value.
</li>
<li>state - Set to the exact value received from the RP.
</li>
<li>server_id - The Server Identifier.
</li>
</ul><p>No other parameter SHOULD be returned. The entire URL MUST NOT exceed 512 bytes.
</p>
<p>Following is a non-normative example. Line wraps after the second line is for the display purpose only.
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found
Location: https://rp.example.com/rp.php?
&code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
</pre></div><p>
</p>
<a name="authz_error"></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.4.2"></a><h3>8.4.2.
End-user Denies Authorization or Invalid Request FIle</h3>
<p></p>
<ul class="text">
<li>error - A single error code as described below.
</li>
<li>request_url - Set to the exact value received from the RP.
</li>
<li>state - Set to the exact value received from the RP.
</li>
</ul><p>No other parameter SHOULD be returned. The entire URL MUST NOT exceed 512 bytes.
</p>
<p>Error codes are as follows:
</p>
<p></p>
<ul class="text">
<li>invalid_request - The request is missing a required parameter, includes an unsupported parameter or parameter value, or is otherwise malformed.
</li>
<li>invalid_client - The client identifier provided is invalid. unauthorized_client The client is not authorized to use the requested response type.
</li>
<li>redirect_uri_mismatch - The redirection URI provided does not match a pre-registered value.
</li>
<li>access_denied - The end-user or authorization server denied the request.
</li>
<li>unsupported_response_type - The requested response type is not supported by the authorization server.
</li>
<li>invalid_scope - The requested scope is invalid, unknown, or malformed.
</li>
<li>setup_needed - "immediate" request denied so that the user interaction was required.
</li>
</ul><p>Following is a non-normative example. Line wraps after the second line is for the display purpose only.
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found
Location: https://openid4.us/rp/rp.php?
&error=setup_needed
&request_url=https%3A%2F%2Frp.example.com%2Frpf.json</pre></div><p>
</p>
<a name="id_req"></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.5"></a><h3>8.5.
RP requests Assertion directly to the OP</h3>
<p>To obtain the assertion, the RP makes a direct request to the Token Endpoint. The RP may authenticate against the OP depending on the level of assurance desired. There are two ways of authentication, namely:
</p>
<p></p>
<ol class="text">
<li>Through the use of client_secret
</li>
<li>Through the use of asymmetric signature
</li>
</ol><p>Added benefit of using asymmetric signature are as follows:
</p>
<p></p>
<ol class="text">
<li>One can achieve the non-repudiation of the request
</li>
<li>One do not need to have association or dynamic association
</li>
<li>OP does not need to keep the state on each and every RP
</li>
</ol>
<p>The asymmetric signature based "client_secret" can be created as follows:
</p>
<p></p>
<ol class="text">
<li>Apply JSON Simple Sign to 'code'. Use Web Token serialization.
</li>
</ol>
<a name="anchor4"></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.5.1"></a><h3>8.5.1.
Requesting Assertion using the Artifact</h3>
<p>To obtain the assertion, send the following parameters via HTTPS POST to the token endpoint using the application/x-www-form-urlencoded format in the HTTP request entity-body:
</p>
<p></p>
<ul class="text">
<li>grant_type - "authorization_code"
</li>
<li>code - The artifact received
</li>
<li>client_id - The client_id of the RP
</li>
<li>client_secret - (OPTIONAL) If the secret_type is "shared", send the pre-shared secret. If the secret_type is "jsst", send the Web Token serealization of the JSON Simple Sign over the 'code'.
</li>
<li>secret_type - (OPTIONAL) "shared" or "jsst". Required if "client_secret" was used.
</li>
</ul><p>The following is a non-normative example. Line wraps are for display purpose only.
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=_artifact_received_
&client_id=https%3A%2F%2Frp.example.com%2Frpf.json
&client_secret=1234qwer&secret_type=shared</pre></div><p>
</p>
<a name="anchor5"></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.5.2"></a><h3>8.5.2.
Requesting Assertion using the Assertion</h3>
<p>To obtain the assertion, send the following parameters via HTTPS POST to the token endpoint using the application/x-www-form-urlencoded format in the HTTP request entity-body:
</p>
<p></p>
<ul class="text">
<li>grant_type - "assertion"
</li>
<li>assertion_type - "http://openid.net/specs/ab/1.0/"
</li>
<li>assertion - Web Token Serialization of the signed assertion previously received. For higher security, the client should add its signature to the assertion.
</li>
</ul><p>The following is a non-normative example. Line wraps are for display purpose only.
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=assertion&
assertion_type=http%3A%2F%2Fopenid.net%2Fspecs%2Fab%2F1.0%2F&
assertion=PHNhbWxwOl...[omitted for brevity]...ZT4%3D
</pre></div><p>
</p>
<p>Upon receipt of the request, the server MUST verify the validity of the signatures. Note that the server_id must be itself or the OP that the receiving server trust as the user's authorization endpoint. If the client added its signature, the server MUST verify that the signature is that of the client with "client_id" stated in the assertion.
</p>
<a name="id_res"></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.6"></a><h3>8.6.
RP receives Assertion in the response body</h3>
<p>Upon receipt of the Direct Assertion Request, OP MUST return either Positive or Negative Assertion that corresponds to the received Artifact "code".
</p>
<a name="anchor6"></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.6.1"></a><h3>8.6.1.
Positive Assertion</h3>
<p>Positive Assertion can only be returned once for the artifact and contains the following variables under the key "openid".
</p>
<p></p>
<ul class="text">
<li>type - "http://openid.net/specs/ab/1.0#id_res"
</li>
<li>server_id - The identifier of the OP.
</li>
<li>pubkey - OPTIONAL. The OP's X.509 certificate in DER format which is base64url encoded.
</li>
<li>client_certs - OPTIONAL. The client's X.509 certificate in DER format which is base64url encoded.
</li>
<li>client_certs_uri - OPTIONAL. The URL of the client's X.509 certificate in PEM format.
</li>
<li>request_url - The exact request_url URL that the OP received from the RP.
</li>
<li>op_endpoint - The OP Endpoint URL.
</li>
<li>claimed_id - The claimed_id that the OP recognizes as linked to the Local ID, "identity".
</li>
<li>identity - The Local ID that was verified by the OP.
</li>
<li>cileint_id - The identifier of the requesting RP that OP recognized.
</li>
<li>user_id - A unique persistent HTTPS URI of the currently signed in user. e.g. "https://op.example.com/a3flsjeow1234"
</li>
<li>issued_at - A unix timestamp of when this signature was created.
</li>
</ul><p>Any other variables can be added.
</p>
<p>Following variables are returned as the top level variables.
</p>
<p></p>
<ul class="text">
<li>access_token - The access token issued by the authorization server.
</li>
<li>expires_in - OPTIONAL. The duration in seconds of the access token lifetime. For example, the value 3600 denotes that the access token will expire in one hour from the time the response was generated by the authorization server.
</li>
<li>refresh_token - OPTIONAL. The refresh token used to obtain new access tokens.
</li>
</ul><p>It MUST be formatted in the JSON or JSONP format depending on the atype in the request.
</p>
<p>Following is an example of an assertion.
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"openid": {
"type": "http://openid.net/specs/ab/1.0#id_res",
"server_id": "https://op.example.com/",
"pubkey": "CSqGSIb3DQEBBQ...22WLTnPvcztaqovGW2gaidAyq6",
"request_url": "https://rp.example.com/rf.js%23Qfsoe2F",
"op_endpoint": "https://op.example.com/op_endpoint",
"claimed_id": "https://example.com/alice#1234",
"identity": "alice",
"user_id": "https://op.example.com/a3flsjeow1234",
"issued_at": 1280217103,
"client_id": "https://rp.example.com/"
}
"access_token":"SlAV32hkKG",
"expires_in":3600,
"refresh_token":"8xLOxBtZp8"
}</pre></div><p>
</p>
<p>There are cases where the assertion is presented to different server than the originator. If such use is expected of the assertion, the original authorization assertion MUST NOT include the value to the attributes. Such assertion MAY be presented to each server so that the server can return the attributes that it is authoritative to.
</p>
<a name="anchor7"></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.6.2"></a><h3>8.6.2.
Negative Assertion</h3>
<p>If the assertion request is invalid or unauthorized, the authorization server constructs the response by adding the following parameter to the entity body of the HTTP response using the "application/json" media type:
</p>
<p></p>
<ul class="text">
<li>error - REQUIRED. A single error code as described below.
</li>
<li>error_description - OPTIONAL. A human-readable text providing additional information, used to assist in the understanding and resolution of the error occurred.
</li>
<li>error_uri - OPTIONAL. A URI identifying a human-readable web page with information about the error, used to provide the end-user with additional information about the error.
</li>
</ul><p>The error code is as follows:
</p>
<p></p>
<ul class="text">
<li>invalid_request - The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed.
</li>
<li>invalid_client - The client identifier provided is invalid, the client failed to authenticate, the client did not include its credentials, provided multiple client credentials, or used unsupported credentials type.
</li>
<li>unauthorized_client - The authenticated client is not authorized to use the access grant type provided.
</li>
<li>invalid_grant - The provided access grant is invalid, expired, or revoked (e.g. invalid assertion, expired authorization token, bad end-user password credentials, or mismatching authorization code and redirection URI).
</li>
<li>unsupported_grant_type - The access grant included - its type or another attribute - is not supported by the authorization server.
</li>
<li>invalid_scope - The requested scope is invalid, unknown, malformed, or exceeds the previously granted scope.
</li>
</ul>
<p>
</p>
<a name="veri"></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.7"></a><h3>8.7.
Verifying Assertion</h3>
<p>Upon receipt of the JSON formatted positive assertion, the RP SHOULD parse it to obtain the openid parameters.
</p>
<p>Then, the RP SHOULD perform the verification as follows:
</p>
<p></p>
<ol class="text">
<li>Check that OP that it connected was really the intended OP through TLS/SSL server certificate check.
</li>
<li>Check if "type" is "http://openid.net/specs/ab/1.0#id_res".
</li>
<li>Check if the current time is after "issued_at" and before "issued_at" + "expires_in".
</li>
<li>If "claimed_id" was not sent in the request or different than what was sent, perform the discovery on the "claimed_id" in the assertion.
</li>
<li>Compare "claimed_id", "identity", "op_endpoint" to the discovered or "out-of-band known" values.
</li>
</ol>
<a name="anchor8"></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.8"></a><h3>8.8.
Signed Assertion</h3>
<p>To mitigate Assertion-repudiation attack, the assertion may be digitally signed by the OP using a key that supports non-repudiation. The RP should check the digital signature to verify that it was issued by a legitimate OP.
</p>
<p>In this case, the Assertion will be encoded as described in <a class='info' href='#signed_format'>Section 5.4<span> (</span><span class='info'>Signed Format</span><span>)</span></a> .
</p>
<p>Public key of the OP MUST be included in the assertion as 'certs_uri' or 'pubkey'.
</p>
<p>If the Assertion is signed, the signature validation MUST be performed before other verifications specified in <a class='info' href='#veri'>Section 8.7<span> (</span><span class='info'>Verifying Assertion</span><span>)</span></a>
</p>
<a name="enc_ass"></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.9"></a><h3>8.9.
Encrypted Assertion</h3>
<p>Further, the signed assertion MAY optionally be encrypted based on the RP's public key of the intended recipient to achieve end-to-end encryption and to increase the assurance level of the information protection in the assertion through audience restriction. This is especially useful when the assertion is passed through a medium where the SSL is terminated one or more times, such as an active client.
</p>
<p>To achieve this, in the Request File <a class='info' href='#rpf'>Section 5.2<span> (</span><span class='info'>Request File</span><span>)</span></a>, it MUST contain "enc_key", "enc_type" in addition.
</p>
<p>The assertion will be returned in the format discribed in Encryption <a class='info' href='#encrypted_format'>Section 5.5<span> (</span><span class='info'>Encryption</span><span>)</span></a> using the received "enc_key" and "enc_type". Encryption SHOULD be the last process before the OP returning the assertion.
</p>
<a name="hok"></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.10"></a><h3>8.10.
Holder of Key</h3>
<p>To achieve the highest level of assurance, the assertion MAY optionally include "proofkey" as one of the field, which can be subsequently used at the RP to further authenticate the user.
</p>
<a name="oth_atypes"></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.11"></a><h3>8.11.
Other assertion types</h3>
<p>When RP wishes to obtain other type of assertion than OpenID, it MAY request one by specifying "atype" in the <a class='info' href='#rpf'>Request File<span> (</span><span class='info'>Request File</span><span>)</span></a> or as a request parameter in an Artifact Request.
</p>
<a name="data_req"></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.9"></a><h3>9.
Accessing the Protected Resource</h3>
<p>Clients access protected resources by presenting the following variable in the HTTPS POST to the resource end point.
</p>
<p></p>
<ul class="text">
<li>token_type - REQUIRED if the oauth_token is the Web Token Serilization of the Signed OpenID Assertion. The value is "openid".
</li>
<li>oauth_token - an access_token or a signed assertion in Web Token Serialization.
</li>
</ul><p>The entity-body can include other request-specific parameters, in which case, the oauth_token parameters SHOULD be appended following the request-specific parameters, properly separated by an & character (ASCII code 38).
</p>
<p>For higher security, the client SHOULD add its signature to the assertion so that the server can authenticate the client.
</p>
<p>
<p>Following is a non-normative example.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>POST /resource HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
token_type=openid&oauth_token=PHNhbWxwOl...[omitted for brevity]...ZT4%3D</pre></div>
<p>
</p>
<a name="extensions"></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.10"></a><h3>10.
Extensions</h3>
<p>Extensions are as defined in Section 12 of <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication‑2.0]<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> . In addition, this specification adds following list to the disallowed aliases.
</p>
<p>request_url, code, ope_endpoint, user_id, redirect_uri, client_id, server_id, client_secret, immediate, pubkey, certs_uri, state, code, atype, proofkey, enc_data, enc_key, enc_iv, enc_type, enc_ref, access_token, access_token_secret, issued_at, expires_in, refresh_token.
</p>
<p>
</p>
<a name="security_considerations"></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.11"></a><h3>11.
Security Considerations</h3>
<p>Followings are the list of attack vectors and remedies that were considered for this specification.
</p>
<p>For details of the attack vector, see <a class='info' href='#SP800-63'>[SP800‑63]<span> (</span><span class='info'>National Institute of Standards and Technology, “NIST SP800-63rev.1: Electronic Authentication Guideline,” .</span><span>)</span></a>.
</p>
<a name="assertion_manufacture"></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.11.1"></a><h3>11.1.
Assertion manufacture/modification</h3>
<p>To mitigate this attack, there are two ways to mitigate it.
</p>
<p></p>
<ol class="text">
<li>The assertion may be digitally signed by the OP. The Relying Party SHOULD check the digital signature to verify that it was issued by a legitimate OP.
</li>
<li>The assertion may be sent over a protected channel such as TLS/SSL. In order to protect the integrity of assertions from malicious attack, the OP MUST be authenticated. In this specification, the assertion is always sent over TLS/SSL protected channel.
</li>
</ol>
<a name="assertion_disclosure"></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.11.2"></a><h3>11.2.
Assertion disclosure</h3>
<p>The Assertion disclosure can be mitigated in the following two ways.
</p>
<p></p>
<ol class="text">
<li>Assertion is sent over TLS/SSL protected channel, where RP is authenticated by "client_id" and "client_secret".
</li>
<li>Signed Assertion is encrypted by the RP's public key.
</li>
</ol>
<a name="assertion_repudiation"></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.11.3"></a><h3>11.3.
Assertion repudiation</h3>
<p>To mitigate this threat, the assertion may be digitally signed by the OP using a key that supports non-repudiation. The RP SHOULD check the digital signature to verify that it was issued by a legitimate OP.
</p>
<a name="assertion_redirect"></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.11.4"></a><h3>11.4.
Assertion redirect</h3>
<p>To mitigate this threat, the assertion includes the identity of the RP for whom it was generated as "client_id". The RP verifies that incoming assertions include its identity as the recipient of the assertion.
</p>
<a name="assertion_reuse"></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.11.5"></a><h3>11.5.
Assertion reuse</h3>
<p>The assertion includes a timestamp and a short lifetime of validity. The Relying Party checks the timestamp and lifetime values to ensure that the assertion is currently valid.
</p>
<a name="artifact_manufacture"></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.11.6"></a><h3>11.6.
Secondary authenticator manufacture</h3>
<p>Due to the large entropy requirement of the Artifact ("code") and short life nature of its validity, the success probability of this attack is extremely low.
</p>
<a name="artifact_capture"></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.11.7"></a><h3>11.7.
Secondary authenticator capture</h3>
<p>Secondary authenticator (="code") is transmitted only through HTTPS, thus it is protected between the OP and the User-Agent, and User-Agent and the RP.
</p>
<p>Only the place it can be captured is the User-Agent where the TLS session is terminated, and is possible if the User-Agent is infested by malwares. However, it renders no usefulness as long as the profile in use either RP authentication or assertion encryption.
</p>
<a name="assertion_substitution"></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.11.8"></a><h3>11.8.
Assertion substitution</h3>
<p>Responses to assertion requests is bound to the corresponding requests by message order in HTTP, as both assertions and requests are protected by TLS that can detect and disallow malicious reordering of packets.
</p>
<a name="auth_req_disclosure"></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.11.9"></a><h3>11.9.
Authentication Request Disclosure</h3>
<p>If the authentication request is POSTed directly through a protected channel, it is not possible to disclose the authentication request.
</p>
<p>If the Request File is encrypted by the OP's public key, the authentication request will not be disclosed unless OP's private key gets compromised or the encryption algorithm becomes vulnerable.
</p>
<a name="anchor9"></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.11.10"></a><h3>11.10.
Timing Attack</h3>
<p>Timing attack can be used to reduce the effctive key length of the signature if the time required to return the response in case of signature error and correct signature exists. Care should be taken in the implementation to avoid this attack.
</p>
<a name="authn_proc_threats"></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.11.11"></a><h3>11.11.
Authentication Process Threats</h3>
<p>In the category of Authentication Process Threats, following threats exists.
</p>
<p></p>
<ul class="text">
<li>Online guessing
</li>
<li>Phishing
</li>
<li>Pharming
</li>
<li>Eavesdropping
</li>
<li>Replay
</li>
<li>Session hijack
</li>
<li>Man-in-the-middle
</li>
</ul><p>Authentication process per se as described in NIST SP800-63-rev1 is out of scope for this protocol, but care SHOULD be taken to achieve appropriate protection.
</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.12"></a><h3>12.
IANA Considerations</h3>
<a name="oauth_params"></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.12.1"></a><h3>12.1.
OAuth Parameters Registry</h3>
<p>The following is the parameter registration request for the "scope" parameter as defined in this specification:
</p>
<p>Parameter name: openid
</p>
<p>Parameter usage location: The end-user authorization endpoint request, the end-user authorization endpoint response, the token endpoint request, the token endpoint response, and the "WWW-Authenticate" header field.
</p>
<p>Change controller: IETF
</p>
<p>Specification document(s): [[ this document ]]
</p>
<p>Related information: None
</p>
<a name="anchor10"></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>As a binding of OpenID Authentication, this specification heavily relies on OpenID Authentication 2.0. Please refer to Appendix C of OpenID Authentication 2.0 for the full list of the contributors for OpenID Authentication 2.0.
</p>
<p>In addition, the OpenID Community would like to thank the following people for the work they've done in the drafting and editing of this specification.
</p>
<p></p>
<blockquote class="text">
<p>Breno de Medeiros (breno@gmail.com)
</p>
<p>Hideki Nara (hideki.nara@gmail.com)
</p>
<p>John Bradley (jbradely@mac.com) <author>
</p>
<p>Nat Sakimura (n-sakimura@nri.co.jp) <author/editor>
</p>
<p>Ryo Itou (ritou@yahoo-corp.jp)
</p>
</blockquote>
<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>13. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="FIPS180-2">[FIPS180-2]</a></td>
<td class="author-text">U.S. Department of Commerce and National Institute of Standards and Technology, “<a href="http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf">Secure Hash Signature Standard</a>,” FIPS 180-2.<p>
Defines Secure Hash Algorithm 256 (SHA256)
</p>
</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.authentication-2.0">[OpenID.authentication-2.0]</a></td>
<td class="author-text">specs@openid.net, “OpenID Authentication 2.0,” 2007 (<a href="http://www.openid.net/specs/openid-authentication-2_0.txt">TXT</a>, <a href="http://www.openid.net/specs/openid-authentication-2_0.html">HTML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC1421">[RFC1421]</a></td>
<td class="author-text"><a href="mailto:104-8456@mcimail.com">Linn, J.</a>, “<a href="http://tools.ietf.org/html/rfc1421">Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures</a>,” RFC 1421, February 1993 (<a href="http://www.rfc-editor.org/rfc/rfc1421.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC1422">[RFC1422]</a></td>
<td class="author-text"><a href="mailto:kent@BBN.COM">Kent, S.</a>, “<a href="http://tools.ietf.org/html/rfc1422">Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management</a>,” RFC 1422, February 1993 (<a href="http://www.rfc-editor.org/rfc/rfc1422.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC1423">[RFC1423]</a></td>
<td class="author-text"><a href="mailto:balenson@tis.com">Balenson, D.</a>, “<a href="http://tools.ietf.org/html/rfc1423">Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers</a>,” RFC 1423, February 1993 (<a href="http://www.rfc-editor.org/rfc/rfc1423.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC1424">[RFC1424]</a></td>
<td class="author-text"><a href="mailto:burt@rsa.com">Kaliski, B.</a>, “<a href="http://tools.ietf.org/html/rfc1424">Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services</a>,” RFC 1424, February 1993 (<a href="http://www.rfc-editor.org/rfc/rfc1424.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC1750">[RFC1750]</a></td>
<td class="author-text"><a href="mailto:dee@lkg.dec.com">Eastlake, D.</a>, <a href="mailto:crocker@cybercash.com">Crocker, S.</a>, and <a href="mailto:jis@mit.edu">J. Schiller</a>, “<a href="http://tools.ietf.org/html/rfc1750">Randomness Recommendations for Security</a>,” RFC 1750, December 1994 (<a href="http://www.rfc-editor.org/rfc/rfc1750.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">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 (<a href="http://www.rfc-editor.org/rfc/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2616">[RFC2616]</a></td>
<td class="author-text"><a href="mailto:fielding@ics.uci.edu">Fielding, R.</a>, <a href="mailto:jg@w3.org">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com">Mogul, J.</a>, <a href="mailto:frystyk@w3.org">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com">Leach, P.</a>, and <a href="mailto:timbl@w3.org">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>,” RFC 2616, June 1999 (<a href="http://www.rfc-editor.org/rfc/rfc2616.txt">TXT</a>, <a href="http://www.rfc-editor.org/rfc/rfc2616.ps">PS</a>, <a href="http://www.rfc-editor.org/rfc/rfc2616.pdf">PDF</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2616.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2616.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2617">[RFC2617]</a></td>
<td class="author-text"><a href="mailto:john@math.nwu.edu">Franks, J.</a>, <a href="mailto:pbaker@verisign.com">Hallam-Baker, P.</a>, <a href="mailto:jeff@AbiSource.com">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>,” RFC 2617, June 1999 (<a href="http://www.rfc-editor.org/rfc/rfc2617.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2617.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2617.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3548">[RFC3548]</a></td>
<td class="author-text">Josefsson, S., “<a href="http://tools.ietf.org/html/rfc3548">The Base16, Base32, and Base64 Data Encodings</a>,” RFC 3548, July 2003 (<a href="http://www.rfc-editor.org/rfc/rfc3548.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3629">[RFC3629]</a></td>
<td class="author-text">Yergeau, F., “<a href="http://tools.ietf.org/html/rfc3629">UTF-8, a transformation format of ISO 10646</a>,” STD 63, RFC 3629, November 2003 (<a href="http://www.rfc-editor.org/rfc/rfc3629.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3986">[RFC3986]</a></td>
<td class="author-text"><a href="mailto:timbl@w3.org">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com">Fielding, R.</a>, and <a href="mailto:LMM@acm.org">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>,” STD 66, RFC 3986, January 2005 (<a href="http://www.rfc-editor.org/rfc/rfc3986.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc3986.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc3986.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC4627">[RFC4627]</a></td>
<td class="author-text">Crockford, D., “<a href="http://tools.ietf.org/html/rfc4627">The application/json Media Type for JavaScript Object Notation (JSON)</a>,” RFC 4627, July 2006 (<a href="http://www.rfc-editor.org/rfc/rfc4627.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="SP800-63">[SP800-63]</a></td>
<td class="author-text">National Institute of Standards and Technology, “<a href="http://csrc.nist.gov/publications/drafts/800-63-rev1/SP800-63-Rev1_Dec2008.pdf">NIST SP800-63rev.1: Electronic Authentication Guideline</a>,” NIST SP800-63.<p>
Defines LoA
</p>
</td></tr>
<tr><td class="author-text" valign="top"><a name="json_enc">[json_enc]</a></td>
<td class="author-text">Bradeley, J. and N. Sakimura, “<a href="http://jsonenc.info/1.0/">JSON Simple Encryption</a>,” September 2010.</td></tr>
<tr><td class="author-text" valign="top"><a name="json_sig">[json_sig]</a></td>
<td class="author-text">Bradeley, J. and N. Sakimura, “<a href="http://jsonenc.info/sig/1.0/">JSON Simple Sign</a>,” September 2010.</td></tr>
</table>
<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>Author's Address</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">openid-specs-ab@openid.net</td></tr>
</table>
</body></html>