idnits 2.17.1 draft-ietf-oauth-jwsreq-11.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 30, 2017) is 2641 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO29100' ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Downref: Normative reference to an Informational RFC: RFC 6819 ** Downref: Normative reference to an Informational RFC: RFC 6973 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group N. Sakimura 3 Internet-Draft Nomura Research Institute 4 Intended status: Standards Track J. Bradley 5 Expires: August 3, 2017 Ping Identity 6 January 30, 2017 8 The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request 9 (JAR) 10 draft-ietf-oauth-jwsreq-11 12 Abstract 14 The authorization request in OAuth 2.0 described in RFC 6749 utilizes 15 query parameter serialization, which means that Authorization Request 16 parameters are encoded in the URI of the request and sent through 17 user agents such as web browsers. While it is easy to implement, it 18 means that (a) the communication through the user agents are not 19 integrity protected and thus the parameters can be tainted, and (b) 20 the source of the communication is not authenticated. Because of 21 these weaknesses, several attacks to the protocol have now been put 22 forward. 24 This document introduces the ability to send request parameters in a 25 JSON Web Token (JWT) instead, which allows the request to be JWS 26 signed and/or JWE encrypted so that the integrity, source 27 authentication and confidentiality property of the Authorization 28 Request is attained. The request can be sent by value or by 29 reference. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 3, 2017. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.1. Request Object . . . . . . . . . . . . . . . . . . . . . 6 69 2.2. Request Object URI . . . . . . . . . . . . . . . . . . . 6 70 3. Symbols and abbreviated terms . . . . . . . . . . . . . . . . 6 71 4. Request Object . . . . . . . . . . . . . . . . . . . . . . . 6 72 5. Authorization Request . . . . . . . . . . . . . . . . . . . . 8 73 5.1. Passing a Request Object by Value . . . . . . . . . . . . 9 74 5.2. Passing a Request Object by Reference . . . . . . . . . . 10 75 5.2.1. URL Referencing the Request Object . . . . . . . . . 12 76 5.2.2. Request using the "request_uri" Request Parameter . . 13 77 5.2.3. Authorization Server Fetches Request Object . . . . . 13 78 6. Validating JWT-Based Requests . . . . . . . . . . . . . . . . 13 79 6.1. Encrypted Request Object . . . . . . . . . . . . . . . . 13 80 6.2. JWS Signed Request Object . . . . . . . . . . . . . . . . 14 81 6.3. Request Parameter Assembly and Validation . . . . . . . . 14 82 7. Authorization Server Response . . . . . . . . . . . . . . . . 14 83 8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 14 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 86 10.1. Choice of Algorithms . . . . . . . . . . . . . . . . . . 15 87 10.2. Choice of Parameters to include in the Request Object . 15 88 10.3. Request Source Authentication . . . . . . . . . . . . . 16 89 10.4. Explicit Endpoints . . . . . . . . . . . . . . . . . . . 16 90 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 91 11.1. Collection limitation . . . . . . . . . . . . . . . . . 17 92 11.2. Disclosure Limitation . . . . . . . . . . . . . . . . . 18 93 11.2.1. Request Disclosure . . . . . . . . . . . . . . . . . 18 94 11.2.2. Tracking using Request Object URI . . . . . . . . . 18 95 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 96 13. Revision History . . . . . . . . . . . . . . . . . . . . . . 19 97 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 98 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 99 14.2. Informative References . . . . . . . . . . . . . . . . . 24 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 102 1. Introduction 104 The Authorization Request in OAuth 2.0 [RFC6749] utilizes query 105 parameter serialization and typically sent through user agents such 106 as web browsers. 108 For example, the parameters "response_type", "client_id", "state", 109 and "redirect_uri" are encoded in the URI of the request: 111 GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz 112 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 113 Host: server.example.com 115 While it is easy to implement, the encoding in the URI does not allow 116 application layer security with confidentiality and integrity 117 protection to be used. While TLS is used to offer communication 118 security between the Client and the user-agent and the user-agent and 119 the Authorization Server, TLS sessions are terminated in the user- 120 agent. In addition, TLS sessions may be terminated prematurely at 121 some middlebox (such as a load balancer). 123 As the result, the Authorization Request of [RFC6749] has a property 124 that 126 (a) the communication through the user agents are not integrity 127 protected and thus the parameters can be tainted (integrity 128 protection failure); 130 (b) the source of the communication is not authenticated (source 131 authentication failure); and 133 (c) the communication through the user agents can be monitored 134 (containment / confidentiality failure). 136 Because of these weaknesses, several attacks against the protocol, 137 such as Redirection URI rewriting, has been discovered. 139 The use of application layer security mitigates these issues. 141 In addition, it allows requests to be prepared by a third party so 142 that a client application cannot request more permissions than 143 previously agreed. This offers an additional degree of privacy 144 protection. 146 Furthermore, the request by reference allows the reduction of over- 147 the- wire overhead. 149 The JWT [RFC7519] encoding has been chosen because of 151 (1) its close relationship with JSON, which is used as OAuth's 152 response format; 154 (2) its developer friendliness due to its textual nature; 156 (3) its relative compactness compared to XML; 158 (4) its development status that it is an RFC and so is its 159 associated signing and encryption methods as [RFC7515] and 160 [RFC7516]; 162 (5) the relative ease of JWS and JWE compared to XML Signature and 163 Encryption. 165 The parameters "request" and "request_uri" are introduced as 166 additional authorization request parameters for the OAuth 2.0 167 [RFC6749] flows. The "request" parameter is a JSON Web Token (JWT) 168 [RFC7519] whose JWT Claims Set holds the JSON encoded OAuth 2.0 169 authorization request parameters. This JWT is integrity protected 170 and source authenticated using JWS. 172 The JWT [RFC7519] can be passed to the authorization endpoint by 173 reference, in which case the parameter "request_uri" is used instead 174 of the "request". 176 Using JWT [RFC7519] as the request encoding instead of query 177 parameters has several advantages: 179 (a) (integrity protection) The request can be signed so that the 180 integrity of the request can be checked; 182 (b) (source authentication) The request can be signed so that the 183 signer can be authenticated; 185 (c) (confidentiality protection) The request can be encrypted so 186 that end-to-end confidentiality can be provided even if the TLS 187 connection is terminated at one point or another; and 189 (d) (collection minimization) The request can be signed by a third 190 party attesting that the authorization request is compliant with 191 a certain policy. For example, a request can be pre-examined by 192 a third party that all the personal data requested is strictly 193 necessary to perform the process that the end-user asked for, 194 and statically signed by that third party. The client would 195 then send the request along with dynamic parameters such as 196 "state". The authorization server then examines the signature 197 and shows the conformance status to the end-user, who would have 198 some assurance as to the legitimacy of the request when 199 authorizing it. In some cases, it may even be desirable to skip 200 the authorization dialogue under such circumstances. 202 There are a few cases that request by reference is useful such as: 204 1. When it is desirable to reduce the size of transmitted request. 205 The use of application layer security increases the size of the 206 request, particularly when public key cryptography is used. 208 2. The client can make a signed Request Object and put it in a place 209 that the Authorization Server can access. This may just be done 210 by a client utility or other process, so that the private key 211 does not have to reside on the client, simplifying programming. 212 The downside of it is that the signed portion just become a 213 token. 215 3. When the server wants the requests to be cacheable: The 216 "request_uri" may include a SHA-256 hash of the contents of the 217 resources referenced by the Request Object URI. With this, the 218 server knows if the resource has changed without fetching it, so 219 it does not have to re-fetch the same content, which is a win as 220 well. This is explained in Section 5.2. 222 4. When the client does not want to do the crypto: The Authorization 223 Server may provide an endpoint to accept the Authorization 224 Request through direct communication with the Client so that the 225 Client is authenticated and the channel is TLS protected. 227 This capability is in use by OpenID Connect [OpenID.Core]. 229 1.1. Requirements Language 231 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 232 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 233 document are to be interpreted as described in RFC 2119 [RFC2119]. 235 2. Terminology 237 For the purposes of this specification, the following terms and 238 definitions in addition to what is defined in OAuth 2.0 Framework 239 [RFC6749], JSON Web Signature [RFC7515], and JSON Web Encryption 240 [RFC7519] apply. 242 2.1. Request Object 244 JWT [RFC7519] that holds an OAuth 2.0 authorization request as JWT 245 Claims Set 247 2.2. Request Object URI 249 Absolute URI from which the Request Object (Section 2.1) can be 250 obtained 252 3. Symbols and abbreviated terms 254 The following abbreviations are common to this specification. 256 JSON Javascript Object Notation 258 JWT JSON Web Token 260 JWS JSON Web Signature 262 JWE JSON Web Encryption 264 URI Uniform Resource Identifier 266 URL Uniform Resource Locator 268 WAP Wireless Application Protocol 270 4. Request Object 272 A Request Object (Section 2.1) is used to provide authorization 273 request parameters for an OAuth 2.0 authorization request. It 274 contains OAuth 2.0 [RFC6749] authorization request parameters 275 including extension parameters. The parameters are represented as 276 the JWT claims. Parameter names and string values MUST be included 277 as JSON strings. Since it is a JWT, JSON strings MUST be represented 278 in UTF-8. Numerical values MUST be included as JSON numbers. It MAY 279 include any extension parameters. This JSON [RFC7159] constitutes 280 the JWT Claims Set defined in JWT [RFC7519]. The JWT Claims Set is 281 then signed, encrypted, or signed and encrypted. 283 To sign, JSON Web Signature (JWS) [RFC7515] is used. The result is a 284 JWS signed JWT [RFC7519]. If signed, the Authorization Request 285 Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience) 286 as members, with their semantics being the same as defined in the JWT 287 [RFC7519] specification. 289 To encrypt, JWE [RFC7516] is used. Unless the algorithm used in JWE 290 allows for the source to be authenticated, JWS signature SHOULD also 291 be applied so that the source authentication can be done. When both 292 signature and encryption are being applied, the JWT MUST be signed 293 then encrypted as advised in the section 11.2 of [RFC7519]. The 294 result is a Nested JWT, as defined in [RFC7519]. 296 The Authorization Request Object MAY be sent by value as described in 297 Section 5.1 or by reference as described in Section 5.2. 299 Required OAuth 2.0 Authorization Request parameters that are not 300 included in the Request Object MUST be sent as query parameters. If 301 a required parameter is missing from both the query parameters and 302 the Request Object, the request is malformed. 304 "request" and "request_uri" parameters MUST NOT be included in 305 Request Objects. 307 If the parameter exists in both the query string and the 308 Authorization Request Object, the values in the Request Object take 309 precedence. This means that if it intends to use a cached request 310 object, it cannot include parameters such as "state" that are 311 expected to differ in every request. It is fine to include them in 312 the request object if it is going to be prepared afresh every time. 314 The following is a non-normative example of the Claims in a Request 315 Object before base64url encoding and signing. Note that it includes 316 extension variables such as "nonce" and "max_age". 318 { 319 "iss": "s6BhdRkqt3", 320 "aud": "https://server.example.com", 321 "response_type": "code id_token", 322 "client_id": "s6BhdRkqt3", 323 "redirect_uri": "https://client.example.org/cb", 324 "scope": "openid", 325 "state": "af0ifjsldkj", 326 "nonce": "n-0S6_WzA2Mj", 327 "max_age": 86400 328 } 330 Signing it with the "RS256" algorithm results in this Request Object 331 value (with line wraps within values for display purposes only): 333 eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3 334 F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl 335 c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk 336 JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w 337 bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW 338 Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog 339 ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ 340 ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p 341 Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS 342 wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg 343 ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH 344 sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu 345 dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm 346 luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs 347 F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF 348 KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx 349 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K 350 ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG 351 iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw 353 The following RSA public key, represented in JWK format, can be used 354 to validate the Request Object signature in this and subsequent 355 Request Object examples (with line wraps within values for display 356 purposes only): 358 { 359 "kty":"RSA", 360 "kid":"k2bdc", 361 "n":"y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKGHAtKlE5P 362 7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5OaaXDF 363 I6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVjdEFgZa 364 ZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghLL0HzOuYR 365 adBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUGsqkNA9b3xV 366 W53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw", 367 "e":"AQAB" 368 } 370 5. Authorization Request 372 The client constructs the authorization request URI by adding one of 373 the following parameters but not both to the query component of the 374 authorization endpoint URI using the "application/x-www-form- 375 urlencoded" format: 377 request The Request Object (Section 2.1) that holds authorization 378 request parameters stated in section 4 of OAuth 2.0 [RFC6749]. 380 request_uri The absolute URL that points to the Request Object 381 (Section 2.1) that holds authorization request parameters stated 382 in section 4 of OAuth 2.0 [RFC6749]. 384 The client directs the resource owner to the constructed URI using an 385 HTTP redirection response, or by other means available to it via the 386 user-agent. 388 For example, the client directs the end user's user-agent to make the 389 following HTTPS request: 391 GET /authz?request=eyJhbG..AlMGzw HTTP/1.1 392 Host: server.example.com 394 The value for the request parameter is abbreviated for brevity. 396 The authorization request object MUST be either 398 (a) JWS signed; or 400 (b) JWE encrypted (when symmetric keys are being used); or 402 (c) JWS signed and JWE encrypted. 404 When the Request Object is used, the OAuth 2.0 request parameter 405 values contained in the JWS Signed and/or JWE Encrypted JWT supersede 406 those passed using the OAuth 2.0 request syntax. Parameters MAY also 407 be passed using the OAuth 2.0 request syntax even when a Request 408 Object is used in the cases such as (a) to achieve backward 409 compatibility with [RFC6749] or (b) to enable a cached, pre-signed 410 (and possibly pre-encrypted) Request Object value to be used 411 containing the fixed request parameters, while parameters that can 412 vary with each request, such as "state" and "nonce" of OpenID 413 Connect, are passed as OAuth 2.0 parameters. In such case, one needs 414 to carefully assess the risk associated with it as unprotected 415 parameters would create additional attack surfaces. See Section 10.2 416 as well. 418 5.1. Passing a Request Object by Value 420 The Client sends the Authorization Request as a Request Object to the 421 Authorization Endpoint as the "request" parameter value. 423 The following is a non-normative example of an Authorization Request 424 using the "request" parameter (with line wraps within values for 425 display purposes only): 427 https://server.example.com/authorize? 428 request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiA 429 iczZCaGRSa3F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmN 430 vbSIsDQogInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWV 431 udF9pZCI6ICJzNkJoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8 432 vY2xpZW50LmV4YW1wbGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiA 433 ic3RhdGUiOiAiYWYwaWZqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWo 434 iLA0KICJtYXhfYWdlIjogODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXN 435 lcmluZm8iOiANCiAgICB7DQogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWw 436 iOiB0cnVlfSwNCiAgICAgIm5pY2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjo 437 geyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJ 438 lc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgInBpY3R1cmUiOiBudWxsDQogICAgfSw 439 NCiAgICJpZF90b2tlbiI6IA0KICAgIHsNCiAgICAgImdlbmRlciI6IG51bGwsDQo 440 gICAgICJiaXJ0aGRhdGUiOiB7ImVzc2VudGlhbCI6IHRydWV9LA0KICAgICAiYWN 441 yIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOmluY29tbW9uOmlhcDpzaWx2ZXIiXX0 442 NCiAgICB9DQogIH0NCn0.nwwnNsk1-ZkbmnvsF6zTHm8CHERFMGQPhos-EJcaH4H 443 h-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyFKzuMXZFSZ3p6Mb8dkxtVyjoy2 444 GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx0GxFbuPbj96tVuj11pTnmFC 445 UR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8Kol-cSLWoYE9l5QqholImz 446 jT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPGiyon_-Te111V8uE83Il 447 zCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw 449 5.2. Passing a Request Object by Reference 451 The "request_uri" Authorization Request parameter enables OAuth 452 authorization requests to be passed by reference, rather than by 453 value. This parameter is used identically to the "request" 454 parameter, other than that the Request Object value is retrieved from 455 the resource at the specified URL, rather than passed by value. 457 When the "request_uri" parameter is used, the OAuth 2.0 authorization 458 request parameter values contained in the referenced JWT supersede 459 those passed using the OAuth 2.0 request syntax. Parameters MAY also 460 be passed using the OAuth 2.0 request syntax even when a Request 461 Object is used in the cases such as (a) to achieve backward 462 compatibility with [RFC6749] or (b) to enable a cached, pre-signed 463 (and possibly pre-encrypted) Request Object value to be used 464 containing the fixed request parameters, while parameters that can 465 vary with each request, such as "state" and "nonce" of OpenID 466 Connect, are passed as OAuth 2.0 parameters. In such case, one needs 467 to carefully assess the risk associated with it as unprotected 468 parameters would create additional attack surfaces. See Section 10.2 469 as well. 471 Servers MAY cache the contents of the resources referenced by Request 472 Object URIs. If the contents of the referenced resource could ever 473 change, the URI SHOULD include the base64url encoded SHA-256 hash as 474 defined in RFC6234 [RFC6234] of the referenced resource contents as 475 the fragment component of the URI. If the fragment value used for a 476 URI changes, it signals the server that any cached value for that URI 477 with the old fragment value is no longer valid. 479 The entire Request URI MUST NOT exceed 512 ASCII characters. There 480 are three reasons for this restriction. 482 1. Many WAP / feature phones do not accept large payloads. The 483 restriction is typically either 512 or 1024 ASCII characters. 485 2. The maximum URL length supported by older versions of Internet 486 Explorer is 2083 ASCII characters. 488 3. On a slow connection such as 2G mobile connection, a large URL 489 would cause the slow response and therefore the use of such is 490 not advisable from the user experience point of view. 492 The contents of the resource referenced by the URL MUST be a Request 493 Object. The scheme used in the "request_uri" value MUST be "https", 494 unless the target Request Object is signed in a way that is 495 verifiable by the Authorization Server. The "request_uri" value MUST 496 be reachable by the Authorization Server, and SHOULD be reachable by 497 the Client. 499 The following is a non-normative example of the contents of a Request 500 Object resource that can be referenced by a "request_uri" (with line 501 wraps within values for display purposes only): 503 eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3 504 F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl 505 c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk 506 JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w 507 bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW 508 Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog 509 ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ 510 ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p 511 Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS 512 wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg 513 ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH 514 sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu 515 dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm 516 luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs 517 F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF 518 KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx 519 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K 520 ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG 521 iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw 523 5.2.1. URL Referencing the Request Object 525 The Client stores the Request Object resource either locally or 526 remotely at a URL the Authorization Server can access. The URL MUST 527 be HTTPS URL. This URL is the Request Object URI, "request_uri". 529 It is possible for the Request Object to include values that are to 530 be revealed only to the Authorization Server. As such, the 531 "request_uri" MUST have appropriate entropy for its lifetime. It is 532 RECOMMENDED that it be removed if it is known that it will not be 533 used again or after a reasonable timeout unless access control 534 measures are taken. 536 Unless the access to the "request_uri" over TLS provides adequate 537 authentication of the source of the Request Object, the Request 538 Object MUST be JWS Signed. 540 The following is a non-normative example of a Request Object URI 541 value (with line wraps within values for display purposes only): 543 https://client.example.org/request.jwt# 544 GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM 546 5.2.2. Request using the "request_uri" Request Parameter 548 The Client sends the Authorization Request to the Authorization 549 Endpoint. 551 The following is a non-normative example of an Authorization Request 552 using the "request_uri" parameter (with line wraps within values for 553 display purposes only): 555 https://server.example.com/authorize? 556 response_type=code%20id_token 557 &client_id=s6BhdRkqt3 558 &request_uri=https%3A%2F%2Fclient.example.org%2Frequest.jwt 559 %23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM 560 &state=af0ifjsldkj 562 5.2.3. Authorization Server Fetches Request Object 564 Upon receipt of the Request, the Authorization Server MUST send an 565 HTTP "GET" request to the "request_uri" to retrieve the referenced 566 Request Object, unless it is already cached, and parse it to recreate 567 the Authorization Request parameters. 569 Note that the client SHOULD use a unique URI for each request 570 containing distinct parameters values, or otherwise prevent the 571 Authorization Server from caching the "request_uri". 573 The following is a non-normative example of this fetch process: 575 GET /request.jwt HTTP/1.1 576 Host: client.example.org 578 6. Validating JWT-Based Requests 580 6.1. Encrypted Request Object 582 The Authorization Server MUST decrypt the JWT in accordance with the 583 JSON Web Encryption [RFC7516] specification. If the result is a 584 signed request object, signature validation MUST be performed as 585 defined in Section 6.2 as well. 587 If decryption fails, the Authorization Server MUST return an 588 "invalid_request_object" error. 590 6.2. JWS Signed Request Object 592 To perform JWS Signature Validation, the "alg" Header Parameter in 593 the JOSE Header MUST match the value of the pre-registered algorithm. 594 The signature MUST be validated against the appropriate key for that 595 "client_id" and algorithm. 597 If signature validation fails, the Authorization Server MUST return 598 an "invalid_request_object" error. 600 6.3. Request Parameter Assembly and Validation 602 The Authorization Server MUST assemble the set of Authorization 603 Request parameters to be used from the Request Object value and the 604 OAuth 2.0 Authorization Request parameters (minus the "request" or 605 "request_uri" parameters). If the same parameter exists both in the 606 Request Object and the OAuth Authorization Request parameters, the 607 parameter in the Request Object is used. Using the assembled set of 608 Authorization Request parameters, the Authorization Server then 609 validates the request as specified in OAuth 2.0 [RFC6749]. 611 7. Authorization Server Response 613 Authorization Server Response is created and sent to the client as in 614 Section 4 of OAuth 2.0 [RFC6749] . 616 In addition, this document uses these additional error values: 618 invalid_request_uri The "request_uri" in the Authorization Request 619 returns an error or contains invalid data. 621 invalid_request_object The request parameter contains an invalid 622 Request Object. 624 request_not_supported The Authorization Server does not support the 625 use of the "request" parameter. 627 request_uri_not_supported The Authorization Server does not support 628 the use of the "request_uri" parameter. 630 8. TLS Requirements 632 Client implementations supporting the Request Object URI method MUST 633 support TLS following Recommendations for Secure Use of Transport 634 Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 635 [RFC7525]. 637 To protect against information disclosure and tampering, 638 confidentiality protection MUST be applied using TLS with a cipher 639 suite that provides confidentiality and integrity protection. 641 Whenever TLS is used, the identity of the service provider encoded in 642 the TLS server certificate MUST be verified using the procedures 643 described in Section 6 of [RFC6125]. 645 9. IANA Considerations 647 This specification requests no actions by IANA. 649 10. Security Considerations 651 In addition to the all the security considerations discussed in OAuth 652 2.0 [RFC6819], the security considerations in [RFC7515], [RFC7516], 653 and [RFC7518] needs to be considered. Also, there are several 654 academic papers such as [BASIN] that provide useful insight into the 655 security properties of protocols like OAuth. 657 In consideration of the above, this document advises taking the 658 following security considerations into account. 660 10.1. Choice of Algorithms 662 When sending the authorization request object through "request" 663 parameter, it MUST either be signed using JWS [RFC7515] or encrypted 664 using JWE [RFC7516] with then considered appropriate algorithm. 666 10.2. Choice of Parameters to include in the Request Object 668 Unless there is a compelling reason to do otherwise, it is strongly 669 recommended to create a request object that covers all the parameters 670 so that the entire request is integrity protected. 672 This means that the request object is going to be prepared fresh each 673 time an authorization request is made and caching cannot be used. It 674 has a performance disadvantage, but where such disadvantage is 675 permissible, it should be considered. 677 Unless the server and the client have agreed prior to the 678 authorization request to use the non-protected parameters, the 679 authorization server SHOULD reject a request that is not fully 680 integrity protected and source authenticated. Note that such 681 agreement needs to be done in a secure fashion. For example, the 682 developers from the server side and the client side can have a face 683 to face meeting to come to such an agreement. 685 10.3. Request Source Authentication 687 The source of the Authorization Request MUST always be verified. 688 There are several ways to do it in this specification. 690 (a) Verifying the JWS Signature of the Request Object. 692 (b) Verifying the TLS Server Identity of the Request Object URI. In 693 this case, the Authorization Server MUST know out-of-band that 694 the Client uses Request Object URI and only the Client is 695 covered by the TLS certificate. In general, it is not a 696 reliable method. 698 (c) Authorization Server is providing an endpoint that provides a 699 Request Object URI in exchange for a Request Object. In this 700 case, the Authorization Server MUST perform Client 701 Authentication to accept the Request Object and bind the Client 702 Identifier to the Request Object URI it is providing. Since 703 Request Object URI can be replayed, the lifetime of the Request 704 Object URI MUST be short and preferably one-time use. The 705 entropy of the Request Object URI MUST be sufficiently large. 706 The adequate shortness of the validity and the entropy of the 707 Request Object URI depends on the risk calculation based on the 708 value of the resource being protected. A general guidance for 709 the validity time would be less than a minute and the Request 710 Object URI is to include a cryptographic random value of 128bit 711 or more at the time of the writing of this specification. 713 (d) A third party, such as a Trust Framework Provider, provides an 714 endpoint that provides a Request Object URI in exchange for a 715 Request Object. The same requirements as (b) above apply. In 716 addition, the Authorization Server MUST know out-of-band that 717 the Client utilizes the Trust Framework Operator. 719 10.4. Explicit Endpoints 721 Although this specification does not require them, research such as 722 [BASIN] points out that it is a good practice to explicitly state the 723 intended interaction endpoints and the message position in the 724 sequence in a tamper evident manner so that the intent of the 725 initiator is unambiguous. The endpoints that come into question in 726 this specification are 728 (a) Protected Resources ("protected_resources"); 730 (b) Authorization Endpoint ("authorization_endpoint"); 732 (c) Redirection URI ("redirect_uri"); and 733 (d) Token Endpoint ("token_endpoint"). 735 While Redirection URI is included, others are not included in the 736 Authorization Request Object. It is probably a good idea to include 737 these in it to reduce the attack surface. An extension specification 738 should be created as a preventive measure to address potential 739 vulnerabilities that have not yet been identified. 741 11. Privacy Considerations 743 When the Client is being granted access to a protected resource 744 containing personal data, both the Client and the Authorization 745 Server need to adhere to Privacy Principles. ISO/IEC 29100 746 [ISO29100] is a freely accessible International Standard and its 747 Privacy Principles are good to follow. 749 While ISO/IEC 29100 [ISO29100] is a high-level document that gives 750 general guidance, RFC 6973 Privacy Considerations for Internet 751 Protocols [RFC6973] gives more specific guidances on the privacy 752 consideration for Internet Protocols. It gives excellent guidances 753 on the enhancement of protocol design and implementation. The 754 provision listed in it should be followed. 756 Most of the provision would apply to The OAuth 2.0 Authorization 757 Framework [RFC6749] and The OAuth 2.0 Authorization Framework: Bearer 758 Token Usage [RFC6750] and not specific to this specification. In 759 what follows, only the specific provisions to this specification are 760 noted. 762 11.1. Collection limitation 764 When the Client is being granted access to a protected resource 765 containing personal data, the Client SHOULD limit the collection of 766 personal data to that which is within the bounds of applicable law 767 and strictly necessary for the specified purpose(s). 769 It is often hard for the user to find out if the personal data asked 770 for is strictly necessary. A Trust Framework Provider can help the 771 user by examining the Client request and comparing to the proposed 772 processing by the Client and certifying the request. After the 773 certification, the Client, when making an Authorization Request, can 774 submit Authorization Request to the Trust Framework Provider to 775 obtain the Request Object URI. 777 Upon receiving such Request Object URI in the Authorization Request, 778 the Authorization Server first verifies that the authority portion of 779 the Request Object URI is a legitimate one for the Trust Framework 780 Provider. Then, the Authorization Server issues HTTP GET request to 781 the Request Object URI. Upon connecting, the Authorization Server 782 MUST verify the server identity represented in the TLS certificate is 783 legitimate for the Request Object URI. Then, the Authorization 784 Server can obtain the Request Object, which includes the "client_id" 785 representing the Client. 787 The Consent screen MUST indicate the Client and SHOULD indicate that 788 the request has been vetted by the Trust Framework Operator for the 789 adherence to the Collection Limitation principle. 791 11.2. Disclosure Limitation 793 11.2.1. Request Disclosure 795 This specification allows extension parameters. These may include 796 potentially sensitive information. Since URI query parameter may 797 leak through various means but most notably through referrer and 798 browser history, if the authorization request contains a potentially 799 sensitive parameter, the Client SHOULD JWE [RFC7516] encrypt the 800 request object. 802 Where Request Object URI method is being used, if the request object 803 contains personally identifiable or sensitive information, the 804 "request_uri" SHOULD be used only once, have a short validity period, 805 and MUST have large enough entropy deemed necessary with applicable 806 security policy unless the Request Object itself is JWE [RFC7516] 807 Encrypted. The adequate shortness of the validity and the entropy of 808 the Request Object URI depends on the risk calculation based on the 809 value of the resource being protected. A general guidance for the 810 validity time would be less than a minute and the Request Object URI 811 is to include a cryptographic random value of 128bit or more at the 812 time of the writing of this specification. 814 11.2.2. Tracking using Request Object URI 816 Even if the protected resource does not include a personally 817 identifiable information, it is sometimes possible to identify the 818 user through the Request Object URI if persistent per-user Request 819 Object URI is used. A third party may observe it through browser 820 history etc. and start correlating the user's activity using it. It 821 is in a way a data disclosure as well and should be avoided. 823 Therefore, per-user Request Object URI should be avoided. 825 12. Acknowledgements 827 The following people contributed to the creation of this document in 828 the OAuth WG. (Affiliations at the time of the contribution is 829 used.) 831 Sergey Beryozkin, Brian Campbell (Ping Identity), Vladimir Dzhuvinov 832 (Connect2id), Michael B. Jones (Microsoft), Torsten Lodderstedt 833 (Deutsche Telecom) Jim Manico, Axel Nenker(Deutsche Telecom), Hannes 834 Tschofenig (ARM), Denis Pinkas, Kathleen Moriarty (as AD), and Steve 835 Kent (as SECDIR). 837 The following people contributed to creating this document through 838 the OpenID Connect Core 1.0 [OpenID.Core]. 840 Brian Campbell (Ping Identity), George Fletcher (AOL), Ryo Itou 841 (Mixi), Edmund Jay (Illumila), Michael B. Jones (Microsoft), Breno 842 de Medeiros (Google), Hideki Nara (TACT), Justin Richer (MITRE). 844 In addition, the following people contributed to this and previous 845 versions through the OAuth Working Group. 847 Dirk Balfanz (Google), James H. Manger (Telstra), John Panzer 848 (Google), David Recordon (Facebook), Marius Scurtescu (Google), Luke 849 Shepard (Facebook). 851 13. Revision History 853 -11 855 o s/bing/being/ 857 o Added history for -10 859 -10 861 o #20: KM1 -- some wording that is awkward in the TLS section. 863 o #21: KM2 - the additional attacks against OAuth 2.0 should also 864 have a pointer 866 o #22: KM3 -- Nit: in the first line of 10.4: 868 o #23: KM4 -- Mention RFC6973 in Section 11 in addition to ISO 29100 870 o #24: SECDIR review: Section 4 -- Confusing requirements for 871 sign+encrypt 873 o #25: SECDIR review: Section 6 -- authentication and integrity need 874 not be provided if the requestor encrypts the token? 876 o #26: SECDIR Review: Section 10 -- why no reference for JWS 877 algorithms? 879 o #27: SECDIR Review: Section 10.2 - how to do the agreement between 880 client and server "a priori"? 882 o #28: SECDIR Review: Section 10.3 - Indication on "large entropy" 883 and "short lifetime" should be indicated 885 o #29: SECDIR Review: Section 10.3 - Typo 887 o #30: SECDIR Review: Section 10.4 - typos and missing articles 889 o #31: SECDIR Review: Section 10.4 - Clearer statement on the lack 890 of endpoint identifiers needed 892 o #32: SECDIR Review: Section 11 - ISO29100 needs to be moved to 893 normative reference 895 o #33: SECDIR Review: Section 11 - Better English and Entropy 896 language needed 898 o #34: Section 4: Typo 900 o #35: More Acknowledgment 902 o #36: DP - More precise qualification on Encryption needed. 904 -09 906 o Minor Editorial Nits. 908 o Section 10.4 added. 910 o Explicit reference to Security consideration (10.2) added in 911 section 5 and section 5.2. 913 o , (add yourself) removed from the acknowledgment. 915 -08 917 o Applied changes proposed by Hannes on 2016-06-29 on IETF OAuth 918 list recorded as https://bitbucket.org/Nat/oauth-jwsreq/ 919 issues/12/. 921 o TLS requirements added. 923 o Security Consideration reinforced. 925 o Privacy Consideration added. 927 o Introduction improved. 929 -07 931 o Changed the abbrev to OAuth JAR from oauth-jar. 933 o Clarified sig and enc methods. 935 o Better English. 937 o Removed claims from one of the example. 939 o Re-worded the URI construction. 941 o Changed the example to use request instead of request_uri. 943 o Clarified that Request Object parameters take precedence 944 regardless of request or request_uri parameters were used. 946 o Generalized the language in 4.2.1 to convey the intent more 947 clearly. 949 o Changed "Server" to "Authorization Server" as a clarification. 951 o Stopped talking about request_object_signing_alg. 953 o IANA considerations now reflect the current status. 955 o Added Brian Campbell to the contributors list. Made the lists 956 alphabetic order based on the last names. Clarified that the 957 affiliation is at the time of the contribution. 959 o Added "older versions of " to the reference to IE uri length 960 limitations. 962 o Stopped talking about signed or unsigned JWS etc. 964 o 1.Introduction improved. 966 -06 968 o Added explanation on the 512 chars URL restriction. 970 o Updated Acknowledgements. 972 -05 974 o More alignment with OpenID Connect. 976 -04 978 o Fixed typos in examples. (request_url -> request_uri, cliend_id -> 979 client_id) 981 o Aligned the error messages with the OAuth IANA registry. 983 o Added another rationale for having request object. 985 -03 987 o Fixed the non-normative description about the advantage of static 988 signature. 990 o Changed the requirement for the parameter values in the request 991 itself and the request object from 'MUST MATCH" to 'Req Obj takes 992 precedence. 994 -02 996 o Now that they are RFCs, replaced JWS, JWE, etc. with RFC numbers. 998 -01 1000 o Copy Edits. 1002 14. References 1004 14.1. Normative References 1006 [ISO29100] 1007 "ISO/IEC 29100 Information technology - Security 1008 techniques - Privacy framework", December 2011, 1009 . 1012 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1013 Requirement Levels", BCP 14, RFC 2119, 1014 DOI 10.17487/RFC2119, March 1997, 1015 . 1017 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1018 Verification of Domain-Based Application Service Identity 1019 within Internet Public Key Infrastructure Using X.509 1020 (PKIX) Certificates in the Context of Transport Layer 1021 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1022 2011, . 1024 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1025 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1026 DOI 10.17487/RFC6234, May 2011, 1027 . 1029 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1030 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1031 . 1033 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 1034 Framework: Bearer Token Usage", RFC 6750, 1035 DOI 10.17487/RFC6750, October 2012, 1036 . 1038 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 1039 Threat Model and Security Considerations", RFC 6819, 1040 DOI 10.17487/RFC6819, January 2013, 1041 . 1043 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1044 Morris, J., Hansen, M., and R. Smith, "Privacy 1045 Considerations for Internet Protocols", RFC 6973, 1046 DOI 10.17487/RFC6973, July 2013, 1047 . 1049 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1050 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1051 2014, . 1053 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1054 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1055 2015, . 1057 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1058 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1059 . 1061 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 1062 DOI 10.17487/RFC7518, May 2015, 1063 . 1065 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1066 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1067 . 1069 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1070 "Recommendations for Secure Use of Transport Layer 1071 Security (TLS) and Datagram Transport Layer Security 1072 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1073 2015, . 1075 14.2. Informative References 1077 [BASIN] Basin, D., Cremers, C., and S. Meier, "Provably Repairing 1078 the ISO/IEC 9798 Standard for Entity Authentication", 1079 Journal of Computer Security - Security and Trust 1080 Principles Volume 21 Issue 6, Pages 817-846, November 1081 2013, 1082 . 1085 [OpenID.Core] 1086 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 1087 C. Mortimore, "OpenID Connect Core 1.0", OpenID 1088 Foundation Standards, February 2014, 1089 . 1091 Authors' Addresses 1093 Nat Sakimura 1094 Nomura Research Institute 1095 1-6-5 Marunouchi, Marunouchi Kitaguchi Bldg. 1096 Chiyoda-ku, Tokyo 100-0005 1097 Japan 1099 Phone: +81-3-5533-2111 1100 Email: n-sakimura@nri.co.jp 1101 URI: http://nat.sakimura.org/ 1103 John Bradley 1104 Ping Identity 1105 Casilla 177, Sucursal Talagante 1106 Talagante, RM 1107 Chile 1109 Phone: +44 20 8133 3718 1110 Email: ve7jtb@ve7jtb.com 1111 URI: http://www.thread-safe.com/