idnits 2.17.1 draft-wmills-oauth-lrdd-07.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 date (February 5, 2013) is 4069 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5849 (Obsoleted by RFC 6749) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual W. Mills 3 Internet-Draft Yahoo! Inc. 4 Intended status: Informational February 5, 2013 5 Expires: August 9, 2013 7 Link relation Type Registrations for OAuth 2 8 draft-wmills-oauth-lrdd-07.txt 10 Abstract 12 Defines link relation type registrations for the OAuth 2 13 authentication framework and OAuth 1.0a. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on August 9, 2013. 32 Copyright Notice 34 Copyright (c) 2013 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. OAuth 2 Link Relation Types . . . . . . . . . . . . . . . . . 5 52 3.1. The "oauth2-authorize" Link Relation Type . . . . . . . . 5 53 3.2. The "oauth2-token" Link Relation Type . . . . . . . . . . 5 54 4. OAuth 1.0a Link Relation Types . . . . . . . . . . . . . . . . 6 55 4.1. The "oauth-initiate" Link Relation Type . . . . . . . . . 6 56 4.2. The "oauth-authorize" Link Relation Type . . . . . . . . . 6 57 4.3. The "oauth-token" Link Relation Type . . . . . . . . . . . 6 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 6.1. Link Type Registration . . . . . . . . . . . . . . . . . . 8 61 6.1.1. OAuth 2: oauth2-authorize . . . . . . . . . . . . . . 8 62 6.1.2. OAuth 2: oauth2-token . . . . . . . . . . . . . . . . 8 63 6.1.3. OAuth 1.0a: oauth-initiate . . . . . . . . . . . . . . 8 64 6.1.4. OAuth 1.0a: oauth-authorize . . . . . . . . . . . . . 9 65 6.1.5. OAuth 1.0a: oauth-token . . . . . . . . . . . . . . . 9 66 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 67 Appendix A. Document History . . . . . . . . . . . . . . . . . . 11 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 1. Introduction 72 This document defines the link relation type [RFC5988] registrations 73 for the OAuth 2 [RFC6749] authentication framework and for OAuth 1.0a 74 [RFC5849]. These link relation types are used during the discovery 75 process by clients needing to discover the entry points for OAuth 76 authorization, token, and initiation for a service or site. 78 2. Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 The reader is assumed to be familiar with the terms used in the OAuth 85 2 and OAuth 1.0a specifcations. OAuth uses the term "endpoint" 86 instead of "entry point", this document will generlaly use the term 87 "entry point" unless an OAuth specific term is needed. 89 3. OAuth 2 Link Relation Types 91 OAuth 2 [RFC6749] defines two entry points which a site or domain 92 might need to advertize. These are the user authorization endpoint 93 (usually expected to be a web page the user interacts with) and the 94 token endpoint used for obtaining tokens used to access protected 95 resources. These are described in detail in Section 3 of the OAuth 2 96 specification. 98 3.1. The "oauth2-authorize" Link Relation Type 100 This link type indicates a resource that provides an OAuth 2 101 authorization endpoint to be used for user authentication/ 102 authorization to grant access to a protected resource. 104 3.2. The "oauth2-token" Link Relation Type 106 The OAuth 2 token endpoint to be used for obtaining tokens to access 107 protected services. This link type has two link-extensions: 109 grant-types: A space separated list of OAuth 2 grant types (see 110 section 4 of [RFC6749]) that can be used at the token endpoint 111 to obtain a token. This is not an exclusive list, it provides 112 a hint to the application of what SHOULD be valid. A token 113 endpoint MAY support additional grant types not advertised by a 114 discovery service. The client MAY use this to determine the 115 grant types available for use. 117 token-types: A space separated list of OAuth 2 token types (see 118 section 7.1 of [RFC6749]) that may be issued by the token 119 endpoint. It is possible for a token endpoint to issue 120 multiple tokens, and types may vary based on scope or other 121 factors. This is not an exclusive list, it provides a hint to 122 the application of what SHOULD be valid, and it MAY be used by 123 a client to determine if the client supports one or more of the 124 token type(s) available. 126 4. OAuth 1.0a Link Relation Types 128 The OAuth 1.0a [RFC5849] protocol defines three entry points that a 129 site supporting OAuth 1.0a might advertize: the request initiation 130 endpoint, the authorization endpoint, and the token endpoint. These 131 are descibed in detail in Section 2 of the OAuth 1.0a specification. 133 4.1. The "oauth-initiate" Link Relation Type 135 The OAuth 1.0a entry point used to initiate the sequence, this short 136 lived request is what the user approves to grant access to the 137 resource. 139 4.2. The "oauth-authorize" Link Relation Type 141 The OAuth 1.0a authorization entry point used to approve an access 142 request. This is expected to be a user facing web interface. 144 4.3. The "oauth-token" Link Relation Type 146 The OAuth 1.0a token API entry point used to exchange an approved 147 access request for a token, used by the client once the resource 148 owner has approved the access request. 150 5. Security Considerations 152 This document is informational, defining values in existing 153 registries, and as such has no security properties to discuss. 155 6. IANA Considerations 157 6.1. Link Type Registration 159 Pursuant to [RFC5988] The following link relation type registrations 160 [[will be]] registered by mail to link-relations@ietf.org. 162 6.1.1. OAuth 2: oauth2-authorize 164 o Relation Name: oauth2-authorize 166 o Description: An OAuth 2 authorization endpoint to be used for user 167 authentication/authorization to grant access to a protected 168 resource. 170 o Reference: Section 3.1 of [[This Document]] 172 o Notes: 174 o Application Data: N/A 176 6.1.2. OAuth 2: oauth2-token 178 o Relation Name: oauth2-token 180 o Description: The OAuth 2 token endpoint to be used for obtaining 181 tokens use to access a protected resource. 183 o Reference: Section 3.2 of [[This Document]] 185 o Notes: This link type has two link extension parameters: "grant- 186 types" and "token-types". 188 o Application Data: N/A 190 6.1.3. OAuth 1.0a: oauth-initiate 192 o Relation Name: oauth-initiate 194 o Description: The OAuth 1.0a request initiation endpoint used to 195 get an access request. 197 o Reference: Section 4.1 of [[This Document]] 199 o Notes: 201 o Application Data: N/A 203 6.1.4. OAuth 1.0a: oauth-authorize 205 o Relation Name: oauth-authorize 207 o Description: The OAuth 1.0a authorization endpoint used to approve 208 an access request. 210 o Reference: Section 4.2 of [[This Document]] 212 o Notes: 214 o Application Data: N/A 216 6.1.5. OAuth 1.0a: oauth-token 218 o Relation Name: oauth-token 220 o Description: The OAuth 1.0a token API endpoint used to exchange an 221 approved access request for a token, used by the client once the 222 resource owner has approved the access request. 224 o Reference: Section 4.3 of [[This Document]] 226 o Notes: 228 o Application Data: N/A 230 7. Normative References 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, March 1997. 235 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 236 April 2010. 238 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 240 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", 241 RFC 6749, October 2012. 243 Appendix A. Document History 245 [[ to be removed by RFC editor before publication as an RFC ]] 247 -07 249 o Editorial feedback & removed references. 251 o Added specific text to note sections in the OAuth specs. 253 -06 255 o Restructured the link extensions dscription into the prose, 256 simplifying the IANA section. 258 -05 260 o Changed the references to [[this document]] in the IANA parts. 262 o Added a small ammount of text. 264 -04 266 o Fixed the title. 268 o Removed the examples. 270 -03 272 o Corrected more typos and fixed the XRD for the examples, and small 273 changes in the prose. 275 -02 277 o Corrected typos. Added and example. 279 -01 281 o Editorial changes, corrected authenticate to authrorize is most 282 places, and added examples. 284 -00 286 o Initial revision 288 Author's Address 290 William J. Mills 291 Yahoo! Inc. 293 Phone: 294 Email: wmills_92105@yahoo.com