<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?xml-stylesheet type='text/xsl' 'rfc2629.xslt ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->                                                                                         
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->                                                                              
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std"
     docName="draft-ietf-oauth-urn-sub-ns-06"
     ipr="trust200902">
    <!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->

    <!-- ***** FRONT MATTER ***** -->

    <front>
        <!-- The abbreviated title is used in the page header - it is only necessary if the
 full title is longer than 39 characters -->

        <title>An IETF URN Sub-Namespace for OAuth</title>

        <!-- add 'role="editor"' below for the editors if appropriate -->
        <author fullname="Brian Campbell" initials="B" surname="Campbell">
            <organization>Ping Identity Corp.</organization>
            <address>
                <email>brian.d.campbell@gmail.com</email>
            </address>
        </author>

        <author fullname="Hannes Tschofenig" initials="H" surname="Tschofenig">
            <organization>Nokia Siemens Networks</organization>
            <address>
                <email>hannes.tschofenig@gmx.net</email>
            </address>
        </author>

        <date year="2012"/>

        <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
           in the current day for you. If only the current year is specified, xml2rfc will fill
       in the current day and month for you. If the year is not the current one, it is
       necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
       purpose of calculating the expiry date).  With drafts it is normally sufficient to
       specify just the year. -->

        <!-- Meta-data Declarations -->

        <area>Security</area>

        <workgroup>OAuth Working Group</workgroup>

        <!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->

        <keyword>OAuth</keyword>
        <keyword>URN</keyword>
        <keyword>sub-namespace</keyword>
        <keyword>urn:ietf:params:oauth</keyword>


        <!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->

        <abstract>
            <t>This document establishes an IETF URN Sub-namespace for use with OAuth related specifications.
            </t>
        </abstract>
    </front>

    <middle>
        <section title="Introduction">
            <t>
              Various extensions and companion specifications to <xref target="I-D.ietf-oauth-v2">The OAuth 2.0 Authorization Framework</xref>
              utilize URIs to identify the extension in use or other relevant context.  This document creates and registers an IETF URN Sub-namespace,
              as documented in <xref target="RFC3553">RFC 3553</xref>, for use with such specifications.
              The new 'oauth' sub-namespace is urn:ietf:params:oauth and OAuth relevant parameters will be established underneath it.
            </t>
        </section>
      <section title="Registration Template" anchor="registration">
        <t>If a registrant wishes to have a OAuth URI registered, then a URN of the form urn:ietf:params:oauth:&lt;value&gt;
          will be requested where &lt;value&gt; is a suitable representation of the functionality or concept being registered.
        </t>
        <t>
          The registration procedure for new entries requires a request in the form of the following template and is Specification Required per <xref target="RFC5226">RFC 5226</xref>.
        </t>
        <t>
          <list style='hanging' hangIndent='3'>
            <t hangText='URN:'>
              <vspace/>
              The URI that identifies the registered functionality.
            </t>
            <t hangText='Common Name:'>
              <vspace/>
              The name by which the functionality being registered is generally known.
            </t>
            <t hangText='Change Controller:'>
              For standards-track RFCs, state "IETF".  For others, give the name
              of the responsible party.  Other details (e.g., postal address,
              e-mail address, home page URI) may also be included.
            </t>
            <t hangText='Specification Document(s):'>
              Reference to the document that specifies the URI, preferably
              including a URI that can be used to retrieve a copy of the
              document.  An indication of the relevant sections may also be
              included, but is not required.
            </t>
          </list>
        </t>
        <t>The registration request for the urn:ietf:params:oauth URN Sub-namespace is found in the <xref target="IANA">IANA Considerations</xref> section of this document.</t>
        <section title="Example Registration Request" anchor="example">

          <t>The following is an example registration request for a URI underneath the urn:ietf:params:oauth sub-namespece. The requested URI represents a new OAuth 2.0 grant type.</t>
          <t>
            This is a request to IANA to please register the value
            <spanx style='verb'>grant-type:example</spanx> in the
            registry urn:ietf:params:oauth established in
            An IETF URN Sub-Namespace for OAuth.

            <list style='symbols'>
              <t>URN: urn:ietf:params:oauth:grant-type:example</t>
              <t>Common Name: An Example Grant Type for OAuth 2.0</t>
              <t>Change controller: IETF</t>
              <t>Specification Document: [[the document URI]] </t>
            </list>
          </t>


        </section>
      </section>
      <section anchor="Security" title="Security Considerations">
            <!--<t>All drafts are required to have a security considerations section.
                See
                <xref target="RFC3552">RFC 3552</xref>
                for a guide.
            </t>   -->
          <t>There are no additional security considerations beyond those already inherent to using URNs. Security considerations for URNs in general can be found in <xref target="RFC2141">RFC 2141</xref>.</t>
          <t>Any work that is related to OAuth would benefit from familiarity with the security considerations of <xref target="I-D.ietf-oauth-v2">The OAuth 2.0 Authorization Framework</xref>.</t>
        </section>
        <section title='IANA Considerations' anchor="IANA">
          <t>This document makes two requests of IANA:</t>
          <t>
            <list style='symbols'>
              <t>Registration of a new IANA URN sub-namespace, urn:ietf:params:oauth:, per
                  <xref target="RFC3553">RFC 3553</xref>. The registration request can be found in <xref target="sub-ns-reg"/> below.</t>
              <t>Establishment of a new registry for URNs subordinate to urn:ietf:params:oauth.
                Instructions for a registrant to request the registration of such a URN are in <xref target="registration"/>.</t>
            </list>
          </t>



          <section title='IETF URN Sub-namespace Registration urn:ietf:params:oauth' anchor="sub-ns-reg">
            <t>
              Per <xref target="RFC3553">RFC 3553</xref>, IANA is requested to please register a new URN sub-namespace, urn:ietf:params:oauth.
            </t>
            <t>
            <list style='symbols'>
                <t>Registry name: oauth</t>
                <t>Specification: [[this document]]</t>
                <t>Repository:  [[The registry created in Section 3.]] </t>
                <t>Index value: values subordinate to urn:ietf:params:oauth are of the form urn:ietf:params:oauth:&lt;value&gt; with &lt;value&gt; as the index value.  It is suggested that &lt;value&gt; include both a "class" and an "identifier-within-class" component, with the two components being separated by a colon (":"); other compositions of the &lt;value&gt; may also be used.</t>
            </list>
            </t>
          </section>

          <!--  "IANA considerations - what you have is fine for now, no need to change it unless you request a URN from them."" - Peter Saint-Andre  -->
        </section>

    </middle>


    <!--  *****BACK MATTER ***** -->

    <back>

        <!-- References split into informative and normative -->

        <!-- see http://www.rfc-editor.org/policy.html#policy.refs -->

        <!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
  (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search.  These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->

      <references title="Normative References">
          <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2141.xml' ?>
          <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3553.xml' ?>
          <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml' ?>


      </references>                                                                                                       
      <references title="Informative References">        
        <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-v2.xml' ?>
      </references>

      <section title="Acknowledgements">
        <t>The authors thank the following for their helpful contributions: Stephen Farrell, Barry Leiba, Peter Saint-Andre, Eran Hammer, John Bradley, Ben Campbell and Michael B. Jones.</t>
      </section>

      <section title='Document History'>
        <t>
          [[ to be removed by RFC editor before publication as an RFC ]]
        </t>
        <t>
              draft-ietf-oauth-urn-sub-ns-06
              <list style='symbols'>
                <t>Address editorial comments from Gen-ART LC Review: http://www.ietf.org/mail-archive/web/gen-art/current/msg07576.html</t>
              </list>
        </t>
        <t>
              draft-ietf-oauth-urn-sub-ns-05
              <list style='symbols'>
                <t>Change the registration procedure from Expert Review to Specification Required per WG discussion http://www.ietf.org/mail-archive/web/oauth/current/msg09445.html</t>
              </list>
        </t>
        <t>
              draft-ietf-oauth-urn-sub-ns-04
              <list style='symbols'>
                <t>Changed the Index value (and Registration Template into paragraph) from &lt;class&gt;&lt;id&gt; to just &lt;value&gt; with a suggestion that it have both a "class" and an "identifier-within-class" parts per http://www.ietf.org/mail-archive/web/oauth/current/msg09381.html so as to be less restrictive</t>
              </list>
        </t>


        <t>
              draft-ietf-oauth-urn-sub-ns-03
              <list style='symbols'>
                <t>Changes to address comments in the message "AD review of draft-ietf-oauth-urn-sub-ns-02" at http://www.ietf.org/mail-archive/web/oauth/current/msg09350.html and subsequent messages in that thread</t>
                <t>Update area and workgroup (now Security and OAuth was Internet and nothing)</t>
                <t>Change from informational to standards-track</t>
                <t>Requesting new URNs now more lightweight by changing from 'RFC Required' to 'Expert Review' (RFC5226)</t>
                <t>Rework much of the document to be more clear about it registering the urn:ietf:params:oauth URN sub-namespace and separately how other documents are to request URNs under that sub-namespace.</t>
                <t>Removed everything about asking the IANA to generate any part of the URN.</t>
                <t>Added an Example Registration Request</t>
                <t>Added reference to OAuth security considerations in security considerations.</t>
                <t>Added Acknowledgements</t>
              </list>
        </t>

        <t>
              draft-ietf-oauth-urn-sub-ns-02
              <list style='symbols'>
                <t>
                  fix typo: "The registration procedure for new entries to the requires a request ..." --> "The registration procedure for new entries requires a request ..."
                </t>
              </list>

        </t>
         <t>
              draft-ietf-oauth-urn-sub-ns-01
              <list style='symbols'>
                <t>
                 security considerations now points to RFC 2141 rather than RFC 3553 per http://www.ietf.org/mail-archive/web/oauth/current/msg07880.html
                </t>
              </list>

        </t>
         <t>
              draft-ietf-oauth-urn-sub-ns-00
              <list style='symbols'>
                <t>
                  change doc name from draft-campbell-oauth-urn-sub-ns to draft-ietf-oauth-urn-sub-ns per http://www.ietf.org/mail-archive/web/oauth/current/msg07384.html
                </t>
              </list>

        </t>
        <t>
              draft-campbell-oauth-urn-sub-ns-01
              <list style='symbols'>
                <t>
                  minor editorial changes

                </t>
              </list>

        </t>
        <t>
              draft-campbell-oauth-urn-sub-ns-00
              <list style='symbols'>
                <t>
                  initial draft based on http://www.ietf.org/mail-archive/web/oauth/current/msg06949.html
                </t>
              </list>

        </t>
      </section>
    </back>
</rfc>
