idnits 2.17.1 draft-bradley-oauth-stateless-client-id-01.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 (May 22, 2015) is 3254 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: November 23, 2015 May 22, 2015 7 Stateless Client Identifier for OAuth 2 8 draft-bradley-oauth-stateless-client-id-01 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 November 23, 2015. 39 Copyright Notice 41 Copyright (c) 2015 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 66 1. Introduction 68 In the OAuth 2.0 Authorization protocol, the Client must provide a 69 Client Identifier that the Authorization Server recognizes. 70 Additionally, an Autorization Server needs to know about a client's 71 details, such as its name and redirect URIs. Traditionally, this is 72 handled through a registration process, which may be either manual or 73 automated, where the authorization server maintains a stateful 74 relationship between the Client Identifier and its associated 75 metadata. This draft proposes a mechanism whereby the essential 76 metadata can be encoded into the Client Identifier itself, signed by 77 the issuer, and validated by the authorization server, thus allowing 78 the authorization server to be stateless in regard to client 79 information. 81 2. Stateless Client Identifier 83 The stateless client identifier consists of a JWT [RFC7519], 84 optionally signed with JWS [RFC7515], whose payload contains claims 85 as defined here. 87 iss REQUIRED. URL identifying the party that issued this client 88 identifier. 90 sub REQUIRED. Identifier of the client, locally unique to the 91 issuer. 93 iat OPTIONAL. Timestamp of when this client identifier was issued. 95 exp OPTIONAL. Timestamp of when this client identifier will expire. 97 kid RECOMMENDED if signed. Identifier of the key used to sign this 98 client identifier at the issuer. 100 reg REQUIRED. JSON Object containing a set of metadata claims of 101 client information such as its redirect URIs, display name, and 102 other items as defined in [Dyn Reg] and its extensions. 104 The issuer SHOULD sign the JWT with JWS in such a way that the 105 signature can be verified by the authorization server. 107 The issuer MAY encrypt the JWT with JWE [RFC7516]. 109 3. Validating the Stateless Client Identifier 111 Upon receiving a stateless client identifier at either the 112 authorization endpoint or the token endpoint, the authorization 113 server parses it as a JWT. It first checks the iss field to 114 determine if it trusts identifiers issued by the party represented. 115 It then verifies the signature if the JWT (if signed) using JWS. The 116 key used to sign the JWT MAY be indicated by the kid field. The 117 authorization server MAY use other means to validate the JWT and 118 determine its authenticity. 120 The authorization server then reads the fields inside the reg claim 121 and uses these to configure the user experience and security 122 parameters of the authorization. 124 4. Obtaining a Stateless Client Identifier 126 The client identifier is intended to be opaque to the client, and as 127 such a stateless client identifier is intended to be obtained and 128 used in exactly the same way as a stateful client identifer would be 129 for any OAuth client. 131 o Manual registration: a developer uses an out-of-band adminstrative 132 process to generate the client identifier and related credentials. 134 o Dynamic registration: a developer or client uses the process 135 described in [Dyn Reg] to generate the client identifier and 136 related credentials. 138 o Self assertion: a developer or client generates the client 139 identifier on their own, often signing it with their own public 140 key. 142 It is completely up to the purview of particular authorization 143 servers which generation methods, and which client identifiers, they 144 will accept. 146 5. IANA Considerations 148 [ maybe we register the "reg" claim above? ] 150 This document makes no request of IANA. 152 Note to RFC Editor: this section may be removed on publication as an 153 RFC. 155 6. Security Considerations 157 Since many OAuth systems assume that a change in the client 158 identifier indicates a change in the client itself, systems using 159 stateless client identifiers SHOULD NOT allow clients to update their 160 information post registration. 162 Since the client identifier is passed through the browser to the 163 authorization endpoint, it MUST NOT contain any sensitive 164 information. Additionally, as in standard OAuth, posession of the 165 client identifier itself MUST NOT be assumed to be sufficient 166 authentication [in many cases? except implicit mode?]. 168 7. Acknowledgements 170 8. Normative References 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, March 1997. 175 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 176 Signature (JWS)", RFC 7515, May 2015. 178 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 179 RFC 7516, May 2015. 181 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 182 (JWT)", RFC 7519, May 2015. 184 Authors' Addresses 186 John Bradley (editor) 187 Ping Identity 189 Email: ve7jtb@ve7jtb.com 190 URI: http://www.thread-safe.com/ 192 Justin Richer