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