idnits 2.17.1 draft-hallambaker-json-web-service-03.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 : ---------------------------------------------------------------------------- == There are 15 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 649 has weird spacing: '...egistry jose-...' -- The document date (September 19, 2016) is 2777 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) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Standards Track September 19, 2016 5 Expires: March 23, 2017 7 JSON Web Service Binding Version 1.0 8 draft-hallambaker-json-web-service-03 10 Abstract 12 The JSON Web Binding (JWB) describes a standardized approach to 13 implementing Web Services. Services are advertised using the DNS SRV 14 and HTTP Well Known Service conventions. Messages may be 15 authenticated or authenticated and encrypted at the message layer in 16 addition to any transport and/or network layer security. Service 17 messages are encoded in JSON using Internet time format for Date-Time 18 fields and Base64urlencoding for binary objects. 20 This document specifies Version 1.0 of JWB which uses HTTP/1.1 for 21 transport. Use of the multiple stream capabilities of HTTP version 2 22 is outside the scope of this document. 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 http://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 March 23, 2017. 41 Copyright Notice 43 Copyright (c) 2016 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 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 3. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Host Identification . . . . . . . . . . . . . . . . . . . 5 63 3.1.1. SRV Lookup . . . . . . . . . . . . . . . . . . . . . 5 64 3.1.2. DNS Fallback . . . . . . . . . . . . . . . . . . . . 5 65 3.2. HTTP host processing . . . . . . . . . . . . . . . . . . 5 66 3.2.1. Use of TLS transport . . . . . . . . . . . . . . . . 6 67 3.2.2. Fallback Processing Rules . . . . . . . . . . . . . . 6 68 3.2.3. Service Continuation . . . . . . . . . . . . . . . . 6 69 3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4. HTTP Messages . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5. Error handling and response codes . . . . . . . . . . . . . . 10 74 6. Content Encoding . . . . . . . . . . . . . . . . . . . . . . 10 75 6.1. Direct Encoding . . . . . . . . . . . . . . . . . . . . . 11 76 6.2. Content-Encoding: jose-jwb . . . . . . . . . . . . . . . 11 77 6.3. Authenticated . . . . . . . . . . . . . . . . . . . . . . 11 78 6.4. Authenticated Encryption . . . . . . . . . . . . . . . . 12 79 7. Content Type . . . . . . . . . . . . . . . . . . . . . . . . 12 80 8. JSON Data Bindings . . . . . . . . . . . . . . . . . . . . . 12 81 8.1. Request Message . . . . . . . . . . . . . . . . . . . . . 12 82 8.2. Response Message . . . . . . . . . . . . . . . . . . . . 13 83 8.3. Data Fields . . . . . . . . . . . . . . . . . . . . . . . 13 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 9.1. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 14 86 9.1.1. DNS Spoofing . . . . . . . . . . . . . . . . . . . . 14 87 9.1.2. TLS Downgrade . . . . . . . . . . . . . . . . . . . . 14 88 9.1.3. TLS Service Impersonation . . . . . . . . . . . . . . 14 89 9.1.4. Request Replay Attack . . . . . . . . . . . . . . . . 14 90 9.1.5. Response Replay Attack . . . . . . . . . . . . . . . 14 91 9.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 14 92 9.2.1. Side Channel Attack . . . . . . . . . . . . . . . . . 14 93 9.2.2. Session Key Leakage . . . . . . . . . . . . . . . . . 14 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 97 11.2. Informative References . . . . . . . . . . . . . . . . . 16 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 100 1. Introduction 102 The JSON Web Binding (JWB) specifies one approach to using DNS 103 Discovery [RFC1035], the HTTP [RFC7230] protocol and the JSON data 104 encoding [RFC7159] in a Web Service. 106 JWB is not the only approach possible, but developing a standard 107 means making choices that don't matter to developers that build on 108 it. While there are infinitely many ways that a Web Service might 109 employ HTTP and JSON to implement a Web Service, a client and a 110 server can only interoperate if they both agree to use the same one. 112 Discovery Beginning with a DNS address of the service (e.g. 113 example.com), the client identifies a specific HTTP URL at 114 which to access the service. The DNS SRV record [RFC2782] and 115 Well Known Service [RFC5785] mechanisms are used for this 116 purpose. 118 Authentication and Encryption Web Services MAY require 119 authentication and encryption services at the message level 120 even if transport layer security (e.g. TLS [RFC5264]) is used. 121 Use of such enhancements is signaled using the HTTP Content- 122 Encoding header. 124 Content Mapping The mapping of data types described in the 125 specification (integer, string, etc.) to JSON data types. 126 [RFC3339] Date time encoding and BASE64-url encoding [RFC4648] 127 are used to map date-time and binary data types to JSON 128 encoding values. 130 A key architectural principle that guides the design of JWB is that 131 the Web Service application should be as independent of the HTTP 132 presentation layer as is possible. Thus: 134 Message semantics are not affected by HTTP headers or the request 135 line URL. 137 The use of HTTP response codes is limited to reporting errors and 138 warnings that arise from the HTTP transport. 140 If message layer authentication or authenticated encryption are used, 141 this is applied within the HTTP content payload and not through a 142 combination of payload and header data. 144 This specification describes a mechanism for accessing a collection 145 of hosts as a single undifferentiated service with provision for load 146 balancing and fault tolerance. This has important consequences for 147 state management. Web Services typically involve some form of 148 stateful interaction or real world side effect. Otherwise, it is 149 likely that the Web Service would be better written as a traditional 150 Web interaction mapping the stateless resources to URIs. 152 The mechanism described in this specification is intended for the 153 initial discovery of a host with which to engage in a Web Service 154 transaction which may or may not consist of a series of message 155 exchanges. Since sharing state between hosts supporting a virtual 156 service requires resources and typically introduces latency, a 157 service specification MAY require that a transaction begun on one 158 host be completed with the same host and the time period in which a 159 transaction that is accepted by one host will be regarded as 'final' 160 by the virtual service. 162 For example, a file upload protocol for a photograph sharing service 163 might have separate messages for checking that there is space to 164 store the photograph 'Check', uploading the file 'Store' and 165 reporting that the data is safely stored at multiple locations. When 166 responding to the Check command, the host is reporting that there is 167 space at that local node. It is obviously undesirable for a client 168 to verify that host1 has enough space to store the file and then 169 attempt to upload the file to host2. Equally, having uploaded the 170 file to host1, it might be minutes, hours or even days before the 171 photograph could be retrieved through host2. Such questions are left 172 for the Web Service protocol designer to address. 174 2. Definitions 176 2.1. Requirements Language 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in RFC 2119 [RFC2119]. 182 3. Service Discovery 184 Service discovery is the process of resolving the address of a Web 185 Service to a Web Service Endpoint, a URI [RFC3986] at which the 186 service is provided. 188 A JWB Web Service is specified by giving the DNS Address of the 189 service , and Well Known Service name . 191 3.1. Host Identification 193 The first step in service discovery is to resolve the and 194 identifiers to the IP address of a host that provides that 195 service. 197 3.1.1. SRV Lookup 199 A client attempting to connect to the service first attempts to 200 locate an SRV record [RFC2782] for the specified service: 202 _._tcp._ SRV 204 Where and are the SRV priority and weight 205 parameters specified in [RFC2782], is the TCP port number and 206 is the DNS name of the host for which the service 207 advertisement is made. Standard A/AAAA/CNAME resolution is used to 208 obtain the IP address of the host from . 210 If a match is found, the client uses the mechanism specified in 211 [RFC2782] to choose hosts and attempts to contact each host in turn 212 until a successful HTTP connection is established or the maximum 213 number of attempts threshold is reached. 215 3.1.2. DNS Fallback 217 Despite the fact that SRV records have been a part of the DNS 218 standard for 20 years, it is not uncommon for network intermediaries 219 to implement SRV record resolution incorrectly or block it entirely. 221 If no SRV record is found, a client MAY perform fallback discovery if 222 explicitly authorized to do so by the corresponding Web Service 223 protocol specification. The client attempts to connect to the host 224 . using the standard A/AAAA/CNAME resolution rules 225 to obtain the IP address of the host. 227 3.2. HTTP host processing 229 Having identified the IP address, the client performs a HTTP or HTTPS 230 Web Service POST request at the default Web Service Endpoint 231 specified by the Well Known Service name and the original DNS address 232 of the service. 234 http://:/.well-known/ 236 Note that a given host MAY provide multiple instances of a Web 237 Service under different discovery addresses. Therefore it is 238 essential to use the original value rather than the 239 returned in the SRV record. 241 3.2.1. Use of TLS transport 243 The use of TLS transport is indicated by the SRV port number as 244 follows: 246 If the SRV port number is 80, 8000, 8080 or greater than 32,767 247 HTTP over TCP is used. 249 Otherwise HTTP over TLS Transport (HTTPS) is used. 251 If an authenticated DNS resolution protocol (e.g. DNSSEC 252 [RFC4033]) is used to resolve the SRV record, these rules permit 253 deployments to achieve 'secure on first contact' transport 254 security without the need to resolve additional records (e.g. 255 TLSA [RFC6698]. Note however that while the use of TLS is 256 mandated, the criteria for evaluating the TLS certificate chain 257 presented by the server is left to local site policy. 259 A service presented on a port for which HTTP is indicated MAY 260 specify a redirect to require use of HTTPS protocol. 262 3.2.2. Fallback Processing Rules 264 If a client's attempt to connect to a host selected from an SRV 265 connection redirection results in a HTTP (3xx), Client error (4xx) or 266 Server error (5xx) code, the client MUST process the HTTP error 267 response and not simply attempt a connection to a different host. If 268 a client request is rejected for lack of authentication (511) or 269 because the request is too large (413) at one host, the client should 270 assume that the request will be rejected for the same reason at 271 another. If the attempt to create a TCP connection fails or the 272 server returns Service Unavailable (503), the client MAY use the SRV 273 fallback rules to select an alternative host. 275 3.2.3. Service Continuation 277 Once the initial service discovery mechanism has been used to 278 establish contact with a host, the service protocol MAY specify that 279 further interactions be directed to another host and/or using a 280 different protocol. Such mechanisms are outside the scope of this 281 specification. 283 3.3. Example 285 The Mathematical Mesh has the Well Known Service name of 'MMM'. 286 Accounts used in the Mathematical Mesh follow the [RFC5322] format of 287 @. 289 Alice has the account alice@example.com and the DNS configuration 290 file for example.com has the following entries: 292 _mmm._tcp.example.com SRV host1.example.com 0 10 80 host1.example.com 293 _mmm._tcp.example.com SRV host2.example.com 0 40 80 host2.example.com 294 mmm.example.com CNAME host3.example.com 295 host1.example.com A 10.0.1.1 296 host2.example.com A 10.0.1.2 297 host3.example.com A 10.0.1.1 298 host3.example.com A 10.0.1.2 300 The client attempts to resolve the address alice@example.com as 301 follows: 303 Client attempts to resolve SRV record for _mmm._tcp.example.com 305 DNS resolver returns two entries. 307 Client makes a random selection between host1 (20% weighting) and 308 host2 (80% weighting). Chooses host1. 310 Client resolves A/AAAA for host1.example.com 312 DNS resolver returns 10.0.1.1 314 Client attempts to POST Web Service request to 315 http://example.com/.well-known/mmm at host address 10.0.1.1 317 The host at 10.0.1.1 returns 503 Service Unavailable 319 Client resolves A/AAAA for host2.example.com 321 DNS resolver returns 10.0.1.2 323 Client attempts to POST Web Service request to 324 http://example.com/.well-known/mmm at host address 10.0.1.2 326 Request succeeds, session proceeds. 328 If the same client is used in a network location where the SRV record 329 resolution fails due to a faulty firewall configuration, the 330 resolution proceeds as follows: 332 Client attempts to resolve SRV record for _mmm._tcp.example.com 334 DNS resolver returns 'not found' 336 Client attempts to resolve A and AAAA record 338 DNS resolver returns 10.0.1.1, 10.0.1.2 340 Client makes a random selection between 10.0.1.1 (50% weighting) and 341 10.0.1.2 (50% weighting). Chooses host1. 343 Client attempts to POST Web Service request to 344 http://example.com/.well-known/mmm at host address 10.0.1.1 346 The host at 10.0.1.1 returns 503 Service Unavailable 348 Client attempts to POST Web Service request to 349 http://example.com/.well-known/mmm at host address 10.0.1.2 351 Request succeeds, session proceeds. 353 Note that the main difference between these two scenarios is that the 354 use of the SRV record allows the service configuration to account for 355 load balancing with tiers of fallback support while the use of round 356 robin A/AAAA records does not. 358 4. HTTP Messages 360 JWB messages are exchanged as HTTP POST transactions. Support for 361 and use of HTTP/1.1 [RFC7230] is REQUIRED unless otherwise specified 362 by the Web Service Specification. 364 While the use of HTTP/2 [RFC7540] offers the potential benefit of 365 multiple concurrent transaction streams, the means of making use of 366 such capabilities is outside the scope of JWB v1.0 but is likely to 367 be the main incentive for defining a revision. 369 In contrast to other approaches to the design of Web Services, the 370 only use made of the HTTP transport is to distinguish between 371 different services on the same host using the Host header and .well- 372 known convention and for message framing. 374 In particular no use is made of the URI request line to identify 375 commands, nor are the caching or proxy capabilities of HTTP. One of 376 the main design objectives of JWB is to enable message level 377 authentication. Since HTTP headers are mutable and may be changed by 378 intermediaries, any attempt to make use of HTTP features requires a 379 mechanism to canonicalize or duplicate the headers. Furthermore, the 380 implementation of authentication and encryption features at the 381 message level is liable to be incompatible with the HTTP caching 382 model and any attempt to implement caching is moot when TLS is in 383 use. 385 4.1. Request 387 The HTTP request MAY contain any valid HTTP header specified in 388 [RFC7230]. 390 Request Line URI /well-known/ 392 Request Line Method POST 394 Host: Header 396 Content-Encoding As specified in section yy below. 398 Content-Type As specified in section zz below. 400 Content-Length or Transfer-Encoding As specified in [RFC7230]. 402 Payload The content payload as specified in section XX below. 404 Example: The HTTP request for the mmm service in the previous example 405 would be: 407 POST /.well-known/mmm HTTP/1.1 408 Host: example.com 409 Content-Type: application/json 410 Content-Length: 16 412 { ?hello? : {} } 414 4.2. Response 416 The response MAY contain any HTTP response header. However since JWB 417 services do not make use of HTTP caching and messages are not 418 intended to be modified by HTTP intermediaries, only a limited number 419 of headers have significance. 421 Response Code The HTTP response code. This is processed as 422 described in section zz below. 424 Content-Type As specified in section zz below. 426 Content-Length or Transfer-Encoding As specified in [RFC7230]. 428 Cache-Control Since the only valid HTTP method for a JWB request 429 is POST, JWB responses are not cacheable. The use of the 430 cache-control header is therefore unnecessary. However 431 experience suggests that reviewers find it easier to understand 432 protocol specifications if they are reminded of the fact that 433 caching is neither supported nor desired. 435 Example: The HTTP response for the mmm service in the previous 436 example would be: 438 HTTP/1.1 200 OK 439 Content-Type: application/json 440 Connection: keep-alive 441 Cache-Control: no-store 442 Content-Length: 43 444 { ?hello-response? : { ?Version? : ?1.0? }} 446 5. Error handling and response codes 448 A JWB Web Service is effectively using a three layer protocol stack 449 with the potential for an error to occur at any of the three layers: 451 Transport Layer 453 HTTP Layer 455 Web Service Layer 457 Services SHOULD always attempt to return error codes at the highest 458 level possible. However it is clearly impossible for a connection 459 that is refused at the Transport layer to return an error code at the 460 HTTP layer. It is however possible for a HTTP layer error response 461 to contain a content body. 463 In the case that a JWB response contains both a HTTP response code 464 and a well formed JWB payload containing a response, the JWB payload 465 response SHALL have precedence. 467 6. Content Encoding 469 The HTTP Content-Encoding header specifies transformations performed 470 on the content before the HTTP Transfer encoding was applied. This 471 is commonly used for specifying compression. In JWB the Content- 472 Encoding header MAY be used to specify that the content that follows 473 contains a payload that is either authenticated [RFC7515] or 474 authenticated and encrypted [RFC7516] using the JOSE specification. 476 6.1. Direct Encoding 478 If the Content-Encoding header is absent or empty, the HTTP content 479 is the message payload as specified by the Content-Type header. 481 6.2. Content-Encoding: jose-jwb 483 The Content-Encoding type jose-jwb is a serialization format for JSON 484 Web Signature and JSON Web Encryption objects. Each message consists 485 of the following sequence: 487 Preamble: A JSON object in UTF-8 encoding 489 ASCII Record Separator Character (%x1E) 491 Payload 493 ASCII Record Separator Character (%x1E) 495 Postscript: A JSON object in UTF-8 encoding 497 The payload data consists of all the data that appears between the 498 first and the last occurrence of the record separator character %x1E 499 in the HTTP content. Since the UTF-8 encoding does not permit the 500 octet %0x1E to occur within a well formed JSON object, the use of 501 this character as a record separator is unambiguous even if the 502 character occurs within the payload (as is possible with a binary 503 content-type or if the payload is encrypted). 505 The contents of the Preamble, Payload and Postscript vary according 506 to whether the message is authenticated or authenticated and 507 encrypted. 509 6.3. Authenticated 511 Authenticated messages are signed using Jose Web Signature [RFC7515]. 512 The Preamble, Payload and Postscript are formed as follows: 514 Preamble A JSON Object containing the JWS Protected Header 516 Payload The binary data over which the signature value is 517 calculated 519 Postscript The JWS Signature header 521 Note that a jsoe-jwb message is only permitted to have a single 522 header and there is no provision for providing data that is not 523 integrity protected. 525 6.4. Authenticated Encryption 527 Authenticated messages are signed using Jose Web Signature [RFC7515]. 528 The Preamble, Payload and Postscript are formed as follows: 530 Preamble A JSON Object containing the JWS Protected Header 532 Payload The binary data over which the signature value is 533 calculated 535 Postscript The JWS Signature header 537 Note that a jsoe-jwb message is only permitted to have a single 538 header and there is no provision for providing data that is not 539 integrity protected. 541 7. Content Type 543 The Content Type header specifies the plaintext payload media type as 544 specified in [RFC6838]. 546 For version1.0 of this specification, the only supported payload 547 media type is application/json as specified in [RFC7159]. 549 Future versions of this specification may include support for binary 550 encodings such as JSON-B [draft-hallambaker-jsonbcd-05] and/or CBOR 551 [rfc7049]. 553 8. JSON Data Bindings 555 Note that this is the only part of this specification that is 556 strictly limited to JSON encoding. The rest of the specification is 557 equally applicable to Web Services using XML and/or CBOR encoding. 559 8.1. Request Message 561 Each JWBv1.0 request contains exactly one Web Service Command. 562 [Future versions MAY specify a mechanism that permits multiple 563 commands to be sent in parallel] 564 The request payload contains a JSON object that contains exactly one 565 member whose name is the name of the command that is requested and 566 whose value is an object that contains the command parameters (if 567 any). 569 { ?hello? : {} } 571 8.2. Response Message 573 The response payload contains a JSON object that contains the members 574 specified by the Web Service specification. 576 Future versions of this specification MAY reserve particular fields 577 in the response payload for particular purposes (e.g. returning 578 status values). 580 { ?hello-response? : { ?Version? : ?1.0? }} 582 8.3. Data Fields 584 JSON was originally developed to provide a serialization format for 585 the JavaScript programming language [ECMA-262]. While this approach 586 is generally applicable to the type systems of scripting programming 587 languages, it is less well matched to the richer type systems of 588 modern object oriented programming languages such as Java and C#. 589 Moreover 591 Working within a subset of the capabilities of JSON allows a Web 592 Service protocol to be accessed with equal ease from either platform 593 type. In particular the following capabilities of JSON are avoided: 595 The ability to use arbitrary strings as field names. 597 The use of JSON objects to define maps directly 599 The following data field types are used: 601 Integer Integer values are encoded as JSON number values. 603 String Test strings are encoded as JSON text strings. 605 Boolean Boolean values are encoded as JSON 'false', 'true' or 606 'null' tokens according to value. 608 Sequence Sequences of data items that are encoded as JSON arrays 609 Object of known type Objects whose type is known to the receiver 610 are encoded as JSON objects 612 Object of variable type Objects whose type is not known to the 613 receiver are encoded as JSON objects containing a single field 614 whose name describes the type of the object value and whose 615 value contains the value. 617 Binary Data Byte sequences are converted to BASE64-url encoding 618 [RFC4648] and encoded as JSON string values. 620 Date Time Date Time values are converted to Internet time format 621 as described in [RFC3339] and encoded as JSON string values. 623 9. Security Considerations 625 A fuller treatment of the security considerations will follow. 627 9.1. Integrity 629 9.1.1. DNS Spoofing 631 9.1.2. TLS Downgrade 633 9.1.3. TLS Service Impersonation 635 9.1.4. Request Replay Attack 637 9.1.5. Response Replay Attack 639 9.2. Confidentiality 641 9.2.1. Side Channel Attack 643 9.2.2. Session Key Leakage 645 10. IANA Considerations 647 The following registrations are required: 649 HTTP Content Coding Registry jose-jwb 651 Well-Known URIs /.well-known/srv/ 653 [Or change registry to FCFS] 655 11. References 657 11.1. Normative References 659 [RFC1035] Mockapetris, P., "Domain names - implementation and 660 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 661 November 1987. 663 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 664 Requirement Levels", BCP 14, RFC 2119, 665 DOI 10.17487/RFC2119, March 1997. 667 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 668 specifying the location of services (DNS SRV)", RFC 2782, 669 DOI 10.17487/RFC2782, February 2000. 671 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 672 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002. 674 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 675 Resource Identifier (URI): Generic Syntax", STD 66, 676 RFC 3986, DOI 10.17487/RFC3986, January 2005. 678 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 679 Rose, "DNS Security Introduction and Requirements", 680 RFC 4033, DOI 10.17487/RFC4033, March 2005. 682 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 683 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006. 685 [RFC5264] Niemi, A., Lonnfors, M., and E. Leppanen, "Publication of 686 Partial Presence Information", RFC 5264, 687 DOI 10.17487/RFC5264, September 2008. 689 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 690 Uniform Resource Identifiers (URIs)", RFC 5785, 691 DOI 10.17487/RFC5785, April 2010. 693 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 694 Specifications and Registration Procedures", BCP 13, 695 RFC 6838, DOI 10.17487/RFC6838, January 2013. 697 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 698 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 699 2014. 701 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 702 (HTTP/1.1): Message Syntax and Routing", RFC 7230, 703 DOI 10.17487/RFC7230, June 2014. 705 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 706 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 707 2015. 709 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 710 RFC 7516, DOI 10.17487/RFC7516, May 2015. 712 11.2. Informative References 714 [draft-hallambaker-jsonbcd-05] 715 "[Reference Not Found!]". 717 [ECMA-262] 718 "[Reference Not Found!]". 720 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 721 DOI 10.17487/RFC5322, October 2008. 723 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 724 of Named Entities (DANE) Transport Layer Security (TLS) 725 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 726 2012. 728 [RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 729 Protocol Version 2 (HTTP/2)", RFC 7540, 730 DOI 10.17487/RFC7540, May 2015. 732 Author's Address 734 Phillip Hallam-Baker 735 Comodo Group Inc. 737 Email: philliph@comodo.com