idnits 2.17.1 draft-hardjono-oauth-resource-reg-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 26, 2016) is 3006 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'JSON' is defined on line 107, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 120, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7159 (ref. 'JSON') (Obsoleted by RFC 8259) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hardjono, Ed. 3 Internet-Draft MIT 4 Intended status: Informational E. Maler 5 Expires: July 29, 2016 ForgeRock 6 M. Machulak 7 Cloud Identity 8 D. Catalano 9 Oracle 10 January 26, 2016 12 OAuth 2.0 Resource Set Registration 13 draft-hardjono-oauth-resource-reg-07 15 Abstract 17 This specification defines a resource set registration mechanism 18 between an OAuth 2.0 authorization server and resource server. The 19 resource server registers information about the semantics and 20 discovery properties of its resources with the authorization server. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 29, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Normative References . . . . . . . . . . . . . . . . . . 3 59 2.2. Informative References . . . . . . . . . . . . . . . . . 3 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 3 62 1. Introduction 64 There are various circumstances under which an OAuth 2.0 [OAuth2] 65 resource server may need to communicate information about its 66 protected resources to its authorization server: 68 o In some OAuth 2.0 deployments, the resource server and 69 authorization server are operated by the same organization and 70 deployed in the same domain, but many resource servers share a 71 single authorization server (a security token service (STS) 72 component). Thus, even though the trust between these two is 73 typically tightly bound, there is value in defining a singular 74 standardized resource protection communications interface between 75 the authorization server and each of the resource servers. 77 o In some deployments of OpenID Connect [OpenIDConnect], which has a 78 dependency on OAuth 2.0, the OpenID Provider (OP) component is a 79 specialized version of an OAuth authorization server that brokers 80 availability of user attributes by dealing with an ecosystem of 81 attribute providers (APs). These APs effectively function as 82 third-party resource servers. Thus, there is value in defining a 83 mechanism by which all of the third-party APs can communicate with 84 a central OP, as well as ensuring that trust between the 85 authorization server and resource servers is able to be 86 established in a dynamic, loosely coupled fashion. 88 o In some deployments of User-Managed Access [UMAcore], which has a 89 dependency on OAuth 2.0, an end-user resource owner (the "user" in 90 UMA) may choose their own authorization server as an independent 91 cloud-based service, along with using any number of resource 92 servers that make up their "personal cloud". Thus, there is value 93 in defining a mechanism by which all of the third-party resource 94 servers can outsource resource protection (and potentially 95 discovery) to a central authorization server, as well as ensuring 96 that trust between the authorization server and resource servers 97 is able to be established by the resource owner in a dynamic, 98 loosely coupled fashion. 100 Please see the full Resource Set Registration 1.0 Specification 101 [ResourceReg] for a complete description. 103 2. References 105 2.1. Normative References 107 [JSON] Bray, T., "The JavaScript Object Notation (JSON) Data 108 Interchange Format", March 2014, 109 . 111 [OAuth2] Hardt, D., "The OAuth 2.0 Authorization Framework", 112 October 2012, . 114 [ResourceReg] 115 Hardjono, T., Maler, E., Machulak, M., and D. Catalano, 116 "OAuth 2.0 Resource Set Registration Version 1.0.1", 117 December 2015, . 120 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 121 Requirement Levels", BCP 14, RFC 2119, 122 DOI 10.17487/RFC2119, March 1997, 123 . 125 [UMAcore] Hardjono, T., Maler, E., Machulak, M., and D. Catalano, 126 "User-Managed Access (UMA) Profile of OAuth 2.0 Version 127 1.0.1", December 2015, 128 . 131 2.2. Informative References 133 [OpenIDConnect] 134 Sakimura, N., "OpenID Connect Core 1.0 incorporating 135 errata set 1", November 2014, 136 . 138 Authors' Addresses 140 Thomas Hardjono (editor) 141 MIT 143 Email: hardjono@mit.edu 144 Eve Maler 145 ForgeRock 147 Email: eve.maler@forgerock.com 149 Maciej Machulak 150 Cloud Identity 152 Email: maciej.machulak@cloudidentity.co.uk 154 Domenico Catalano 155 Oracle 157 Email: domenico.catalano@oracle.com