idnits 2.17.1 draft-ietf-oauth-jwt-introspection-response-08.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 (Sep 19, 2019) is 1681 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) == Outdated reference: A later version (-07) exists of draft-ietf-oauth-jwt-bcp-06 == Outdated reference: A later version (-26) exists of draft-ietf-oauth-security-topics-13 ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Authentication Protocol T. Lodderstedt, Ed. 3 Internet-Draft yes.com AG 4 Intended status: Standards Track V. Dzhuvinov 5 Expires: March 22, 2020 Connect2id Ltd. 6 Sep 19, 2019 8 JWT Response for OAuth Token Introspection 9 draft-ietf-oauth-jwt-introspection-response-08 11 Abstract 13 This specification proposes an additional JSON Web Token (JWT) 14 secured response for OAuth 2.0 Token Introspection. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on March 22, 2020. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Requirements Notation and Conventions . . . . . . . . . . . . 3 52 3. Resource server management . . . . . . . . . . . . . . . . . 3 53 4. Requesting a JWT Response . . . . . . . . . . . . . . . . . . 4 54 5. JWT Response . . . . . . . . . . . . . . . . . . . . . . . . 4 55 6. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 7 56 7. Authorization Server Metadata . . . . . . . . . . . . . . . . 8 57 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 58 8.1. Cross-JWT Confusion . . . . . . . . . . . . . . . . . . . 9 59 8.2. Token Data Leakage . . . . . . . . . . . . . . . . . . . 9 60 8.3. Keeping Token Data Confidential from OAuth Clients . . . 10 61 8.4. Logging and Audit of Introspection Activity . . . . . . . 10 62 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 63 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 64 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 11.1. OAuth Dynamic Client Registration Metadata Registration 11 66 11.1.1. Registry Contents . . . . . . . . . . . . . . . . . 11 67 11.2. OAuth Authorization Server Metadata Registration . . . . 12 68 11.2.1. Registry Contents . . . . . . . . . . . . . . . . . 12 69 11.3. Media Type Registration . . . . . . . . . . . . . . . . 12 70 11.3.1. Registry Contents . . . . . . . . . . . . . . . . . 13 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 73 12.2. Informative References . . . . . . . . . . . . . . . . . 15 74 Appendix A. Document History . . . . . . . . . . . . . . . . . . 15 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 77 1. Introduction 79 OAuth 2.0 Token Introspection [RFC7662] specifies a method for a 80 protected resource to query an OAuth 2.0 authorization server to 81 determine the state of an access token and obtain data associated 82 with the access token. This enables deployments to implement opaque 83 access tokens in an interoperable way. 85 The introspection response, as specified in OAuth 2.0 Token 86 Introspection [RFC7662], is a plain JSON object. However, there are 87 use cases where the resource server requires stronger assurance that 88 the authorization server issued the token introspection response for 89 an access token, including cases where the authorization server 90 assumes liability for the content of the token introspection 91 response. An example is a resource server using verified person data 92 to create certificates, which in turn are used to create qualified 93 electronic signatures. 95 In such use cases it may be useful or even required to return a 96 signed JWT [RFC7519] as the introspection response. This 97 specification extends the token introspection endpoint with the 98 capability to return responses as JWTs. 100 2. Requirements Notation and Conventions 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 3. Resource server management 110 The authorization server (AS) and the resource server (RS) maintain a 111 strong two-way trust relationship. The resource server relies on the 112 authorization server to obtain authorization, user and other data as 113 input to its access control decisions and service delivery. The 114 authorization server relies on the resource server to handle the 115 provided data appropriately. 117 In the context of this specification, the Token Introspection 118 Endpoint is used to convey such security data and potentially also 119 privacy sensitive data related to an access token. 121 In order to process the introspection requests in a secure and 122 privacy-preserving manner, the authorization server MUST be able to 123 identify, authenticate and authorize resource servers. 125 To support encrypted token introspection response JWTs, the 126 authorization server MUST also be provided with the respective 127 resource server encryption keys and algorithms. 129 The authorization server MUST be able to determine whether an RS is 130 the audience for a particular access token and what data it is 131 entitled to receive, otherwise the RS is not authorized to obtain 132 data for the access token. The AS has the discretion how to fulfil 133 this requirement. The AS could, for example, maintain a mapping 134 between scopes values and resource servers. 136 The requirements given above imply that the authorization server 137 maintains credentials and other configuration data for each RS. 139 One way is by utilizing dynamic client registration [RFC7591] and 140 treating every RS as an OAuth client. In this case, the 141 authorization server is assumed to at least maintain "client_id" and 142 "token_endpoint_auth_method" with complementary authentication method 143 metadata, such as "jwks" or "client_secret". In cases where the AS 144 needs to acquire consent to transmit data to a RS, the following 145 client metadata fields are recommended: "client_name", "client_uri", 146 "contacts", "tos_uri", "policy_uri". 148 The AS MUST restrict the use of client credentials by a RS to the 149 calls it requires, e.g. the AS MAY restrict such a client to call the 150 token introspection endpoint only. How the AS implements this 151 restriction is beyond the scope of this specification. 153 This specification further introduces client metadata to manage the 154 configuration options required to sign and encrypt token 155 introspection response JWTs. 157 4. Requesting a JWT Response 159 A resource server requests to receive a JWT introspection response by 160 including an Accept header with content type "application/jwt" in the 161 introspection request. 163 Authentication at the token introspection endpoint can utilize client 164 authentication methods or a separate access token issued to the 165 resource server. Whether a resource server is required to 166 authenticate is determined by the respective RS-specific policy at 167 the AS. 169 The following is a non-normative example request using client 170 authentication: 172 POST /introspect HTTP/1.1 173 Host: server.example.com 174 Accept: application/jwt 175 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 176 Content-Type: application/x-www-form-urlencoded 178 token=2YotnFZFEjr1zCsicMWpAA 180 If required by its policy, the authorization server MUST authenticate 181 the caller and check its authorization to use the token introspection 182 endpoint. 184 5. JWT Response 186 The introspection endpoint responds with a JWT, setting the "Content- 187 Type" header to "application/jwt". This JWT is a cryptographically 188 protected representation of the token introspection response as 189 specified in [RFC7662]. 191 Note: Although the JWT format is widely used as an access token 192 format, the JWT returned in the introspection response is not an 193 alternative representation of the introspected access token and is 194 not intended to be used as an access token. 196 JWT metadata values, such as "iat", might differ between the token 197 introspection response in JWT format and the introspected access 198 token (see below). 200 This specification registers the "application/token- 201 introspection+jwt" media type, which is used as value of the "typ" 202 header parameter of the JWT to indicate that the payload is a token 203 introspection response. 205 If the access token is invalid, expired, has been revoked, or is not 206 intended to be consumed by the calling resource server (audience), 207 the authorization server MUST set the value of the response claim 208 "active" to "false". Otherwise, this claim is set to "true". 210 If the access token is considered active, it MUST contain the claims 211 "iss" and "aud" in order to prevent misuse of the JWT as an ID or 212 access token (see Section 8.1). 214 The "iss" MUST be set to the issuer URL of the AS. 216 The value of the "aud" claims MUST identify the resource server 217 receiving the token introspection response. 219 If the AS adds the following claims to the token introspection 220 response their meaning is defined as follows: 222 iat The "iat" claim indicates when the introspection response was 223 issued by the AS. 225 exp The "exp" claim indicates when the access token passed in the 226 introspection request will expire. 228 jti The "jti" claim is a unique identifier for the access token 229 passed in the introspection request. This identifier MUST be 230 stable for all introspection calls for a given access token. 232 Further content of the introspection response is determined by the 233 RS-specific policy at the AS. 235 If possible, the AS MUST narrow down the "scope" value to the scopes 236 relevant to the particular RS. 238 The JWT formatted introspection response MAY contain further claims, 239 especially the claims defined in the "OAuth Token Introspection 240 Response" registry established by [RFC7662] and the "JSON Web Token 241 Claims" registry established by [RFC7519]. 243 This includes claims from the "JSON Web Token Claims" registry that 244 are commonly used in [OpenID.Core] and can be applied to the resource 245 owner. These claims can serve to identify the resource owner as a 246 natural person or to provide a required contact detail, such as an 247 e-Mail address or phone number. When transmitting such claims the AS 248 acts as an identity provider in regard to the RS. 250 The AS determines based on the RS-specific policy what claims about 251 the resource owner to return in the token introspection response. 252 The AS MUST ensure that the release of any privacy-sensitive data is 253 legally based. 255 The following is a non-normative example response (with line breaks 256 for display purposes only): 258 HTTP/1.1 200 OK 259 Content-Type: application/jwt 261 eyJ0eXAiOiJ0b2tlbi1pbnRyb3NwZWN0aW9uK2p3dCIsImFsZyI6IlJTMjU2In0.eyJ 262 pc3MiOiJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbS8iLCJhdWQiOiJzNkJoZFJrcX 263 QzIiwianRpIjoidDFGb0NDYVpkNFh2NE9SSlVXVlVlVFpmc0toVzMwQ1FDcldERGp3W 264 Hk2dyIsImFjdGl2ZSI6dHJ1ZSwic2NvcGUiOiJyZWFkIHdyaXRlIGRvbHBoaW4iLCJl 265 eHAiOjE1MTQ3OTc5NDIwMDAsImlhdCI6MTUxNDc5NzgyMjAwMCwiY2xpZW50X2lkIjo 266 iczZCaGRSa3F0MyIsInN1YiI6Ilo1TzN1cFBDODhRckFqeDAwZGlzIiwiZ2l2ZW5fbm 267 FtZSI6IkpvaG4iLCJmYW1pbHlfbmFtZSI6IkRvZSIsImJpcnRoZGF0ZSI6IjE5ODItM 268 DItMDEifQ.mnGNVJJwMaMR-drVHIyjOd7S5mScHT5tYC_sLdeaS9C4pkmiOgwHNGah9 269 w_15kbotjDckotJNHpNTQCcE5nRC29L_jz5hSCNTMmK62fJdEcq0QVuCL_roeHzc-s1 270 bjU2V2Qme6_2468zqcuhf1fhcieWxx9bDwFFwk3su0qdoF9RBa0HobWzy1ENU6MjiKH 271 vmrnd5PkJenn1rJEt0EQTUuVE0vh2tQGhxbaZkQ34mLLgES5TCuBK7ALDXhT4aGCzxg 272 3jLprs_jYTjCq2kugptseKaxsvti0TxOxmxLPcuy5xRxHDUzV2h9_VWVJRgM8y0vhLN 273 v9XKDe4EQqaIFLA_YD4TBeyPV7Sm4xMQ-2OsSmAz0E2BY_b_s0WrFN2K8tspQhj2mnG 274 v7Zz8O3zeE2gC59JR56aU_SNspGPbt8GvTwuL5ZZTCmiWKUzQ0ev4zVthUczQmK53dx 275 Zl6ZxBfIRPV5k1GTPyEPbWehizbJT4JBSLlk-l8JvJcfL2USLtJgMLH1D01fww0IqN1 276 ofHeHFUmZWB_LR7kGaJ8Kx_a9z4CaaVesW8jzgSmwA8K_pv9yJqqjnUhsh51c49OAgn 277 cqwAahGrUhrN0dIBrd6sRXU3AiRpaah0MMNcjR2UJbEZKwnMyHTkBQAeZAe9vO9pKV8 278 JOd0ziYBpAbEpYGE4p3wog4 280 The example response header contains the following JSON document: 282 { 283 "typ": "token-introspection+jwt", 284 "alg": "RS256" 285 } 286 The example response payload contains the following JSON document: 288 { 289 "iss":"https://server.example.com/", 290 "aud":"s6BhdRkqt3", 291 "jti": "t1FoCCaZd4Xv4ORJUWVUeTZfsKhW30CQCrWDDjwXy6w", 292 "active":true, 293 "scope":"read write dolphin", 294 "exp":1514797942000, 295 "iat":1514797822000, 296 "client_id":"s6BhdRkqt3", 297 "sub":"Z5O3upPC88QrAjx00dis", 298 "given_name":"John", 299 "family_name":"Doe", 300 "birthdate":"1982-02-01" 301 } 303 Depending on the specific resource server policy the JWT is either 304 signed, or signed and encrypted. If the JWT is signed and encrypted 305 it MUST be a Nested JWT, as defined in JWT [RFC7519]. 307 Note: If the resource server policy requires a signed and encrypted 308 response and the authorization server receives an unauthenticated 309 request containing an Accept header with content type other than 310 "application/jwt", it MUST refuse to serve the request and return an 311 HTTP status code 400. This is done to prevent downgrading attacks to 312 obtain token data intended for release to legitimate recipients only 313 (see Section 8.2). 315 6. Client Metadata 317 The authorization server determines what algorithm to employ to 318 secure the JWT for a particular introspection response. This 319 decision can be based on registered metadata parameters for the 320 resource server, supplied via dynamic client registration [RFC7591] 321 with the resource server acting as a client, as specified below. 323 The parameter names follow the pattern established by OpenID Connect 324 Dynamic Client Registration [OpenID.Registration] for configuring 325 signing and encryption algorithms for JWT responses at the UserInfo 326 endpoint. 328 The following client metadata parameters are introduced by this 329 specification: 331 introspection_signed_response_alg OPTIONAL. JWS [RFC7515] algorithm 332 ("alg" value) as defined in JWA [RFC7518] for signing 333 introspection responses. If this is specified, the response 334 will be signed using JWS and the configured algorithm. The 335 default, if omitted, is "RS256". 337 introspection_encrypted_response_alg OPTIONAL. JWE [RFC7516] 338 algorithm ("alg" value) as defined in JWA [RFC7518] for 339 content key encryption. If this is specified, the response 340 will be encrypted using JWE and the configured content 341 encryption algorithm 342 ("introspection_encrypted_response_enc"). The default, if 343 omitted, is that no encryption is performed. If both signing 344 and encryption are requested, the response will be signed 345 then encrypted, with the result being a Nested JWT, as 346 defined in JWT [RFC7519]. 348 introspection_encrypted_response_enc OPTIONAL. JWE [RFC7516] 349 algorithm ("enc" value) as defined in JWA [RFC7518] for 350 content encryption of introspection responses. The default, 351 if omitted, is "A128CBC-HS256". Note: This parameter MUST 352 NOT be specified without setting 353 "introspection_encrypted_response_alg". 355 Resource servers may register their public encryption keys using the 356 "jwks_uri" or "jwks" metadata parameters. 358 7. Authorization Server Metadata 360 Authorization servers SHOULD publish the supported algorithms for 361 signing and encrypting the JWT of an introspection response by 362 utilizing OAuth 2.0 Authorization Server Metadata [RFC8414] 363 parameters. Resource servers use this data to parametrize their 364 client registration requests. 366 The following parameters are introduced by this specification: 368 introspection_signing_alg_values_supported OPTIONAL. JSON array 369 containing a list of the JWS [RFC7515] signing algorithms 370 ("alg" values) as defined in JWA [RFC7518] supported by the 371 introspection endpoint to sign the response. 373 introspection_encryption_alg_values_supported OPTIONAL. JSON array 374 containing a list of the JWE [RFC7516] encryption algorithms 375 ("alg" values) as defined in JWA [RFC7518] supported by the 376 introspection endpoint to encrypt the content encryption key 377 for introspection responses (content key encryption). 379 introspection_encryption_enc_values_supported OPTIONAL. JSON array 380 containing a list of the JWE [RFC7516] encryption algorithms 381 ("enc" values) as defined in JWA [RFC7518] supported by the 382 introspection endpoint to encrypt the response (content 383 encryption). 385 8. Security Considerations 387 8.1. Cross-JWT Confusion 389 Token introspection responses in JWT format, access tokens in JWT 390 format, and OpenID Connect ID Tokens are syntactical similar. 391 Attackers could try to utilize this fact and attempt to use a token 392 introspection response as access token when invoking a resource 393 server or as ID Token when logging into at a OpenID Connect RP. 395 Any relying party processing the "typ" JWT header element should 396 detect the attack since token introspection responses in JWT format 397 set this header to the value "token-introspection+jwt". 398 Unfortunately, this is not a well established practice yet. 400 As an alternative approach, such an attack can be prevented like any 401 other token substitution attack by restricting the audience of the 402 JWT. As specified in Section 5, the authorization server includes 403 the claims "iss" and "aud" in each JWT introspection response, with 404 the "iss" value set to the authorization server's issuer URL and the 405 "aud" value set to the resource server's identifier. Any recipient 406 of an JWT MUST check these values in order to detect substitution 407 attacks. 409 OpenID Connect RPs are additionally expected to use and check the 410 "nonce" parameter and claim to prevent token and code replay. 412 Resource servers MUST additionally apply the countermeasures against 413 replay as described in [I-D.ietf-oauth-security-topics], section 3.2. 415 JWT Confusion and other attacks involving JWTs are discussed in 416 [I-D.ietf-oauth-jwt-bcp]. 418 8.2. Token Data Leakage 420 The authorization server MUST use Transport Layer Security (TLS) 1.2 421 (or higher) per BCP 195 [RFC7525] in order to prevent token data 422 leakage. 424 To prevent introspection of leaked tokens and to present an 425 additional security layer against token guessing attacks the 426 authorization server MAY require all requests to the token 427 introspection endpoint to be authenticated. As an alternative or as 428 an addition to the authentication, the intended recipients MAY be set 429 up for encrypted responses. 431 In the latter case, confidentiality is ensured by the fact that only 432 the legitimate recipient is able to decrypt the response. An 433 attacker could try to circumvent this measure by requesting a plain 434 JSON response, using an Accept header with the content type set to, 435 for example, "application/json" instead of "application/jwt". To 436 prevent this attack the authorization server MUST NOT serve requests 437 with a content type other than "application/jwt" if the resource 438 server is set up to receive encrypted responses (see also Section 5). 440 8.3. Keeping Token Data Confidential from OAuth Clients 442 Authorization servers with a policy that requires token data to be 443 kept confidential from OAuth clients must require all requests to the 444 token introspection endpoint to be authenticated. As an alternative 445 or as an addition to the authentication, the intended recipients may 446 be set up for encrypted responses. 448 8.4. Logging and Audit of Introspection Activity 450 Authorization servers with a policy that requires token introspection 451 activity to be logged and audited must require all requests to the 452 token introspection endpoint to be authenticated. 454 9. Privacy Considerations 456 The token introspection response can be used to transfer personal 457 identifiable information from the AS to the RS. The AS MUST ensure a 458 legal basis exists for the data transfer before any data is released 459 to a particular RS. The way the legal basis is established might 460 vary among jurisdictions and MUST consider the legal entities 461 involved. 463 For example, the classical way to establish the legal basis is by 464 explicit user consent gathered from the resource owner by the AS 465 during the authorization flow. 467 It is also possible that the legal basis is established out of band, 468 e.g. in an explicit contract or by the client gathering the resource 469 owner's consent. 471 If the AS and the RS belong to the same legal entity (1st party 472 scenario), there is potentially no need for an explicit user consent 473 but the terms of service and policy of the respective service 474 provider MUST be enforced at all times. 476 In any case, the AS MUST ensure that the scope of the legal basis is 477 enforced throughout the whole process. The AS MUST retain the scope 478 of the legal basis with the access token, e.g. in the scope value, 479 and the AS MUST determine the data a resource server is allowed to 480 receive based on the resource server's identity and suitable token 481 data, e.g. the scope value. 483 10. Acknowledgements 485 We would like to thank Petteri Stenius, Neil Madden, Filip Skokan, 486 Tony Nadalin, and Remco Schaar for their valuable feedback. 488 11. IANA Considerations 490 11.1. OAuth Dynamic Client Registration Metadata Registration 492 This specification requests registration of the following client 493 metadata definitions in the IANA "OAuth Dynamic Client Registration 494 Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]: 496 11.1.1. Registry Contents 498 o Client Metadata Name: "introspection_signed_response_alg" 500 o Client Metadata Description: String value indicating the client's 501 desired introspection response signing algorithm. 503 o Change Controller: IESG 505 o Specification Document(s): Section 6 of [[ this specification ]] 507 o Client Metadata Name: "introspection_encrypted_response_alg" 509 o Client Metadata Description: String value specifying the desired 510 introspection response content key encryption algorithm (alg 511 value). 513 o Change Controller: IESG 515 o Specification Document(s): Section 6 of [[ this specification ]] 517 o Client Metadata Name: "introspection_encrypted_response_enc" 519 o Client Metadata Description: String value specifying the desired 520 introspection response content encryption algorithm (enc value). 522 o Change Controller: IESG 524 o Specification Document(s): Section 6 of [[ this specification ]] 526 11.2. OAuth Authorization Server Metadata Registration 528 This specification requests registration of the following values in 529 the IANA "OAuth Authorization Server Metadata" registry 530 [IANA.OAuth.Parameters] established by [RFC8414]. 532 11.2.1. Registry Contents 534 o Metadata Name: "introspection_signing_alg_values_supported" 536 o Metadata Description: JSON array containing a list of algorithms 537 supported by the authorization server for introspection response 538 signing. 540 o Change Controller: IESG 542 o Specification Document(s): Section 7 of [[ this specification ]] 544 o Metadata Name: "introspection_encryption_alg_values_supported" 546 o Metadata Description: JSON array containing a list of algorithms 547 supported by the authorization server for introspection response 548 content key encryption (alg value). 550 o Change Controller: IESG 552 o Specification Document(s): Section 7 of [[ this specification ]] 554 o Metadata Name: "introspection_encryption_enc_values_supported" 556 o Metadata Description: JSON array containing a list of algorithms 557 supported by the authorization server for introspection response 558 content encryption (enc value). 560 o Change Controller: IESG 562 o Specification Document(s): Section 7 of [[ this specification ]] 564 11.3. Media Type Registration 566 This section registers the "application/token-introspection+jwt" 567 media type in the "Media Types" registry [IANA.MediaTypes] in the 568 manner described in [RFC6838], which can be used to indicate that the 569 content is a token introspection response in JWT format. 571 11.3.1. Registry Contents 573 o Type name: application 575 o Subtype name: token-introspection+jwt 577 o Required parameters: N/A 579 o Optional parameters: N/A 581 o Encoding considerations: binary; A token introspection response is 582 a JWT; JWT values are encoded as a series of base64url-encoded 583 values (with trailing '=' characters removed), some of which may 584 be the empty string, separated by period ('.') characters. 586 o Security considerations: See Section 7 of this specification 588 o Interoperability considerations: N/A 590 o Published specification: Section 4 of this specification 592 o Applications that use this media type: Applications that produce 593 and consume OAuth Token Introspection Responses in JWT format 595 o Fragment identifier considerations: N/A 597 o Additional information: 599 * Magic number(s): N/A 601 * File extension(s): N/A 603 * Macintosh file type code(s): N/A 605 o Person & email address to contact for further information: Torsten 606 Lodderstedt, torsten@lodderstedt.net 608 o Intended usage: COMMON 610 o Restrictions on usage: none 612 o Author: Torsten Lodderstedt, torsten@lodderstedt.net 614 o Change controller: IESG 616 o Provisional registration? No 618 12. References 620 12.1. Normative References 622 [I-D.ietf-oauth-jwt-bcp] 623 Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best 624 Current Practices", draft-ietf-oauth-jwt-bcp-06 (work in 625 progress), June 2019. 627 [I-D.ietf-oauth-security-topics] 628 Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, 629 "OAuth 2.0 Security Best Current Practice", draft-ietf- 630 oauth-security-topics-13 (work in progress), July 2019. 632 [IANA.MediaTypes] 633 IANA, "Media Types", 634 . 636 [OpenID.Core] 637 Sakimura, N., Bradley, J., Jones, M., Medeiros, B. D., and 638 C. Mortimore, "OpenID Connect Core 1.0 incorporating 639 errata set 1", Nov 2014, 640 . 642 [OpenID.Registration] 643 Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect 644 Dynamic Client Registration 1.0 incorporating errata set 645 1", Nov 2014, . 648 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 649 Requirement Levels", BCP 14, RFC 2119, 650 DOI 10.17487/RFC2119, March 1997, 651 . 653 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 654 Specifications and Registration Procedures", BCP 13, 655 RFC 6838, DOI 10.17487/RFC6838, January 2013, 656 . 658 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 659 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 660 2015, . 662 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 663 RFC 7516, DOI 10.17487/RFC7516, May 2015, 664 . 666 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 667 DOI 10.17487/RFC7518, May 2015, 668 . 670 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 671 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 672 . 674 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 675 "Recommendations for Secure Use of Transport Layer 676 Security (TLS) and Datagram Transport Layer Security 677 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 678 2015, . 680 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 681 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 682 RFC 7591, DOI 10.17487/RFC7591, July 2015, 683 . 685 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 686 RFC 7662, DOI 10.17487/RFC7662, October 2015, 687 . 689 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 690 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 691 May 2017, . 693 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 694 Authorization Server Metadata", RFC 8414, 695 DOI 10.17487/RFC8414, June 2018, 696 . 698 12.2. Informative References 700 [IANA.OAuth.Parameters] 701 IANA, "OAuth Parameters", 702 . 704 Appendix A. Document History 706 [[ To be removed from the final specification ]] 708 -08 710 o made difference between introspected access token and 711 introspection response clearer 713 o defined semantics of JWT claims overlapping between introspected 714 access token and introspection response as JWT 716 o added section about RS management 718 o added text about user claims including a privacy considerations 719 section 721 o removed registration of OpenID Connect claims to "Token 722 Introspection Response" registry and refer to "JWT Claims" 723 registry instead 725 o added registration of "application/token-introspection+jwt" media 726 type as type identifier of token introspection responses in JWT 727 format 729 o more changed to incorporate IESG review feedback 731 -07 733 o fixed wrong description of "locale" 735 o added references for ISO and ITU specifications 737 -06 739 o replaced reference to RFC 7159 with reference to RFC 8259 741 -05 743 o improved wording for TLS requirement 745 o added RFC 2119 boilerplate 747 o fixed and updated some references 749 -04 751 o reworked definition of parameters in section 4 753 o added text on data minimization to security considerations section 755 o added statement regarding TLS to security considerations section 757 -03 759 o added registration for OpenID Connect Standard Claims to OAuth 760 Token Introspection Response registry 762 -02 764 o updated references 766 -01 768 o adapted wording to preclude any accept header except "application/ 769 jwt" if encrypted responses are required 771 o use registered alg value RS256 for default signing algorithm 773 o added text on claims in the token introspection response 775 -00 777 o initial version of the WG draft 779 o defined default signing algorithm 781 o changed behavior in case resource server is set up for encryption 783 o Added text on token data leakage prevention to the security 784 considerations 786 o moved Security Considerations section forward 788 WG draft 790 -01 792 o fixed typos in client meta data field names 794 o added OAuth Server Metadata parameters to publish algorithms 795 supported for signing and encrypting the introspection response 797 o added registration of new parameters for OAuth Server Metadata and 798 Client Registration 800 o added explicit request for JWT introspection response 802 o made iss and aud claims mandatory in introspection response 804 o Stylistic and clarifying edits, updates references 806 -00 808 o initial version 810 Authors' Addresses 812 Torsten Lodderstedt (editor) 813 yes.com AG 815 Email: torsten@lodderstedt.net 817 Vladimir Dzhuvinov 818 Connect2id Ltd. 820 Email: vladimir@connect2id.com