idnits 2.17.1 draft-ietf-sipcore-sip-token-authnz-10.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 249 -- Looks like a reference, but probably isn't: '2' on line 254 -- Looks like a reference, but probably isn't: '3' on line 260 -- Looks like a reference, but probably isn't: '4' on line 260 -- Looks like a reference, but probably isn't: '5' on line 265 -- Looks like a reference, but probably isn't: '6' on line 209 -- Looks like a reference, but probably isn't: '7' on line 215 -- 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-10 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 Formats . . . . . . . . . . . . . . . . . . . . . . 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 Formats 136 Tokens can be represented in two different formats: 138 * Structured Token: a token that consists of a structured object 139 that contains the claims associated with the token, e.g. JWT as 140 defined in [RFC7519]. 142 * Reference Token: a token that consists of a random string that is 143 used to obtain the details of the token and its associated claims, 144 as defined in [RFC6749]. 146 Access Tokens could be represnetd in one of the above two formats. 147 Refresh Tokens usualy are represented in a reference format, as this 148 token is consumed only the AS that issued the token. ID Token is 149 defined as a structured token in the form of a JWT. 151 1.4. Example Flows 153 1.4.1. Registration 155 Figure 1 below shows an example of a SIP registration, where the 156 registrar informs the UAC about the authorization server from which 157 the UAC can obtain an access token in a 401 response to the REGISTER 158 request. 160 UAC Registrar AS 161 --------------------------------------------------------------------- 162 | | | 163 | [1] REGISTER | | 164 |------------------------------>| | 165 | | | 166 | [2] 401 Unauthorized | | 167 | WWW-Authenticate: Bearer "authz_server"="" | 168 |<------------------------------| | 169 | | | 170 | [3] The UAC interacts with the AS and obtains tokens, using | 171 | some out-of-scope mechanism. | 172 |<=============================================================>| 173 | | | 174 | [4] REGISTER | | 175 | Authorization: Bearer | 176 |------------------------------>| | 177 | | [5] HTTP POST /introspect | 178 | | {access_token} | 179 | |------------------------------>| 180 | | | 181 | | [6] 200 OK {metadata} | 182 | |<------------------------------| 183 | | | 184 | [7] 200 OK | | 185 |<------------------------------| | 186 | | | 188 Figure 1: Example Registration Flow 190 In step [1], the UAC starts the registration process by sending a SIP 191 REGISTER request to the registrar without any credentials. 193 In step [2], the registrar challenges the UA, by sending a SIP 401 194 (Unauthorized) response to the REGISTER request. In the response, 195 the registrar includes information about the AS to contact in order 196 to obtain a token. 198 In step [3], the UAC interacts with the AS via an out-of-scope 199 mechanism, potentially using the OAuth Native App mechanism defined 200 in [RFC8252]. The AS authenticates the user and provides the UAC 201 with the tokens needed to access the SIP service. 203 In step [4], the UAC retries the registration process by sending a 204 new REGISTER request that includes the access token that the UAC 205 obtained previously. 207 The registrar validates the access token. If the access token is a 208 reference token, the registrar MAY perform an introspection 209 [RFC7662], as in steps [5] and [6], in order to obtain more 210 information about the access token and its scope, per [RFC7662]. 211 Otherwise, after the registrar validates the token to make sure it 212 was signed by a trusted entity, it inspects its claims and acts upon 213 it. 215 In step [7], once the registrar has successfully verified and 216 accepted the access token, it sends a 200 (OK) response to the 217 REGISTER request. 219 1.4.2. Registration with Preconfigured AS 221 Figure 2 shows an example of a SIP registration where the UAC has 222 been preconfigured with information about the AS from which to obtain 223 the access token. 225 UAC Registrar AS 226 --------------------------------------------------------------------- 227 | | | 228 | [1] The UAC interacts with the AS and obtains tokens, using | 229 | some out of scope mechanism. | 230 |<=============================================================>| 231 | | | 232 | [2] REGISTER | | 233 | Authorization: Bearer | 234 |------------------------------>| | 235 | | [3] HTTP POST /introspect | 236 | | {access_token} | 237 | |------------------------------>| 238 | | | 239 | | [4] 200 OK {metadata} | 240 | |<------------------------------| 241 | | | 242 | [5] 200 OK | | 243 |<------------------------------| | 244 | | | 246 Figure 2: Example Registration Flow - Authorization Server 247 Information Preconfigured 249 In step [1], the UAC interacts with the AS using an out-of-scope 250 mechanism, potentially using the OAuth Native App mechanism defined 251 in [RFC8252]. The AS authenticates the user and provides the UAC 252 with the tokens needed to access the SIP service. 254 In step [2], the UAC retries the registration process by sending a 255 new REGISTER request that includes the access token that the UAC 256 obtained previously. 258 The registrar validates the access token. If the access token is a 259 reference token, the registrar MAY perform an introspection, as in 260 steps [3] and [4], in order to obtain more information about the 261 access token and its scope, per [RFC7662]. Otherwise, after the 262 registrar validates the token to make sure it was signed by a trusted 263 entity, it inspects its claims and acts upon it. 265 In step [5], once the registrar has successfully verified and 266 accepted the access token, it sends a 200 (OK) response to the 267 REGISTER request. 269 2. SIP Procedures 271 Section 22 of [RFC3261] defines the SIP procedures for the Digest 272 authentication mechanism. The same procedures apply to the Bearer 273 authentication mechanism, with the changes described in this section. 275 2.1. UAC Behavior 277 2.1.1. Obtaining Tokens and Responding to Challenges 279 When a UAC sends a request without credentials (or with invalid 280 credentials), it could receive either a 401 (Unauthorized) response 281 with a WWW-Authenticate header field or a 407 (Proxy Authentication 282 Required) response with a Proxy-Authenticate header field. If the 283 WWW-Authenticate or Proxy-Authenticate header field indicates 284 "Bearer" scheme authentication and contains an address to an 285 authorization server, the UAC contacts the authorization server in 286 order to obtain tokens, and includes the requested scopes, based on a 287 local configuration (Figure 1). 289 The detailed OAuth2 procedure to authenticate the user and obtain 290 these tokens is out of scope of this document. The address of the 291 authorization server might already be known to the UAC via 292 configuration. In which case, the UAC can contact the authorization 293 server for tokens before it sends a SIP request (Figure 2). 294 Procedures for native applications are defined in [RFC8252]. When 295 using the mechanism defined in [RFC8252] the user of the UAC will be 296 directed to interact with the authorization server using a web 297 browser, allowing the authorization server to prompt the user for 298 multi-factor authentication, to redirect the user to third-party 299 identity providers, and to enable the use of single-sign-on sessions. 301 The tokens returned to the UAC depend on the type of authorization 302 server (AS): an OAuth AS provides an access token and refresh token 303 [RFC6749]. The UAC provides the access token to the SIP servers to 304 authorize UAC's access to the service. The UAC uses the refresh 305 token only with the AS to get a new access token and refresh token 306 before the expiry of the current access token (see [RFC6749], section 307 1.5 Refresh Token for details). An OpenID Connect server returns an 308 additional ID-Token containing the SIP URI and other user-specific 309 details that will be consumed by the UAC. 311 If the UAC receives a 401/407 response with multiple WWW- 312 Authenticate/Proxy-Authenticate header fields, providing challenges 313 using different authentication schemes for the same realm, the UAC 314 provides credentials for one or more of the schemes that it supports, 315 based on local policy. 317 NOTE: The address of the Authorization Server might be known to the 318 UAC e.g., using means of configuration, in which case the UAC can 319 contact the Authorization Server in order to obtain the access token 320 before it sends SIP request without credentials. 322 2.1.2. Protecting the Access Token 324 [RFC6749] mandates that access tokens are protected with TLS when in 325 transit. However, TLS only guarantees hop-to-hop protection when 326 used to protect SIP signaling. Therefore the access token MUST be 327 protected in a way so that only authorized SIP servers will have 328 access to it. Endpoints that support this specification MUST support 329 encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and protecting 330 access tokens when they are included in SIP requests, unless some 331 other mechanism is used to guarantee that only authorized SIP 332 endpoints have access to the access token. 334 2.1.3. REGISTER Request 336 The procedures in this section apply when the UAC has received a 337 challenge that contains a "Bearer" scheme, and the UAC has obtained a 338 token as specified in Section 2.1.1. 340 The UAC sends a REGISTER request with an Authorization header field 341 containing the response to the challenge, including the Bearer scheme 342 carrying a valid access token in the request, as specified in 343 [RFC6750]. 345 Note that, if there were multiple challenges with different schemes, 346 then the UAC may be able to successfully retry the request using non- 347 Bearer credentials. 349 Based on local policy, the UAC MAY include an access token that has 350 been used for another binding associated with the same AOR in the 351 request. 353 If the access token included in a REGISTER request is not accepted, 354 and the UAC receives a 401 response or a 407 response, the UAC 355 follows the procedures in Section 2.1.1. 357 2.1.4. Non-REGISTER Request 359 The procedures in this section apply when the UAC has received a 360 challenge that contains a "Bearer" scheme, and the UAC has obtained a 361 token as specified in Section 2.1.1. 363 When the UAC sends a request, it MUST include an Authorization header 364 field with a Bearer scheme, carrying a valid access token in the 365 request, as specified in [RFC6750]. Based on local policy, the UAC 366 MAY include an access token that has been used for another dialog, or 367 for another stand-alone request, if the target of the new request is 368 the same. 370 If the access token included in a request is not accepted, and the 371 UAC receives a 401 response or a 407 response, the UAC follows the 372 procedures in Section 2.1.1. 374 2.2. UAS and Registrar Behavior 376 When a UAS or Registrar receives a request that fails to contain 377 authorization credentials acceptable to it, it SHOULD challenge the 378 request by sending a 401 (Unauthorized) response. To indicate that 379 it is willing to accept an access token as a credential, the UAS/ 380 Registrar MUST include a Proxy-Authentication header field in the 381 response that indicates "Bearer" scheme and includes an address of an 382 authorization server from which the originator can obtain an access 383 token. 385 When a UAS/Registrar receives a SIP request that contains an 386 Authorization header field with an access token, the UAS/Registrar 387 MUST validate the access token, using the procedures associated with 388 the type of access token used, e.g. [RFC7519]. If the token 389 provided is an expired access token, then the UAS MUST reply with 401 390 Unauthorized, as defined in section 3 of [RFC6750]. If the 391 validation is successful, the UAS/Registrar can continue to process 392 the request using normal SIP procedures. If the validation fails, 393 the UAS/Registrar MUST reject the request. 395 2.3. Proxy Behavior 397 When a proxy receives a request that fails to contain authorization 398 credentials acceptable to it, it SHOULD challenge the request by 399 sending a 407 (Proxy Authentication Required) response. To indicate 400 that it is willing to accept an access token as a credential, the 401 proxy MUST include a Proxy-Authentication header field in the 402 response that indicates "Bearer" scheme and includes an address to an 403 authorization server from which the originator can obtain an access 404 token. 406 When a proxy wishes to authenticate a received request, it MUST 407 search the request for Proxy-Authorization header fields with 'realm' 408 parameters that match its realm. It then MUST successfully validate 409 the credentials from at least one Proxy-Authorization header field 410 for its realm. When the scheme is "Bearer", the proxy MUST validate 411 the access token, using the procedures associated with the type of 412 access token used, e.g., [RFC7519]. 414 3. Access Token Claims 416 The type of services to which an access token grants access can be 417 determined using different methods. The methods used and the access 418 provided by the token is based on local policy agreed between the AS 419 and the registrar. 421 If an access token is encoded as a JWT, it might contain a list of 422 claims [RFC7519], some registered and some application-specific. The 423 REGISTRAR can grant access to services based on such claims, some 424 other mechanism, or a combination of claims and some other mechanism. 425 If an access token is a reference token, the REGISTRAR will grant 426 access based on some other mechanism. Examples of such other 427 mechanisms are introspection [RFC7662], user profile lookups, etc. 429 4. WWW-Authenticate Response Header Field 431 This section uses ABNF [RFC5234] to describe the syntax of the WWW- 432 Authenticate header field when used with the "Bearer" scheme to 433 challenge the UAC for credentials, by extending the 'challenge' 434 parameter defined by [RFC3261]. 436 challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln)) 437 bearer-cln = realm / scope / authz-server / error / 438 auth-param 439 authz-server = "authz_server" EQUAL authz-server-value 440 authz-server-value = https-URI 441 realm = 442 auth-param = 443 scope = 444 error = 445 https-URI = 447 Figure 3: Bearer Scheme Syntax 449 The authz-server parameter contains the HTTPS URI, as defined in 450 [RFC7230], of the authorization server. The UAC can discover 451 metadata about the AS using a mechanism like the one defined in 452 [RFC8414]. 454 The realm and auth-param parameters are defined in [RFC3261]. 456 Per [RFC3261], the realm string alone defines the protection domain. 457 [RFC3261] states that the realm string must be globally unique and 458 recommends that the realm string contain a hostname or domain name. 459 It also states that the realm string should be a human-readable 460 identifier that can be rendered to the user. 462 The scope and error parameters are defined in [RFC6749]. 464 The scope parameter could be used by the registrar/proxy to indicate 465 to the UAC the minimum scope that must be associated with the access 466 token to be able to get service. As defined in [RFC6749], the value 467 of the scope parameter is expressed as a list of space-delimited, 468 case-sensitive strings. The strings are defined by the authorization 469 server. The values of the scope parameter are out of scope of this 470 document. The UAC will use the scope provided by the registrar to 471 contact the AS and obtain a proper token with the requested scope. 473 The error parameter could be used by the registrar/proxy to indicate 474 to the UAC the reason for the error, with possible values of 475 "invalid_token" or "invalid_scope". 477 5. Security Considerations 479 The security considerations for OAuth are defined in [RFC6749]. The 480 security considerations for bearer tokens are defined in [RFC6750]. 481 The security considerations for JSON Web Tokens (JWT) are defined in 482 [RFC7519]. These security considerations also apply to SIP usage of 483 access token as defined in this document. 485 [RFC6749] mandates that access tokens are protected with TLS. 486 However, TLS only guarantees hop-to-hop protection when used to 487 protect SIP signaling. Therefore the access token MUST be protected 488 in a way so that only authorized SIP endpoints will have access to 489 it. Endpoints that support this specification MUST support encrypted 490 JSON Web Tokens (JWT) [RFC7519] for encoding and protecting access 491 tokens when included in SIP requests, unless some other mechanism is 492 used to guarantee that only authorized SIP endpoints have access to 493 the access token. 495 6. IANA Considerations 497 7. Acknowledgments 499 The authors would like to specially thank Paul Kyzivat for his 500 multiple detailed reviews and suggested text that significantly 501 improved the quality of the document. 503 The authors would also like to thank the following for their review 504 and feedback on this document: 506 Olle Johansson, Roman Shpount, Dale Worley, and Jorgen Axell. 508 The authors would also like to thank the following for their review 509 and feedback of the original document that was replaced with this 510 document: 512 Andrew Allen, Martin Dolly, Keith Drage, Paul Kyzivat, Jon Peterson, 513 Michael Procter, Roy Radhika, Matt Ryan, Ivo Sedlacek, Roman Shpount, 514 Robert Sparks, Asveren Tolga, Dale Worley, and Yehoshua Gev. 516 The authors would also like to specially thank Jean Mahoney for her 517 multiple reviews, editorial help, and the coversion of the XML source 518 file from v2 to v3. 520 8. Normative References 522 [OPENID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 523 C. Mortimore, "OpenID Connect Core 1.0", February 2014. 525 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 526 Requirement Levels", BCP 14, RFC 2119, 527 DOI 10.17487/RFC2119, March 1997, 528 . 530 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 531 A., Peterson, J., Sparks, R., Handley, M., and E. 532 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 533 DOI 10.17487/RFC3261, June 2002, 534 . 536 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 537 Specifications: ABNF", STD 68, RFC 5234, 538 DOI 10.17487/RFC5234, January 2008, 539 . 541 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 542 RFC 6749, DOI 10.17487/RFC6749, October 2012, 543 . 545 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 546 Framework: Bearer Token Usage", RFC 6750, 547 DOI 10.17487/RFC6750, October 2012, 548 . 550 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 551 Protocol (HTTP/1.1): Message Syntax and Routing", 552 RFC 7230, DOI 10.17487/RFC7230, June 2014, 553 . 555 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 556 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 557 . 559 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 560 RFC 7662, DOI 10.17487/RFC7662, October 2015, 561 . 563 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 564 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 565 May 2017, . 567 [RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", 568 BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, 569 . 571 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 572 Authorization Server Metadata", RFC 8414, 573 DOI 10.17487/RFC8414, June 2018, 574 . 576 Authors' Addresses 578 Rifaat Shekh-Yusef 579 Avaya 580 425 Legget Drive 581 Ottawa Ontario 582 Canada 584 Phone: +1-613-595-9106 585 Email: rifaat.ietf@gmail.com 587 Christer Holmberg 588 Ericsson 589 Hirsalantie 11 590 FI- Jorvas 02420 591 Finland 593 Email: christer.holmberg@ericsson.com 594 Victor Pascual 595 webrtchacks 596 Spain 598 Email: victor.pascual.avila@gmail.com