OAuth Working Group                                          B. Campbell, Ed. Campbell
Internet-Draft                                       Ping Identity Corp.
Intended status: Informational Standards Track                           H. Tschofenig
Expires: July 4, December 23, 2012                        Nokia Siemens Networks
                                                                Jan
                                                           June 21, 2012

                  An IETF URN Sub-Namespace for OAuth
                     draft-ietf-oauth-urn-sub-ns-02
                     draft-ietf-oauth-urn-sub-ns-03

Abstract

   This document establishes an IETF URN Sub-namespace for use with
   OAuth related specifications.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 4, December 23, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . . . 3
   3.  Registration Template . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Example Registration Request  . . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
     5.1.  IETF URN Sub-namespace Registration
           urn:ietf:params:oauth . . . . . . . . . . . . . . . . . . . 4
   Appendix A.  Document History
   6.  References  . . . . . . . . . . . . . . . . . . . 4
   6.  References . . . . . . . 5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     6.1.  Normative
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . . . 5
     6.2.  Informative References
   Appendix B.  Document History . . . . . . . . . . . . . . . . . . . 5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 5 7

1.  Introduction

   Various extensions and companion specifications to The OAuth 2.0
   Authorization Protocol [I-D.ietf.oauth-v2] Framework [I-D.ietf-oauth-v2] 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 [RFC3553], for use with such specifications.  The new 'oauth'
   sub-namespace look like is urn:ietf:params:oauth and OAuth relevant parameters
   will be established underneath it.

2.  Notational Conventions

   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 [RFC2119].

3.  Registration Template

   If the a registrant wishes to have a OAuth URI assigned, registered, then a URN of
   the form urn:ietf:params:oauth:<class>:<id> will be assigned requested where
   <class> is the category of the parameters functionality 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 [RFC3553] URN
   registration template is found in the IANA consideration section of
   this document. functionality within that class.

   The registration procedure for new entries requires a request in the
   form of the following template: template and is subject to Expert Review per
   RFC 5226 [RFC5226].

   URN:
      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". functionality.

   Common Name:
      The name by which the functionality being registered is generally
      referred.

   Registrant Contact:
      The individual/organization that is
      known.

   Change Controller:  For standards-track RFCs, state "IETF".  For
      others, give the registration contact for name of the component being registered.  Ideally, this will responsible party.  Other details
      (e.g., postal address, e-mail address, home page URI) may also be
      included.

   Specification Document(s):  Reference to the name
      and pertinent physical and network contact information.  In document that specifies
      the URI, preferably including a URI that can be used to retrieve a
      copy of the
      case document.  An indication of IETF developed standards, the Registrant will relevant sections may
      also be included, but is not required.

   The registration request for the IESG.

   Description:
      Information about urn:ietf:params:oauth URN Sub-
   namespace is found in the registered functionality. 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

   None not already inherent to using URNs.  Security considerations for
   URNs in general can be found in RFC 2141 [RFC2141].

5.  IANA Considerations

5.1.  IETF URN Sub-namespace Registration urn:ietf:params:oauth

   Per

   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

   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

   Per RFC 3553 [RFC3553], IANA is requested to establish the following
   registry.  New entries to the registry are Specification Required. please register a new
   URN sub-namespace, urn:ietf:params:oauth.

   o  Registry name: urn:ietf:params:oauth oauth

   o  Specification: Section 3 of this document contains the registry
      specification. [[this document]]

   o  Repository: To be assigned according to the guidelines found
      above. [[not sure about this? this document or
      http://www.iana.org/assignments/oauth]]

   o  Index value: The class name values subordinate to urn:ietf:params:oauth are of
      the from urn:ietf:params:oauth:<class>:<id> with <class>:<id> as
      the index value.

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 ]]

   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

   o  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

   o  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

   o  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
   o  minor editorial changes

   draft-campbell-oauth-urn-sub-ns-00

   o  initial draft based on
      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

   Brian Campbell (editor)
   Ping Identity Corp.

   Email: brian.d.campbell@gmail.com

   Hannes Tschofenig
   Nokia Siemens Networks

   Email: hannes.tschofenig@gmx.net