One document matched: draft-ietf-oauth-urn-sub-ns-02.xml
<?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="info"
docName="draft-ietf-oauth-urn-sub-ns-02"
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" role="editor" 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 month="Jan" 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>Internet</area>
<workgroup> </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>
<!-- 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 Protocol</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 look like urn:ietf:params:oauth and OAuth relevant parameters will be established underneath it.
</t>
</section>
<section title="Notational Conventions">
<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 title="Registration Template">
<t>If the registrant wishes to have a URI assigned, then a URN of the form urn:ietf:params:oauth:<class>:<id>
will be assigned where <class> is the category of the parameters being registered and <id> is a
unique id generated by the IANA
based on any means the IANA deems necessary to maintain uniqueness
and persistence. NOTE: in order for a URN of this type to be
assigned, the item being registered MUST be documented
in a RFC. The
<xref target="RFC3553">RFC 3553</xref>
URN registration template is found
in the IANA consideration section of this document.
</t>
<t>
The registration procedure for new entries requires a request in the form of the following template:
</t>
<t>
<list style='hanging' hangIndent='3'>
<t hangText='URN:'>
<vspace/>
The token URI that identifies the registered component. If
the registrant is requesting that the IANA assign a URI then this
field should be specified as "please assign".
</t>
<t hangText='Common Name:'>
<vspace/>
The name by which the functionality being registered is generally referred.
</t>
<t hangText='Registrant Contact:'>
<vspace/>
The individual/organization that is the registration contact for
the component being registered. Ideally, this will be the name
and pertinent physical and network contact information. In the
case of IETF developed standards, the Registrant will be the IESG.
</t>
<t hangText='Description:'>
<vspace/>
Information about the registered functionality.
</t>
</list>
</t>
</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>None not already inherent to using URNs. Security considerations for URNs in general can be found in <xref target="RFC2141">RFC 2141</xref>.</t>
</section>
<section title='IANA Considerations'>
<section title='IETF URN Sub-namespace Registration urn:ietf:params:oauth'>
<t>
Per <xref target="RFC3553">RFC 3553</xref>, IANA is requested to establish the following registry. New entries
to the registry are Specification Required.
</t>
<t>
<list style='symbols'>
<t>Registry name: urn:ietf:params:oauth</t>
<t>Specification: Section 3 of this document contains the registry specification.</t>
<t>Repository: To be assigned according to the guidelines found above.</t>
<t>Index value: The class name</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>
<appendix title='Document History'>
<t>
[[ to be removed by RFC editor before publication as an RFC ]]
</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>
</appendix>
</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.2119.xml' ?>
<?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' ?>
</references>
<references title="Informative References">
<reference anchor="I-D.ietf.oauth-v2">
<front>
<title abbrev='OAuth2'>The OAuth 2.0 Authorization Protocol</title>
<author initials='E.' surname='Hammer-Lahav' fullname='Eran Hammer-Lahav' role='editor'></author>
<author initials='D.' surname='Recordon' fullname='David Recordon'></author>
<author initials='D.' surname='Hardt' fullname='Dick Hardt'></author>
<date year="2011" month="July"/>
</front>
<seriesInfo name="ID" value="draft-ietf-oauth-v2-20 (work in progress)"/>
<format type='TXT' target='http://tools.ietf.org/id/draft-ietf-oauth-v2-20.txt'/>
<format type='HTML' target='http://tools.ietf.org/id/draft-ietf-oauth-v2-20.html'/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:56:29 |