diff options
| author | Andrew Arnott <andrewarnott@gmail.com> | 2011-05-06 13:26:25 -0700 |
|---|---|---|
| committer | Andrew Arnott <andrewarnott@gmail.com> | 2011-05-06 13:26:25 -0700 |
| commit | 0d17e6bbbd119520269716fb5de7db36a1a28683 (patch) | |
| tree | c2ab3add3c3f8f58c4f0af44c962eb26e4672d58 /doc/specs | |
| parent | 5de32fe6bb05eed7a2b337227e5b0bb82c6baecd (diff) | |
| download | DotNetOpenAuth-0d17e6bbbd119520269716fb5de7db36a1a28683.zip DotNetOpenAuth-0d17e6bbbd119520269716fb5de7db36a1a28683.tar.gz DotNetOpenAuth-0d17e6bbbd119520269716fb5de7db36a1a28683.tar.bz2 | |
Added OpenID Connect Core draft 4.
Diffstat (limited to 'doc/specs')
| -rw-r--r-- | doc/specs/OpenID Connect Core.htm | 2240 |
1 files changed, 2240 insertions, 0 deletions
diff --git a/doc/specs/OpenID Connect Core.htm b/doc/specs/OpenID Connect Core.htm new file mode 100644 index 0000000..a4db283 --- /dev/null +++ b/doc/specs/OpenID Connect Core.htm @@ -0,0 +1,2240 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd"> +<!-- saved from url=(0055)http://openid4.us/specs/ab/openid-connect-core-1_0.html --> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><HTML +lang="en"><HEAD><TITLE>Draft: OpenID Connect Core 1.0 - draft 04</TITLE> +<META content="text/html; charset=utf-8" http-equiv="Content-Type"> +<META name="description" content="OpenID Connect Core 1.0 - draft 04"> +<META name="GENERATOR" content="MSHTML 9.00.8112.16421"> +<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 class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<TABLE border="0" cellSpacing="0" summary="layout" cellPadding="0" + width="66%"><TBODY> + <TR> + <TD> + <TABLE border="0" cellSpacing="1" summary="layout" cellPadding="2" width="100%"> + <TBODY> + <TR> + <TD class="header">Draft</TD> + <TD class="header">N. Sakimura, Ed.</TD></TR> + <TR> + <TD class="header"> </TD> + <TD class="header">NRI</TD></TR> + <TR> + <TD class="header"> </TD> + <TD class="header">D. Recordon</TD></TR> + <TR> + <TD class="header"> </TD> + <TD class="header">Facebook</TD></TR> + <TR> + <TD class="header"> </TD> + <TD class="header">J. Bradeley</TD></TR> + <TR> + <TD class="header"> </TD> + <TD class="header">Protiviti Government Services</TD></TR> + <TR> + <TD class="header"> </TD> + <TD class="header">B. de Madeiros</TD></TR> + <TR> + <TD class="header"> </TD> + <TD class="header">Google</TD></TR> + <TR> + <TD class="header"> </TD> + <TD class="header">M. Jones</TD></TR> + <TR> + <TD class="header"> </TD> + <TD class="header">Microsoft</TD></TR> + <TR> + <TD class="header"> </TD> + <TD class="header">E. Jay, Ed.</TD></TR> + <TR> + <TD class="header"> </TD> + <TD class="header">MGI1</TD></TR> + <TR> + <TD class="header"> </TD> + <TD class="header">May 1, 2011</TD></TR> +</TBODY></TABLE></TD></TR></TBODY></TABLE> +<H1><BR>OpenID Connect Core 1.0 - draft 04</H1> +<H3>Abstract</H3> +<P>OpenID Connect is an identity framework that provides authentication, +authorization, and attribute transmition capability. It allows third party +attested claims from distributed sources. The specification suite consists +of Building Blocks (Core, JSON Web Token, JSON Web Signatures, JSON WEB +Encryption, JSON Web Keys, Simple Web Discovery), Protocol Bindings (e.g, +Artifact Binding, Web App Binding, User Agent Binding) and Extensions. This +specification is the "Core" of the suite that defines the messages used and +abstract flow which will be further constrained or extended in the +companion specifications in the suite.</P><A name="toc"></A><BR> +<HR> + +<H3>Table of Contents</H3> +<P class="toc"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#rnc">1.</A> + Requirements Notation and Conventions<BR><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#terminology">2.</A> + Terminology<BR><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#anchor1">3.</A> + Overview<BR><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#anchor2">4.</A> + Messages<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#anchor3">4.1.</A> + Authorization Endpoint<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#anchor7">4.2.</A> + Token Endpoint<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#anchor11">4.3.</A> + UserInfo Endpoint<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#anchor15">4.4.</A> + Session Management Endpoints<BR><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#serializations">5.</A> + serializations<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#qss">5.1.</A> + Query String serialization<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#js">5.2.</A> + JSON Serialization<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#anchor19">5.3.</A> + Conversions of OpenID 2.0 encodings<BR><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#sigs">6.</A> + Signatures<BR><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#encryption">7.</A> + Encryption<BR><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#anchor23">8.</A> + Requests and Responses<BR><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#anchor24">9.</A> + Verification<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#anchor25">9.1.</A> + Authorization Request Verification<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#anchor26">9.2.</A> + Authorization Response Verification<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#anchor27">9.3.</A> + UserInfo Request Verification<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#anchor28">9.4.</A> + UserInfo Response Verification<BR><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#extensions">10.</A> + Extensions<BR><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#security_considerations">11.</A> + Security Considerations<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#assertion_manufacture">11.1.</A> + Assertion manufacture/modification<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#assertion_disclosure">11.2.</A> + Assertion disclosure<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#assertion_repudiation">11.3.</A> + Assertion repudiation<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#assertion_redirect">11.4.</A> + Assertion redirect<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#assertion_reuse">11.5.</A> + Assertion reuse<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#artifact_manufacture">11.6.</A> + Secondary authenticator manufacture<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#artifact_capture">11.7.</A> + Secondary authenticator capture<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#assertion_substitution">11.8.</A> + Assertion substitution<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#auth_req_disclosure">11.9.</A> + Authentication Request Disclosure<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#anchor29">11.10.</A> + Timing Attack<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#authn_proc_threats">11.11.</A> + Authentication Process Threats<BR><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#iana">12.</A> + IANA Considerations<BR> <A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#oauth_params">12.1.</A> + OAuth Parameters Registry<BR><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#anchor30">13.</A> + Open Issues and Things To Be Done (TBD)<BR><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#anchor31">Appendix A.</A> + Acknowledgements<BR><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#anchor32">Appendix B.</A> + Document History<BR><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#rfc.references1">14.</A> + Normative References<BR><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#rfc.authors">§</A> + Authors' Addresses<BR></P><BR clear="all"><A name="rnc"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></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="http://openid4.us/specs/ab/openid-connect-core-1_0.html#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 class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.2"></A> +<H3>2. Terminology</H3> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>Protected Resource</DT> + <DD>An access-restricted resource which can be obtained using an + OAuth-authenticated request.</DD> + <DT>Resource Server</DT> + <DD>A server capable of accepting and responding to protected + resource requests.</DD> + <DT>Client</DT> + <DD>An application obtaining authorization and making protected + resource requests on behalf of the resource owner and with its + authorization.</DD> + <DT>Resource Owner</DT> + <DD>An entity capable of granting access to a protected resource. + When the resource owner is a person, it is referred to as an + End-user.</DD> + <DT>End-user</DT> + <DD>A human resource owner.</DD> + <DT>Authentication</DT> + <DD>An act of verifying End-User's identity through the + verification of the credential.</DD> + <DT>Access Token</DT> + <DD>A string representing an access authorization issued to the + client. The string is usually opaque to the client. Tokens + represent specific scopes and durations of access, granted by the + resource owner, and enforced by the resource server and + authorization servers.</DD> + <DT>Refresh Token</DT> + <DD>A token used by the client to obtain a new access token without + having to involve the resource owner.</DD> + <DT>Authorization Code</DT> + <DD>A short-lived token representing the authorization provided by + the end-user. The authorization code is used to obtain an access + token and a refresh token.</DD> + <DT>Authorization Grant</DT> + <DD>A general term used to describe the intermediate credentials + (such as an end-user password or authorization code) representing + the resource owner authorization. Access grants are used by the + client to obtain an access token. By exchanging access grants of + different types for an access token, the resource server is only + required to support a single authentication scheme.</DD> + <DT>Authorization Server</DT> + <DD>A server capable of authenticating the resource owner and + issuing tokens after obtaining authorization from the authenticated + Resource Owner. The authorization server may be the same server as + Resource Server or a separate entity. A single authorization server + may issue tokens for multiple resource servers.</DD> + <DT>OpenID Provider (OP)</DT> + <DD>Authorization Servers that are able to support OpenID Connect + Messages.</DD> + <DT>Relying Party (RP)</DT> + <DD>Client and Resource Servers.</DD> + <DT>Authorization Endpoint</DT> + <DD>The Authorization Server's endpoint capable of authenticating + the End-User and obtaining authorization.</DD> + <DT>Client Identifier</DT> + <DD>An unique identifier that the client to identify itself to the + OP.</DD> + <DT>Client Secret</DT> + <DD>A shared secret established between the OP and client.</DD> + <DT>Token Endpoint</DT> + <DD>The Authorization Server's HTTP endpoint capable of issuing + tokens.</DD> + <DT>OP Endpoints</DT> + <DD>End-User Authentication, Authorization, and Token Endpoint. + </DD> + <DT>RP Endpoints</DT> + <DD>The endpoint to which the OP responses are returned through + redirect.</DD> + <DT>UserInfo Endpoint</DT> + <DD>A protected resource that when presented with a token by the + client returns authorized information about the current user.</DD> + <DT>Claims</DT> + <DD>A statement that something is true or factual.</DD> + <DT>Assertion</DT> + <DD>A set of Claims about the End-User which is attested by the OP + and Resource Servers.</DD> + <DT>Compact Serialization</DT> + <DD>Compact Serialization defined in <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#jwt">JSON + Web Token<SPAN> (</SPAN><SPAN class="info">Jones, M., Belfanz, D., Bradeley, + J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” + January 2011.</SPAN><SPAN>)</SPAN></A> [jwt].</DD> + <DT>Base64url</DT> + <DD>Base 64 Encoding <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#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></DL></BLOCKQUOTE> +<P></P><A name="anchor1"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.3"></A> +<H3>3. Overview</H3> +<P>OpenID Connect protocol in abstract follows the following steps.</P> +<P></P> +<OL class="text"> + <LI>The Client sends a request to the Server's End-User Authorization + Endpoint.</LI> + <LI>The Server authenticates the user and obtains appropriate + authorization.</LI> + <LI>The Server responds with access_token and a few other variables. + </LI> + <LI>The Client sends a request with the access_token to the Userinfo + Endpoint.</LI> + <LI>Userinfo Endpoint returns the additional user information + supported by the Server.</LI></OL> +<P>Each message may be signed and encrypted. When the message is encrypted, +it MUST be signed first then encrypted. This specification only defines the +abstract messsage flow and message formats. The actual use MUST base on one +of the companion protocol bindings specifications such as <A class="info" +href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#OpenID.AB">OpenID +Connect Artifact Binding 1.0<SPAN> (</SPAN><SPAN class="info">Sakimura, N., +Ed., Bradley, J., de Madeiros, B., Ito, R., and M. Jones, “OpenID Connect +Artifact Binding 1.0,” January 2011.</SPAN><SPAN>)</SPAN></A> [OpenID.AB] +or <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#OpenID.AC">OpenID +Connect Authorization Code Binding 1.0<SPAN> (</SPAN><SPAN +class="info">Mortimore, C., Ed., Sakimura, N., Bradley, J., de Madeiros, B., +Ito, R., and M. Jones, “OpenID Connect Authorization Code Binding 1.0,” +January 2011.</SPAN><SPAN>)</SPAN></A> [OpenID.AC].</P><A +name="anchor2"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4"></A> +<H3>4. Messages</H3> +<P></P> +<P>In OpenID Connect protocols in abstract, the process proceeds by the +Client interacting with Endpoints. There are number of Endpoints involved. +</P> +<P></P> +<OL class="text"> + <LI>Authorization Endpoint: The Client sends a request to the Server + at the Authorization endpoint. The Server then authenticate the + End-User to find out if he is eligible to make the authorization. + Then, upon the authorization action of the End-User, the Server + returns an Authorization Response that includes Authorization Code, + <TT>code</TT>. For some Clients, Implicit Grant may be used to obtain + <TT>access_token</TT> without using <TT>code</TT>. In this case, + <TT>response_type</TT> MUST be set to <TT>token</TT>.</LI> + <LI>Token Endpoint: The Client sends the Access Token Request to the + Token Endpoint to obtain Access Token Response which includes + <TT>access_token</TT>. </LI> + <LI>UserInfo Endpoint: The <TT>access_token</TT> MAY be used as a + query parameter to obtain user information/assertion/claims about the + user by sending a request to the userinfo endpoint.</LI> + <LI>Session Management Endpoints: The <TT>openid</TT> token MAY be sent to + these endpoints to manage the session. </LI></OL> +<P>Both Request and Response may either be serialized into <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#qss">Query +String serialization<SPAN> (</SPAN><SPAN class="info">Query String +serialization</SPAN><SPAN>)</SPAN></A> or <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#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]. </P> +<P></P><A name="anchor3"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.1"></A> +<H3>4.1. Authorization Endpoint</H3> +<P>Autorization Code Request / Response interacts with Authorization +Endpoint.</P><A name="auth_req"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.1.1"></A> +<H3>4.1.1. Authorization Request</H3> +<P>Following is the list of variables to be sent as the top level keys: +</P> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>response_type</DT> + <DD>REQUIRED. The parameter value MUST be set to <TT>code</TT> + for requesting an Authorization Code, <TT>token</TT> for + requesting an Access Token. The Authorization Server MAY decline + to provide one or more of these response types.</DD> + <DT>client_id </DT> + <DD>REQUIRED. The client identifier recognized by the + Authorization Server.</DD> + <DT>redirect_uri</DT> + <DD>REQUIRED unless a redirection URI has been established + between the client and authorization server via other means. An + absolute URI to which the authorization server will redirect + the user-agent to when the End-User authorization step is + completed. The authorization server SHOULD require the client + to pre-register their redirection URI.</DD> + <DT>scope</DT> + <DD>OPTIONAL. The scope of the access request expressed as a + list of space-delimited strings. The value of the scope + parameter is defined by the authorization server. If the value + contains multiple space-delimited strings, their order does not + matter, and each string adds an additional access range to the + requested scope. It MUST include <TT>openid</TT> as one of the string. + [[ToDo: Maybe we do not need it, as openid param is required.]] + </DD> + <DT>state</DT> + <DD>OPTIONAL. An opaque value used by the client to maintain + state between the request and callback. The authorization + server includes this value when redirecting the user-agent back + to the client.</DD> + <DT>openid</DT> + <DD>REQUIRED. A JSON object that holds OpenID request + variables.</DD> + <DT>type</DT> + <DD>REQUIRED. A type identifier that identifies the message + type. A URI <TT>http://openid.net/specs/cc/1.0#env</TT> .</DD></DL></BLOCKQUOTE> +<P></P> +<P>Following is the list of <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#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] + variables are to be sent under the key <TT>"openid"</TT>: when OpenID +2.0 identifier compatibility is sought.</P> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>type</DT> + <DD>REQUIRED. A type identifier that identifies the message + type. Set to <TT>"http://openid.net/specs/cc/1.0/#req"</TT>.</DD> + <DT>immediate</DT> + <DD>OPTIONAL. indicates if the authorization server should + display the authorization user interface. <TT>"True"</TT> if it should not + display the user interface or <TT>"False"</TT> to display. + Default is <TT>"False"</TT>.</DD> + <DT>claimed_id</DT> + <DD>OPTIONAL. The claimed_id as in <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#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]</DD> + <DT>identity</DT> + <DD>OPTIONAL. The local identifier as in <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#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].</DD> + <DT>realm</DT> + <DD>REQUIRED if PPID were used in previous authentications. URL + pattern the OP SHOULD ask the end user to trust. See Section + 9.2 of <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#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].</DD> + <DT>server_id</DT> + <DD>OPTIONAL. The intended recipient of this request.</DD> + <DT>pubkey</DT> + <DD>OPTIONAL. The base64url encoded DER format X.509 + certificate of the RP.</DD> + <DT>atype</DT> + <DD>OPTIONAL. Type of assertion to be returned at the end. + Values are one of the following: + <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+sig: openid2json assertion signed.</LI> + <LI>openid2json+sig+enc: openid2json assertion signed and + encrypted.</LI> + <LI>saml2: SAML ver.2 assertion.</LI> + <LI>wss : WS-Security assertion.</LI></UL></DD></DL></BLOCKQUOTE> +<P></P> +<P>These variables are sent from the client to the end-user +authorization endpoint according to the protocol bindings of this +specification. There are two serialization of the above variables: +Query Parameters serialization and JSON serialization.</P> +<P>Following is a non-normative example when they are sent in the +query parameters serialization.</P> +<DIV style="width: 0px; margin-right: auto; margin-left: 3em; display: table;"><PRE>GET /authorize?scope=openid&response_type=code +&openid.type=http%3A%2F%2Fopenid.net%2Fspecs%2Fcc%2F1.0%2F%23req +&client_id=s6BhdRkqt3&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 +Host: server.example.com</PRE></DIV> +<P></P> +<P>Following is a non-normative example when they are sent as a JSON +object serialization.</P> +<DIV style="width: 0px; margin-right: auto; margin-left: 3em; display: table;"><PRE>{ + "type": "http://openid.net/specs/cc/1.0#env, + "openid": { + "type": "http://openid.net/specs/cc/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.pape": "http://specs.openid.net/extensions/pape/1.0", + "pape.auth_level.ns.nist": "http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf", + "pape.preferred_auth_level_types": "nist" + }, + "redirect_uri": "https://example.com/rp/endpoint_url", + "response_type":"code", + "client_id": "http://example.com/rp/", + "scope": "openid", + "state": "af0ifjsldkj" +}</PRE></DIV> +<P></P><A name="anchor4"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.1.2"></A> +<H3>4.1.2. Authorization Response</H3> +<P>If the End-User grants the access request, the Authorization Server +issues an Authorization Code or an Access Token and delivers them to +the Client. Following are the list of the parameter included in the +Response message when the <TT>response_type</TT> in the request was +<TT>code</TT>. Note that if the <TT>response_type</TT> in the request was +<TT>token</TT>, the <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#access_token_response">Access +Token Response<SPAN> (</SPAN><SPAN class="info">Access Token +Response</SPAN><SPAN>)</SPAN></A> defined later MUST be returned +instead.</P> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>code</DT> + <DD>REQUIRED. The authorization code generated by the + authorization server. The authorization code SHOULD expire + shortly after it is issued to minimize the risk of leaks. The + client MUST NOT reuse the authorization code. If an + authorization code is used more than once, the authorization + server MAY revoke all tokens previously issued based on that + authorization code. The authorization code is bound to the + client identifier and redirection URI.</DD> + <DT>state</DT> + <DD>REQUIRED if the state parameter was present in the client + authorization request. Set to the exact value received from the + client.</DD></DL></BLOCKQUOTE> +<P></P> +<P>For example, the Authorization Server redirects the End-User's +user-agent by sending the following HTTP response:</P> +<DIV style="width: 0px; margin-right: auto; margin-left: 3em; display: table;"><PRE>HTTP/1.1 302 Found +Location: https://client.example.com/cb?code=i1WsRn1uB1</PRE></DIV> +<P></P> +<P>Clients SHOULD ignore unrecognized response parameters. The sizes of +tokens and other values received from the authorization server, are +left undefined by this specification. Clients should avoid making +assumptions about value sizes. Servers should document the expected +size of any value they issue.</P><A name="anchor5"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.1.3"></A> +<H3>4.1.3. Authorization Error Response</H3> +<P>If the end-user denies the access request or if the request fails +for reasons other than a missing or invalid redirection URI, the +authorization server informs the client by adding the following +parameters to the redirection URI query component using the +<TT>application/x-www-form-urlencoded</TT> format as defined by <A +class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#html401">W3C.REC&nbhy;html401&nbhy;19991224<SPAN> +(</SPAN><SPAN class="info">Ragget, D., “HTML 4.01 Specification,” +December 1999.</SPAN><SPAN>)</SPAN></A> [html401]:</P> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>error</DT> + <DD>REQUIRED. A single error code as described below.</DD> + <DT>error_description</DT> + <DD>OPTIONAL. A human-readable text providing additional + information, used to assist in the understanding and resolution + of the error occurred.</DD> + <DT>error_uri</DT> + <DD>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.</DD> + <DT>state</DT> + <DD>REQUIRED if the state parameter was present in the client + authorization request. Set to the exact value received from the + client.</DD></DL></BLOCKQUOTE> +<P></P><A name="anchor6"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.1.3.1"></A> +<H3>4.1.3.1. Error Codes</H3> +<P>The Authorization Server includes one of the following error codes +with the error response:</P> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>invalid_request </DT> + <DD>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.</DD> + <DT>invalid_client</DT> + <DD>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.</DD> + <DT>unauthorized_client </DT> + <DD>The authenticated client is not authorized to use the + access grant type provided.</DD> + <DT>invalid_grant</DT> + <DD>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).</DD> + <DT>unsupported_grant_type</DT> + <DD>The access grant included - its type or another attribute + - is not supported by the authorization server.</DD> + <DT>invalid_scope</DT> + <DD>The requested scope is invalid, unknown, malformed, or + exceeds the previously granted scope.</DD> + <DT>invalid_request_response_type</DT> + <DD>The requested response type is unsupported or is missing. + </DD> + <DT>invalid_request_type</DT> + <DD>The request type is unsupported.</DD> + <DT>invalid_request_openid_type</DT> + <DD>The openid type in the the request is not supported.</DD> + <DT>invalid_request_redirect_uri</DT> + <DD>The redirect_uri in the request is missing or malformed. + </DD> + <DT>invalid_request_signature</DT> + <DD>The request has an invalid signature.</DD> + <DT>invalid_request_realm</DT> + <DD>The openid request realm is missing or malformed.</DD> + <DT>invalid_request_atype</DT> + <DD>The request contains an unsupported response assertion + type.</DD> + <DT>invalid_request_recipient</DT> + <DD>The recipient of the request is invalid or does not + match.</DD></DL></BLOCKQUOTE> +<P></P> +<P>The error codes can be extended by the string prefixed by +<TT>x_</TT>. If custome error code are used, <TT>error_uri</TT> MUST +be provided.</P> +<P></P><A name="anchor7"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.2"></A> +<H3>4.2. Token Endpoint</H3> +<P>Access Token Request / Response interacts with an OpenID Token +Endpoint. Upon the successful request, the OpenID returns two tokens, +Access Token and OpenID Token.</P><A name="access_token_request"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.2.1"></A> +<H3>4.2.1. Access Token Request</H3> +<P>The client obtains an access token by authenticating with the +authorization server and presenting its access grant (in the form of an +authorization code, resource owner credentials, an assertion, or a +refresh token).</P> +<P>To make the Access Token Request, the Client sends the following +parameters to the Token Endpoint:</P> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>grant_type</DT> + <DD>REQUIRED. The access grant type included in the request. + Value MUST be one of <TT>authorization_code</TT>, <TT>refresh_token</TT>, or + an absolute URI identifying an assertion format supported by + the authorization server.</DD> + <DT>client_id</DT> + <DD>REQUIRED. The client identifier.</DD> + <DT>client_secret</DT> + <DD>REQUIRED. Client Secret. If the secret_type is + <TT>"shared"</TT>, send the pre-shared secret. If the + secret_type is <TT>"jwt"</TT>, send the compact serealization of + the <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#jwt">JWT<SPAN> + (</SPAN><SPAN class="info">Jones, M., Belfanz, D., Bradeley, J., Goland, Y., + Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” + January 2011.</SPAN><SPAN>)</SPAN></A> [jwt] Signature over the 'code'. + </DD> + <DT>secret_type</DT> + <DD>OPTIONAL. Type of the <TT>client_secret</TT>. <TT>"shared"</TT> or + <TT>"jwt"</TT>. Defaults to <TT>"shared"</TT>.</DD></DL></BLOCKQUOTE> +<P>In addition, the client MUST include the appropriate parameters +specified in the bindings used.</P><A name="access_token_response"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.2.2"></A> +<H3>4.2.2. Access Token Response</H3> +<P>After receiving and verifying a valid and authorized access token +request from the client, the Authorization Server returns a Positive +Assertion that includes an Access Token.</P> +<P>The token response contains the following parameters which 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. Numerical values are included as JSON numbers.</P> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>access_token</DT> + <DD>REQUIRED if the response type is <TT>token</TT> or + <TT>code_and_token</TT>, otherwise MUST NOT be included. The + Access Token issued by the Authorization Server.</DD> + <DT>token_type</DT> + <DD>REQUIRED. The type of the token issued. Value is case + insensitive.</DD> + <DT>refresh_token</DT> + <DD>OPTIONAL. The Refresh Token used to obtain new Access + Tokens using the same End-User authorization. The authorization + server SHOULD NOT issue a Refresh Token when the access grant + type is set to none.</DD> + <DT>expires_in</DT> + <DD>OPTIONAL. The duration in seconds of the access token + lifetime if an access token is included. 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.</DD> + <DT>scope</DT> + <DD>OPTIONAL. The scope of the access token as a list of + space-delimited strings. The value of the scope parameter is + defined by the authorization server. If the value contains + multiple space-delimited strings, their order does not matter, + and each string adds an additional access range to the + requested scope. The authorization server SHOULD include the + parameter if the requested scope is different from the one + requested by the client.</DD> + <DT>openid</DT> + <DD>REQUIRED if it was requested in the request. An OpenID + Token. It is a <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#jws">JWS<SPAN> + (</SPAN><SPAN class="info">Jones, M., Belfanz, D., Bradeley, J., Goland, Y., + Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” + March 2011.</SPAN><SPAN>)</SPAN></A> [jws] signed claim + described below.</DD></DL></BLOCKQUOTE> +<P></P> +<P></P> +<P>It MAY include any other extension parameters.</P> +<P></P> +<P>Following is a non-normative example.</P> +<DIV style="width: 0px; margin-right: auto; margin-left: 3em; display: table;"><PRE>{ + "access_token": "SlAV32hkKG", + "token_type": "jwt", + "refresh_token": "8xLOxBtZp8", + "user_id": "http://op.example.com/alice#1234", + "domain": "op.example.com", + "expires_in": 3600, + "openid":"jwtheader.jwtpayload.jwtcrypto" +}</PRE></DIV> +<P></P> +<P>Clients SHOULD ignore unrecognized response parameters. The sizes of +tokens and other values received from the authorization server, are +left undefined by this specification. Clients should avoid making +assumptions about value sizes. Servers should document the expected +size of any value they issue.</P><A name="anchor8"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.2.2.1"></A> +<H3>4.2.2.1. OpenID Token</H3> +<P>The OpenID Token is a JWS signed claim that attests the following: +</P> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>server_id</DT> + <DD>REQUIRED. The unique identifier of the authorization + server such that when paired with the user_id creates a + globally unique and never reassigned identifier.</DD> + <DT>user_id</DT> + <DD>REQUIRED. A locally unique and never reassigned + identifier for the user, which is intended to be consumed by + the Client. e.g. "24400320" or + "AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4". It MUST NOT exceed + 255 ASCII characters in length.</DD> + <DT>client_id</DT> + <DD>REQUIRED. The client identifier recognized by the + authorization server.</DD> + <DT>aud</DT> + <DD>REQUIRED. The <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#jwt">JWT<SPAN> + (</SPAN><SPAN class="info">Jones, M., Belfanz, D., Bradeley, J., Goland, Y., + Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” + January 2011.</SPAN><SPAN>)</SPAN></A> [jwt]aud (audience) claim.</DD> + <DT>exp</DT> + <DD>REQUIRED. The <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#jwt">JWT<SPAN> + (</SPAN><SPAN class="info">Jones, M., Belfanz, D., Bradeley, J., Goland, Y., + Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” + January 2011.</SPAN><SPAN>)</SPAN></A> [jwt] exp + (expiration time) claim.</DD> + <DT>pape</DT> + <DD>OPTIONAL. (TBD) If we want this token to be short, we + probably want to define a shorter equivalent of PAPE. </DD> +</DL></BLOCKQUOTE> +<P></P> +<P></P><A name="anchor9"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.2.3"></A> +<H3>4.2.3. Token Error Response</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> +<BLOCKQUOTE class="text"> + <DL> + <DT>error</DT> + <DD>REQUIRED. A single error code as described below.</DD> + <DT>error_description</DT> + <DD>OPTIONAL. A human-readable text providing additional + information, used to assist in the understanding and resolution + of the error occurred.</DD> + <DT>error_uri</DT> + <DD>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.</DD></DL></BLOCKQUOTE> +<P></P> +<P></P><A name="anchor10"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.2.3.1"></A> +<H3>4.2.3.1. Error Codes</H3> +<P>The Authorization Server includes one of the following error codes +with the error response:</P> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>invalid_request </DT> + <DD>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.</DD> + <DT>invalid_client</DT> + <DD>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.</DD> + <DT>unauthorized_client </DT> + <DD>The authenticated client is not authorized to use the + access grant type provided.</DD> + <DT>invalid_grant</DT> + <DD>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).</DD> + <DT>unsupported_grant_type</DT> + <DD>The access grant included - its type or another attribute + - is not supported by the authorization server.</DD> + <DT>invalid_scope</DT> + <DD>The requested scope is invalid, unknown, malformed, or + exceeds the previously granted scope.</DD> + <DT>invalid_client_secret</DT> + <DD>The client secret does not matched pre-shared secret + code, is of a different type, or has an invalid signature. + </DD> + <DT>invalid_secret_type</DT> + <DD>The specified secret type is unsupported.</DD> + <DT>invalid_request_signature</DT> + <DD>The request has an invalid signature.</DD> + <DT>invalid_request_code</DT> + <DD>The authorization code is missing, malformed, or invalid. + </DD> + <DT>invalid_request_openid_type</DT> + <DD>The openid type in the the request is not supported.</DD> + </DL></BLOCKQUOTE> +<P>The error codes can be extended by the string prefixed by +<TT>x_</TT>. If custome error code are used, <TT>error_uri</TT> MUST +be provided.</P><A name="anchor11"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.3"></A> +<H3>4.3. UserInfo Endpoint</H3> +<P>UserInfo Request/Response interacts with UserInfo Endpoint.</P><A name="anchor12"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.3.1"></A> +<H3>4.3.1. UserInfo Request</H3> +<P>Client MAY send request with following parameters to the UserInfo +Endpoint to obtain further information about the user.</P> +<P>[[TBD: How to ask the attributes the Client is requesting?]]</P> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>access_token</DT> + <DD>REQUIRED. The access_token obtained above.</DD> + <DT>user_id</DT> + <DD>REQUIRED. A locally unique and never reassigned identifier + for the user. e.g. "24400320" or + "AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4". It MUST NOT exceed + 255 ASCII characters in length. It could be a pairwise private + identifier of the enduser between the Client and the Server.</DD> + <DT>client_id</DT> + <DD>REQUIRED. The client identifier recognized by the + authorization server.</DD></DL></BLOCKQUOTE> +<P></P><A name="anchor13"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.3.2"></A> +<H3>4.3.2. UserInfo Response</H3> +<P>The response is a JSON object which contains some (or all) of the +following reserved keys:</P> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>user_id</DT> + <DD>REQUIRED. A locally unique and never reassigned identifier + for the user. e.g. "24400320" or + "AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4". It MUST NOT exceed + 255 ASCII characters in length. It MUST NOT be reassigned to + another user. </DD> + <DT>server_id</DT> + <DD>REQUIRED. The unique identifier of the authorization server + such that when paired with the user_id creates a globally + unique and never reassigned identifier.</DD> + <DT>client_id</DT> + <DD>REQUIRED. The client identifier recognized by the + authorization server.</DD> + <DT>asserted_user</DT> + <DD>REQUIRED. One of "true" if the access was issued for this + user or "false" if it is for a different user.</DD> + <DT>profile_urls</DT> + <DD>OPTIONAL. An array of URLs that belong to the user across + any number of domains.</DD> + <DT>display_name</DT> + <DD>OPTIONAL. The display name of the user. e.g., "David + Recordon".</DD> + <DT>given_name</DT> + <DD>OPTIONAL. The first name of the user. e.g., "David".</DD> + <DT>family_name</DT> + <DD>OPTIONAL. The family name of the user. e.g., "Recordon". + </DD> + <DT>email</DT> + <DD>OPTIONAL. The verified email address of the user. e.g., + "recordond@gmail.com".</DD> + <DT>language</DT> + <DD>OPTIONAL. End User's preferred language as specified by + ISO639.</DD> + <DT>picture</DT> + <DD>OPTIONAL. The URL of End User's Picture. e.g., + "http://graph.facebook.com/davidrecordon/picture".</DD> + <DT>openid</DT> + <DD>REQUIRED if OpenID variables were specified in the + Authorization Request. It is a JSON Object. </DD></DL></BLOCKQUOTE> +<P></P> +<P>If the OP desires to provide the identifier transition service from +OpenID 2.0, it SHOULD provide the following parameters in addition +under the key <TT>openid</TT>. The key <TT>openid</TT> includes the +following parameters. </P> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>claimed_id</DT> + <DD>OPTIONAL. The OpenID 2.0 verified identifier of this user, + if the user has OpenID 2.0 account.</DD> + <DT>identity</DT> + <DD>OPTIONAL. The OpenID 2.0 Local ID that this user was + verified against, if the user has OpenID 2.0 account.</DD> + <DT>op_endpoint</DT> + <DD>OPTIONAL. The OP Endpoint URL.</DD></DL></BLOCKQUOTE> +<P>Upon receipt of these parameters, the Client MUST migrate the user +to the new <TT>user_id</TT>. </P> +<P>If the Authorization Server supports authorization for distributed +resources from different entities, it needs to provide different Access +Tokens to each resource endpoints. To do this, it returns a JSON object +<TT>access_tokens</TT>.</P> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>access_tokens</DT> + <DD>OPTIONAL. An array of JSON objects that has "endpoint", + "access_token", "user_id" and "expires_in" as its subkey.</DD> + </DL></BLOCKQUOTE> +<P>The key <TT>"access_tokens" </TT>holds an array of JSON object +composed of the following parameters.</P> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>endpoint</DT> + <DD>REQUIRED. Resource Endpoint URL to which the token is used + to access.</DD> + <DT>access_token</DT> + <DD>REQUIRED. Access token used to access the resource. + [Alternatively: An array of JSON objects that has "user_id", + "expires_in" and other variables that the resource requires, + which is encoded into Encrypted JWT.]</DD> + <DT>token_type</DT> + <DD>OPTIONAL. "plain", "jwt", or a fully qualified type URI of + the token's type. Defaults to "plain".</DD> + <DT>expires_in</DT> + <DD>OPTIONAL. The duration in seconds of the access token + lifetime if an access token is included. 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. If token type is "jwt", then it MUST NOT be specified. + </DD></DL></BLOCKQUOTE> +<P></P> +<P></P><A name="anchor14"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.3.3"></A> +<H3>4.3.3. UserInfo Error Response</H3> +<P>(TBD)</P> +<P>The Authorization Server includes one of the following error codes +with the error response:</P> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>invalid_request </DT> + <DD>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.</DD> + <DT>invalid_client</DT> + <DD>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.</DD> + <DT>unauthorized_client </DT> + <DD>The authenticated client is not authorized to use the + access grant type provided.</DD> + <DT>invalid_grant</DT> + <DD>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).</DD> + <DT>unsupported_grant_type</DT> + <DD>The access grant included - its type or another attribute - + is not supported by the authorization server.</DD> + <DT>invalid_scope</DT> + <DD>The requested scope is invalid, unknown, malformed, or + exceeds the previously granted scope.</DD> + <DT>invalid_access_token</DT> + <DD>The access token is not valid for the requested resource, + malformed, is in an incorrect format, outside the valid scope, + or expired.</DD> + <DT>invalid_refresh_token</DT> + <DD>The refresh token is not valid, malformed, is in an + incorrect format, outside the valid scope, or expired.</DD> + <DT>invalid_request_signature</DT> + <DD>The request has an invalid signature.</DD> + <DT>invalid_request_type</DT> + <DD>The request type is unsupported.</DD> + <DT>invalid_request_atype</DT> + <DD>The request contains an unsupported response assertion + type.</DD> + <DT>invalid_request_recipient</DT> + <DD>The recipient of the request is invalid or does not match. + </DD></DL></BLOCKQUOTE> +<P></P><A name="anchor15"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.4"></A> +<H3>4.4. Session Management Endpoints</H3> +<P>To manage a session, the client sends a request to the session +management endpoints at the authorization server. The session management +endpoints at the authorization server are:</P> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>Session Refresh</DT> + <DD>Refreshes an expired ID Token</DD> + <DT>Check Session</DT> + <DD>Get a plain text JSON structure from a ID Token</DD> + <DT>End Session</DT> + <DD>Ends a session</DD></DL></BLOCKQUOTE> +<P></P> +<P></P> +<P>The sequences for session management are as follows:</P><A +name="anchor16"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.4.1"></A> +<H3>4.4.1. Session Refresh</H3> +<P>To refresh a ID Token session that has expired, the client sends a +request to the Refresh Session endpoint with an ID Token. A new ID +Token is returned in JWS signed format.</P> +<P>Request Parameters:</P> +<BLOCKQUOTE class="text"> + <DL> + <DT>openid</DT> + <DD>REQUIRED. A previously issued ID Token from a session + request</DD> + <DT>state</DT> + <DD>REQUIRED. An opaque value used by the Client to maintain + state between the request and callback. If provided, the + Authorization Server MUST include this value when redirecting + the user-agent back to the Client. Clients are strongly advised + to use this variable to relate the request and response.</DD> + <DT>redirect_uri</DT> + <DD>REQUIRED. An absolute URI to which the authorization server + will redirect the user-agent to with the new ID Token.</DD> +</DL></BLOCKQUOTE> +<P>Response:</P> +<P>The response is a new ID Token. In a typical HTTP binding, an HTTP +302 redirect to the specified redirect_uri in the request with a new ID +Token.</P> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>openid</DT> + <DD>A new ID Token</DD></DL></BLOCKQUOTE> +<P></P> +<P></P> +<P>The following is a non-normative session refresh request:</P> +<P></P> +<DIV style="width: 0px; margin-right: auto; margin-left: 3em; display: table;"><PRE>Request: + +GET /op/refresh_token?openid=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20iLCJhdWRpZW5jZSI6ImNsaWVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJleHAiOjEzMDM4NTI3MzJ9.Vdj-sU3xxwHRd9rF6gjBTw3YMm1BqmT43fGDCpa96jo +&state=bar&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fidtoken_cb +Host: server.example.com + +Response: + +HTTP/1.1 302 OK +Location: http://client.example.com/idtoken_cb?openid=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20iLCJhdWRpZW5jZSI6ImNsaWVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJleHAiOjEzMDM4NTI4ODB9.aJwagC6501Da-zK-X8Az9B-Y625aSEfxVuBpFEDjOxQ&state=bar&expires_in=3600 +</PRE></DIV> +<P></P><A name="anchor17"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.4.2"></A> +<H3>4.4.2. Check Session</H3> +<P>For clients that are not capable of dealing with JWS signed ID +Tokens, they can send the ID Token to the Check Session endpoint. It +will validate the ID Token and return a plain text JSON structure of +the ID Token.</P> +<P>Request Parameters:</P> +<BLOCKQUOTE class="text"> + <DL> + <DT>openid</DT> + <DD>REQUIRED. A previously issued ID Token from a session + request</DD></DL></BLOCKQUOTE> +<P>Response:</P> +<P>The response body is a plain text JSON structure of the base64url +decoded payload of the signed ID Token. In a typical HTTP binding, the +response is a HTTP 200 response code with the content-type header set +to "application/json". </P> +<P>The following is a non-normative example of a check session request: +</P> +<P></P> +<DIV style="width: 0px; margin-right: auto; margin-left: 3em; display: table;"><PRE>Request: +POST /op/check_openid?openid=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20iLCJhdWRpZW5jZSI6ImNsaWVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJleHAiOjEzMDM4NTI4ODB9.aJwagC6501Da-zK-X8Az9B-Y625aSEfxVuBpFEDjOxQ + +Response: +HTTP/1.1 200 OK +Content-Type: application/json + +{ + "iss":"http://server.example.com", + "client_id","http://client.example.com", + "audience", "http://client.example.com", + "user_id":"user_328723", + "exp":1303852880 +} + + +</PRE></DIV> +<P></P><A name="anchor18"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.4.4.3"></A> +<H3>4.4.3. End Session</H3> +<P>To end the session, the client sends a ID Token to the End Session +endpoint. Upon receiving the request, the authorization server performs +the logout flow for the user and then redirects the user-agent to the +specified redirect_uri.</P> +<P>Request Parameters:</P> +<BLOCKQUOTE class="text"> + <DL> + <DT>openid</DT> + <DD>REQUIRED. A previously issued ID Token from a session + request</DD> + <DT>state</DT> + <DD>REQUIRED. An opaque value used by the Client to maintain + state between the request and callback. If provided, the + Authorization Server MUST include this value when redirecting + the user-agent back to the Client. Clients are strongly advised + to use this variable to relate the request and response.</DD> + <DT>redirect_uri</DT> + <DD>REQUIRED. An absolute URI to which the authorization server + will redirect the user-agent to with the new ID Token.</DD> +</DL></BLOCKQUOTE> +<P>Response:</P> +<P>The response is dependant on the particular binding. In HTTP +binding, the response is a HTTP 302 redirect response to the +redirect_uri specified in the request.</P> +<P>The following is a non-normative session refresh request:</P> +<P></P> +<DIV style="width: 0px; margin-right: auto; margin-left: 3em; display: table;"><PRE>Request: + +GET /op/end_session?openid=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20iLCJhdWRpZW5jZSI6ImNsaWVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJleHAiOjEzMDM4NTI4ODB9.aJwagC6501Da-zK-X8Az9B-Y625aSEfxVuBpFEDjOxQ&state=bar&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fendtoken_cb +Host: server.example.com + +... + Authorizion server performs logout flow +... + +Response: + +HTTP/1.1 302 OK +Location: http://client.example.com/endtoken_cb?state=bar +</PRE></DIV> +<P></P><A name="serializations"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.5"></A> +<H3>5. serializations</H3> +<P>Each message can be serialized either in query parameter serialization +or JSON serialization unless it was explicitly stated in the previous +sections.</P><A name="qss"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.5.1"></A> +<H3>5.1. Query String serialization</H3> +<P>In order to serialize the parameters into Query String Serialization, +the client constructs the string by adding the following parameters to +the end-user authorization endpoint URI query component using the +<TT>application/x-www-form-urlencoded</TT> format as defined by <A class="info" +href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#html401">HTML 4.01 +Specification<SPAN> (</SPAN><SPAN class="info">Ragget, D., “HTML 4.01 +Specification,” December 1999.</SPAN><SPAN>)</SPAN></A> [html401]:</P> +<P>Following is a non-normative example of such Serialization.</P> +<DIV style="width: 0px; margin-right: auto; margin-left: 3em; display: table;"><PRE>GET /authorize?scope=openid&response_type=code&openid.type=http%3A%2F%2Fopenid.net%2Fspecs%2Fcc%2F1.0%2F%23req& +client_id=s6BhdRkqt3&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HT +TP/1.1 +Host: server.example.com</PRE></DIV> +<A name="js"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.5.2"></A> +<H3>5.2. JSON Serialization</H3> +<P>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. Numerical values are included as +JSON numbers. Each parameter may have JSON Structure as its value.</P> +<P>Following is a non-normative example of such Serialization.</P> +<DIV style="width: 0px; margin-right: auto; margin-left: 3em; display: table;"><PRE>{ + "access_token":"SlAV32hkKG", + "expires_in":3600, + "refresh_token":"8xLOxBtZp8", + "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 + } +}</PRE></DIV> +<A name="anchor19"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.5.3"></A> +<H3>5.3. Conversions of OpenID 2.0 encodings</H3> +<P>The two encoding form used in <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#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>, "HTTP encoding" and "key-value form +encoding" can be converted to the OpenID Connect JSON form as follows: +</P><A name="anchor20"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.5.3.1"></A> +<H3>5.3.1. key-value form encoding Conversion</H3> +<P>Section 4.1.1 of <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#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> defines key-value form encoding. Each +line begins with a key, followed by a colon, and the value associated +with the key. The line is terminated by a single newline (UCS codepoint +10, "\n"). A key or value MUST NOT contain a newline and a key also +MUST NOT contain a colon.</P> +<P>This encoding can be trivially converted to JSON objects by making +the key the JSON key and the value the JSON value. The resulting JSON +object is stored as the value of the top-level key "openid".</P> +<P>For example, the key-value form encoding</P> +<DIV style="width: 0px; margin-right: auto; margin-left: 3em; display: table;"><PRE>mode:error +error:This is an example message +</PRE></DIV> +<P>is converted to a OpenID JSON Encoding as</P> +<DIV style="width: 0px; margin-right: auto; margin-left: 3em; display: table;"><PRE>{ + "openid": { + "mode": "error", + "error": "This is an example message" + } +}</PRE></DIV> +<A name="anchor21"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.5.3.2"></A> +<H3>5.3.2. HTTP encoding Conversion</H3> +<P>In <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#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 query parameters are prefixed by +"openid." : e.g., openid.sreg.fname and openid.pape.level. They can be +translated into a JSON object by listing all the query parameters under +the key "openid". Subkeys are constructed by removing "openid." prefix +from each parameters. For values, strings are converted to JSON String +and num</P> +<P>For example, a query string +openid.sreg.fname=Nat&openid.pape.level=1 are converted to JSON as +follows:</P> +<DIV style="width: 0px; margin-right: auto; margin-left: 3em; display: table;"><PRE>{ + "openid":{ + "sreg.fname":"Nat", + "pape.level":1 + } +}</PRE></DIV> +<P></P><A name="anchor22"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.5.3.3"></A> +<H3>5.3.3. Additional Constraint</H3> +<P>To simplify the implementations, the following practice is strongly +RECOMMENDED.</P> +<P></P> +<UL class="text"> + <LI>For the support of the <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#PAPE1.0">[PAPE1.0]<SPAN> + (</SPAN><SPAN class="info">Recordon, D., Jones, M., Bufu, J., Ed., Daughty, + J., and N. Sakimura, “OpenID Provider Authentication Property Extension 1.0,” + December 2008.</SPAN><SPAN>)</SPAN></A>, use "pape" as the + prefix.</LI> + <LI>For the support of the <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#AX1.0">[AX1.0]<SPAN> + (</SPAN><SPAN class="info">Hardt, D., Bufu, J., and J. Hoyt, “OpenID Attribute + Exchange 1.0,” December 2007.</SPAN><SPAN>)</SPAN></A>, use "ax" as + the prefix.</LI> + <LI>For the support of the SREG1.1, use "sreg" as the prefix.</LI></UL> +<P></P><A name="sigs"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.6"></A> +<H3>6. Signatures</H3> +<P>Depending on the transport through wich the messages are transported, +the integrity of the message may not be guaranteed, nor the originator of +the message is not authenticated. To mitigate these risks, OpenID Connect +supports <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#jws">JSON +Web Signatures(JWS)<SPAN> (</SPAN><SPAN class="info">Jones, M., Belfanz, D., +Bradeley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web +Signatures,” March 2011.</SPAN><SPAN>)</SPAN></A> [jws].</P> +<P>Following is the parameters for JWT.</P> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>typ</DT> + <DD>OPTIONAL. One of <TT>"JWT"</TT>, <TT>"openid2json+sig"</TT>.</DD> + <DT>alg</DT> + <DD>REQUIRED. One of the algorithm specified in Table 4 of <A + class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#jwt">JWT<SPAN> + (</SPAN><SPAN class="info">Jones, M., Belfanz, D., Bradeley, J., Goland, Y., + Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” + January 2011.</SPAN><SPAN>)</SPAN></A> [jwt]</DD></DL></BLOCKQUOTE> +<P>Compact Serialization SHOULD BE used when passing it through query +parameters, while JSON serialization SHOULD BE used when returning it in +HTTP Body.</P> +<P>Following is a non-normative example of such signature in Compact +serialization, where HS256 algorithm was used (with line breaks for +display purposes only):</P> +<DIV style="width: 0px; margin-right: auto; margin-left: 3em; display: table;"><PRE>eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 +. +eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ +. +dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk</PRE></DIV> +<P></P> +<P>Following is a non-normative example of such signature in JSON +serialization, where ES256 algorithm was used.</P> +<DIV style="width: 0px; margin-right: auto; margin-left: 3em; display: table;"><PRE>{ + "header": [ + "eyJhbGciOiJFUzI1NiJ9" + ], + "payload": "eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ", + "signature": [ + "DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSApmWQxfKTUJqPP3-Kg6NU1Q" + ] +}</PRE></DIV> +<P></P><A name="encryption"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.7"></A> +<H3>7. Encryption</H3> +<P>To achieve message confidentiality and audience restriction, OpenID +Connect uses <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#jwe">JSON +Web Encryption (JWE)<SPAN> (</SPAN><SPAN class="info">Jones, M., Belfanz, D., +Bradeley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web +Encryption,” March 2011.</SPAN><SPAN>)</SPAN></A> [jwe].</P><A name="anchor23"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.8"></A> +<H3>8. Requests and Responses</H3> +<P>Requests and Responses can either be plain, signed or encrypted. +Signature should be applied to the entire request or response. Signed +request and responses in the query are sent in the parameter "signed" +together with other parameters. If the request and responses are in the +JSON Serialization, the JWS signed version MUST use the JSON serialization. +</P> +<P>If the request and responses are to be encrypted with <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#jwe">JSON +Web Encryption (JWE)<SPAN> (</SPAN><SPAN class="info">Jones, M., Belfanz, D., +Bradeley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web +Encryption,” March 2011.</SPAN><SPAN>)</SPAN></A> [jwe], non-encrypted +payload MUST NOT be sent. The parameter name for the encrypted payload MUST +be 'jwe'.</P><A name="anchor24"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.9"></A> +<H3>9. Verification</H3> +<P></P><A name="anchor25"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.9.1"></A> +<H3>9.1. Authorization Request Verification</H3> +<P>If the request was signed, the Server MUST verify the signature as in +JWT.</P><A name="anchor26"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.9.2"></A> +<H3>9.2. Authorization Response Verification</H3> +<P>To verify the validity of the Authorization Response, the client MUST +to the following:</P> +<P></P> +<OL class="text"> + <LI>If the response was signed, the Client SHOULD verify the + signature as in JWT as the first step.</LI> + <LI>Check that OP that it connected was really the intended OP + through TLS/SSL server certificate check if the endpoint is TLS/SSL + endpoint.</LI> + <LI>Check if "type" is "http://openid.net/specs/cc/1.0/#id_res". + </LI> + <LI>Verify that the "domain" matches the domain including + sub-domain of the server's token endpoint URI.</LI> + <LI>Check if the current time is after "issued_at" and before + "issued_at" + "expires_in".</LI> + <LI>If the claimed_id field is present, the client MUST verify that + the user info endpoint is authoritative to issue assertions about + it. This is done by performing OpenID 2.0 discovery on the URL and + finding a <xrd:Service> element with the following + information: + <UL class="text"> + <LI><xrd:Type> - whose text content is + "http://openid.net/specs/cc/1.0/".</LI> + <LI><xrd:URI> - whose text content is the URL of this + user info endpoint.</LI></UL></LI> + <LI>If this tag is not found via OpenID 2.0 discovery or if the URI + does not match, the client MUST ignore the presence of the <TT>claimed_id</TT> + parameter.</LI></OL> +<P>Note: An authorization server MUST only issue assertions about user +identifiers on its domain. The authorization server is responsible for +managing its own local namespace and enforcing that each user_id is +locally unique and never reassigned.</P> +<P>If the client does not verify the signature, it MUST make a User Info +API request.</P><A name="anchor27"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.9.3"></A> +<H3>9.3. UserInfo Request Verification</H3> +<P>If the request was signed, the Server MUST verify the signature as in +<A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#jwt">JWT<SPAN> +(</SPAN><SPAN class="info">Jones, M., Belfanz, D., Bradeley, J., Goland, Y., +Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” +January 2011.</SPAN><SPAN>)</SPAN></A> [jwt].</P><A +name="anchor28"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.9.4"></A> +<H3>9.4. UserInfo Response Verification</H3> +<P>To verify the validity of the UserInfo Response, the client MUST to +the following:</P> +<P></P> +<OL class="text"> + <LI>If the response was signed, the Client SHOULD verify the + signature as in JWT as the first step.</LI> + <LI>Check that OP that it connected was really the intended OP + through TLS/SSL server certificate check if the endpoint is TLS/SSL + endpoint.</LI> + <LI>Check if the current time is after "issued_at" and before + "issued_at" + "expires_in".</LI></OL> +<P></P> +<P></P><A name="extensions"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.10"></A> +<H3>10. Extensions</H3> +<P>OpenID Connect supports the extensions that are as defined in Section 12 +of <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#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 specification adds following list to +the disallowed aliases.</P> +<P>request_uri, refresh_uri, op_endpoint, user_id, redirect_uri, client_id, +server_id, client_meta_uri, server_meta_uri, 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 class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></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="http://openid4.us/specs/ab/openid-connect-core-1_0.html#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 class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></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> +<P></P><A name="assertion_disclosure"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></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> +<P></P><A name="assertion_repudiation"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></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 class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></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 class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></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 class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></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 class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></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 class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></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 class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></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="anchor29"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></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 class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></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 class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.12"></A> +<H3>12. IANA Considerations</H3><A name="oauth_params"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></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 <TT>WWW-Authenticate</TT> header field.</P> +<P>Change controller: IETF</P> +<P>Specification document(s): [[ this document ]]</P> +<P>Related information: None</P><A name="anchor30"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.13"></A> +<H3>13. Open Issues and Things To Be Done (TBD)</H3> +<P>[[To be removed from the final specification.]]</P> +<P>Following items remains to be done in this draft.</P> +<P></P> +<OL class="text"> + <LI>Check that all the "protocols" has been abstracted and "messages" + are protocol independent.</LI> + <LI>IANA registration issue while OAuth registry is not up yet.</LI> + <LI>Clean Up and add references.</LI> + <LI>Update JWT/JWS/JWE related things with the most current version + of them.</LI> + <LI>Finish the security consideration section.</LI> + <LI>Properly capitalize the Defined Words.</LI> + <LI>Better to split the Authentication and Authorization server? + (Model-wise, yes, but it gets complicated. Current model is + implicitly assuming that the Authentication and Authorization server + are operated by the same entity and the protocol between them are + proprietary.)</LI></OL> +<P></P><A name="anchor31"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.A"></A> +<H3>Appendix A. Acknowledgements</H3> +<P>As a successor version of <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#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], + this specification heavily relies on <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#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]. + Please refer to Appendix C of <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#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] +for the full list of the contributors for <A class="info" href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#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>This specification is largely compliant with OAuth 2.0 draft 15. As the +draft is not yet referenceable, relevant text has been incorporated into +this draft. Please refer to the OAuth 2.0 specification for the list of +contributors.</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> +<P></P> +<BLOCKQUOTE class="text"> + <P>Anthony Nadalin (tonynad@microsoft.com), Microsoft.</P> + <P>Breno de Medeiros (breno@gmail.com), Google.</P> + <P>Chuck Mortimore (cmortimore@salesforce.com), Salesforce.com.</P> + <P>David Recordon (dr@fb.com)<author>, Facebook.</P> + <P>George Fletcher (george.fletcher@corp.aol.com), AOL.</P> + <P>Hideki Nara (hideki.nara@gmail.com), Takt Communications.</P> + <P>John Bradley (jbradely@mac.com) <author>, Protiviti + Government Service.</P> + <P>Mike Jones (Michael.Jones@microsoft.com), Microsoft.</P> + <P>Nat Sakimura (n-sakimura@nri.co.jp) <author/editor>, Nomura + Research Institute, Ltd.</P> + <P>Paul Tarjan (pt@fb.com), Facebook.</P> + <P>Ryo Itou (ritou@yahoo-corp.jp), Yahoo! Japan.</P></BLOCKQUOTE> +<P></P><A name="anchor32"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="rfc.section.B"></A> +<H3>Appendix B. Document History</H3> +<P></P> +<BLOCKQUOTE class="text"> + <DL> + <DT>-01</DT> + <DD>First Draft that incorporates the core of both openidonnect.com + proposal and OpenID Artifact Binding RC3 and abstracted.</DD> + <DT>-02</DT> + <DD>Catch up to OAuth 2.0 d15. Replaced JSS and JSE to JWS and JWE. + Section grouping and reorganizations. Added more contributors.</DD> + <DT>-03</DT> + <DD>Combined with Session Management. Moved "openid" back to Token + Endpoint. Renaming the sections according to the Endpoint names. + Rewrote intro to the Messages section to be more approacheable. + </DD> + <DT>-04</DT> + <DD>To keep the ID Token small so that it fits cookie more easily, + moved OPTIONAL parameters to UserInfo endpoint response. </DD> +</DL></BLOCKQUOTE> +<P></P><A name="rfc.references1"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<H3>14. Normative References</H3> +<TABLE border="0" width="99%"> + <TBODY> + <TR> + <TD class="author-text" vAlign="top"><A name="AX1.0">[AX1.0]</A></TD> + <TD class="author-text">Hardt, D., Bufu, J., and J. Hoyt, “<A href="http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html">OpenID + Attribute Exchange 1.0</A>,” December 2007.</TD></TR> + <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.AB">[OpenID.AB]</A></TD> + <TD class="author-text">Sakimura, N., Ed., Bradley, J., de Madeiros, B., + Ito, R., and M. Jones, “<A href="http://openid.net/specs/ab/1.0/">OpenID + Connect Artifact Binding 1.0</A>,” January 2011.</TD></TR> + <TR> + <TD class="author-text" vAlign="top"><A + name="OpenID.AC">[OpenID.AC]</A></TD> + <TD class="author-text">Mortimore, C., Ed., Sakimura, N., Bradley, J., de + Madeiros, B., Ito, R., and M. Jones, “<A href="http://openid.net/specs/ab/1.0/">OpenID + Connect Authorization Code Binding 1.0</A>,” January 2011.</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="PAPE1.0">[PAPE1.0]</A></TD> + <TD class="author-text">Recordon, D., Jones, M., Bufu, J., Ed., Daughty, + J., and N. Sakimura, “<A href="http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html">OpenID + Provider Authentication Property Extension 1.0</A>,” + December 2008.</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="RFC3339">[RFC3339]</A></TD> + <TD class="author-text"><A href="mailto:GK@ACM.ORG">Klyne, G., Ed.</A> and + <A href="mailto:chris.newman@sun.com">C. Newman</A>, “<A href="http://tools.ietf.org/html/rfc3339">Date + and Time on the Internet: Timestamps</A>,” RFC 3339, July 2002 + (<A href="http://www.rfc-editor.org/rfc/rfc3339.txt">TXT</A>, <A href="http://xml.resource.org/public/rfc/html/rfc3339.html">HTML</A>, + <A + href="http://xml.resource.org/public/rfc/xml/rfc3339.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="RFC5246">[RFC5246]</A></TD> + <TD class="author-text">Dierks, T. and E. Rescorla, “<A href="http://tools.ietf.org/html/rfc5246">The + Transport Layer Security (TLS) Protocol Version 1.2</A>,” RFC 5246, + August 2008 (<A + href="http://www.rfc-editor.org/rfc/rfc5246.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="SREG1.0">[SREG1.0]</A></TD> + <TD class="author-text">Hoyt, J., Hoyt, J., and D. Recordon, “<A href="http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html">OpenID + Simple Registration Extension 1.0</A>,” December 2007.</TD></TR> + <TR> + <TD class="author-text" vAlign="top"><A name="html401">[html401]</A></TD> + <TD class="author-text">Ragget, D., “<A href="http://www.w3.org/TR/html401/">HTML + 4.01 Specification</A>,” December 1999.</TD></TR> + <TR> + <TD class="author-text" vAlign="top"><A name="jwe">[jwe]</A></TD> + <TD class="author-text">Jones, M., Belfanz, D., Bradeley, J., Goland, Y., + Panzer, J., Sakimura, N., and P. Tarjan, “<A href="http://self-issued.info/docs/draft-jones-json-web-signature-01.html">JSON + Web Encryption</A>,” March 2011.</TD></TR> + <TR> + <TD class="author-text" vAlign="top"><A name="jws">[jws]</A></TD> + <TD class="author-text">Jones, M., Belfanz, D., Bradeley, J., Goland, Y., + Panzer, J., Sakimura, N., and P. Tarjan, “<A href="http://self-issued.info/docs/draft-jones-json-web-signature-01.html">JSON + Web Signatures</A>,” March 2011.</TD></TR> + <TR> + <TD class="author-text" vAlign="top"><A name="jwt">[jwt]</A></TD> + <TD class="author-text">Jones, M., Belfanz, D., Bradeley, J., Goland, Y., + Panzer, J., Sakimura, N., and P. Tarjan, “<A href="http://jsonenc.info/sig/1.0/">JSON + Web Token</A>,” January 2011.</TD></TR></TBODY></TABLE><A name="rfc.authors"></A><BR> +<HR> + +<TABLE class="TOCbug" cellSpacing="2" summary="layout" cellPadding="0" align="right"> + <TBODY> + <TR> + <TD class="TOCbug"><A href="http://openid4.us/specs/ab/openid-connect-core-1_0.html#toc"> TOC </A></TD></TR></TBODY></TABLE> +<H3>Authors' Addresses</H3> +<TABLE border="0" cellSpacing="0" cellPadding="0" width="99%"> + <TBODY> + <TR> + <TD class="author-text"> </TD> + <TD class="author-text">Nat Sakimura (editor)</TD></TR> + <TR> + <TD class="author-text"> </TD> + <TD class="author-text">Nomura Research Institute, Ltd.</TD></TR> + <TR> + <TD class="author" align="right">Email: </TD> + <TD class="author-text"><A + href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</A></TD></TR> + <TR cellpadding="3"> + <TD> </TD> + <TD> </TD></TR> + <TR> + <TD class="author-text"> </TD> + <TD class="author-text">David Recordon</TD></TR> + <TR> + <TD class="author-text"> </TD> + <TD class="author-text">Facebook Inc.</TD></TR> + <TR> + <TD class="author" align="right">Email: </TD> + <TD class="author-text"><A href="mailto:dr@fb.com">dr@fb.com</A></TD></TR> + <TR cellpadding="3"> + <TD> </TD> + <TD> </TD></TR> + <TR> + <TD class="author-text"> </TD> + <TD class="author-text">John Bradley</TD></TR> + <TR> + <TD class="author-text"> </TD> + <TD class="author-text">Protiviti Government Services</TD></TR> + <TR> + <TD class="author" align="right">Email: </TD> + <TD class="author-text"><A + href="mailto:jbradley@mac.com">jbradley@mac.com</A></TD></TR> + <TR cellpadding="3"> + <TD> </TD> + <TD> </TD></TR> + <TR> + <TD class="author-text"> </TD> + <TD class="author-text">Breno de Madeiros</TD></TR> + <TR> + <TD class="author-text"> </TD> + <TD class="author-text">Google Inc.</TD></TR> + <TR> + <TD class="author" align="right">Email: </TD> + <TD class="author-text"><A + href="mailto:breno@google.com">breno@google.com</A></TD></TR> + <TR cellpadding="3"> + <TD> </TD> + <TD> </TD></TR> + <TR> + <TD class="author-text"> </TD> + <TD class="author-text">Mike Jones</TD></TR> + <TR> + <TD class="author-text"> </TD> + <TD class="author-text">Microsoft Corporation</TD></TR> + <TR> + <TD class="author" align="right">Email: </TD> + <TD class="author-text"><A + href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</A></TD></TR> + <TR cellpadding="3"> + <TD> </TD> + <TD> </TD></TR> + <TR> + <TD class="author-text"> </TD> + <TD class="author-text">Edmund Jay (editor)</TD></TR> + <TR> + <TD class="author-text"> </TD> + <TD class="author-text">MGI1</TD></TR> + <TR> + <TD class="author" align="right">Email: </TD> + <TD class="author-text"><A + href="mailto:ejay@mgi1.com">ejay@mgi1.com</A></TD></TR> +</TBODY></TABLE></BODY></HTML> |