One document matched: draft-sakimura-oauth-meta-05.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-sakimura-oauth-meta-05" ipr="trust200902">
  <front>
    <title abbrev="OAuth-Meta">OAuth Response Metadata</title>

	<author fullname="Nat Sakimura" initials="N." 
            surname="Sakimura">
      <organization>Nomura Research Institute</organization>

      <address>
        <email>sakimura@gmail.com</email>
      </address>
    </author>

    <date day="04" month="November" year="2015"/>

    <area>Security</area>

    <workgroup>OAuth Working Group</workgroup>

    <abstract>
      <t>This specification defines an extensible metadata that may be
      inserted into the OAuth 2.0 responses to assist the clients to process
      those responses. It is expressed either as a link header, or 
	  query parameters. It will allow the
      client to learn where the members in the response could be used. 
	  Since it is just additional response header/query parameters, 
	  any client that does not understand this
      extension should not break and work normally while supporting clients
      can utilize the metadata to take the advantage of the extension.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Although <xref target="RFC6749">OAuth 2.0</xref> has been known for
      its REST friendliness, OAuth itself is not RESTful, as it heavily relies
      on out-of-band information to drive the interactions. This situation can
      be eased by hypertext-enabling the endpoint responses through the
      introduction of data structure that represents such hypertext and other
      metadata. This specification defines methods to represent such metadata 
	  in the authorization and token endpoints. </t>
    </section>

    <section title="Requirements">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </section>
	
	<section anchor="authz_res" title="Authorization Response">
	  <t>The Authorization response of the implementation of this specification MUST return 
	  the following query parameter in the redirect URI.</t>
	  <t><list style="hanging">
		<t hangText="turi">REQUIRED if the response contains 
		code. Token Endpoint URI. 
		The value of this parameter is the URI of the Token Endpoint that the code 
		can be sent to obtain the access token. </t>
		<t hangText="ruri">REQUIRED if the response contains an Access Token. 
		Resource URI. The value of this parameter is the URI of the Resource Endpoint 
		that the Access Token can be used at. </t>
		<t hangText="duri">OPTIONAL. Discovery Endpoint URI. The URI of from which the discovery document 
		can be obtained. </t>
      </list></t>
	  <t>If the discovery document also includes Token Endpoint URI or Resource Endpoint, 
		the value of the turi or ruri takes precedence.</t>
	  <t>The following is an example of such resopnse. Line breaks are for display purposes only.</t>
      <figure>
        <artwork><![CDATA[
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
    &turi=https%3A%2F%2Fexample.com%2Ftoken
    &duri=https%3A%2F%2Fexample.com%2Fdisco
    &state=xyz
	]]></artwork>
      </figure>
	</section>
	<section anchor="token_res" title="Token Endpoint Response">
	  <t>Token Endpoints that implements this specification MUST return the following 
	  relation (rel) and the corresponding URI value as defined in <xref target="RFC5988" />
	  in the Access Token Response defined in <xref target="RFC6749" />. </t>
	  <t><list style="hanging">
		<t hangText="ruri">REQUIRED if the response contains a bearer Access Token. 
		Resource URI. The value of this parameter is the URI of the Resource Endpoint 
		that the Access Token can be used at. </t>
		<t hangText="turi">OPTIONAL. Token Endpoint URI. 
		The value of this parameter is the URI of the Token Endpoint that the Refresh Token  
		can be sent to obtain a new Access Token. </t>
		<t hangText="duri">OPTIONAL. Discovery Endpoint URI. The URI of from which the discovery document 
		can be obtained. </t>
      </list></t>
	  <t>Following is an example of an HTTPS response.</t>
      <figure>
        <artwork><![CDATA[
HTTP/1.1 200 OK
Link: <https://example.com/userinfo>; rel="ruri",
 <https://example.com/disco>; rel="duri"
Content-Type: application/JSON; charset=utf-8

{
	"access_token":"aCeSsToKen"
}
	]]></artwork>
      </figure>
	</section>


    <section anchor="IANA" title="IANA Considerations">
      <t/>

      <section title="Link Type Registration">
        <t>Pursuant to <xref target="RFC5988"/>, the following link type
        registrations [[will be]] registered by mail to
        link-relations@ietf.org.</t>

        <t><list style="symbols">
           <t>Relation Name: turl</t>
           <t>Description: An OAuth 2.0 Token Endpoint specified in
              section 3.2 of <xref target="RFC6749"/>.</t>
           <t>Reference: This specification</t>
        </list></t>
        <t><list style="symbols">
           <t>Relation Name: rurl</t>
           <t>Description: An OAuth 2.0 Resource Endpoint specified in
              section 3.2 of <xref target="RFC6750"/>.</t>
           <t>Reference: This specification</t>
        </list></t>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t/>

      <section title="Query Parameter Tampering">
        <t>The query response parameters may be tampered by the man-in-the-browser. </t>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Members of OAuth WG helped to form this specification. Notabely: 
	  Hannes tschofenig, John Bradley, Justin Richer, Kaoru Maeda, Masashi Kurabayashi, 
	  Nov Matake, Michael B. Jones, Phil Hunt, William Dennis, (add yourselves). 
	  </t>
    </section>

    <section title="Document History">
	  <t>-05</t>
	  <t><list style="symbols">
          <t>Factored out JSON Meta and now using query param and Web Linking.</t>
	  </list></t>
	  <t>-04</t>
	  <t><list style="symbols">
          <t>Date refresh.</t>
	  </list></t>
	  <t>-03</t>
	  <t><list style="symbols">
          <t>Date refresh.</t>
	  </list></t>
      <t>-02</t>

      <t><list style="symbols">
          <t>Added Mike Kelly as an author.</t>

          <t>xref fix.</t>

          <t>Introduced "operations" as in
          draft-ietf-scim-api-00#section-3.5.</t>

          <t>Updated the informative reference to HAL.</t>

          <t>Added description to OAuth Token Endpoint hrefs.</t>

          <t>Added content-type to the example.</t>

          <t>Added Area and Working Group.</t>
        </list></t>

      <t>-01</t>

      <t><list style="symbols">
          <t>Some format changes, reference fix, and typo fixes.</t>

          <t>Changed 'items' to 'elements' to match the JSON terminology.</t>
        </list></t>

      <t>-00</t>

      <t><list style="symbols">
          <t>Initial Draft</t>
        </list></t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.2616'?>

      <?rfc include='reference.RFC.5988'?>
      <?rfc include='reference.RFC.6749'?>
	  <?rfc include='reference.RFC.6750'?>
    </references>

    <references title="Informational References">
      <?rfc include='reference.RFC.4627'?>
	  <?rfc include='reference.RFC.6570'?>

      <reference anchor="HAL">
        <front>
          <title>JSON Hypermedia API Language</title>

          <author fullname="Mike Kelly" initials="M." surname="Kelly">
            <address>
              <email>mike@stateless.co</email>
            </address>
          </author>

          <date day="12" month="February" year="2013"/>
        </front>
      </reference>

      <reference anchor="oauth-lrdd">
        <front>
          <title>Link Type Registrations for OAuth 2</title>

          <author fullname="William J. Mills" initials="W. J. "
                  surname="Mills">
            <address>
              <email>wmills_92105@yahoo.com</email>
            </address>
          </author>

          <date day="10" month="October" year="2012"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>