An IETF URN Sub-Namespace for OAuth
Ping Identity Corp.
brian.d.campbell@gmail.com
Nokia Siemens Networks
hannes.tschofenig@gmx.net
Internet
OAuth
URN
sub-namespace
This document establishes an IETF URN Sub-namespace for use with OAuth related specifications.
Various extensions and companion specifications to The OAuth 2.0 Authorization Protocol
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 RFC 3553, 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.
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 RFC 2119.
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
RFC 3553
URN registration template is found
in the IANA consideration section of this document.
The registration procedure for new entries requires a request in the form of the following template:
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".
The name by which the functionality being registered is generally referred.
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.
Information about the registered functionality.
None not already inherent to using URNs. Security considerations for URNs in general can be found in RFC 2141.
Per RFC 3553, IANA is requested to establish the following registry. New entries
to the registry are Specification Required.
Registry name: urn:ietf:params:oauth
Specification: Section 3 of this document contains the registry specification.
Repository: To be assigned according to the guidelines found above.
Index value: The class name
[[ to be removed by RFC editor before publication as an RFC ]]
draft-ietf-oauth-urn-sub-ns-02
fix typo: "The registration procedure for new entries to the requires a request ..." --> "The registration procedure for new entries requires a request ..."
draft-ietf-oauth-urn-sub-ns-01
security considerations now points to RFC 2141 rather than RFC 3553 per http://www.ietf.org/mail-archive/web/oauth/current/msg07880.html
draft-ietf-oauth-urn-sub-ns-00
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
draft-campbell-oauth-urn-sub-ns-01
minor editorial changes
draft-campbell-oauth-urn-sub-ns-00
initial draft based on http://www.ietf.org/mail-archive/web/oauth/current/msg06949.html
The OAuth 2.0 Authorization Protocol