<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Simple Web Discovery (SWD)</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="Simple Web Discovery (SWD)">
<meta name="keywords" content="RFC, Request for Comments, I-D, Internet-Draft, Discovery, Finger">
<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">M. Jones (editor)</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">Y. Goland</td></tr>
<tr><td class="header">Intended status: Standards Track</td><td class="header">Microsoft</td></tr>
<tr><td class="header">Expires: April 29, 2011</td><td class="header">October 26, 2010</td></tr>
</table></td></tr></table>
<h1><br />Simple Web Discovery (SWD)<br />draft-jones-simple-web-discovery-00</h1>
<h3>Abstract</h3>
<p>
Simple Web Discovery (SWD) defines a HTTPS GET based mechanism to discover the location of a given type of service for a given principal
starting only with a domain name.
</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 April 29, 2011.</p>
<h3>Copyright Notice</h3>
<p>
Copyright (c) 2010 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="#anchor2">2.</a>
A Simple Web Discovery Request<br />
<a href="#anchor3">3.</a>
Simple Web Discovery Responses<br />
<a href="#anchor4">3.1.</a>
A response containing one or more locations<br />
<a href="#anchor5">3.2.</a>
Redirecting all Simple Web Discovery Requests<br />
<a href="#anchor6">3.3.</a>
401 Unauthorized Response<br />
<a href="#anchor7">3.4.</a>
Other HTTP 1.1 Responses<br />
<a href="#IANA">4.</a>
IANA Considerations<br />
<a href="#Security">5.</a>
Security Considerations<br />
<a href="#rfc.references1">6.</a>
References<br />
<a href="#rfc.references1">6.1.</a>
Normative References<br />
<a href="#rfc.references2">6.2.</a>
Informative 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>
Simple Web Discovery (SWD) defines a HTTPS GET based mechanism to discover the location of a given type of service for a given principal
starting only with a domain name. SWD requests use the x-www-form-urlencoded format to specify a URI for the principal and another URI
for the type of service being sought. If the request is successful then the response, by default, is a JSON object containing an array of URIs that point to where the
principal has instances of services of the requested type.
</p>
<p>For example, let us say that a requester wants to discover where Joe keeps his calendar. The requester could take Joe's e-mail address,
joe@example.com and take from it its domain to create a HTTPS GET request of the following form:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
GET /.well-known/simple-web-discovery?principal=mailto:joe@example.com&service=urn:adatum.com:calendar HTTP/1.1
Host: example.com
HTTP/1.1 200 O.K.
Content-Type: application/json
{
"locations":["http://calendars.proseware.com/calendars/joseph"]
}
</pre></div>
<p>Note: The request-URI is left un-encoded in the above example
for the sake of readability in the above example.
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
A Simple Web Discovery Request</h3>
<p>Domains that support SWD requests MUST make available a SWD server for their domain at the path .well-known/simple-web-discovery.
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].
"simple-web-discovery" MUST point to a SWD server compliant with this specification.
</p>
<p>
SWD servers MUST support receiving SWD requests via TLS 1.2 as defined in <a class='info' href='#RFC5246'>RFC 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. SWD servers MUST reject SWD requests sent over plain HTTP or any other
transport that does not provide both privacy and validation of the server's identity.
</p>
<p>
A SWD server is queried using a HTTPS GET request with the previously specified path along with a query segment containing a x-www-form-urlencoded
form as defined in <a class='info' href='#W3C.REC-html401-19991224'>HTML 4.01<span> (</span><span class='info'>Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.</span><span>)</span></a> [W3C.REC‑html401‑19991224]. The form MUST contain two name/value pairs that MUST
appear exactly once, principal and service. Both name/value pairs MUST have values that are set to URIs (as defined in
<a class='info' href='#RFC3986'>RFC 3986<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] . If any of the previous requirements
are not met in a SWD request then the request MUST be rejected with a 400 Bad Request.
</p>
<p>
The SWD request form MAY contain additional name/value pairs but if those name/value pairs are not recognized by the SWD server then the SWD
server MUST ignore them for processing purposes.
</p>
<p>
The principal query component is a URI that identifies an entity. The service query component is a URI that identifies a service type. The semantics
of the SWD query is "Please return the location(s) of instances of the specified service type associated with the specified principal". The definition
of URIs used to identify principals and services are outside the scope of this specification.
</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"></a><h3>3.
Simple Web Discovery Responses</h3>
<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"></a><h3>3.1.
A response containing one or more locations</h3>
<p>Unless another content-type is negotiated, a 200 O.K. response to a SWD request that contains the information requested
MUST return content of type application/json
as defined in <a class='info' href='#RFC4627'>RFC 4627<span> (</span><span class='info'>Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.</span><span>)</span></a> [RFC4627]. The JSON response MUST contain a JSON object that contains a member pair whose
name is the string "locations" and whose value is an array of strings that are each a URI pointing to a location where the
desired service type belonging to the specified principal can be found. There are no semantics associated with the order in
which the URIs are listed in the array.
</p>
<p>The JSON object MAY contain other members but a receiver of the object MAY ignore any member pairs whose name it does not recognize.
</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.2"></a><h3>3.2.
Redirecting all Simple Web Discovery Requests</h3>
<p>
SWD requests by definition start off by being issued to the .well-known/simple-web-discovery location. But locating a SWD server at a root location
can prove inconvenient. To enable service level redirection a SWD server MAY return
a 200 O.k. to a HTTPS request with a content type of application/json (or whatever other content type has been negotiated) that contains a
JSON object that contains a member pair whose name is the string "SWD_service_redirect" whose value is a JSON object with a member pair whose name
is "location" and whose
value is a string that encodes a URI. Optionally the JSON object value of "SWD_service_redirect" MAY also contain a member whose name is "expires"
and whose value is
a JSON number that encodes an integer.
</p>
<p>
A SWC compliant client MUST support the SWD_service_redirect response.
</p>
<p>
The JSON objects MAY contain other members but a receiver of the objects MAY ignore any pairs whose name it does not recognize.
</p>
<p>
The location member identifies the URI that the caller MUST redirect all SWD requests for that domain to until the expires time is met. SWD
requests for the redirected domain MUST be constructed by taking the URI returned in the location and using it as the base URI to which
the SWD form arguments are then added as query parameters. The location URI MUST NOT include a query component.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
GET /.well-known/simple-web-discovery?principal=mailto:joe@example.com&service=urn:adatum.com:calendar HTTP/1.1
Host: example.com
HTTP/1.1 200 O.K.
Content-Type: application/json
{
"SWD_service_redirect":
{
"location":"https://swd.proseware.com/swd_server",
"expires": 1300752001
}
}
GET /swd_server?principal=mailto:joe@example.com&service=urn:adatum.com:calendar HTTP/1.1
Host: swd.proseware.com
HTTP/1.1 200 O.K.
Content-Type: application/json
{
"locations":["http://calendars.proseware.com/calendars/joseph"]
}
</pre></div>
<p>Note: The request-URIs are left un-encoded in the above
example for the sake of readability in the above example.
</p>
<p>
The location URI MUST be a HTTPS URL.
</p>
<p>
The optional expires member identifies the point in time at which the caller MUST NOT redirect its SWD requests for that domain to the previously
obtained location and MUST instead return to the .well-known/simple-web-discovery location. The value of the expires member MUST encode
the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the desired date/time. See <a class='info' href='#RFC3339'>RFC 3339<span> (</span><span class='info'>Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.</span><span>)</span></a> [RFC3339] for
details regarding date/times in general and UTC in particular. If the expires value is in the past or if the value is more than
one hour in the future then the response MUST be treated as if it didn't contain an expires value.
</p>
<p>
If the expires value is omitted or if its value is incorrect then the expires value MUST be treated as having a value of exactly one hour into the future.
</p>
<p>
If a JSON response is received that contains both a member pair with the name "SWD_service_redirect" and a member pair with the name "locations"
as children of the object root then the "SWD_service_redirect" member pair MUST be ignored.
</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.3"></a><h3>3.3.
401 Unauthorized Response</h3>
<p>
A SWD server MAY respond to a request with a 401
Unauthorized Response, as described in <a class='info' href='#RFC2616'>RFC 2616<span> (</span><span class='info'>Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.</span><span>)</span></a> [RFC2616], Section 10. Per the RFC,
the request MAY be repeated with a suitable Authorization
header field. Authorization information may be communicated
in this manner, including a JSON Web Token <a class='info' href='#JWT'>[JWT]<span> (</span><span class='info'>Jones (editor), M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., and N. Sakimura, “JSON Web Token (JWT),” October 2010.</span><span>)</span></a>.
</p>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.4"></a><h3>3.4.
Other HTTP 1.1 Responses</h3>
<p>
A SWD server MAY return other HTTP 1.1 responses, including
404 Not Found, 400 Bad Request, and 403 Forbidden. SWD
implementations MUST correctly handle these responses.
</p>
<a name="IANA"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
IANA Considerations</h3>
<p>Per <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] the following registration template is offered:
</p>
<blockquote class="text"><dl>
<dt>URI suffix</dt>
<dd>simple-web-discovery
</dd>
<dt>Change controller</dt>
<dd>IETF
</dd>
<dt>Specification document</dt>
<dd>This RFC
</dd>
</dl></blockquote><p>
</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.5"></a><h3>5.
Security Considerations</h3>
<p>
SWD responses can contain confidential information. Therefore
a, general approach is used to require TLS in all cases. But
TLS can only provide for privacy and server validation, it
cannot validate that the requester is authorized to see the
results of a query. The exact mechanism used to determine if
the requester is authorized to see the result of the query is
outside the scope of this specification.
</p>
<p>
Because SWD responses can contain confidential information,
the requestor may need authorization to receive them.
Standard HTTP authorization mechanisms MAY be employed to
request authorized access, including the use of an HTTP
Authorization header field in requests, which in turn, may
contain a JSON Web Token <a class='info' href='#JWT'>[JWT]<span> (</span><span class='info'>Jones (editor), M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., and N. Sakimura, “JSON Web Token (JWT),” October 2010.</span><span>)</span></a>, among
other authorization data formats.
</p>
<p>
The ability to redirect an entire SWD server as defined in
this document is an obvious attack point. This is another
reason why we have mandated TLS, so as to be sure that the
redirect can only be received over a secure connection. We
have also put in the upper limit of 60 minutes for a redirect
so as to provide a path for regaining control over queries
should a successful attack be launched to return false
redirects.
</p>
<p>
The SWD_service_redirect capability may cause unanticipated
failures in cases where a requestor may have permissions to
discover content at the original SWD endpoint but not the one
redirected to, or vice-versa.
</p>
<a name="rfc.references"></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.
References</h3>
<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>6.1. Normative References</h3>
<table width="99%" border="0">
<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="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="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="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="W3C.REC-html401-19991224">[W3C.REC-html401-19991224]</a></td>
<td class="author-text">Hors, A., Raggett, D., and I. Jacobs, “<a href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML 4.01 Specification</a>,” World Wide Web Consortium Recommendation REC-html401-19991224, December 1999 (<a href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML</a>).</td></tr>
</table>
<a name="rfc.references2"></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>6.2. Informative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="JWT">[JWT]</a></td>
<td class="author-text">Jones (editor), M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., and N. Sakimura, “<a href="http://self-issued.info/docs/draft-jones-json-web-token-00.html">JSON Web Token (JWT)</a>,” October 2010.</td></tr>
</table>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Michael B. Jones (Editor)</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Microsoft</td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Yaron Y. Goland</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Microsoft</td></tr>
</table>
</body></html>