idnits 2.17.1 draft-bradley-oauth-stateless-client-id-03.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 (July 18, 2016) is 2840 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: January 19, 2017 July 18, 2016 7 Stateless Client Identifier for OAuth 2 8 draft-bradley-oauth-stateless-client-id-03 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 January 19, 2017. 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. 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 cnf OPTIONAL. JWT Confirmation claim [RFC7800] providing 95 information for the token _endpoint to validate the presenter of 96 the client_id 98 iat OPTIONAL. Timestamp of when this client identifier was issued. 100 exp OPTIONAL. Timestamp of when this client identifier will expire. 102 kid RECOMMENDED if signed. Identifier of the key used to sign this 103 client identifier at the issuer. 105 reg REQUIRED. JSON Object containing a set of metadata claims of 106 client information such as its redirect URIs, display name, and 107 other items as defined in Dynamic Client Registration [RFC7591] 108 and its extensions. 110 The issuer SHOULD sign the JWT with JWS in such a way that the 111 signature can be verified by the authorization server. 113 The issuer MAY encrypt the JWT with JWE [RFC7516]. 115 3. Validating the Stateless Client Identifier 117 Upon receiving a stateless client identifier at either the 118 authorization endpoint or the token endpoint, the authorization 119 server parses it as a JWT. It first checks the iss field to 120 determine if it trusts identifiers issued by the party represented. 121 It then verifies the signature if the JWT (if signed) using JWS. The 122 key used to sign the JWT MAY be indicated by the kid field. The 123 authorization server MAY use other means to validate the JWT and 124 determine its authenticity. 126 The authorization server then reads the fields inside the reg claim 127 and uses these to configure the user experience and security 128 parameters of the authorization. 130 4. Obtaining a Stateless Client Identifier 132 The client identifier is intended to be opaque to the client, and as 133 such a stateless client identifier is intended to be obtained and 134 used in exactly the same way as a stateful client identifer would be 135 for any OAuth client. 137 o Manual registration: a developer uses an out-of-band adminstrative 138 process to generate the client identifier and related credentials. 140 o Dynamic registration: a developer or client uses the process 141 described in [Dyn Reg] to generate the client identifier and 142 related credentials. 144 o Self assertion: a developer or client generates the client 145 identifier on their own, often signing it with their own public 146 key. 148 It is completely up to the purview of particular authorization 149 servers which generation methods, and which client identifiers, they 150 will accept. 152 5. IANA Considerations 154 [ maybe we register the "reg" claim above? ] 156 This document makes no request of IANA. 158 Note to RFC Editor: this section may be removed on publication as an 159 RFC. 161 6. Security Considerations 163 Since many OAuth systems assume that a change in the client 164 identifier indicates a change in the client itself, systems using 165 stateless client identifiers SHOULD NOT allow clients to update their 166 information post registration. 168 Since the client identifier is passed through the browser to the 169 authorization endpoint, it MUST NOT contain any sensitive 170 information. Additionally, as in standard OAuth, posession of the 171 client identifier itself MUST NOT be assumed to be sufficient 172 authentication [in many cases? except implicit mode?]. 174 7. Acknowledgements 176 8. Normative References 178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 179 Requirement Levels", BCP 14, RFC 2119, 180 DOI 10.17487/RFC2119, March 1997, 181 . 183 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 184 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 185 2015, . 187 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 188 RFC 7516, DOI 10.17487/RFC7516, May 2015, 189 . 191 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 192 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 193 . 195 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 196 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 197 RFC 7591, DOI 10.17487/RFC7591, July 2015, 198 . 200 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 201 Possession Key Semantics for JSON Web Tokens (JWTs)", 202 RFC 7800, DOI 10.17487/RFC7800, April 2016, 203 . 205 Appendix A. Document History 207 [[ to be removed by the RFC Editor before publication as an RFC ]] 209 -03 211 o Added reference to RFC7800 and using the cnf claim in a clinet_id 212 (I am thinking that if the dynamic client registration endpoint is 213 on the same host as the token_endpoint, you could use the token 214 binding ID as the cnf method. 216 -02 218 o Added reference to RFC7591 220 -01 222 o Added reference to RFC for JOSE 224 -00 226 o Wrote the first draft. 228 Authors' Addresses 230 John Bradley (editor) 231 Ping Identity 233 Email: ve7jtb@ve7jtb.com 234 URI: http://www.thread-safe.com/ 236 Justin Richer