idnits 2.17.1 draft-ietf-sipcore-sip-token-authnz-09.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (7 March 2020) is 1482 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) -- Looks like a reference, but probably isn't: '1' on line 245 -- Looks like a reference, but probably isn't: '2' on line 250 -- Looks like a reference, but probably isn't: '3' on line 256 -- Looks like a reference, but probably isn't: '4' on line 256 -- Looks like a reference, but probably isn't: '5' on line 261 -- Looks like a reference, but probably isn't: '6' on line 205 -- Looks like a reference, but probably isn't: '7' on line 211 -- Possible downref: Non-RFC (?) normative reference: ref. 'OPENID' ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Core R. Shekh-Yusef 3 Internet-Draft Avaya 4 Updates: 3261 (if approved) C. Holmberg 5 Intended status: Standards Track Ericsson 6 Expires: 8 September 2020 V. Pascual 7 webrtchacks 8 7 March 2020 10 Third-Party Token-based Authentication and Authorization for Session 11 Initiation Protocol (SIP) 12 draft-ietf-sipcore-sip-token-authnz-09 14 Abstract 16 This document defines the "Bearer" authentication scheme for the 17 Session Initiation Protocol (SIP), and a mechanism by which user 18 authentication and SIP registration authorization is delegated to a 19 third party, using the OAuth 2.0 framework and OpenID Connect Core 20 1.0. This document updates RFC 3261 to provide guidance on how a SIP 21 User Agent Client (UAC) responds to a SIP 401/407 response that 22 contains multiple WWW-Authenticate/Proxy-Authenticate header fields. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 8 September 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. SIP User Agent Types . . . . . . . . . . . . . . . . . . 3 60 1.3. Token Types . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.4. Example Flows . . . . . . . . . . . . . . . . . . . . . . 4 62 1.4.1. Registration . . . . . . . . . . . . . . . . . . . . 4 63 1.4.2. Registration with Preconfigured AS . . . . . . . . . 5 64 2. SIP Procedures . . . . . . . . . . . . . . . . . . . . . . . 7 65 2.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 7 66 2.1.1. Obtaining Tokens and Responding to Challenges . . . . 7 67 2.1.2. Protecting the Access Token . . . . . . . . . . . . . 8 68 2.1.3. REGISTER Request . . . . . . . . . . . . . . . . . . 8 69 2.1.4. Non-REGISTER Request . . . . . . . . . . . . . . . . 8 70 2.2. UAS and Registrar Behavior . . . . . . . . . . . . . . . 9 71 2.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 9 72 3. Access Token Claims . . . . . . . . . . . . . . . . . . . . . 10 73 4. WWW-Authenticate Response Header Field . . . . . . . . . . . 10 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 77 8. Normative References . . . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 The Session Initiation Protocol (SIP) [RFC3261] uses the same 83 framework as HTTP [RFC7230] to authenticate users: a simple 84 challenge-response authentication mechanism that allows a SIP server 85 to challenge a SIP client request and allows a SIP client to provide 86 authentication information in response to that challenge. 88 OAuth 2.0 [RFC6749] defines a token-based authorization framework to 89 allow an OAuth client to access resources on behalf of its user. 91 The OpenID Connect 1.0 specification [OPENID] defines a simple 92 identity layer on top of the OAuth 2.0 protocol, which enables 93 clients to verify the identity of the user based on the 94 authentication performed by a dedicated authorization server, as well 95 as to obtain basic profile information about the user. 97 This document defines the "Bearer" authentication scheme for the 98 Session Initiation Protocol (SIP), and a mechanism by which user 99 authentication and SIP registration authorization is delegated to a 100 third party, using the OAuth 2.0 framework and OpenID Connect Core 101 1.0. This kind of user authentication enables the single-sign-on 102 feature, which allows the user to authenticate once and gain access 103 to both SIP and non-SIP services. 105 This document also updates [RFC3261], by defining the User Agent 106 Client (UAC) procedures when a UAC receives a 401/407 response with 107 multiple WWW-Authenticate/Proxy-Authenticate header fields, providing 108 challenges using different authentication schemes for the same realm. 110 1.1. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in BCP 14 [RFC2119] 115 [RFC8174] when, and only when, they appear in all capitals, as shown 116 here. 118 1.2. SIP User Agent Types 120 The OAuth 2.0 authorization framework [RFC6749] defines two types of 121 clients, confidential and public, that apply to the SIP UACs. 123 * Confidential User Agent: a SIP UAC that is capable of maintaining 124 the confidentiality of the user credentials and any tokens 125 obtained using these user credentials. 127 * Public User Agent: a SIP UAC that is incapable of maintaining the 128 confidentiality of the user credentials and any obtained tokens. 130 The mechanism defined in this document MUST only be used with 131 Confidential User Agents, as the UAC is expected to obtain and 132 maintain tokens to be able to access the SIP network. 134 1.3. Token Types 136 There are two types of tokens that might be used with this 137 specification: 139 * Structured Token: a token that consists of a structured object 140 that contains the claims associated with the token, e.g. JWT as 141 defined in [RFC7519]. 143 * Reference Token: a token that consists of a random string that is 144 used to obtain the details of the token and its associated claims, 145 as defined in [RFC6749]. 147 1.4. Example Flows 149 1.4.1. Registration 151 Figure 1 below shows an example of a SIP registration, where the 152 registrar informs the UAC about the authorization server from which 153 the UAC can obtain an access token in a 401 response to the REGISTER 154 request. 156 UAC Registrar AS 157 --------------------------------------------------------------------- 158 | | | 159 | [1] REGISTER | | 160 |------------------------------>| | 161 | | | 162 | [2] 401 Unauthorized | | 163 | WWW-Authenticate: Bearer "authz_server"="" | 164 |<------------------------------| | 165 | | | 166 | [3] The UAC interacts with the AS and obtains tokens, using | 167 | some out-of-scope mechanism. | 168 |<=============================================================>| 169 | | | 170 | [4] REGISTER | | 171 | Authorization: Bearer | 172 |------------------------------>| | 173 | | [5] HTTP POST /introspect | 174 | | {access_token} | 175 | |------------------------------>| 176 | | | 177 | | [6] 200 OK {metadata} | 178 | |<------------------------------| 179 | | | 180 | [7] 200 OK | | 181 |<------------------------------| | 182 | | | 184 Figure 1: Example Registration Flow 186 In step [1], the UAC starts the registration process by sending a SIP 187 REGISTER request to the registrar without any credentials. 189 In step [2], the registrar challenges the UA, by sending a SIP 401 190 (Unauthorized) response to the REGISTER request. In the response, 191 the registrar includes information about the AS to contact in order 192 to obtain a token. 194 In step [3], the UAC interacts with the AS via an out-of-scope 195 mechanism, potentially using the OAuth Native App mechanism defined 196 in [RFC8252]. The AS authenticates the user and provides the UAC 197 with the tokens needed to access the SIP service. 199 In step [4], the UAC retries the registration process by sending a 200 new REGISTER request that includes the access token that the UAC 201 obtained previously. 203 The registrar validates the access token. If the access token is a 204 reference token, the registrar MAY perform an introspection 205 [RFC7662], as in steps [5] and [6], in order to obtain more 206 information about the access token and its scope, per [RFC7662]. 207 Otherwise, after the registrar validates the token to make sure it 208 was signed by a trusted entity, it inspects its claims and acts upon 209 it. 211 In step [7], once the registrar has successfully verified and 212 accepted the access token, it sends a 200 (OK) response to the 213 REGISTER request. 215 1.4.2. Registration with Preconfigured AS 217 Figure 2 shows an example of a SIP registration where the UAC has 218 been preconfigured with information about the AS from which to obtain 219 the access token. 221 UAC Registrar AS 222 --------------------------------------------------------------------- 223 | | | 224 | [1] The UAC interacts with the AS and obtains tokens, using | 225 | some out of scope mechanism. | 226 |<=============================================================>| 227 | | | 228 | [2] REGISTER | | 229 | Authorization: Bearer | 230 |------------------------------>| | 231 | | [3] HTTP POST /introspect | 232 | | {access_token} | 233 | |------------------------------>| 234 | | | 235 | | [4] 200 OK {metadata} | 236 | |<------------------------------| 237 | | | 238 | [5] 200 OK | | 239 |<------------------------------| | 240 | | | 242 Figure 2: Example Registration Flow - Authorization Server 243 Information Preconfigured 245 In step [1], the UAC interacts with the AS using an out-of-scope 246 mechanism, potentially using the OAuth Native App mechanism defined 247 in [RFC8252]. The AS authenticates the user and provides the UAC 248 with the tokens needed to access the SIP service. 250 In step [2], the UAC retries the registration process by sending a 251 new REGISTER request that includes the access token that the UAC 252 obtained previously. 254 The registrar validates the access token. If the access token is a 255 reference token, the registrar MAY perform an introspection, as in 256 steps [3] and [4], in order to obtain more information about the 257 access token and its scope, per [RFC7662]. Otherwise, after the 258 registrar validates the token to make sure it was signed by a trusted 259 entity, it inspects its claims and acts upon it. 261 In step [5], once the registrar has successfully verified and 262 accepted the access token, it sends a 200 (OK) response to the 263 REGISTER request. 265 2. SIP Procedures 267 Section 22 of [RFC3261] defines the SIP procedures for the Digest 268 authentication mechanism. The same procedures apply to the Bearer 269 authentication mechanism, with the changes described in this section. 271 2.1. UAC Behavior 273 2.1.1. Obtaining Tokens and Responding to Challenges 275 When a UAC sends a request without credentials (or with invalid 276 credentials), it could receive either a 401 (Unauthorized) response 277 with a WWW-Authenticate header field or a 407 (Proxy Authentication 278 Required) response with a Proxy-Authenticate header field. If the 279 WWW-Authenticate or Proxy-Authenticate header field indicates 280 "Bearer" scheme authentication and contains an address to an 281 authorization server, the UAC contacts the authorization server in 282 order to obtain tokens, and includes the requested scopes, based on a 283 local configuration (Figure 1). 285 The detailed OAuth2 procedure to authenticate the user and obtain 286 these tokens is out of scope of this document. The address of the 287 authorization server might already be known to the UAC via 288 configuration. In which case, the UAC can contact the authorization 289 server for tokens before it sends a SIP request (Figure 2). 290 Procedures for native applications are defined in [RFC8252]. When 291 using the mechanism defined in [RFC8252] the user of the UAC will be 292 directed to interact with the authorization server using a web 293 browser, allowing the authorization server to prompt the user for 294 multi-factor authentication, to redirect the user to third-party 295 identity providers, and to enable the use of single-sign-on sessions. 297 The tokens returned to the UAC depend on the type of authorization 298 server (AS): an OAuth AS provides an access token and refresh token 299 [RFC6749]. The UAC provides the access token to the SIP servers to 300 authorize UAC's access to the service. The UAC uses the refresh 301 token only with the AS to get a new access token and refresh token 302 before the expiry of the current access token (see [RFC6749], section 303 1.5 Refresh Token for details). An OpenID Connect server returns an 304 additional ID-Token containing the SIP URI and other user-specific 305 details that will be consumed by the UAC. 307 If the UAC receives a 401/407 response with multiple WWW- 308 Authenticate/Proxy-Authenticate header fields, providing challenges 309 using different authentication schemes for the same realm, the UAC 310 provides credentials for one or more of the schemes that it supports, 311 based on local policy. 313 NOTE: The address of the Authorization Server might be known to the 314 UAC e.g., using means of configuration, in which case the UAC can 315 contact the Authorization Server in order to obtain the access token 316 before it sends SIP request without credentials. 318 2.1.2. Protecting the Access Token 320 [RFC6749] mandates that access tokens are protected with TLS when in 321 transit. However, TLS only guarantees hop-to-hop protection when 322 used to protect SIP signaling. Therefore the access token MUST be 323 protected in a way so that only authorized SIP servers will have 324 access to it. Endpoints that support this specification MUST support 325 encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and protecting 326 access tokens when they are included in SIP requests, unless some 327 other mechanism is used to guarantee that only authorized SIP 328 endpoints have access to the access token. 330 2.1.3. REGISTER Request 332 The procedures in this section apply when the UAC has received a 333 challenge that contains a "Bearer" scheme, and the UAC has obtained a 334 token as specified in Section 2.1.1. 336 The UAC sends a REGISTER request with an Authorization header field 337 containing the response to the challenge, including the Bearer scheme 338 carrying a valid access token in the request, as specified in 339 [RFC6750]. 341 Note that, if there were multiple challenges with different schemes, 342 then the UAC may be able to successfully retry the request using non- 343 Bearer credentials. 345 Based on local policy, the UAC MAY include an access token that has 346 been used for another binding associated with the same AOR in the 347 request. 349 If the access token included in a REGISTER request is not accepted, 350 and the UAC receives a 401 response or a 407 response, the UAC 351 follows the procedures in Section 2.1.1. 353 2.1.4. Non-REGISTER Request 355 The procedures in this section apply when the UAC has received a 356 challenge that contains a "Bearer" scheme, and the UAC has obtained a 357 token as specified in Section 2.1.1. 359 When the UAC sends a request, it MUST include an Authorization header 360 field with a Bearer scheme, carrying a valid access token in the 361 request, as specified in [RFC6750]. Based on local policy, the UAC 362 MAY include an access token that has been used for another dialog, or 363 for another stand-alone request, if the target of the new request is 364 the same. 366 If the access token included in a request is not accepted, and the 367 UAC receives a 401 response or a 407 response, the UAC follows the 368 procedures in Section 2.1.1. 370 2.2. UAS and Registrar Behavior 372 When a UAS or Registrar receives a request that fails to contain 373 authorization credentials acceptable to it, it SHOULD challenge the 374 request by sending a 401 (Unauthorized) response. To indicate that 375 it is willing to accept an access token as a credential, the UAS/ 376 Registrar MUST include a Proxy-Authentication header field in the 377 response that indicates "Bearer" scheme and includes an address of an 378 authorization server from which the originator can obtain an access 379 token. 381 When a UAS/Registrar receives a SIP request that contains an 382 Authorization header field with an access token, the UAS/Registrar 383 MUST validate the access token, using the procedures associated with 384 the type of access token used, e.g. [RFC7519]. If the token 385 provided is an expired access token, then the UAS MUST reply with 401 386 Unauthorized, as defined in section 3 of [RFC6750]. If the 387 validation is successful, the UAS/Registrar can continue to process 388 the request using normal SIP procedures. If the validation fails, 389 the UAS/Registrar MUST reject the request. 391 2.3. Proxy Behavior 393 When a proxy receives a request that fails to contain authorization 394 credentials acceptable to it, it SHOULD challenge the request by 395 sending a 407 (Proxy Authentication Required) response. To indicate 396 that it is willing to accept an access token as a credential, the 397 proxy MUST include a Proxy-Authentication header field in the 398 response that indicates "Bearer" scheme and includes an address to an 399 authorization server from which the originator can obtain an access 400 token. 402 When a proxy wishes to authenticate a received request, it MUST 403 search the request for Proxy-Authorization header fields with 'realm' 404 parameters that match its realm. It then MUST successfully validate 405 the credentials from at least one Proxy-Authorization header field 406 for its realm. When the scheme is "Bearer", the proxy MUST validate 407 the access token, using the procedures associated with the type of 408 access token used, e.g., [RFC7519]. 410 3. Access Token Claims 412 The type of services to which an access token grants access can be 413 determined using different methods. The methods used and the access 414 provided by the token is based on local policy agreed between the AS 415 and the registrar. 417 If an access token is encoded as a JWT, it might contain a list of 418 claims [RFC7519], some registered and some application-specific. The 419 REGISTRAR can grant access to services based on such claims, some 420 other mechanism, or a combination of claims and some other mechanism. 421 If an access token is a reference token, the REGISTRAR will grant 422 access based on some other mechanism. Examples of such other 423 mechanisms are introspection [RFC7662], user profile lookups, etc. 425 4. WWW-Authenticate Response Header Field 427 This section uses ABNF [RFC5234] to describe the syntax of the WWW- 428 Authenticate header field when used with the "Bearer" scheme to 429 challenge the UAC for credentials, by extending the 'challenge' 430 parameter defined by [RFC3261]. 432 challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln)) 433 bearer-cln = realm / scope / authz-server / error / 434 auth-param 435 authz-server = "authz_server" EQUAL authz-server-value 436 authz-server-value = https-URI 437 realm = 438 auth-param = 439 scope = 440 error = 441 https-URI = 443 Figure 3: Bearer Scheme Syntax 445 The authz-server parameter contains the HTTPS URI, as defined in 446 [RFC7230], of the authorization server. The UAC can discover 447 metadata about the AS using a mechanism like the one defined in 448 [RFC8414]. 450 The realm and auth-param parameters are defined in [RFC3261]. 452 Per [RFC3261], the realm string alone defines the protection domain. 453 [RFC3261] states that the realm string must be globally unique and 454 recommends that the realm string contain a hostname or domain name. 455 It also states that the realm string should be a human-readable 456 identifier that can be rendered to the user. 458 The scope and error parameters are defined in [RFC6749]. 460 The scope parameter could be used by the registrar/proxy to indicate 461 to the UAC the minimum scope that must be associated with the access 462 token to be able to get service. As defined in [RFC6749], the value 463 of the scope parameter is expressed as a list of space-delimited, 464 case-sensitive strings. The strings are defined by the authorization 465 server. The values of the scope parameter are out of scope of this 466 document. The UAC will use the scope provided by the registrar to 467 contact the AS and obtain a proper token with the requested scope. 469 The error parameter could be used by the registrar/proxy to indicate 470 to the UAC the reason for the error, with possible values of 471 "invalid_token" or "invalid_scope". 473 5. Security Considerations 475 The security considerations for OAuth are defined in [RFC6749]. The 476 security considerations for bearer tokens are defined in [RFC6750]. 477 The security considerations for JSON Web Tokens (JWT) are defined in 478 [RFC7519]. These security considerations also apply to SIP usage of 479 access token as defined in this document. 481 [RFC6749] mandates that access tokens are protected with TLS. 482 However, TLS only guarantees hop-to-hop protection when used to 483 protect SIP signaling. Therefore the access token MUST be protected 484 in a way so that only authorized SIP endpoints will have access to 485 it. Endpoints that support this specification MUST support encrypted 486 JSON Web Tokens (JWT) [RFC7519] for encoding and protecting access 487 tokens when included in SIP requests, unless some other mechanism is 488 used to guarantee that only authorized SIP endpoints have access to 489 the access token. 491 6. IANA Considerations 493 7. Acknowledgments 495 The authors would like to specially thank Paul Kyzivat for his 496 multiple detailed reviews and suggested text that significantly 497 improved the quality of the document. 499 The authors would also like to thank the following for their review 500 and feedback on this document: 502 Olle Johansson, Roman Shpount, Dale Worley, and Jorgen Axell. 504 The authors would also like to thank the following for their review 505 and feedback of the original document that was replaced with this 506 document: 508 Andrew Allen, Martin Dolly, Keith Drage, Paul Kyzivat, Jon Peterson, 509 Michael Procter, Roy Radhika, Matt Ryan, Ivo Sedlacek, Roman Shpount, 510 Robert Sparks, Asveren Tolga, Dale Worley, and Yehoshua Gev. 512 The authors would also like to specially thank Jean Mahoney for her 513 multiple reviews, editorial help, and the coversion of the XML source 514 file from v2 to v3. 516 8. Normative References 518 [OPENID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 519 C. Mortimore, "OpenID Connect Core 1.0", February 2014. 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, 523 DOI 10.17487/RFC2119, March 1997, 524 . 526 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 527 A., Peterson, J., Sparks, R., Handley, M., and E. 528 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 529 DOI 10.17487/RFC3261, June 2002, 530 . 532 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 533 Specifications: ABNF", STD 68, RFC 5234, 534 DOI 10.17487/RFC5234, January 2008, 535 . 537 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 538 RFC 6749, DOI 10.17487/RFC6749, October 2012, 539 . 541 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 542 Framework: Bearer Token Usage", RFC 6750, 543 DOI 10.17487/RFC6750, October 2012, 544 . 546 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 547 Protocol (HTTP/1.1): Message Syntax and Routing", 548 RFC 7230, DOI 10.17487/RFC7230, June 2014, 549 . 551 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 552 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 553 . 555 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 556 RFC 7662, DOI 10.17487/RFC7662, October 2015, 557 . 559 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 560 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 561 May 2017, . 563 [RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", 564 BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, 565 . 567 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 568 Authorization Server Metadata", RFC 8414, 569 DOI 10.17487/RFC8414, June 2018, 570 . 572 Authors' Addresses 574 Rifaat Shekh-Yusef 575 Avaya 576 425 Legget Drive 577 Ottawa Ontario 578 Canada 580 Phone: +1-613-595-9106 581 Email: rifaat.ietf@gmail.com 583 Christer Holmberg 584 Ericsson 585 Hirsalantie 11 586 FI- Jorvas 02420 587 Finland 589 Email: christer.holmberg@ericsson.com 590 Victor Pascual 591 webrtchacks 592 Spain 594 Email: victor.pascual.avila@gmail.com