idnits 2.17.1 draft-ietf-oauth-urn-sub-ns-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 22, 2012) is 4319 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-31) exists of draft-ietf-oauth-v2-27 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group B. Campbell 3 Internet-Draft Ping Identity Corp. 4 Intended status: Standards Track H. Tschofenig 5 Expires: December 24, 2012 Nokia Siemens Networks 6 June 22, 2012 8 An IETF URN Sub-Namespace for OAuth 9 draft-ietf-oauth-urn-sub-ns-04 11 Abstract 13 This document establishes an IETF URN Sub-namespace for use with 14 OAuth related specifications. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 24, 2012. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 52 3. Registration Template . . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Example Registration Request . . . . . . . . . . . . . . . 4 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 56 5.1. IETF URN Sub-namespace Registration 57 urn:ietf:params:oauth . . . . . . . . . . . . . . . . . . . 4 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 60 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 61 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5 62 Appendix B. Document History . . . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 Various extensions and companion specifications to The OAuth 2.0 68 Authorization Framework [I-D.ietf-oauth-v2] utilize URIs to identify 69 the extension in use or other relevant context. This document 70 creates and registers an IETF URN Sub-namespace, as documented in RFC 71 3553 [RFC3553], for use with such specifications. The new 'oauth' 72 sub-namespace is urn:ietf:params:oauth and OAuth relevant parameters 73 will be established underneath it. 75 2. Notational Conventions 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 [RFC2119]. 81 3. Registration Template 83 If a registrant wishes to have a OAuth URI registered, then a URN of 84 the form urn:ietf:params:oauth: will be requested where 85 is a suitable representation of the functionality or concept 86 being registered. 88 The registration procedure for new entries requires a request in the 89 form of the following template and is subject to Expert Review per 90 RFC 5226 [RFC5226]. 92 URN: 93 The URI that identifies the registered functionality. 95 Common Name: 96 The name by which the functionality being registered is generally 97 known. 99 Change Controller: For standards-track RFCs, state "IETF". For 100 others, give the name of the responsible party. Other details 101 (e.g., postal address, e-mail address, home page URI) may also be 102 included. 104 Specification Document(s): Reference to the document that specifies 105 the URI, preferably including a URI that can be used to retrieve a 106 copy of the document. An indication of the relevant sections may 107 also be included, but is not required. 109 The registration request for the urn:ietf:params:oauth URN Sub- 110 namespace is found in the IANA Considerations (Section 5) section of 111 this document. 113 3.1. Example Registration Request 115 The following is an example registration request for a URI underneath 116 the urn:ietf:params:oauth sub-namespece. The requested URI 117 represents a new OAuth 2.0 grant type. 119 This is a request to IANA to please register the value 120 "grant-type:example" in the registry urn:ietf:params:oauth 121 established in An IETF URN Sub-Namespace for OAuth. 123 o URN: urn:ietf:params:oauth:grant-type:example 125 o Common Name: An Example Grant Type for OAuth 2.0 127 o Change controller: IETF 129 o Specification Document: [[the document URI]] 131 4. Security Considerations 133 None not already inherent to using URNs. Security considerations for 134 URNs in general can be found in RFC 2141 [RFC2141]. 136 Any work that is related to OAuth would benefit from familiarity with 137 the security considerations of The OAuth 2.0 Authorization Framework 138 [I-D.ietf-oauth-v2]. 140 5. IANA Considerations 142 This document makes two requests of IANA: 144 o Registration of a new IANA URN sub-namespace, 145 urn:ietf:params:oauth:, per RFC 3553 [RFC3553]. The registration 146 request can be found in Section 5.1 below. 148 o Establishment of a new registry for URNs subordinate to 149 urn:ietf:params:oauth. Instructions for a registrant to request 150 the registration of such a URN are in Section 3. 152 5.1. IETF URN Sub-namespace Registration urn:ietf:params:oauth 154 Per RFC 3553 [RFC3553], IANA is requested to please register a new 155 URN sub-namespace, urn:ietf:params:oauth. 157 o Registry name: oauth 159 o Specification: [[this document]] 161 o Repository: [[The registry created in Section 3.]] 163 o Index value: values subordinate to urn:ietf:params:oauth are of 164 the from urn:ietf:params:oauth: with as the index 165 value. It is suggested that include both a "class" and an 166 "identifier-within-class" component, with the two components being 167 separated by a colon (":"); other compositions of the may 168 also be used. 170 6. References 172 6.1. Normative References 174 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 175 Requirement Levels", BCP 14, RFC 2119, March 1997. 177 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 179 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 180 IETF URN Sub-namespace for Registered Protocol 181 Parameters", BCP 73, RFC 3553, June 2003. 183 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 184 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 185 May 2008. 187 6.2. Informative References 189 [I-D.ietf-oauth-v2] 190 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 191 2.0 Authorization Framework", draft-ietf-oauth-v2-27 (work 192 in progress), June 2012. 194 Appendix A. Acknowledgements 196 The authors thank the following for their helpful contributions: 197 Stephen Farrell, Barry Leiba, Peter Saint-Andre and Michael B. Jones. 199 Appendix B. Document History 201 [[ to be removed by RFC editor before publication as an RFC ]] 202 o Changed the Index value (and Registration Template into paragraph) 203 from to just with a suggestion that it have 204 both a "class" and an "identifier-within-class" parts per 205 http://www.ietf.org/mail-archive/web/oauth/current/msg09381.html 206 so as to be less restrictive 208 draft-ietf-oauth-urn-sub-ns-03 210 o Changes to address comments in the message "AD review of 211 draft-ietf-oauth-urn-sub-ns-02" at 212 http://www.ietf.org/mail-archive/web/oauth/current/msg09350.html 213 and subsequent messages in that thread 215 o Update area and workgroup (now Security and OAuth was Internet and 216 nothing) 218 o Change from informational to standards-track 220 o Requesting new URNs now more lightweight by changing from 'RFC 221 Required' to 'Expert Review' (RFC5226) 223 o Rework much of the document to be more clear about it registering 224 the urn:ietf:params:oauth URN sub-namespace and separately how 225 other documents are to request URNs under that sub-namespace. 227 o Removed everything about asking the IANA to generate any part of 228 the URN. 230 o Added an Example Registration Request 232 o Added reference to OAuth security considerations in security 233 considerations. 235 o Added Acknowledgements 237 draft-ietf-oauth-urn-sub-ns-02 239 o fix typo: "The registration procedure for new entries to the 240 requires a request ..." --> "The registration procedure for new 241 entries requires a request ..." 243 draft-ietf-oauth-urn-sub-ns-01 245 o security considerations now points to RFC 2141 rather than RFC 246 3553 per 247 http://www.ietf.org/mail-archive/web/oauth/current/msg07880.html 249 o change doc name from draft-campbell-oauth-urn-sub-ns to 250 draft-ietf-oauth-urn-sub-ns per 251 http://www.ietf.org/mail-archive/web/oauth/current/msg07384.html 253 draft-campbell-oauth-urn-sub-ns-01 255 o minor editorial changes 257 draft-campbell-oauth-urn-sub-ns-00 259 o initial draft based on 260 http://www.ietf.org/mail-archive/web/oauth/current/msg06949.html 262 Authors' Addresses 264 Brian Campbell 265 Ping Identity Corp. 267 Email: brian.d.campbell@gmail.com 269 Hannes Tschofenig 270 Nokia Siemens Networks 272 Email: hannes.tschofenig@gmx.net