idnits 2.17.1 draft-bradley-oauth-stateless-client-id-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 date (January 11, 2017) is 2633 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Bradley, Ed. 3 Internet-Draft Ping 4 Intended status: Experimental J. Richer 5 Expires: July 15, 2017 January 11, 2017 7 Stateless Client Identifier for OAuth 2 8 draft-bradley-oauth-stateless-client-id-04 10 Abstract 12 This draft provides a method for communicating information about an 13 OAuth client through its client identifier allowing for fully 14 stateless operation. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 15, 2017. 39 Copyright Notice 41 Copyright (c) 2017 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. Stateless Client Identifier . . . . . . . . . . . . . . . . . 2 58 3. Validating the Stateless Client Identifier . . . . . . . . . 3 59 4. Obtaining a Stateless Client Identifier . . . . . . . . . . . 3 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 63 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 64 Appendix A. Document History . . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 In the OAuth 2.0 Authorization protocol, the Client must provide a 70 Client Identifier that the Authorization Server recognizes. 71 Additionally, an Autorization Server needs to know about a client's 72 details, such as its name and redirect URIs. Traditionally, this is 73 handled through a registration process, which may be either manual or 74 automated, where the authorization server maintains a stateful 75 relationship between the Client Identifier and its associated 76 metadata. This draft proposes a mechanism whereby the essential 77 metadata can be encoded into the Client Identifier itself, signed by 78 the issuer, and validated by the authorization server, thus allowing 79 the authorization server to be stateless in regard to client 80 information. 82 2. Stateless Client Identifier 84 The stateless client identifier consists of a JWT [RFC7519], 85 optionally signed with JWS [RFC7515], whose payload contains claims 86 as defined here. 88 iss REQUIRED. URL identifying the party that issued this client 89 identifier. 91 sub REQUIRED. Identifier of the client, locally unique to the 92 issuer. 94 iat OPTIONAL. Timestamp of when this client identifier was issued. 96 exp OPTIONAL. Timestamp of when this client identifier will expire. 98 kid RECOMMENDED if signed. Identifier of the key used to sign this 99 client identifier at the issuer. 101 reg REQUIRED. JSON Object containing a set of metadata claims of 102 client information such as its redirect URIs, display name, and 103 other items as defined in Dynamic Client Registration [RFC7591] 104 and its extensions. 106 The issuer SHOULD sign the JWT with JWS in such a way that the 107 signature can be verified by the authorization server. 109 The issuer MAY encrypt the JWT with JWE [RFC7516]. 111 3. Validating the Stateless Client Identifier 113 Upon receiving a stateless client identifier at either the 114 authorization endpoint or the token endpoint, the authorization 115 server parses it as a JWT. It first checks the iss field to 116 determine if it trusts identifiers issued by the party represented. 117 It then verifies the signature if the JWT (if signed) using JWS. The 118 key used to sign the JWT MAY be indicated by the kid field. The 119 authorization server MAY use other means to validate the JWT and 120 determine its authenticity. 122 The authorization server then reads the fields inside the reg claim 123 and uses these to configure the user experience and security 124 parameters of the authorization. 126 4. Obtaining a Stateless Client Identifier 128 The client identifier is intended to be opaque to the client, and as 129 such a stateless client identifier is intended to be obtained and 130 used in exactly the same way as a stateful client identifer would be 131 for any OAuth client. 133 o Manual registration: a developer uses an out-of-band adminstrative 134 process to generate the client identifier and related credentials. 136 o Dynamic registration: a developer or client uses the process 137 described in [Dyn Reg] to generate the client identifier and 138 related credentials. 140 o Self assertion: a developer or client generates the client 141 identifier on their own, often signing it with their own public 142 key. 144 It is completely up to the purview of particular authorization 145 servers which generation methods, and which client identifiers, they 146 will accept. 148 5. IANA Considerations 150 [ maybe we register the "reg" claim above? ] 152 This document makes no request of IANA. 154 Note to RFC Editor: this section may be removed on publication as an 155 RFC. 157 6. Security Considerations 159 Since many OAuth systems assume that a change in the client 160 identifier indicates a change in the client itself, systems using 161 stateless client identifiers SHOULD NOT allow clients to update their 162 information post registration. 164 Since the client identifier is passed through the browser to the 165 authorization endpoint, it MUST NOT contain any sensitive 166 information. Additionally, as in standard OAuth, posession of the 167 client identifier itself MUST NOT be assumed to be sufficient 168 authentication [in many cases? except implicit mode?]. 170 7. Acknowledgements 172 8. Normative References 174 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 175 Requirement Levels", BCP 14, RFC 2119, 176 DOI 10.17487/RFC2119, March 1997, 177 . 179 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 180 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 181 2015, . 183 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 184 RFC 7516, DOI 10.17487/RFC7516, May 2015, 185 . 187 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 188 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 189 . 191 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 192 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 193 RFC 7591, DOI 10.17487/RFC7591, July 2015, 194 . 196 Appendix A. Document History 198 [[ to be removed by the RFC Editor before publication as an RFC ]] 200 -02 202 o Added reference to RFC7591 204 -01 206 o Added reference to RFC for JOSE 208 -00 210 o Wrote the first draft. 212 Authors' Addresses 214 John Bradley (editor) 215 Ping Identity 217 Email: ve7jtb@ve7jtb.com 218 URI: http://www.thread-safe.com/ 220 Justin Richer