<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>OpenID Connect Discovery 1.0 - draft
01</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Connect Discovery 1.0 - draft
01">
<meta name="generator" content="xml2rfc v1.35 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Network Working Group</td><td class="header">N. Sakimura</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">NRI</td></tr>
<tr><td class="header">Intended status: Experimental</td><td class="header">J. Bradley, Ed.</td></tr>
<tr><td class="header">Expires: January 5, 2012</td><td class="header">Protiviti Government Services</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">July 4, 2011</td></tr>
</table></td></tr></table>
<h1><br />OpenID Connect Discovery 1.0 - draft
01<br />draft-openid-connect-discovery-0_1.xml</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 Core, Protocol Bindings, Dynamic Registration, Discovery,
and Extensions. This specification is the "Discovery" part of the suite
that defines how user and server endpoints are discovered.
</p>
<h3>Requirements Language</h3>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a class='info' href='#RFC2119'>RFC 2119<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> [RFC2119].
</p>
<h3>Status of this Memo</h3>
<p>
This Internet-Draft is submitted in full
conformance with the provisions of BCP 78 and BCP 79.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as “work in progress.”</p>
<p>
This Internet-Draft will expire on January 5, 2012.</p>
<h3>Copyright Notice</h3>
<p>
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.</p>
<p>
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.</p>
<a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
Introduction<br />
<a href="#terminology">2.</a>
Terminology<br />
<a href="#anchor2">3.</a>
Provider Discovery<br />
<a href="#anchor3">3.1.</a>
Identifier Normalization<br />
<a href="#anchor4">3.1.1.</a>
Hostname<br />
<a href="#anchor5">3.1.2.</a>
Email Address<br />
<a href="#anchor6">3.1.3.</a>
URL<br />
<a href="#anchor7">3.2.</a>
Non-Normative Examples<br />
<a href="#anchor8">3.2.1.</a>
Hostname<br />
<a href="#anchor9">3.2.2.</a>
Email Address<br />
<a href="#anchor10">3.2.3.</a>
URL<br />
<a href="#anchor11">3.3.</a>
Redirection<br />
<a href="#anchor12">4.</a>
Provider Configuration Information<br />
<a href="#anchor13">4.1.</a>
Provider Configuration Request<br />
<a href="#anchor14">4.2.</a>
Provider Configuration Response<br />
<a href="#anchor15">5.</a>
Other Items for Consideration<br />
<a href="#IANA">6.</a>
IANA Considerations<br />
<a href="#Security">7.</a>
Security Considerations<br />
<a href="#Acknowledgements">8.</a>
Acknowledgements<br />
<a href="#rfc.references1">9.</a>
Normative References<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
</p>
<br clear="all" />
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
Introduction</h3>
<p>In order for an OpenID client to utilize OpenID services for a user,
the client needs to know where the OpenID provider is. OpenID Connect
uses <a class='info' href='#SWD'>Simple Web Discovery<span> (</span><span class='info'>Jones, M., Ed. and Y. Goland, “Simple Web Discovery,” October 2010.</span><span>)</span></a> [SWD] to locate the openID
Connect provider for a end-user. This document describes the OpenID
Connect specific parts related to <a class='info' href='#SWD'>Simple Web
Discovery<span> (</span><span class='info'>Jones, M., Ed. and Y. Goland, “Simple Web Discovery,” October 2010.</span><span>)</span></a> [SWD].
</p>
<p>Once a OpenID provider is identified, the endpoint and other
configuration information for that provider is retreved from a well
known location as a JSON document.
</p>
<a name="terminology"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
Terminology</h3>
<p></p>
<blockquote class="text"><dl>
<dt>Client</dt>
<dd>An application obtaining authorization and
making protected resource requests.
</dd>
<dt>End-user</dt>
<dd>A human resource owner.
</dd>
<dt>Principal</dt>
<dd>A human resource owner that is the target of
a request in Simple Web Discovery.
</dd>
<dt>OpenID Provider (OP)</dt>
<dd>Authorization Servers that are
able to support OpenID Connect Messages.
</dd>
<dt>Issuer ID</dt>
<dd>The unique identifyer of the OpenID
Provider.
</dd>
<dt>Relying Party (RP)</dt>
<dd>Client and Resource Servers.
</dd>
<dt>End-User 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
uses to identify itself to the OP.
</dd>
<dt>Token Endpoint</dt>
<dd>The Authorization Server's HTTP
endpoint capable of issuing tokens.
</dd>
<dt>Authentication Endpoints</dt>
<dd>End-User Authentication,
& Authorization 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>Introspection Endpoint</dt>
<dd>The Authorization Servers
endpoint that takes a ID_Token or access token as input and returns
a unpacked JSON representation of a ID_Token.
</dd>
<dt>Identifier</dt>
<dd>An Identifier is either a "http" or "https"
URI, (commonly referred to as a "URL" within this document), or an
account URI. This document defines various kinds of Identifiers,
designed for use in different contexts.
</dd>
</dl></blockquote>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
Provider Discovery</h3>
<p>Provider discovery is optional, If a RP knows through an out of band
mechinisim that all identifiers containing particular have the same
issuer then they can ship this step and procede to Section 4.
</p>
<p>Provider discovery Simple Web Discovery requires the following
information to make a discovery request:
</p>
<p></p>
<ul class="text">
<li>principal - identifier of the target end user who is the subject
of the discovery request
</li>
<li>host - server where a Simple Web Discovery service is hosted
</li>
<li>service - URI of the service whose location is requested
</li>
</ul>
<p>OpendID Connect has the following discoverable service in Simple Web
Discovery:
</p><table class="all" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left">
<tr><th align="left">Service Type</th><th align="left">URI</th></tr>
<tr>
<td align="left">OpenID Issuer</td>
<td align="left">http://openid.net/specs/cc/1.0/issuer</td>
</tr>
</table>
<br clear="all" />
<p>To start discovery of OpenID end points, the end-user supplies an
identifier to the client or relying party. The client performs
normalization rules to the identifier to extract the principal and host.
Then it makes a HTTPS request the host's Simple Web Discovery endpoint
with the <tt>principal</tt> and <tt>service</tt>
parameters to obtain the location of the requested service.
</p>
<p>What MUST be returned in the response is the Java origin of the
Issuer. This includes URI scheme HOST and port.
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.1"></a><h3>3.1.
Identifier Normalization</h3>
<p>The user identifier can be one of the following:
</p>
<p></p>
<ul class="text">
<li>Hostname
</li>
<li>Email address
</li>
<li>URL
</li>
</ul><p>Identifiers starting with the <a class='info' href='#XRI_Syntax_2.0'>XRI<span> (</span><span class='info'>Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” November 2005.</span><span>)</span></a> [XRI_Syntax_2.0] characters ('=','@', and '!') are
reserved. Any identifier that contains the character '@' in any other
position other than the first position must be treated as an email
address.
</p>
<p>
</p>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.1"></a><h3>3.1.1.
Hostname</h3>
<p>If the identifier is the hostname, then the hostname is used as
both the principal and host in Simple Web Discovery request. This
results in a directed identity request.
</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.2"></a><h3>3.1.2.
Email Address</h3>
<p>If the identifier is an email address, the principal is the email
address and the host is the portion to the right of the '@'
character.
</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.3"></a><h3>3.1.3.
URL</h3>
<p>A URL identifier is normalized according to the following
rules:
</p>
<p></p>
<ul class="text">
<li>If the URL does not have a "http" or "https" scheme, the
string "https://" is prefixed to the URL.
</li>
<li>If the URL contains a fragment part, it MUST be stripped off
together with the fragment delimiter character "#".
</li>
<li>The resulting URL is used as the principal and the host is
extracted from it according to <a class='info' href='#RFC3986'>URI<span> (</span><span class='info'>Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.</span><span>)</span></a> [RFC3986]
syntax rules.
</li>
</ul>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.2"></a><h3>3.2.
Non-Normative Examples</h3>
<p>
</p>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.2.1"></a><h3>3.2.1.
Hostname</h3>
<p>To find the authorization endpoint for the given hostname,
"example.com", the SWD parameters are as follows:
</p><table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left">
<tr><th align="left">SWD Parameter</th><th align="left">Value</th></tr>
<tr>
<td align="left">principal</td>
<td align="left">example.com</td>
</tr>
<tr>
<td align="left">host</td>
<td align="left">example.com</td>
</tr>
<tr>
<td align="left">service</td>
<td align="left">http://openid.net/specs/cc/1.0/issuer</td>
</tr>
</table>
<br clear="all" />
<p>Following the SWD specification, the client would make the
following request to get the discovery information:
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>GET /.well-known/simple-web-discovery?principal=example.com&service=http://openid.net/specs/cc/1.0/issuer HTTP/1.1
Host: example.com
HTTP/1.1 200 O.K.
Content-Type: application/json
{
"locations":["https://example.com/auth"]
}</pre></div><p>
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.2.2"></a><h3>3.2.2.
Email Address</h3>
<p>To find the authorization endpoint for the given email address,
"joe@example.com", the SWD parameters are as follows:
</p><table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left">
<tr><th align="left">SWD Parameter</th><th align="left">Value</th></tr>
<tr>
<td align="left">principal</td>
<td align="left">joe@example.com</td>
</tr>
<tr>
<td align="left">host</td>
<td align="left">example.com</td>
</tr>
<tr>
<td align="left">service</td>
<td align="left">http://openid.net/specs/cc/1.0/issuer</td>
</tr>
</table>
<br clear="all" />
<p>Following the SWD specification, the client would make the
following request to get the discovery information:
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>GET /.well-known/simple-web-discovery?principal=joe@example.com&service=http://openid.net/specs/cc/1.0/issuer HTTP/1.1
Host: example.com
HTTP/1.1 200 O.K.
Content-Type: application/json
{
"locations":["https://example.com/auth"]
}</pre></div><p>
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.2.3"></a><h3>3.2.3.
URL</h3>
<p>To find the authorization endpoint for the given URL,
'https://example.com/joe", the SWD parameters are as follows:
</p><table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left">
<tr><th align="left">SWD Parameter</th><th align="left">Value</th></tr>
<tr>
<td align="left">principal</td>
<td align="left">https://example.com/joe</td>
</tr>
<tr>
<td align="left">host</td>
<td align="left">example.com</td>
</tr>
<tr>
<td align="left">service</td>
<td align="left">http://openid.net/specs/cc/1.0/issuer</td>
</tr>
</table>
<br clear="all" />
<p>Following the SWD specification, the client would make the
following request to get the discovery information:
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>GET /.well-known/simple-web-discovery?principal=https://example.com/joe&service=http://openid.net/specs/cc/1.0/issuer HTTP/1.1
Host: example.com
HTTP/1.1 200 O.K.
Content-Type: application/json
{
"locations":["https://example.com/auth"]
}</pre></div><p>
</p>
<a name="anchor11"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.3"></a><h3>3.3.
Redirection</h3>
<p>In cases where the SWD request is handled at a host or location
other than the one derived from the end-user's identifier, the host
will return a JSON object containing the new location.
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>GET /.well-known/simple-web-discovery?principal=joe@example.com&service=http://openid.net/specs/cc/1.0/issuer HTTP/1.1
Host: example.com
HTTP/1.1 200 O.K.
Content-Type: application/json
{
"SWD_service_redirect":
{
"location":"https://example.net/swd_server"
}
}
GET /swd_server?principal=joe@example.com&service=http://openid.net/specs/cc/1.0/issuer HTTP/1.1
Host: example.net
HTTP/1.1 200 O.K.
Content-Type: application/json
{
"locations":["https://example.net/auth"]
}</pre></div><p>
</p>
<a name="anchor12"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
Provider Configuration Information</h3>
<p>This step is optional. The provider endpoints and configuration
information may be provided out of band.
</p>
<p>Using the Issuer ID discoverd in Section 3 or through direct
configuration the openID providers configuration can be retreved.
</p>
<p>OpenID providers MUST make available a JSON document at the path
.well-known/openid-configuration. The syntax and semantics of
".well-known" are defined in <a class='info' href='#RFC5785'>RFC 5785<span> (</span><span class='info'>Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known Uniform Resource Identifiers (URIs),” April 2010.</span><span>)</span></a> [RFC5785] .
"openid-configuration" MUST point to a JSON document compliant with this
specification.
</p>
<p>OpenID providers MUST support receiving SWD requests via TLS 1.2 as
defined in <a class='info' href='#RFC5246'>RFCRFC 5246<span> (</span><span class='info'>Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.</span><span>)</span></a> [RFC5246] and MAY support
other transport layer security mechanisms of equivalent security.
</p>
<a name="anchor13"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.1"></a><h3>4.1.
Provider Configuration Request</h3>
<p>A Provider Configuration Document is queried using a HTTPS GET
request with the previously specified path.
</p>
<p>The client would make the following request to get the
Configuration information
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>GET /.well-known/openid-configuration HTTP/1.1
Host: example.com
</pre></div><p>
</p>
<a name="anchor14"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.2"></a><h3>4.2.
Provider Configuration Response</h3>
<p>The response is a set of claims about the OpenID Providers
configuration, including all neccicary endpoint, supported scope, and
public key location information.
</p>
<p>The response MUST return a plain text JSON object that contains a
set of claims that are a subset of those defined below. Other claims
MAY also be returned.
</p><br /><hr class="insert" />
<a name="ClaimTable"></a>
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left"><col align="left">
<tr><th align="left">Claim</th><th align="left">Type</th><th align="left">Description</th></tr>
<tr>
<td align="left">authorization_endpoint</td>
<td align="left">string</td>
<td align="left">URI of the providers Authentication & Authorization
Endpoint.</td>
</tr>
<tr>
<td align="left">token_endpoint</td>
<td align="left">string</td>
<td align="left">URI of the providers Token </td>
</tr>
<tr>
<td align="left">introspection_endpoint</td>
<td align="left">string</td>
<td align="left">URI of the providers IDToken Introspection Endpoint</td>
</tr>
<tr>
<td align="left">user_info_endpoint</td>
<td align="left">string</td>
<td align="left">URI of the providers User Information Endpoint</td>
</tr>
<tr>
<td align="left">session_management_endpoint</td>
<td align="left">string</td>
<td align="left">URI of the providers Session Management Endpoint</td>
</tr>
<tr>
<td align="left">swk_endpoint</td>
<td align="left">string</td>
<td align="left">URI of the providers Simple Web Key "SWK" Document</td>
</tr>
<tr>
<td align="left">registration_endpoint</td>
<td align="left">string</td>
<td align="left">URI of the providers Simple Registration endpoint</td>
</tr>
<tr>
<td align="left">scopes_supported</td>
<td align="left">string</td>
<td align="left">A comma separated list of the OAuth 2.0 scopes which this server
supports. The server MUST support the openid scope.</td>
</tr>
<tr>
<td align="left">flows_supported</td>
<td align="left">string</td>
<td align="left">A comma separated list of the OAuth 2.0 flows which this server
supports. The server MUST support the code flow.</td>
</tr>
<tr>
<td align="left">eaa_supported</td>
<td align="left">string</td>
<td align="left">A comma separated list of the eaa which this server supports</td>
</tr>
<tr>
<td align="left">Identidiers_supported</td>
<td align="left">string</td>
<td align="left">A comma separated list of the user identifyer types which this
server supports</td>
</tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Table 1: Reserved Claim Definitions </b></font><br /></td></tr></table><hr class="insert" />
<p>Example response
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"authorization_endpoint": "https://example.com/authorize",
"token_endpoint": "https://example.com/token"
"introspection_endpoint": "https://example.com/introspection",
"user_info_endpoint": "https://example.com/user",
"session_management_endpoint": "https://example.com/sm",
"swk_endpoint": "https://example.com/swk.json",
"registration_endpoint": "https://example.com/register",
"scopes_supported": "openid",
"flows_supported": "code,token",
"eaa_supported": "http://www.idmanagement.gov/schema/2009/05/icam/openid-trust-level1.pdf",
"Identidiers_supported": "omni,ppid"
}</pre></div><p>
Should the Should
</p>
<a name="anchor15"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.
Other Items for Consideration</h3>
<p></p>
<ol class="text">
<li>Should issuer be in the Provider Configuration Response
</li>
<li>Should issuer ID be explicitly restricted to the https://
scheme.
</li>
</ol>
<a name="IANA"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.
IANA Considerations</h3>
<p>This document makes no request of IANA.
</p>
<p>Note to RFC Editor: this section may be removed on publication as an
RFC.
</p>
<a name="Security"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.
Security Considerations</h3>
<p>
</p>
<a name="Acknowledgements"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8"></a><h3>8.
Acknowledgements</h3>
<p>
</p>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>9. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="JWS">[JWS]</a></td>
<td class="author-text">Jones, M., Balfanz, D., Bradley, 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., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “<a href="http://self-issued.info/docs/draft-jones-json-web-token-03.html">JSON Web Token</a>,” March 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.2.0">[OpenID.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="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://openid4.us/specs/ab/openid-connect-ab-1_0.html">OpenID Connect Artifact Binding 1.0</a>,” January 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.CC">[OpenID.CC]</a></td>
<td class="author-text">Recordon, D., Sakimura, N., Bradley, J., de Madeiros, B., and M. Jones, “<a href="http://openid4.us/specs/ab/openid-connect-core-1_0.html">OpenID Connect Connect Core 1.0</a>,” January 2011.</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="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="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="RFC5785">[RFC5785]</a></td>
<td class="author-text">Nottingham, M. and E. Hammer-Lahav, “<a href="http://tools.ietf.org/html/rfc5785">Defining Well-Known Uniform Resource Identifiers (URIs)</a>,” RFC 5785, April 2010 (<a href="http://www.rfc-editor.org/rfc/rfc5785.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="SWD">[SWD]</a></td>
<td class="author-text">Jones, M., Ed. and Y. Goland, “<a href="http://self-issued.info/docs/draft-jones-simple-web-discovery-00.html">Simple Web Discovery</a>,” October 2010.</td></tr>
<tr><td class="author-text" valign="top"><a name="XRI_Syntax_2.0">[XRI_Syntax_2.0]</a></td>
<td class="author-text">Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” November 2005 (<a href="http://www.oasis-open.org/committees/download.php/15376/xri-syntax-V2.0-cs.html">HTML</a>, <a href="http://www.oasis-open.org/committees/download.php/15377/xri-syntax-V2.0-cs.pdf">PDF</a>).</td></tr>
</table>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Nat Sakimura</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">John Bradley (editor)</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">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>
</table>
</body></html>