idnits 2.17.1 draft-young-md-query-05.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 (April 24, 2015) is 3288 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Young, Ed. 3 Internet-Draft Independent 4 Intended status: Informational April 24, 2015 5 Expires: October 26, 2015 7 Metadata Query Protocol 8 draft-young-md-query-05 10 Abstract 12 This document defines a simple protocol for retrieving metadata about 13 named entities, or named collections of entities. The goal of the 14 protocol is to profile various aspects of HTTP to allow requesters to 15 rely on certain, rigorously defined, behaviour. 17 This document is a product of the Research and Education Federations 18 (REFEDS) Working Group process. 20 Editorial Note (To be removed by RFC Editor before publication) 22 Discussion of this draft takes place on the MDX mailing list 23 (mdx@lists.iay.org.uk), which is accessed from [MDX.list]. 25 XML versions, latest edits and the issues list for this document are 26 available from [md-query]. 28 The changes in this draft are summarized in Appendix A.6. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on October 26, 2015. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Notation and Conventions . . . . . . . . . . . . . . . . 3 63 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Protocol Transport . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Transport Protocol . . . . . . . . . . . . . . . . . . . 4 66 2.2. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.4. Request Headers . . . . . . . . . . . . . . . . . . . . . 4 69 2.5. Response Headers . . . . . . . . . . . . . . . . . . . . 5 70 2.6. Status Codes . . . . . . . . . . . . . . . . . . . . . . 5 71 2.7. Base URL . . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.8. Content Negotiation . . . . . . . . . . . . . . . . . . . 6 73 3. Metadata Query Protocol . . . . . . . . . . . . . . . . . . . 6 74 3.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.2.1. Request by Identifier . . . . . . . . . . . . . . . . 7 77 3.2.2. Request All Entities . . . . . . . . . . . . . . . . 7 78 3.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 8 79 3.2.4. Example Request and Response . . . . . . . . . . . . 8 80 4. Efficient Retrieval and Caching . . . . . . . . . . . . . . . 9 81 4.1. Conditional Retrieval . . . . . . . . . . . . . . . . . . 9 82 4.2. Content Caching . . . . . . . . . . . . . . . . . . . . . 9 83 4.3. Content Compression . . . . . . . . . . . . . . . . . . . 9 84 5. Protocol Extension Points . . . . . . . . . . . . . . . . . . 9 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 86 6.1. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 10 87 6.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 10 88 6.3. Authentication . . . . . . . . . . . . . . . . . . . . . 10 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 93 9.2. Informative References . . . . . . . . . . . . . . . . . 11 94 Appendix A. Change Log (to be removed by RFC Editor before 95 publication) . . . . . . . . . . . . . . . . . . . . 13 96 A.1. Since draft-lajoie-md-query-01 . . . . . . . . . . . . . 13 97 A.2. Since draft-young-md-query-00 . . . . . . . . . . . . . . 13 98 A.3. Since draft-young-md-query-01 . . . . . . . . . . . . . . 14 99 A.4. Since draft-young-md-query-02 . . . . . . . . . . . . . . 14 100 A.5. Since draft-young-md-query-03 . . . . . . . . . . . . . . 14 101 A.6. Since draft-young-md-query-04 . . . . . . . . . . . . . . 14 103 1. Introduction 105 Many clients of web-based services are capable of consuming 106 descriptive metadata about a service in order to customize or obtain 107 information about the client's connection parameters. While the form 108 of the metadata (e.g., JSON, XML) and content varies between services 109 this document specifies a set of semantics for HTTP ([RFC7230] et 110 seq.) that allow clients to rely on certain behavior. The defined 111 behavior is meant to make it easy for clients to perform queries, to 112 be efficient for both requesters and responders, and to allow the 113 responder to scale in various ways. 115 The Research and Education Federations group ([REFEDS]) is the voice 116 that articulates the mutual needs of research and education identity 117 federations worldwide. It aims to represent the requirements of 118 research and education in the ever-growing space of access and 119 identity management. 121 From time to time REFEDS will wish to publish a document in the 122 Internet RFC series. Such documents will be published as part of the 123 RFC Independent Submission Stream [RFC4844]; however the REFEDS 124 working group sign-off process will have been followed for these 125 documents, as described in the REFEDS Participant's Agreement 126 [REFEDS.agreement]. 128 This document is a product of the REFEDS Working Group process. 130 1.1. Notation and Conventions 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [BCP14]. 136 This document makes use of the Augmented BNF metalanguage defined in 137 [STD68]. 139 1.2. Terminology 141 entity: A single logical construct for which metadata may be 142 asserted. Generally this is a network accessible service. 144 metadata: A machine readable description of certain entity 145 characteristics. Generally metadata provides information such as 146 end point references, service contact information, etc. 148 2. Protocol Transport 150 The metadata query protocol seeks to fully employ the features of the 151 HTTP protocol. Additionally this specification makes mandatory some 152 optional HTTP features. 154 2.1. Transport Protocol 156 The metadata query protocol makes use of the HTTP protocol 157 ([RFC7230]) to transmit requests and responses. The underlying HTTP 158 connection MAY make use of any appropriate transport protocol. In 159 particular, the HTTP connection MAY make use of either TCP or TLS at 160 the transport layer. See the Security Considerations section for 161 guidance in choosing an appropriate transport protocol. 163 2.2. HTTP Version 165 Requests from clients MUST NOT use an HTTP version prior to version 166 1.1. Responders MUST reply to such requests using status code 505, 167 "HTTP Version Not Supported". 169 Protocol responders MUST support requests using HTTP version 1.1, and 170 MAY support later versions. 172 2.3. HTTP Method 174 All metadata query requests MUST use the GET method. 176 2.4. Request Headers 178 All metadata query requests MUST include the following HTTP headers: 180 Accept - this header MUST contain the content-type identifying the 181 type, or form, of metadata to be retrieved. See section 5.3.2 of 182 [RFC7231]. 184 All metadata query requests SHOULD include the following HTTP 185 headers: 187 Accept-Charset, see section 5.3.3 of [RFC7231] 189 Accept-Encoding, see section 5.3.4 of [RFC7231] 191 A metadata request to the same URL, after an initial request, MUST 192 include the following header: 194 If-None-Match, see section 3.2 of [RFC7232]. 196 2.5. Response Headers 198 All successful metadata query responses (even those that return no 199 results) MUST include the following headers: 201 Content-Encoding - required if, and only if, content is 202 compressed. See section 3.1.2.2 of [RFC7231]. 204 Content-Type, see section 3.1.1.5 of [RFC7231]. 206 ETag, see section 2.3 of [RFC7232]. 208 All metadata retrieval responses SHOULD include the following 209 headers: 211 Cache-Control, see section 5.2 of [RFC7234]. 213 Content-Length, see section 3.3.2 of [RFC7230] 215 Last-Modified, see section 2.2 of [RFC7232]. 217 2.6. Status Codes 219 This protocol uses the following HTTP status codes: 221 200 "OK" - standard response code when returning requested 222 metadata 224 304 "Not Modified" - response code indicating requested metadata 225 has not been updated since the last request 227 400 "Bad Request" - response code indicating that the requester's 228 request was malformed in some fashion 230 401 "Unauthorized" - response code indicating the request must be 231 authenticated before requesting metadata 232 404 "Not Found" - indicates that the requested metadata could not 233 be found; this MUST NOT be used in order to indicate a general 234 service error. 236 405 "Method Not Allowed" - response code indicating that a non-GET 237 method was used 239 406 "Not Acceptable" - response code indicating that metadata is 240 not available in the request content-type 242 505 "HTTP Version Not Supported" - response code indicating that 243 HTTP/1.1 was not used 245 2.7. Base URL 247 Requests defined in this document are performed by issuing an HTTP 248 GET request to a particular URL ([STD66]). The final component of 249 the path to which requests are issued is defined by the requests 250 specified within this document. A base URL precedes such paths. 251 Such a base URL: 253 o MUST contain the scheme and authority components. 255 o MUST contain a path component ending with a slash ('/') character. 257 o MUST NOT include a query component. 259 o MUST NOT include a fragment identifier component. 261 2.8. Content Negotiation 263 As there may be many representations for a given piece of metadata, 264 agent-driven content negotiation is used to ensure the proper 265 representation is delivered to the requester. In addition to the 266 required usage of the Accept header a responder SHOULD also support 267 the use of the Accept-Charset header. 269 3. Metadata Query Protocol 271 The metadata query protocol retrieves metadata either for all 272 entities known to the responder or for a named collection based on a 273 single "tag" or "keyword" identifier. A request returns information 274 for none, one, or a collection of entities. 276 3.1. Identifiers 278 The query protocol uses identifiers to "tag" metadata for single- and 279 multi-entity metadata collections. The assignment of such 280 identifiers to a particular metadata document is the responsibility 281 of the query responder. If a metadata collection already contains a 282 well known identifier it is RECOMMENDED that such a natural 283 identifier is used when possible. Any given metadata collection MAY 284 have more than one identifier associated with it. 286 An identifier used in the query protocol is a non-empty sequence of 287 arbitrary 8-bit characters: 289 id = 1*idchar 290 idchar = %x00-ff ; any encodable character 292 3.2. Protocol 294 3.2.1. Request by Identifier 296 A metadata query request for all entities tagged with a particular 297 identifier is performed by issuing an HTTP GET request to a URL 298 constructed as the concatenation of the following components: 300 o The responder's base URL. 302 o The string "entities/". 304 o A single URL-encoded identifier. 306 For example, with a base URL of "http://example.org/mdq/", a query 307 for the identifier "foo" would be performed by an HTTP GET request to 308 the following URL: 310 http://example.org/mdq/entities/foo 312 3.2.2. Request All Entities 314 A metadata query request for all entities known to the responder is 315 performed by issuing an HTTP GET request to a URL constructed as the 316 concatenation of the following components: 318 o The responder's base URL. 320 o The string "entities". 322 For example, with a base URL of "http://example.org/mdq/", a query 323 for all entities would be performed by an HTTP GET request to the 324 following URL: 326 http://example.org/mdq/entities 328 3.2.3. Response 330 The response to a metadata query request MUST be a document that 331 provides metadata for the given request in the format described by 332 the request's Accept header. 334 The responder is responsible for ensuring that the metadata returned 335 is valid. If the responder can not create a valid document it MUST 336 respond with a 406 status code. An example of such an error would be 337 the case where the result of the query is metadata for multiple 338 entities but the request content type does not support returning 339 multiple results in a single document. 341 3.2.4. Example Request and Response 343 The following example demonstrates a metadata query request using a 344 base URL of "http://metadata.example.org/service/" and the identifier 345 "http://example.org/idp". 347 GET /service/entities/http%3A%2F%2Fexample.org%2Fidp HTTP/1.1 348 Host: metadata.example.org 349 Accept: application/samlmetadata+xml 351 Example Metadata Query Request 353 HTTP/1.x 200 OK 354 Content-Type: application/samlmetadata+xml 355 ETag: "abcdefg" 356 Last-Modified: Thu, 15 Apr 2010 12:45:26 GMT 357 Content-Length: 1234 359 360 362 .... 364 Example Metadata Query Response 366 4. Efficient Retrieval and Caching 368 4.1. Conditional Retrieval 370 Upon a successful response the responder MUST return an ETag header 371 and MAY return a Last-Modified header as well. Requesters SHOULD use 372 either or both, with the ETag being preferred, in any subsequent 373 requests for the same resource. In the event that a resource has not 374 changed since the previous request, the requester will receive a 304 375 (Not Modified) status code as a response. 377 4.2. Content Caching 379 Responders SHOULD include cache control information with successful 380 (200 status code) responses, assuming the responder knows when 381 retrieved metadata is meant to expire. The responder SHOULD also 382 include cache control information with 404 Not Found responses. This 383 allows the requester to create and maintain a negative-response 384 cache. When cache controls are used only the 'max-age' directive 385 SHOULD be used. 387 4.3. Content Compression 389 As should be apparent from the required request and response headers 390 this protocol encourages the use of content compression. This is in 391 recognition that some metadata documents can be quite large or 392 fetched with relatively high frequency. 394 Requesters SHOULD support, and advertise support for, gzip 395 compression unless such usage would put exceptional demands on 396 constrained environments. Responders MUST support gzip compression. 397 Requesters and responders MAY support other compression algorithms. 399 5. Protocol Extension Points 401 The Metadata Query Protocol is extensible using the following 402 protocol extension points: 404 o Profiles of this specification may assign semantics to specific 405 identifiers, or to identifiers structured in particular ways. 407 o Profiles of this specification may define additional paths (other 408 than "entities" and "entities/") below the base URL. 410 6. Security Considerations 412 6.1. Integrity 414 As metadata often contains information necessary for the secure 415 operation of interacting services it is RECOMMENDED that some form of 416 content integrity checking be performed. This may include the use of 417 TLS at the transport layer, digital signatures present within the 418 metadata document, or any other such mechanism. 420 6.2. Confidentiality 422 In many cases service metadata is public information and therefore 423 confidentiality is not required. In the cases where such 424 functionality is required, it is RECOMMENDED that both the requester 425 and responder support TLS. Other mechanisms, such as XML encryption, 426 MAY also be supported. 428 6.3. Authentication 430 All responders which require client authentication to view retrieved 431 information MUST support the use of HTTP basic authentication 432 ([RFC7235], [RFC2617]/[I-D.basicauth]) over TLS. Responders SHOULD 433 also support the use of X.509 client certificate authentication. 435 7. IANA Considerations 437 This document has no actions for IANA. 439 8. Acknowledgements 441 The editor would like to acknowledge the following individuals for 442 their contributions to this document: 444 Scott Cantor (The Ohio State University) 446 Leif Johansson (SUNET) 448 Thomas Lenggenhager (SWITCH) 450 Joe St Sauver (University of Oregon) 452 Tom Scavo (Internet2) 454 Special acknowledgement is due to Chad LaJoie (Covisint) for his work 455 in editing previous versions of this specification. 457 9. References 459 9.1. Normative References 461 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, March 1997. 464 [I-D.basicauth] 465 Reschke, J., "The 'Basic' HTTP Authentication Scheme", 466 draft-ietf-httpauth-basicauth-update-07 (work in 467 progress), February 2015. 469 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 470 Leach, P., Luotonen, A., and L. Stewart, "HTTP 471 Authentication: Basic and Digest Access Authentication", 472 RFC 2617, June 1999. 474 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 475 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 476 2014. 478 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 479 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 481 [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 482 (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 484 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 485 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 486 2014. 488 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 489 (HTTP/1.1): Authentication", RFC 7235, June 2014. 491 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 492 Resource Identifier (URI): Generic Syntax", STD 66, RFC 493 3986, January 2005. 495 [STD68] Crocker, D. and P. Overell, "Augmented BNF for Syntax 496 Specifications: ABNF", STD 68, RFC 5234, January 2008. 498 9.2. Informative References 500 [MDX.list] 501 Young, I., Ed., "MDX Mailing List", 502 . 504 [REFEDS] Research and Education Federations, "REFEDS Home Page", 505 . 507 [REFEDS.agreement] 508 Research and Education Federations, "REFEDS Participant's 509 Agreement", . 512 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 513 Series and RFC Editor", RFC 4844, July 2007. 515 [md-query] 516 Young, I., Ed., "md-query Project", 517 . 519 Appendix A. Change Log (to be removed by RFC Editor before publication) 521 A.1. Since draft-lajoie-md-query-01 523 Adopted as base for draft-young-md-query-00. 525 Updated author and list of contributors. 527 Changed ipr from "pre5378Trust200902" to "trust200902", submission 528 type from IETF to independent and category from experimental to 529 informational. 531 Added empty IANA considerations section. 533 Minor typographical nits but (intentionally) no substantive content 534 changes. 536 A.2. Since draft-young-md-query-00 538 Split into two documents: this one is as agnostic as possible around 539 questions such as metadata format and higher level protocol use 540 cases, a new layered document describes the detailed requirements for 541 SAML support. 543 Rewrite Section 3.2.1 to clarify construction of the request URL and 544 its relationship to the base URL. 546 Added Section 2.1 to clarify that the transport protocol underlying 547 HTTP may be either TCP or SSL/TLS. 549 Clarify position on HTTP versions (Section 2.2) which may be used to 550 underly this protocol. 552 Added Change Log modelled on draft-ietf-httpbis-http2. 554 Added a reference to [STD68]. Use ABNF to describe request syntax. 555 Replace transformed identifier concept with extended identifiers 556 (this also resulted in the removal of any discussion of specific 557 transformed identifier formats). Add grammar to distinguish basic 558 from extended identifiers. 560 Changed the required response when the result can not be validly 561 expressed in the requested format from 500 to 406. 563 Removed the '+' operator and all references to multiple identifiers 564 in queries. If more complex queries are required, these will be 565 reintroduced at a different path under the base URL. 567 Added a section describing Protocol Extension Points. 569 A.3. Since draft-young-md-query-01 571 Added REFEDS RFC stream boilerplate. 573 Tidied up some normative language. 575 A.4. Since draft-young-md-query-02 577 Introduced a normative reference to [STD66]. 579 Reworked the definition of the base URL so that a non-empty path 580 ending with '/' is required. This allows the definition of request 581 URLs to be simplified. 583 Clarified the definition of the base URL to exclude a query 584 component; corrected the terminology for the fragment identifier 585 component. 587 Added the definition for the query for all entities in Section 3.2.2. 589 Corrected an example in Section 3.2.4 to include the required double 590 quotes in the value of an ETag header. Added text to clarify the 591 base URL and identifier being used in the example. 593 Simplified the definition of identifiers, so that any non-empty 594 identifier is accepted and no semantics are defined for particular 595 structures. Extended syntaxes such as the "{sha1}" notation for 596 transformed identifiers are now left to profiles. 598 Remove incidental references to SSL. 600 Remove status code 501 ("not implemented") as it is no longer 601 referenced. 603 A.5. Since draft-young-md-query-03 605 Correct a typo in the identifier grammar. 607 A.6. Since draft-young-md-query-04 609 Updated to rely on the new definition of HTTP/1.1 in [RFC7230] et 610 seq. instead of RFC 2616. 612 Corrected Section 3.2.3 to indicate that the request contains an 613 Accept header, not a Content-Type header. 615 Added an Editorial Note to help direct readers back to the 616 discussion. 618 Author's Address 620 Ian A. Young (editor) 621 Independent 623 EMail: ian@iay.org.uk