<!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 - Draft13</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Artifact Binding 1.0 - Draft13">
<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">&nbsp;TOC&nbsp;</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">&nbsp;</td><td class="header">July 26, 2010</td></tr>
</table></td></tr></table>
<h1><br />OpenID Artifact Binding 1.0 - Draft13</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>&nbsp;
Requirements Notation and Conventions<br />
<a href="#terminology">2.</a>&nbsp;
Terminology<br />
<a href="#overview">3.</a>&nbsp;
Protocol Overview<br />
<a href="#parameters">4.</a>&nbsp;
Parameters<br />
<a href="#anchor1">5.</a>&nbsp;
Data Formats<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#oje">5.1.</a>&nbsp;
OpenID JSON Encoding<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#rpf">5.2.</a>&nbsp;
Request File<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#pa">5.3.</a>&nbsp;
Positive Assertion<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#signed_format">5.4.</a>&nbsp;
Signed Format<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#encrypted_format">5.5.</a>&nbsp;
Encryption<br />
<a href="#anchor2">6.</a>&nbsp;
Communication Types<br />
<a href="#anchor3">7.</a>&nbsp;
Common Processing<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#initiation">7.1.</a>&nbsp;
Initiation<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#normalization">7.2.</a>&nbsp;
Normalization<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#discovery">7.3.</a>&nbsp;
Discovery<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#association">7.4.</a>&nbsp;
Association<br />
<a href="#protocol_flows">8.</a>&nbsp;
Protocol Flows<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#rf_prep">8.1.</a>&nbsp;
RP prepares an Request File<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#rurl_create">8.2.</a>&nbsp;
RP Obtains the URL of the Request File<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#art_req">8.3.</a>&nbsp;
RP sends a request to OP via redirect<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#art_res">8.4.</a>&nbsp;
OP Sends the user back to the RP. <br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#id_req">8.5.</a>&nbsp;
RP requests Assertion directly to the OP<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#id_res">8.6.</a>&nbsp;
RP receives Assertion in the response body<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#veri">8.7.</a>&nbsp;
Verifying Assertion<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor6">8.8.</a>&nbsp;
Signed Assertion<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#enc_ass">8.9.</a>&nbsp;
Encrypted Assertion<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#hok">8.10.</a>&nbsp;
Holder of Key<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#oth_atypes">8.11.</a>&nbsp;
Other assertion types<br />
<a href="#extensions">9.</a>&nbsp;
Extensions<br />
<a href="#security_considerations">10.</a>&nbsp;
Security Considerations<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#assertion_manufacture">10.1.</a>&nbsp;
Assertion manufacture/modification<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#assertion_disclosure">10.2.</a>&nbsp;
Assertion disclosure<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#assertion_repudiation">10.3.</a>&nbsp;
Assertion repudiation<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#assertion_redirect">10.4.</a>&nbsp;
Assertion redirect<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#assertion_reuse">10.5.</a>&nbsp;
Assertion reuse<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#artifact_manufacture">10.6.</a>&nbsp;
Secondary authenticator manufacture<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#artifact_capture">10.7.</a>&nbsp;
Secondary authenticator capture<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#assertion_substitution">10.8.</a>&nbsp;
Assertion substitution<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#auth_req_disclosure">10.9.</a>&nbsp;
Authentication Request Disclosure<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#authn_proc_threats">10.10.</a>&nbsp;
Authentication Process Threats<br />
<a href="#iana">11.</a>&nbsp;
IANA Considerations<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#oauth_params">11.1.</a>&nbsp;
OAuth Parameters Regitry<br />
<a href="#anchor7">Appendix&nbsp;A.</a>&nbsp;
Acknowledgements<br />
<a href="#rfc.references1">12.</a>&nbsp;
Normative References<br />
<a href="#rfc.authors">&#167;</a>&nbsp;
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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.&nbsp;
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., &ldquo;Key words for use in RFCs to Indicate Requirement Levels,&rdquo; March&nbsp;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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.&nbsp;
Terminology</h3>

<p>In addition to the terminology used in <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication&#8209;2.0]<span> (</span><span class='info'>specs@openid.net, &ldquo;OpenID Authentication 2.0,&rdquo; 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>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>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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.&nbsp;
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&#8209;2.0]<span> (</span><span class='info'>specs@openid.net, &ldquo;OpenID Authentication 2.0,&rdquo; 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&#8209;2.0]<span> (</span><span class='info'>specs@openid.net, &ldquo;OpenID Authentication 2.0,&rdquo; 2007.</span><span>)</span></a> type signature. The message integrity that <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication&#8209;2.0]<span> (</span><span class='info'>specs@openid.net, &ldquo;OpenID Authentication 2.0,&rdquo; 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 to achieve the non-repudiation.
</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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.&nbsp;
Parameters</h3>

<p>Followings are parameters used in this specification. Most of them are specific to a particular profile and optional.
</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&#8209;2.0]<span> (</span><span class='info'>specs@openid.net, &ldquo;OpenID Authentication 2.0,&rdquo; 2007.</span><span>)</span></a>. This namespace SHOULD be listed as an &lt;xrd:Type&gt; child element of the &lt;xrd:Service&gt; element in the XRDS discovery document.
</p>
</blockquote>
</li>
<li>type 
<blockquote class="text">
<p>Value: The URL 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_url 
<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, &ldquo;Uniform Resource Identifier (URI): Generic Syntax,&rdquo; January&nbsp;2005.</span><span>)</span></a> of the Request File. Optionally, one can put the SHA256 <a class='info' href='#FIPS180-2'>[FIPS180&#8209;2]<span> (</span><span class='info'>U.S. Department of Commerce and National Institute of Standards and Technology, &ldquo;Secure Hash Signature Standard,&rdquo; .</span><span>)</span></a>hash of the file after "#". "#" MUST be escaped.
</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_url 
<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: Base 64 Encoding <a class='info' href='#RFC3548'>[RFC3548]<span> (</span><span class='info'>Josefsson, S., &ldquo;The Base16, Base32, and Base64 Data Encodings,&rdquo; July&nbsp;2003.</span><span>)</span></a> with URL and Filename Safe Alphabet (Base64url) encoded X.509 Certificate without private key in PEM (<a class='info' href='#RFC1421'>RFC1421<span> (</span><span class='info'>Linn, J., &ldquo;Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures,&rdquo; February&nbsp;1993.</span><span>)</span></a> [RFC1421] - <a class='info' href='#RFC1424'>RFC1424<span> (</span><span class='info'>Kaliski, B., &ldquo;Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services,&rdquo; February&nbsp;1993.</span><span>)</span></a> [RFC1424]) Format.
</p>
</blockquote>
</li>
<li>certs_url 
<blockquote class="text">
<p>Value: A URL from which one can retrieve PEM format X.509 certificate.
</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, &ldquo;Randomness Recommendations for Security,&rdquo; December&nbsp;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>In addition, following OAuth 2.0 parameters are defined and MAY be used in the Assertion.
</p>
<p></p>
<ul class="text">
<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.
</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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.&nbsp;
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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5.1"></a><h3>5.1.&nbsp;
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&#8209;2.0]<span> (</span><span class='info'>specs@openid.net, &ldquo;OpenID Authentication 2.0,&rdquo; 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 OpenID JSON Encoding. Keys MUST NOT be prefixed by "openid.". Instead, the entire JSON expression is keyed with "openid" as in the following example.
</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_url": "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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5.2"></a><h3>5.2.&nbsp;
Request File</h3>

<p>Request File is a UTF-8<a class='info' href='#RFC3629'>[RFC3629]<span> (</span><span class='info'>Yergeau, F., &ldquo;UTF-8, a transformation format of ISO 10646,&rdquo; November&nbsp;2003.</span><span>)</span></a> <a class='info' href='#RFC4627'>JSON<span> (</span><span class='info'>Crockford, D., &ldquo;The application/json Media Type for JavaScript Object Notation (JSON),&rdquo; July&nbsp;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 to be sent:
</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, &ldquo;OpenID Authentication 2.0,&rdquo; 2007.</span><span>)</span></a> [OpenID.authentication&#8209;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 PEM format X.509 certificate of the RP.
</li>
</ul><p>Following is the list of OAuth 2.0 variables to be sent:
</p>
<p></p>
<ul class="text">
<li>grant_type - either "authorization_code"
</li>
<li>client_id
</li>
<li>redirect_url
</li>
</ul><p>Any other extension and other variables can be included.
</p>
<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#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_url": "https://example.com/rp/endpoint_url",
    "grant_type":"authorization_code",
    "cliend_id": "http://example.com/rp/"
}
</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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5.3"></a><h3>5.3.&nbsp;
Positive Assertion</h3>

<p>Positive Assertion is a set of data than an OP sends out to the RP on successful Authentication. The default format is the <a class='info' href='#oje'>Section&nbsp;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:
</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 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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5.4"></a><h3>5.4.&nbsp;
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 achieve non-repudiatiability through public key cryptography, one MAY use asymmetric signature as in <a class='info' href='#magic_signatures'>[magic_signatures]<span> (</span><span class='info'>Panzer, J. and B. Laurie, &ldquo;Magic Signatures,&rdquo; February&nbsp;2010.</span><span>)</span></a> where parameters are as follows.
</p>
<p></p>
<blockquote class="text">
<p>"data_type":"application/json"
</p>
<p>"encoding":"base64url"
</p>
<p>"alg":"RSA-SHA256"
</p>
<p>"data":base64url encoded JSON representation of the assertion.
</p>
</blockquote>

<p>This specification defines an additional parameter.
</p>
<p></p>
<ul class="text">
<li>certs_url 
<blockquote class="text">
<p>Value: A URL from which one can retrieve PEM format X.509 certificate. It is used as the replacement of "keyhash". The file may contain certificate chain.
</p>
</blockquote>
</li>
<li>type 
<blockquote class="text">
<p>Value: A URL that signifies the type of this file. "http://openid.net/specs/ab/1.0#signed_format"
</p>
</blockquote>
</li>
</ul>

<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",
    "encoding": "base64url",
    "alg": "RSA-SHA256",
    "data": "base64url encoded data without padding",
    "sigs": [
        {
            "value": "EvGSD2vi8qYcveHnb-rrlok07qn...63iJzeGLKfyHg8ZomQ",
            "certs_url": "https://rp.example.com/certs.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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5.5"></a><h3>5.5.&nbsp;
Encryption</h3>

<p>In the response, the payload may be encrypted by RP's public key to achieve the non-repudiation. 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, &ldquo;JSON Encryption Envelope,&rdquo; February&nbsp;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/rpf_ax.json",
    "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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.&nbsp;
Communication Types</h3>

<p>Communication Types are the same as in <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication&#8209;2.0]<span> (</span><span class='info'>specs@openid.net, &ldquo;OpenID Authentication 2.0,&rdquo; 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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.&nbsp;
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-&gt;UA: Click Login
UA-&gt;RP: Login with identifier
RP-&gt;RP: Normalize identifier
RP-&gt;OP: Get XRDS
RP-&gt;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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7.1"></a><h3>7.1.&nbsp;
Initiation</h3>

<p>Initiation is done as in <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication&#8209;2.0]<span> (</span><span class='info'>specs@openid.net, &ldquo;OpenID Authentication 2.0,&rdquo; 2007.</span><span>)</span></a>
</p>
<p>Following is the non-normative explanation of what it is.
</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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7.2"></a><h3>7.2.&nbsp;
Normalization</h3>

<p>Normalization is done as in <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication&#8209;2.0]<span> (</span><span class='info'>specs@openid.net, &ldquo;OpenID Authentication 2.0,&rdquo; 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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7.3"></a><h3>7.3.&nbsp;
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, &ldquo;OpenID Authentication 2.0,&rdquo; 2007.</span><span>)</span></a> [OpenID.authentication&#8209;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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7.4"></a><h3>7.4.&nbsp;
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, &ldquo;OpenID Authentication 2.0,&rdquo; 2007.</span><span>)</span></a> [OpenID.authentication&#8209;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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7.4.1"></a><h3>7.4.1.&nbsp;
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, &ldquo;Hypertext Transfer Protocol -- HTTP/1.1,&rdquo; June&nbsp;1999.</span><span>)</span></a>request to the OP Endpoint with the following REQUIRED parameters:
</p>
<p></p>
<ul class="text">
<li>type - "client_associate"
</li>
<li>redirect_uri
</li>
</ul><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>server_id
</li>
<li>client_secret
</li>
<li>expires_in
</li>
</ul>

<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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7.4.2"></a><h3>7.4.2.&nbsp;
Exchanging the public key</h3>

<p>If the OP desires non-repudiation possibility of the request from the RP through public key cryptography, then it MUST use the RSA signature mode. Unless the OP has the public key by some out-of-band mechanism, the RP MUST send its Public Key as the PEM format X.509 certificate in the Request. It is also strongly advised that the RP to publish its PEM format X.509 certificate at the 'client_id' URL that the RP uses.
</p>
<p>If the RP desires non-repudiation possibility of the response from the OP thorugh public key cryptography, then it MUST use the RSA 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 the PEM format X.509 certificate in the Response. It is also strongly advised that the OP to publish its PEM format X.509 certificate at the HTTPS URL that 'server_id' URL points to. The OP SHOULD publish its certificate in the XRD or XRDS document as well. The type URL of the certificate is 'http://openid.net/specs/ab/1.0#x509pem'.
</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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8"></a><h3>8.&nbsp;
Protocol Flows</h3>

<p>In this specification, the protocol flow basically follows OAuth2.0 Web Server Flow with a twist that instead of parameters sent as redirect request, the parameters are captured into a file and the URL of the file, 'request_url', is being sent. All steps in the following profiles are preceded by the common processing. The assertion returned may vary in the following four 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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8.1"></a><h3>8.1.&nbsp;
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 well as in <a class='info' href='#signed_format'>Section&nbsp;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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8.2"></a><h3>8.2.&nbsp;
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. 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 proveds the Request File registration service, it SHOULD publish the registration endpoint in the XRDS where the &lt;Type&gt; 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 OP 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.php HTTP/1.1
Host: op.example.com
Content-Length: 2823
 request=wfjsil2wjf...awQfs_w&amp;client_secret=very_secure_secret</pre></div><p>

</p>
<p>If the request is valid, OP returns the following variables in the OpenID JSON format:
</p>
<p></p>
<ul class="text">
<li>type - "http://openid.net/specs/ab/1.0#req_req_res"
</li>
<li>mode - "req_reg_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",
    "mode":"req_reg_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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8.3"></a><h3>8.3.&nbsp;
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>mode - "art_req"
</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. The OP includes this value when redirecting the user-agent back to the client.
</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?mode=art_req
&amp;request_url=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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8.4"></a><h3>8.4.&nbsp;
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&#8209;2.0]<span> (</span><span class='info'>specs@openid.net, &ldquo;OpenID Authentication 2.0,&rdquo; 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 "redirect_url" URL specified in <a class='info' href='#rpf'>Section&nbsp;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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8.4.1"></a><h3>8.4.1.&nbsp;
End-user Grants Authorization</h3>

<p></p>
<ul class="text">
<li>mode - "art_res"
</li>
<li>code - The artifact Value.
</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>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?mode=art_res
&amp;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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8.4.2"></a><h3>8.4.2.&nbsp;
End-user Denies Authorization or Invalid Request FIle</h3>

<p></p>
<ul class="text">
<li>mode - "art_res"
</li>
<li>error - "user_denied", if the end-user denied the request. "invalid" if the request file was invalid. "setup_needed" if the user interaction was required.
</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>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?mode=art_res
&amp;error=setup_needed
&amp;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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8.5"></a><h3>8.5.&nbsp;
RP requests Assertion directly to the OP</h3>

<p>To obtain the assertion, the RP makes a direct request to the OP 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, while it is not specified in OAuth 2.0 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 Magic Signatures to 'code'.
</li>
<li>Base64url encode the result.
</li>
</ol>

<p>To obtain the assertion, send the following parameters via HTTPS GET:
</p>
<p></p>
<ul class="text">
<li>mode - "direct_assertion_req"
</li>
<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 "magic", send the magic signature prepared as above in this section.
</li>
<li>secret_type - (OPTIONAL) "shared" or "magic". 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>GET /op_endpoint?mode=direct_assertion_req&amp;grant_type=authorization_code
&amp;code=_artifact_received_
&amp;client_id=https%3A%2F%2Frp.example.com%2Frpf.json
&amp;client_secret=1234qwer&amp;secret_type=shared HTTP/1.1
Host: op.example.com</pre></div><p>

</p>
<p>
</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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8.6"></a><h3>8.6.&nbsp;
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="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8.6.1"></a><h3>8.6.1.&nbsp;
Positive Assertion</h3>

<p>Positive Assertion can only be returned once for the artifact and contains the following variables.
</p>
<p></p>
<ul class="text">
<li>type - "http://openid.net/specs/ab/1.0#id_res"
</li>
<li>mode - "id_res"
</li>
<li>server_id - The identifier of the OP.
</li>
<li>pubkey - The OP's X.509 certificate without private key.
</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>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",
        "mode": "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/"
    }
}</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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8.6.2"></a><h3>8.6.2.&nbsp;
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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8.7"></a><h3>8.7.&nbsp;
Verifying Assertion</h3>

<p>Upon receipt of the JSON formatted 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 "mode" is "id_res".
</li>
<li>If "claimed_id" was not sent in the request or different than what was sent, perform the discovery on the cliemd_id in the assertion.
</li>
<li>Compare "claimed_id", "identity", "op_endpoint", "ns" to the discovered or "out-of-band known" values.
</li>
</ol>

<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8.8"></a><h3>8.8.&nbsp;
Signed Assertion</h3>

<p>For non-repudiation possibility, the Assertion MUST be singed by an asymmetric key of the authorization server (OP).
</p>
<p>In this case, the Assertion will be encoded as described in <a class='info' href='#signed_format'>Section&nbsp;5.4<span> (</span><span class='info'>Signed Format</span><span>)</span></a> .
</p>
<p>Public key of the OP MUST either be published in the XRDS or given to the RP out-of-band.
</p>
<p>To publish the public key, one SHOULD specify "http://openid.net/specs/ab/1.0/pk" in the Service/Type, and the URL from which the X.509 certificate can be obtained.
</p>
<p>If the Assertion is signed, the signature validation MUST be performed before other verifications specified in <a class='info' href='#veri'>Section&nbsp;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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8.9"></a><h3>8.9.&nbsp;
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. 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&nbsp;5.2<span> (</span><span class='info'>Request File</span><span>)</span></a>, it MUST contain "enckey", "enctype" in addition.
</p>
<p>The assertion will be returned in the format discribed in Encryption <a class='info' href='#encrypted_format'>Section&nbsp;5.5<span> (</span><span class='info'>Encryption</span><span>)</span></a> using the received "enckey" and "enctype". 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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8.10"></a><h3>8.10.&nbsp;
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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8.11"></a><h3>8.11.&nbsp;
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 Request Artifact Request.
</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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.9"></a><h3>9.&nbsp;
Extensions</h3>

<p>Extensions are as defined in Section 12 of <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication&#8209;2.0]<span> (</span><span class='info'>specs@openid.net, &ldquo;OpenID Authentication 2.0,&rdquo; 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_url, client_id, server_id, client_secret, immediate, pubkey, certs_url, state, code, atype, proofkey, encdata, enckey, enciv, enctype, encref, 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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.10"></a><h3>10.&nbsp;
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&#8209;63]<span> (</span><span class='info'>National Institute of Standards and Technology, &ldquo;NIST SP800-63rev.1: Electronic Authentication Guideline,&rdquo; .</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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.10.1"></a><h3>10.1.&nbsp;
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>
<li>Timing attack can be used to reduced 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.
</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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.10.2"></a><h3>10.2.&nbsp;
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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.10.3"></a><h3>10.3.&nbsp;
Assertion repudiation</h3>

<p>To mitigate this threat, the assertion may be digitally signed by the Verifier 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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.10.4"></a><h3>10.4.&nbsp;
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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.10.5"></a><h3>10.5.&nbsp;
Assertion reuse</h3>

<p>The assertion is obtainable only by the RP through Protected Channel. Thus, attacker cannot launch an assertion reuse attack.
</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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.10.6"></a><h3>10.6.&nbsp;
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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.10.7"></a><h3>10.7.&nbsp;
Secondary authenticator capture</h3>

<p>Secondary authenticator (="code") can be captured. 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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.10.8"></a><h3>10.8.&nbsp;
Assertion substitution</h3>

<p>Since Assertion is obtained directly through a protected channel, assertion substitution is not possible.
</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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.10.9"></a><h3>10.9.&nbsp;
Authentication Request Disclosure</h3>

<p>If the authentication request is POSTed directly through a protected channel as in Profile 2, 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="authn_proc_threats"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.10.10"></a><h3>10.10.&nbsp;
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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.11"></a><h3>11.&nbsp;
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">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.11.1"></a><h3>11.1.&nbsp;
OAuth Parameters Regitry</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="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A"></a><h3>Appendix A.&nbsp;
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) &lt;author&gt;
</p>
<p>Nat Sakimura (n-sakimura@nri.co.jp) &lt;author/editor&gt;
</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">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>12.&nbsp;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, &ldquo;<a href="http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf">Secure Hash Signature Standard</a>,&rdquo; FIPS&nbsp;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, &ldquo;OpenID Authentication 2.0,&rdquo; 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>, &ldquo;<a href="http://tools.ietf.org/html/rfc1421">Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures</a>,&rdquo; RFC&nbsp;1421, February&nbsp;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>, &ldquo;<a href="http://tools.ietf.org/html/rfc1422">Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management</a>,&rdquo; RFC&nbsp;1422, February&nbsp;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>, &ldquo;<a href="http://tools.ietf.org/html/rfc1423">Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers</a>,&rdquo; RFC&nbsp;1423, February&nbsp;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>, &ldquo;<a href="http://tools.ietf.org/html/rfc1424">Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services</a>,&rdquo; RFC&nbsp;1424, February&nbsp;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>, &ldquo;<a href="http://tools.ietf.org/html/rfc1750">Randomness Recommendations for Security</a>,&rdquo; RFC&nbsp;1750, December&nbsp;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>, &ldquo;<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,&rdquo; BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;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>, &ldquo;<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>,&rdquo; RFC&nbsp;2616, June&nbsp;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="RFC3548">[RFC3548]</a></td>
<td class="author-text">Josefsson, S., &ldquo;<a href="http://tools.ietf.org/html/rfc3548">The Base16, Base32, and Base64 Data Encodings</a>,&rdquo; RFC&nbsp;3548, July&nbsp;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., &ldquo;<a href="http://tools.ietf.org/html/rfc3629">UTF-8, a transformation format of ISO 10646</a>,&rdquo; STD&nbsp;63, RFC&nbsp;3629, November&nbsp;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>, &ldquo;<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>,&rdquo; STD&nbsp;66, RFC&nbsp;3986, January&nbsp;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., &ldquo;<a href="http://tools.ietf.org/html/rfc4627">The application/json Media Type for JavaScript Object Notation (JSON)</a>,&rdquo; RFC&nbsp;4627, July&nbsp;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, &ldquo;<a href="http://csrc.nist.gov/publications/drafts/800-63-rev1/SP800-63-Rev1_Dec2008.pdf">NIST SP800-63rev.1: Electronic Authentication Guideline</a>,&rdquo; NIST&nbsp;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, &ldquo;<a href="http://jsonenc.info/1.0/">JSON Encryption Envelope</a>,&rdquo; February&nbsp;2010.</td></tr>
<tr><td class="author-text" valign="top"><a name="magic_signatures">[magic_signatures]</a></td>
<td class="author-text">Panzer, J. and B. Laurie, &ldquo;<a href="http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html">Magic Signatures</a>,&rdquo; February&nbsp;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">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>Author's Address</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">openid-specs-ab@openid.net</td></tr>
</table>
</body></html>