idnits 2.17.1 draft-jones-oauth-resource-metadata-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 3, 2016) is 2823 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) == Unused Reference: 'I-D.ietf-oauth-mix-up-mitigation' is defined on line 699, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7525 (ref. 'BCP195') (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Possible downref: Non-RFC (?) normative reference: ref. 'USA15' Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group M. Jones 3 Internet-Draft Microsoft 4 Intended status: Standards Track P. Hunt 5 Expires: February 4, 2017 Oracle 6 August 3, 2016 8 OAuth 2.0 Protected Resource Metadata 9 draft-jones-oauth-resource-metadata-00 11 Abstract 13 This specification defines a metadata format that an OAuth 2.0 client 14 can use to obtain the information needed to interact with an OAuth 15 2.0 protected resource. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on February 4, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Notation and Conventions . . . . . . . . . . 3 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Protected Resource Metadata . . . . . . . . . . . . . . . . . 3 55 2.1. Signed Protected Resource Metadata . . . . . . . . . . . 5 56 3. Obtaining Protected Resource Metadata . . . . . . . . . . . . 6 57 3.1. Protected Resource Metadata Request . . . . . . . . . . . 6 58 3.2. Protected Resource Metadata Response . . . . . . . . . . 7 59 3.3. Protected Resource Metadata Validation . . . . . . . . . 8 60 4. String Operations . . . . . . . . . . . . . . . . . . . . . . 8 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 5.1. TLS Requirements . . . . . . . . . . . . . . . . . . . . 8 63 5.2. Impersonation Attacks . . . . . . . . . . . . . . . . . . 9 64 5.3. Publishing Metadata in a Standard Format . . . . . . . . 9 65 5.4. Authorization Servers . . . . . . . . . . . . . . . . . . 9 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 6.1. OAuth Protected Resource Metadata Registry . . . . . . . 11 68 6.1.1. Registration Template . . . . . . . . . . . . . . . . 11 69 6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 11 70 6.2. Well-Known URI Registry . . . . . . . . . . . . . . . . . 13 71 6.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 13 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 74 7.2. Informative References . . . . . . . . . . . . . . . . . 15 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 76 Appendix B. Document History . . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 This specification defines a metadata format enabling OAuth 2.0 82 clients to obtain information needed to interact with an OAuth 2.0 83 protected resource. This specification is intentionally as parallel 84 as possible to "OAuth 2.0 Dynamic Client Registration Protocol" 85 [RFC7591], which enables a client to provide metadata about itself to 86 an OAuth 2.0 authorization server and to OAuth 2.0 Authorization 87 Server Metadata [OAuth.AuthorizationMetadata], which enables a client 88 to obtain metadata about an OAuth 2.0 authorization server. 90 The metadata for a protected resource is retrieved from a well-known 91 location as a JSON [RFC7159] document, which declares information 92 about its capabilities and optionally, its relationships to other 93 services. This process is described in Section 3. 95 This metadata can either be communicated in a self-asserted fashion 96 or as a set of signed metadata values represented as claims in a JSON 97 Web Token (JWT) [JWT]. In the JWT case, the issuer is vouching for 98 the validity of the data about the protected resource. This is 99 analogous to the role that the Software Statement plays in OAuth 100 Dynamic Client Registration [RFC7591]. 102 Each protected resource publishing metadata about itself makes its 103 own metadata document available at a well-known location rooted at 104 the protect resource's URL, even when the resource server implements 105 multiple protected resources. This prevents attackers from 106 publishing metadata supposedly describing the protected resource, but 107 that is not actually authoritative for the protected resource, as 108 described in Section 5.2. 110 The means by which the client obtains the location of the protected 111 resource metadata document is out of scope. In some cases, the 112 location may be manually configured into the client. In other cases, 113 it may be dynamically discovered, for instance, through the use of 114 WebFinger [RFC7033], in a manner related to the description in 115 Section 2 of "OpenID Connect Discovery 1.0" [OpenID.Discovery]. 117 1.1. Requirements Notation and Conventions 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in RFC 122 2119 [RFC2119]. 124 All uses of JSON Web Signature (JWS) [JWS] and JSON Web Encryption 125 (JWE) [JWE] data structures in this specification utilize the JWS 126 Compact Serialization or the JWE Compact Serialization; the JWS JSON 127 Serialization and the JWE JSON Serialization are not used. 129 1.2. Terminology 131 This specification uses the terms "Access Token", "Authorization 132 Code", "Authorization Endpoint", "Authorization Grant", 133 "Authorization Server", "Client", "Client Authentication", "Client 134 Identifier", "Client Secret", "Grant Type", "Protected Resource", 135 "Redirection URI", "Refresh Token", "Resource Owner", "Resource 136 Server", "Response Type", and "Token Endpoint" defined by OAuth 2.0 137 [RFC6749], the terms "Claim Name", "Claim Value", and "JSON Web Token 138 (JWT)" defined by JSON Web Token (JWT) [JWT]. 140 2. Protected Resource Metadata 142 Protected resources can have metadata describing their configuration. 143 The following protected resource metadata values are used by this 144 specification and are registered in the IANA "OAuth Protected 145 Resource Metadata" registry established in Section 6.1: 147 resource 148 REQUIRED. The protected resource's resource identifier, which is 149 a URL that uses the "https" scheme and has no fragment components. 150 This is the location where ".well-known" RFC 5785 [RFC5785] 151 resources containing information about the protected resource are 152 published. Using these well-known resources is described in 153 Section 3. 155 authorization_servers 156 OPTIONAL. JSON array containing a list of OAuth authorization 157 server issuer identifiers, as defined in 158 [OAuth.AuthorizationMetadata], for authorization servers that can 159 be used with this protected resource. Protected resources MAY 160 choose not to advertise some supported authorization servers even 161 when this parameter is used. In some use cases, the set of 162 authorization servers will not be enumerable, in which case this 163 metadata parameter would not be used. 165 jwks_uri 166 OPTIONAL. URL of the protected resource's JWK Set [JWK] document. 167 This contains keys belonging to the protected resource. For 168 instance, this JWK Set MAY contain encryption key(s) that are used 169 to encrypt access tokens to the protected resource. When both 170 signing and encryption keys are made available, a "use" (public 171 key use) parameter value is REQUIRED for all keys in the 172 referenced JWK Set to indicate each key's intended usage. 174 scopes_provided 175 RECOMMENDED. JSON array containing a list of the OAuth 2.0 176 [RFC6749] "scope" values that are used in authorization requests 177 to request access to this protected resource. Protected resources 178 MAY choose not to advertise some scope values provided even when 179 this parameter is used. 181 bearer_methods_supported 182 OPTIONAL. JSON array containing a list of the OAuth 2.0 Bearer 183 Token [RFC6750] presentation methods that this protected resource 184 supports. Defined values are "["header", "fragment", "query"]", 185 corresponding to Sections 2.1, 2.2, and 2.3 of RFC 6750. 187 resource_signing_alg_values_supported 188 OPTIONAL. JSON array containing a list of the JWS [JWS] signing 189 algorithms ("alg" values) [JWA] supported by the protected 190 resource for signed content. The value "none" MAY be included. 192 resource_encryption_alg_values_supported 193 OPTIONAL. JSON array containing a list of the JWE [JWE] 194 encryption algorithms ("alg" values) [JWA] supported by the 195 protected resource for encrypted content. 197 resource_encryption_enc_values_supported 198 OPTIONAL. JSON array containing a list of the JWE encryption 199 algorithms ("enc" values) [JWA] supported by the protected 200 resource for encrypted content. 202 resource_documentation 203 OPTIONAL. URL of a page containing human-readable information 204 that developers might want or need to know when using the 205 protected resource 207 resource_policy_uri 208 OPTIONAL. URL that the protected resource provides to read about 209 the protected resource's requirements on how the client can use 210 the data provided by the protected resource 212 resource_tos_uri 213 OPTIONAL. URL that the protected resource provides to read about 214 the protected resource's terms of service 216 Additional protected resource metadata parameters MAY also be used. 218 2.1. Signed Protected Resource Metadata 220 In addition to JSON elements, metadata values MAY also be provided as 221 a "signed_metadata" value, which is a JSON Web Token (JWT) [JWT] that 222 asserts metadata values about the protected resource as a bundle. A 223 set of claims that can be used in signed metadata are defined in 224 Section 2. The signed metadata MUST be digitally signed or MACed 225 using JSON Web Signature (JWS) [JWS] and MUST contain an "iss" 226 (issuer) claim denoting the party attesting to the claims in the 227 signed metadata. Consumers of the metadata MAY ignore the signed 228 metadata if they do not support this feature. If the consumer of the 229 metadata supports signed metadata, metadata values conveyed in the 230 signed metadata MUST take precedence over those conveyed using plain 231 JSON elements. 233 Signed metadata is included in the protected resource metadata JSON 234 object using this OPTIONAL member: 236 signed_metadata 237 A JWT containing metadata values about the protected resource as 238 claims. This is a string value consisting of the entire signed 239 JWT. A "signed_metadata" metadata value SHOULD NOT appear as a 240 claim in the JWT. 242 3. Obtaining Protected Resource Metadata 244 Protected resources supporting metadata MUST make a JSON document 245 containing metadata as specified in Section 2 available at a path 246 formed by concatenating a well-known URI string such as "/.well- 247 known/oauth-protected-resource" to the protected resource's resource 248 identifier. The syntax and semantics of ".well-known" are defined in 249 RFC 5785 [RFC5785]. The well-known URI path suffix used MUST be 250 registered in the IANA "Well-Known URIs" registry [IANA.well-known]. 252 Different applications utilizing OAuth protected resources in 253 application-specific ways may define and register different well- 254 known URI path suffixes used to publish protected resource metadata 255 as used by those applications. For instance, if the Example 256 application uses an OAuth protected resource in an Example-specific 257 way, and there are Example-specific metadata values that it needs to 258 publish, then it might register and use the "example-resource- 259 configuration" URI path suffix and publish the metadata document at 260 the path formed by concatenating "/.well-known/example-resource- 261 configuration" to the protected resource's resource identifier. 263 An OAuth 2.0 application using this specification MUST specify what 264 well-known URI string it will use for this purpose. The same 265 protected resource MAY choose to publish its metadata at multiple 266 well-known locations relative to its resource identifier, for 267 example, publishing metadata at both "/.well-known/example-resource- 268 configuration" and "/.well-known/oauth-protected-resource". 270 3.1. Protected Resource Metadata Request 272 A protected resource metadata document MUST be queried using an HTTP 273 "GET" request at the previously specified path. 275 The consumer of the metadata would make the following request when 276 the resource identifier is "https://resource.example.com" and the 277 well-known URI path suffix is "oauth-protected-resource" to obtain 278 the metadata, since the resource identifier contains no path 279 component: 281 GET /.well-known/oauth-protected-resource HTTP/1.1 282 Host: resource.example.com 284 If the resource identifier value contains a path component, any 285 terminating "/" MUST be removed before appending "/.well-known/" and 286 the well-known URI path suffix. The consumer of the metadata would 287 make the following request when the resource identifier is 288 "https://resource.example.com/resource1" and the well-known URI path 289 suffix is "oauth-protected-resource" to obtain the metadata, since 290 the resource identifier contains a path component: 292 GET /resource1/.well-known/oauth-protected-resource HTTP/1.1 293 Host: resource.example.com 295 Using path components enables supporting multiple resources per host. 296 This is required in some multi-tenant hosting configurations. This 297 use of ".well-known" is for supporting multiple resources per host; 298 unlike its use in RFC 5785 [RFC5785], it does not provide general 299 information about the host. 301 3.2. Protected Resource Metadata Response 303 The response is a set of claims about the protected resource's 304 configuration. A successful response MUST use the 200 OK HTTP status 305 code and return a JSON object using the "application/json" content 306 type that contains a set of claims as its members that are a subset 307 of the metadata values defined in Section 2. Other claims MAY also 308 be returned. 310 Claims that return multiple values are represented as JSON arrays. 311 Claims with zero elements MUST be omitted from the response. 313 An error response uses the applicable HTTP status code value. 315 The following is a non-normative example response: 317 HTTP/1.1 200 OK 318 Content-Type: application/json 320 { 321 "resource": 322 "https://resource.example.com", 323 "authorization_servers": 324 ["https://as1.example.com", 325 "https://as2.example.net"], 326 "bearer_methods_supported": 327 ["header", "body"], 328 "resource_documentation": 329 "http://resource.example.com/resource_documentation.html" 330 } 332 3.3. Protected Resource Metadata Validation 334 The "resource" value returned MUST be identical to the protected 335 resource's resource identifier value that was concatenated with the 336 well-known URI path suffix to create the URL used to retrieve the 337 metadata. If these values are not identical, the data contained in 338 the response MUST NOT be used. 340 4. String Operations 342 Processing some OAuth 2.0 messages requires comparing values in the 343 messages to known values. For example, the member names in the 344 metadata response might be compared to specific member names such as 345 "resource". Comparing Unicode [UNICODE] strings, however, has 346 significant security implications. 348 Therefore, comparisons between JSON strings and other Unicode strings 349 MUST be performed as specified below: 351 1. Remove any JSON applied escaping to produce an array of Unicode 352 code points. 354 2. Unicode Normalization [USA15] MUST NOT be applied at any point to 355 either the JSON string or to the string it is to be compared 356 against. 358 3. Comparisons between the two strings MUST be performed as a 359 Unicode code point to code point equality comparison. 361 5. Security Considerations 363 5.1. TLS Requirements 365 Implementations MUST support TLS. Which version(s) ought to be 366 implemented will vary over time, and depend on the widespread 367 deployment and known security vulnerabilities at the time of 368 implementation. The protected resource MUST support TLS version 1.2 369 [RFC5246] and MAY support additional transport-layer security 370 mechanisms meeting its security requirements. When using TLS, the 371 client MUST perform a TLS/SSL server certificate check, per RFC 6125 372 [RFC6125]. Implementation security considerations can be found in 373 Recommendations for Secure Use of TLS and DTLS [BCP195]. 375 To protect against information disclosure and tampering, 376 confidentiality protection MUST be applied using TLS with a 377 ciphersuite that provides confidentiality and integrity protection. 379 5.2. Impersonation Attacks 381 TLS certificate checking MUST be performed by the client, as 382 described in Section 5.1, when making a protected resource metadata 383 request. Checking that the server certificate is valid for the 384 resource identifier URL prevents man-in-middle and DNS-based attacks. 385 These attacks could cause a client to be tricked into using an 386 attacker's resource server, which would enable impersonation of the 387 legitimate protected resource. If an attacker can accomplish this, 388 they can access the resources that the affected client has access to 389 using the protected resource that they are impersonating. 391 An attacker may also attempt to impersonate a protected resource by 392 publishing a metadata document that contains a "resource" claim using 393 the resource identifier URL of the protected resource being 394 impersonated, but containing information of the attacker's choosing. 395 This would enable it to impersonate that protected resource, if 396 accepted by the client. To prevent this, the client MUST ensure that 397 the resource identifier URL it is using as the prefix for the 398 metadata request exactly matches the value of the "resource" metadata 399 value in the protected resource metadata document received by the 400 client. 402 5.3. Publishing Metadata in a Standard Format 404 Publishing information about the protected resource in a standard 405 format makes it easier for both legitimate clients and attackers to 406 use the protected resource. Whether a protected resource publishes 407 its metadata in an ad-hoc manner or in the standard format defined by 408 this specification, the same defenses against attacks that might be 409 mounted that use this information should be applied. 411 5.4. Authorization Servers 413 Secure determination of appropriate authorization servers to use with 414 a protected resource for all use cases is out of scope of this 415 specification. This specification assumes that the client has a 416 means of determining appropriate authorization servers to use with a 417 protected resource and that the client is using the correct metadata 418 for each protected resource. Implementers need to be aware that if 419 an inappropriate authorization server is used by the client, that an 420 attacker may be able to act as a man-in-the-middle proxy to a valid 421 authorization server without it being detected by the authorization 422 server or the client. 424 The ways to determine the appropriate authorization servers to use 425 with a protected resource are in general, application-dependent. For 426 instance, some protected resources are used with a fixed 427 authorization server or set of authorization servers, the locations 428 of which may be well known, or which could be published as metadata 429 values by the protected resource. In other cases, the set of 430 authorization servers that can be used with a protected resource can 431 by dynamically changed by administrative actions or by changes to the 432 set of authorization servers adhering to a trust framework. Many 433 other means of determining appropriate associations between protected 434 resources and authorization servers are also possible. 436 To support use cases in which the set of legitimate authorization 437 servers to use with the protected resource is fixed and enumerable, 438 this specification defines the "authorization_servers" metadata 439 value, which enables explicitly listing them. Note that if the set 440 of legitimate protected resources to use with an authorization server 441 is also fixed and enumerable, lists in the protected resource 442 metadata and authorization server metadata should be cross-checked 443 against one another for consistency when these lists are used by the 444 application profile. 446 6. IANA Considerations 448 The following registration procedure is used for the registry 449 established by this specification. 451 Values are registered on a Specification Required [RFC5226] basis 452 after a two-week review period on the oauth-ext-review@ietf.org 453 mailing list, on the advice of one or more Designated Experts. 454 However, to allow for the allocation of values prior to publication, 455 the Designated Experts may approve registration once they are 456 satisfied that such a specification will be published. 458 Registration requests sent to the mailing list for review should use 459 an appropriate subject (e.g., "Request to register OAuth Protected 460 Resource Metadata: example"). 462 Within the review period, the Designated Experts will either approve 463 or deny the registration request, communicating this decision to the 464 review list and IANA. Denials should include an explanation and, if 465 applicable, suggestions as to how to make the request successful. 466 Registration requests that are undetermined for a period longer than 467 21 days can be brought to the IESG's attention (using the 468 iesg@ietf.org mailing list) for resolution. 470 Criteria that should be applied by the Designated Experts includes 471 determining whether the proposed registration duplicates existing 472 functionality, determining whether it is likely to be of general 473 applicability or whether it is useful only for a single application, 474 and whether the registration makes sense. 476 IANA must only accept registry updates from the Designated Experts 477 and should direct all requests for registration to the review mailing 478 list. 480 It is suggested that multiple Designated Experts be appointed who are 481 able to represent the perspectives of different applications using 482 this specification, in order to enable broadly-informed review of 483 registration decisions. In cases where a registration decision could 484 be perceived as creating a conflict of interest for a particular 485 Expert, that Expert should defer to the judgment of the other 486 Experts. 488 6.1. OAuth Protected Resource Metadata Registry 490 This specification establishes the IANA "OAuth Protected Resource 491 Metadata" registry for OAuth 2.0 protected resource metadata names. 492 The registry records the protected resource metadata member and a 493 reference to the specification that defines it. 495 6.1.1. Registration Template 497 Metadata Name: 498 The name requested (e.g., "resource"). This name is case- 499 sensitive. Names may not match other registered names in a case- 500 insensitive manner unless the Designated Experts state that there 501 is a compelling reason to allow an exception. 503 Metadata Description: 504 Brief description of the metadata (e.g., "Resource identifier 505 URL"). 507 Change Controller: 508 For Standards Track RFCs, list the "IESG". For others, give the 509 name of the responsible party. Other details (e.g., postal 510 address, email address, home page URI) may also be included. 512 Specification Document(s): 513 Reference to the document or documents that specify the parameter, 514 preferably including URIs that can be used to retrieve copies of 515 the documents. An indication of the relevant sections may also be 516 included but is not required. 518 6.1.2. Initial Registry Contents 520 o Metadata Name: "resource" 521 o Metadata Description: Protected resource's resource identifier URL 522 o Change Controller: IESG 523 o Specification Document(s): Section 2 of [[ this specification ]] 524 o Metadata Name: "authorization_servers" 525 o Metadata Description: JSON array containing a list of OAuth 526 authorization server issuer identifiers 527 o Change Controller: IESG 528 o Specification Document(s): Section 2 of [[ this specification ]] 530 o Metadata Name: "jwks_uri" 531 o Metadata Description: URL of the protected resource's JWK Set 532 document 533 o Change Controller: IESG 534 o Specification Document(s): Section 2 of [[ this specification ]] 536 o Metadata Name: "scopes_provided" 537 o Metadata Description: JSON array containing a list of the OAuth 538 2.0 "scope" values that are used in authorization requests to 539 request access this protected resource 540 o Change Controller: IESG 541 o Specification Document(s): Section 2 of [[ this specification ]] 543 o Metadata Name: "bearer_methods_supported" 544 o Metadata Description: JSON array containing a list of the OAuth 545 2.0 Bearer Token presentation methods that this protected resource 546 supports 547 o Change Controller: IESG 548 o Specification Document(s): Section 2 of [[ this specification ]] 550 o Metadata Name: "resource_signing_alg_values_supported" 551 o Metadata Description: JSON array containing a list of the JWS 552 signing algorithms ("alg" values) supported by the protected 553 resource for signed content 554 o Change Controller: IESG 555 o Specification Document(s): Section 2 of [[ this specification ]] 557 o Metadata Name: "resource_encryption_alg_values_supported" 558 o Metadata Description: JSON array containing a list of the JWE 559 encryption algorithms ("alg" values) supported by the protected 560 resource for encrypted content 561 o Change Controller: IESG 562 o Specification Document(s): Section 2 of [[ this specification ]] 564 o Metadata Name: "resource_encryption_enc_values_supported" 565 o Metadata Description: JSON array containing a list of the JWE 566 encryption algorithms ("enc" values) supported by the protected 567 resource for encrypted content 568 o Change Controller: IESG 569 o Specification Document(s): Section 2 of [[ this specification ]] 571 o Metadata Name: "resource_documentation" 572 o Metadata Description: URL of a page containing human-readable 573 information that developers might want or need to know when using 574 the protected resource 575 o Change Controller: IESG 576 o Specification Document(s): Section 2 of [[ this specification ]] 578 o Metadata Name: "resource_policy_uri" 579 o Metadata Description: URL that the protected resource provides to 580 read about the protected resource's requirements on how the client 581 can use the data provided by the protected resource 582 o Change Controller: IESG 583 o Specification Document(s): Section 2 of [[ this specification ]] 585 o Metadata Name: "resource_tos_uri" 586 o Metadata Description: URL that the protected resource provides to 587 read about the protected resource's terms of service 588 o Change Controller: IESG 589 o Specification Document(s): Section 2 of [[ this specification ]] 591 6.2. Well-Known URI Registry 593 This specification registers the well-known URI defined in Section 3 594 in the IANA "Well-Known URIs" registry [IANA.well-known] established 595 by RFC 5785 [RFC5785]. 597 6.2.1. Registry Contents 599 o URI suffix: "oauth-protected-resource" 600 o Change controller: IESG 601 o Specification document: Section 3 of [[ this specification ]] 602 o Related information: (none) 604 7. References 606 7.1. Normative References 608 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 609 "Recommendations for Secure Use of Transport Layer 610 Security (TLS) and Datagram Transport Layer Security 611 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 612 2015, . 614 [JWA] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 615 DOI 10.17487/RFC7518, May 2015, 616 . 618 [JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 619 RFC 7516, DOI 10.17487/RFC7516, May 2015, 620 . 622 [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, 623 DOI 10.17487/RFC7517, May 2015, 624 . 626 [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 627 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 628 2015, . 630 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 631 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 632 . 634 [OAuth.AuthorizationMetadata] 635 Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 636 Authorization Server Metadata", draft-ietf-oauth- 637 discovery-04 (work in progress), August 2016, 638 . 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, 643 DOI 10.17487/RFC2119, March 1997, 644 . 646 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 647 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 648 DOI 10.17487/RFC5226, May 2008, 649 . 651 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 652 (TLS) Protocol Version 1.2", RFC 5246, 653 DOI 10.17487/RFC5246, August 2008, 654 . 656 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 657 Uniform Resource Identifiers (URIs)", RFC 5785, 658 DOI 10.17487/RFC5785, April 2010, 659 . 661 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 662 Verification of Domain-Based Application Service Identity 663 within Internet Public Key Infrastructure Using X.509 664 (PKIX) Certificates in the Context of Transport Layer 665 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 666 2011, . 668 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 669 RFC 6749, DOI 10.17487/RFC6749, October 2012, 670 . 672 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 673 Framework: Bearer Token Usage", RFC 6750, 674 DOI 10.17487/RFC6750, October 2012, 675 . 677 [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, 678 "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 679 2013, . 681 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 682 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 683 2014, . 685 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 686 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 687 RFC 7591, DOI 10.17487/RFC7591, July 2015, 688 . 690 [UNICODE] The Unicode Consortium, "The Unicode Standard", 691 . 693 [USA15] Davis, M. and K. Whistler, "Unicode Normalization Forms", 694 Unicode Standard Annex 15, June 2015, 695 . 697 7.2. Informative References 699 [I-D.ietf-oauth-mix-up-mitigation] 700 Jones, M., Bradley, J., and N. Sakimura, "OAuth 2.0 Mix-Up 701 Mitigation", draft-ietf-oauth-mix-up-mitigation-01 (work 702 in progress), July 2016. 704 [IANA.well-known] 705 IANA, "Well-Known URIs", 706 . 708 [OpenID.Discovery] 709 Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID 710 Connect Discovery 1.0", November 2014, 711 . 714 Appendix A. Acknowledgements 716 Thanks to George Fletcher and Tony Nadalin for their input on the 717 specification. 719 Appendix B. Document History 721 [[ to be removed by the RFC Editor before publication as an RFC ]] 723 -00 725 o Created the initial version. This draft reuses some text from 726 draft-ietf-oauth-discovery-03. 728 Authors' Addresses 730 Michael B. Jones 731 Microsoft 733 Email: mbj@microsoft.com 734 URI: http://self-issued.info/ 736 Phil Hunt 737 Oracle 739 Email: phil.hunt@yahoo.com