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