< draft-ietf-oauth-urn-sub-ns-02.txt		draft-ietf-oauth-urn-sub-ns-03.txt >
	B. Campbell, Ed.		OAuth Working Group B. Campbell
	Internet-Draft Ping Identity Corp.		Internet-Draft Ping Identity Corp.
	Intended status: Informational H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: July 4, 2012 Nokia Siemens Networks		Expires: December 23, 2012 Nokia Siemens Networks
	Jan 2012		June 21, 2012
	An IETF URN Sub-Namespace for OAuth		An IETF URN Sub-Namespace for OAuth
	draft-ietf-oauth-urn-sub-ns-02		draft-ietf-oauth-urn-sub-ns-03
	Abstract		Abstract
	This document establishes an IETF URN Sub-namespace for use with		This document establishes an IETF URN Sub-namespace for use with
	OAuth related specifications.		OAuth related specifications.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 4, 2012.		This Internet-Draft will expire on December 23, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3		2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
	3. Registration Template . . . . . . . . . . . . . . . . . . . . . 3		3. Registration Template . . . . . . . . . . . . . . . . . . . . . 3
			3.1. Example Registration Request . . . . . . . . . . . . . . . 4
	4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4		4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
	5.1. IETF URN Sub-namespace Registration		5.1. IETF URN Sub-namespace Registration
	urn:ietf:params:oauth . . . . . . . . . . . . . . . . . . . 4		urn:ietf:params:oauth . . . . . . . . . . . . . . . . . . . 4
	Appendix A. Document History . . . . . . . . . . . . . . . . . . . 4
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 5		6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
	6.2. Informative References . . . . . . . . . . . . . . . . . . 5		6.2. Informative References . . . . . . . . . . . . . . . . . . 5
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5
			Appendix B. Document History . . . . . . . . . . . . . . . . . . . 5
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	Various extensions and companion specifications to The OAuth 2.0		Various extensions and companion specifications to The OAuth 2.0
	Authorization Protocol [I-D.ietf.oauth-v2] utilize URIs to identify		Authorization Framework [I-D.ietf-oauth-v2] utilize URIs to identify
	the extension in use or other relevant context. This document		the extension in use or other relevant context. This document
	creates and registers an IETF URN Sub-namespace, as documented in RFC		creates and registers an IETF URN Sub-namespace, as documented in RFC
	3553 [RFC3553], for use with such specifications. The new 'oauth'		3553 [RFC3553], for use with such specifications. The new 'oauth'
	sub-namespace look like urn:ietf:params:oauth and OAuth relevant		sub-namespace is urn:ietf:params:oauth and OAuth relevant parameters
	parameters will be established underneath it.		will be established underneath it.
	2. Notational Conventions		2. Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	3. Registration Template		3. Registration Template
	If the registrant wishes to have a URI assigned, then a URN of the		If a registrant wishes to have a OAuth URI registered, then a URN of
	form urn:ietf:params:oauth:<class>:<id> will be assigned where		the form urn:ietf:params:oauth:<class>:<id> will be requested where
	<class> is the category of the parameters being registered and <id>		<class> is the category of the functionality being registered and
	is a unique id generated by the IANA based on any means the IANA		<id> is a unique id for the functionality within that class.
	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 [RFC3553] URN
	registration template is found in the IANA consideration section of
	this document.
	The registration procedure for new entries requires a request in the		The registration procedure for new entries requires a request in the
	form of the following template:		form of the following template and is subject to Expert Review per
			RFC 5226 [RFC5226].
	URN:		URN:
	The token URI that identifies the registered component. If the		The URI that identifies the registered functionality.
	registrant is requesting that the IANA assign a URI then this
	field should be specified as "please assign".
	Common Name:		Common Name:
	The name by which the functionality being registered is generally		The name by which the functionality being registered is generally
	referred.		known.
	Registrant Contact:		Change Controller: For standards-track RFCs, state "IETF". For
	The individual/organization that is the registration contact for		others, give the name of the responsible party. Other details
	the component being registered. Ideally, this will be the name		(e.g., postal address, e-mail address, home page URI) may also be
	and pertinent physical and network contact information. In the		included.
	case of IETF developed standards, the Registrant will be the IESG.
	Description:		Specification Document(s): Reference to the document that specifies
	Information about the registered functionality.		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.
			The registration request for the urn:ietf:params:oauth URN Sub-
			namespace is found in the IANA Considerations (Section 5) section of
			this document.
			3.1. Example Registration Request
			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.
			This is a request to IANA to please register the value
			"grant-type:example" in the registry urn:ietf:params:oauth
			established in An IETF URN Sub-Namespace for OAuth.
			o URN: urn:ietf:params:oauth:grant-type:example
			o Common Name: An Example Grant Type for OAuth 2.0
			o Change controller: IETF
			o Specification Document: [[the document URI]]
	4. Security Considerations		4. Security Considerations
	None not already inherent to using URNs. Security considerations for		None not already inherent to using URNs. Security considerations for
	URNs in general can be found in RFC 2141 [RFC2141].		URNs in general can be found in RFC 2141 [RFC2141].
			Any work that is related to OAuth would benefit from familiarity with
			the security considerations of The OAuth 2.0 Authorization Framework
			[I-D.ietf-oauth-v2].
	5. IANA Considerations		5. IANA Considerations
			This document makes two requests of IANA:
			o Registration of a new IANA URN sub-namespace,
			urn:ietf:params:oauth:, per RFC 3553 [RFC3553]. The registration
			request can be found in Section 5.1 below.
			o 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 Section 3.
	5.1. IETF URN Sub-namespace Registration urn:ietf:params:oauth		5.1. IETF URN Sub-namespace Registration urn:ietf:params:oauth
	Per RFC 3553 [RFC3553], IANA is requested to establish the following		Per RFC 3553 [RFC3553], IANA is requested to please register a new
	registry. New entries to the registry are Specification Required.		URN sub-namespace, urn:ietf:params:oauth.
	o Registry name: urn:ietf:params:oauth		o Registry name: oauth
	o Specification: Section 3 of this document contains the registry		o Specification: [[this document]]
	specification.
	o Repository: To be assigned according to the guidelines found		o Repository: [[not sure about this? this document or
	above.		http://www.iana.org/assignments/oauth]]
	o Index value: The class name		o Index value: values subordinate to urn:ietf:params:oauth are of
			the from urn:ietf:params:oauth:<class>:<id> with <class>:<id> as
			the index value.
	Appendix A. Document History		6. References
			6.1. Normative References
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
			[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
			IETF URN Sub-namespace for Registered Protocol
			Parameters", BCP 73, RFC 3553, June 2003.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			May 2008.
			6.2. Informative References
			[I-D.ietf-oauth-v2]
			Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth
			2.0 Authorization Framework", draft-ietf-oauth-v2-27 (work
			in progress), June 2012.
			Appendix A. Acknowledgements
			The authors thank the following for their helpful contributions:
			Stephen Farrell, Barry Leiba, Peter Saint-Andre and Michael B. Jones.
			Appendix B. Document History
	[[ to be removed by RFC editor before publication as an RFC ]]		[[ to be removed by RFC editor before publication as an RFC ]]
			draft-ietf-oauth-urn-sub-ns-03
			o 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
			o Update area and workgroup (now Security and OAuth was Internet and
			nothing)
			o Change from informational to standards-track
			o Requesting new URNs now more lightweight by changing from 'RFC
			Required' to 'Expert Review' (RFC5226)
			o 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.
			o Removed everything about asking the IANA to generate any part of
			the URN.
			o Added an Example Registration Request
			o Added reference to OAuth security considerations in security
			considerations.
			o Added Acknowledgements
	draft-ietf-oauth-urn-sub-ns-02		draft-ietf-oauth-urn-sub-ns-02
	o fix typo: "The registration procedure for new entries to the		o fix typo: "The registration procedure for new entries to the
	requires a request ..." --> "The registration procedure for new		requires a request ..." --> "The registration procedure for new
	entries requires a request ..."		entries requires a request ..."
	draft-ietf-oauth-urn-sub-ns-01		draft-ietf-oauth-urn-sub-ns-01
	o security considerations now points to RFC 2141 rather than RFC		o security considerations now points to RFC 2141 rather than RFC
	3553 per		3553 per
	skipping to change at page 5, line 7 ¶		skipping to change at page 7, line 4 ¶
	3553 per		3553 per
	http://www.ietf.org/mail-archive/web/oauth/current/msg07880.html		http://www.ietf.org/mail-archive/web/oauth/current/msg07880.html
	draft-ietf-oauth-urn-sub-ns-00		draft-ietf-oauth-urn-sub-ns-00
	o change doc name from draft-campbell-oauth-urn-sub-ns to		o change doc name from draft-campbell-oauth-urn-sub-ns to
	draft-ietf-oauth-urn-sub-ns per		draft-ietf-oauth-urn-sub-ns per
	http://www.ietf.org/mail-archive/web/oauth/current/msg07384.html		http://www.ietf.org/mail-archive/web/oauth/current/msg07384.html
	draft-campbell-oauth-urn-sub-ns-01		draft-campbell-oauth-urn-sub-ns-01
	o minor editorial changes		o minor editorial changes
	draft-campbell-oauth-urn-sub-ns-00		draft-campbell-oauth-urn-sub-ns-00
	o initial draft based on		o initial draft based on
	http://www.ietf.org/mail-archive/web/oauth/current/msg06949.html		http://www.ietf.org/mail-archive/web/oauth/current/msg06949.html
	6. References
	6.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
	[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
	IETF URN Sub-namespace for Registered Protocol
	Parameters", BCP 73, RFC 3553, June 2003.
	6.2. Informative References
	[I-D.ietf.oauth-v2]
	Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, "The
	OAuth 2.0 Authorization Protocol",
	ID draft-ietf-oauth-v2-20 (work in progress), July 2011.
	Authors' Addresses		Authors' Addresses
	Brian Campbell (editor)		Brian Campbell
	Ping Identity Corp.		Ping Identity Corp.
	Email: brian.d.campbell@gmail.com		Email: brian.d.campbell@gmail.com
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Email: hannes.tschofenig@gmx.net		Email: hannes.tschofenig@gmx.net
End of changes. 27 change blocks.
	63 lines changed or deleted		133 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/