idnits 2.17.1 draft-ietf-jose-use-cases-04.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 15, 2013) is 3899 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5083' is defined on line 936, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-17 == Outdated reference: A later version (-40) exists of draft-ietf-jose-json-web-algorithms-14 == Outdated reference: A later version (-40) exists of draft-ietf-jose-json-web-encryption-14 == Outdated reference: A later version (-41) exists of draft-ietf-jose-json-web-key-14 == Outdated reference: A later version (-41) exists of draft-ietf-jose-json-web-signature-14 == Outdated reference: A later version (-07) exists of draft-ietf-lwig-terminology-05 == Outdated reference: A later version (-32) exists of draft-ietf-oauth-json-web-token-11 == Outdated reference: A later version (-12) exists of draft-ietf-oauth-jwt-bearer-06 == Outdated reference: A later version (-23) exists of draft-ietf-oauth-saml2-bearer-17 == Outdated reference: A later version (-07) exists of draft-miller-xmpp-e2e-06 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 JOSE R. Barnes 3 Internet-Draft BBN Technologies 4 Intended status: Informational August 15, 2013 5 Expires: February 16, 2014 7 Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) 8 draft-ietf-jose-use-cases-04 10 Abstract 12 Many Internet applications have a need for object-based security 13 mechanisms in addition to security mechanisms at the network layer or 14 transport layer. In the past, the Cryptographic Message Syntax (CMS) 15 has provided a binary secure object format based on ASN.1. Over 16 time, the use of binary object encodings such as ASN.1 has been 17 overtaken by text-based encodings, for example JavaScript Object 18 Notation. This document defines a set of use cases and requirements 19 for a secure object format encoded using JavaScript Object Notation 20 (JSON), drawn from a variety of application security mechanisms 21 currently in development. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 16, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Requirements on Application Protocols . . . . . . . . . . . . 6 61 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5.1. Security Tokens . . . . . . . . . . . . . . . . . . . . . 7 63 5.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.3. Federation . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5.4. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 5.5. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 5.6. Emergency Alerting . . . . . . . . . . . . . . . . . . . . 13 68 5.7. Web Cryptography . . . . . . . . . . . . . . . . . . . . . 14 69 5.8. Constrained Devices . . . . . . . . . . . . . . . . . . . 15 70 5.8.1. Example: MAC based on ECDH-derived key . . . . . . . . 16 71 5.8.2. Object security for CoAP . . . . . . . . . . . . . . . 17 72 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 6.1. Functional Requirements . . . . . . . . . . . . . . . . . 18 74 6.2. Security Requirements . . . . . . . . . . . . . . . . . . 19 75 6.3. Desiderata . . . . . . . . . . . . . . . . . . . . . . . . 20 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 81 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24 82 Appendix B. Document History . . . . . . . . . . . . . . . . . . 24 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 1. Introduction 87 Internet applications rest on the layered architecture of the 88 Internet, and take advantage of security mechanisms at all layers. 89 Many applications rely primarily on channel-based security 90 technologies such as IPsec and TLS, which create a secure channel at 91 the IP layer or transport layer over which application data can flow 92 [RFC4301][RFC5246]. These mechanisms, however, cannot provide end- 93 to-end security in some cases. For example, in protocols with 94 application-layer intermediaries, channel-based security protocols 95 would protect messages from attackers between intermediaries, but not 96 from the intermediaries themselves. These cases require object-based 97 security technologies, which embed application data within a secure 98 object that can be safely handled by untrusted entities. 100 The most well-known example of such a protocol today is the use of 101 Secure/Multipurpose Internet Mail Extensions (S/MIME) protections 102 within the email system [RFC5751][RFC5322]. An email message 103 typically passes through a series of intermediate Mail Transfer 104 Agents (MTAs) en route to its destination. While these MTAs often 105 apply channel-based security protections to their interactions (e.g., 106 STARTTLS [RFC3207]), these protections do not prevent the MTAs from 107 interfering with the message. In order to provide end-to-end 108 security protections in the presence of untrusted MTAs, mail users 109 can use S/MIME to embed message bodies in a secure object format that 110 can provide confidentiality, integrity, and data origin 111 authentication. 113 S/MIME is based on the Cryptographic Message Syntax for secure 114 objects (CMS) [RFC5652]. CMS is defined using Abstract Syntax 115 Notation 1 (ASN.1) and traditionally encoded using the ASN.1 116 Distinguished Encoding Rules (DER), which define a binary encoding of 117 the protected message and associated parameters [ITU.X690.2002]. In 118 recent years, usage of ASN.1 has decreased (along with other binary 119 encodings for general objects), while more applications have come to 120 rely on text-based formats such as the Extensible Markup Language 121 (XML) [W3C.REC-xml] or the JavaScript Object Notation (JSON) 122 [RFC4627]. 124 Many current applications thus have much more robust support for 125 processing objects in these text-based formats than ASN.1 objects; 126 indeed, many lack the ability to process ASN.1 objects at all. To 127 simplify the addition of object-based security features to these 128 applications, the IETF JSON Object Signing and Encryption (JOSE) 129 working group has been chartered to develop a secure object format 130 based on JSON. While the basic requirements for this object format 131 are straightforward -- namely, confidentiality and integrity 132 mechanisms, encoded in JSON -- discussions in the working group 133 indicated that different applications hoping to use the formats 134 defined by JOSE have different requirements. This document 135 summarizes the use cases for JOSE envisioned by those potential 136 applications and the resulting requirements for security mechanisms 137 and object encodings. 139 Some systems that use XML have specified the use of XML-based 140 security mechanisms for object security, namely XML Digital 141 Signatures and XML Encryption [W3C.xmldsig-core][W3C.xmlenc-core]. 142 These mechanisms are defined for use with several security token 143 systems (e.g., SAML [OASIS.saml-core-2.0-os] and WS-Federation 144 [WS-Federation]) and the CAP emergency alerting format [CAP]. In 145 practice, however, XML-based secure object formats introduce similar 146 levels of complexity to ASN.1, so developers that lack the tools or 147 motivation to handle ASN.1 aren't likely to use XML security either. 148 This situation motivates the creation of a JSON-based secure object 149 format that is simple enough to implement and deploy that it can be 150 easily adopted by developers with minimal effort and tools. 152 2. Definitions 154 This document makes extensive use of standard security terminology 155 [RFC4949]. In addition, because the use cases for JOSE and CMS are 156 similar, we will sometimes make analogies to some CMS concepts 157 [RFC5652]. 159 The JOSE working group charter calls for the group to define three 160 basic JSON object formats: 162 1. Confidentiality-protected object format 164 2. Integrity-protected object format 166 3. A format for expressing keys 168 In this document, we will refer to these as the "signed object 169 format", the "encrypted object format", and the "key format", 170 respectively. The JOSE working group items intended to describe 171 these formats are JSON Web Signature (JWS), JSON Web Encryption 172 (JWE), and JSON Web Key (JWK), respectively 173 [I-D.ietf-jose-json-web-signature] 174 [I-D.ietf-jose-json-web-encryption] [I-D.ietf-jose-json-web-key]. 175 Algorithms and algorithm identifiers used by JWS, JWE, and JWK are 176 defined in JSON Web Algorithms (JWA) 177 [I-D.ietf-jose-json-web-algorithms]. 179 In general, where there is no need to distinguish between asymmetric 180 and symmetric operations, we will use the terms "signing", 181 "signature", etc. to denote both true digital signatures involving 182 asymmetric cryptography as well as message authentication codes using 183 symmetric keys (MACs). 185 In the lifespan of a secure object, there are two basic roles, an 186 entity that creates the object (e.g., encrypting or signing a 187 payload), and an entity that uses the object (decrypting, verifying). 188 We will refer to these roles as "sender" and "recipient", 189 respectively. Note that while some requirements and use cases may 190 refer to these as single entities, each object may have multiple 191 entities in each role. For example, a message may be signed by 192 multiple senders, or decrypted by multiple recipients. 194 3. Basic Requirements 196 Obviously, for the encrypted and signed object formats, the necessary 197 protections will be created using appropriate cryptographic 198 mechanisms: symmetric or asymmetric encryption for confidentiality 199 and MACs or digital signatures for integrity protection. In both 200 cases, it is necessary for the JOSE format to support both symmetric 201 and asymmetric operations. 203 o The JOSE encrypted object format must support object encryption in 204 the case where the sender and receiver share a symmetric key. 206 o The JOSE encrypted object format must support object encryption in 207 the case where the sender has only a public key for the receiver. 209 o The JOSE signed object format must support integrity protection 210 using Message Authentication Codes (MACs), for the case where the 211 sender and receiver share only a symmetric key. 213 o The JOSE signed object format must support integrity protection 214 using digital signatures, for the case where the receiver has only 215 a public key for the sender. 217 In some applications, the key used to process a JOSE object is 218 indicated by application context, instead of directly in the JOSE 219 object. However, in order to avoid confusion, endpoints that lack 220 the necessary context need to be able to recognize this and fail 221 cleanly. Other than keys, JOSE objects do not support pre- 222 negotiation; all cryptographic parameters must be expressed directly 223 in the JOSE object. 225 o The JOSE signed and encrypted object formats must define the 226 process by which an implementation recognizes whether it has the 227 key required to process a given object, whether the key is 228 specified by the object or by some out-of-band mechanism. 230 o Each algorithm used for JOSE must define which parameters are 231 required to be present in a JOSE object using that algorithm. 233 In cases where two entities are going to be exchanging several JOSE 234 objects, it might be helpful to pre-negotiate some parameters so that 235 they do not have to be signaled in every JOSE object. However, so as 236 not to confuse endpoints that do not support pre-negotiation, it is 237 useful to signal when pre-negotiated parameters are in use in those 238 cases. 240 o It should be possible to extend the base JOSE signed and encrypted 241 object formats to indicate that pre-negotiated parameters are to 242 be used to process the object. This extension should also provide 243 a means of indicating of which parameters are to be used. 245 The purpose of the key format is to provide the recipient with 246 sufficient information to use the encoded key to process 247 cryptographic messages. Thus it is sometimes necessary to include 248 additional parameters along with the bare key. 250 o The JOSE key format must enable inclusion of all algorithm 251 parameters necessary to use the encoded key, including an 252 identifier for the algorithm with which the key is used as well as 253 any additional parameters required by the algorithm (e.g., 254 elliptic curve parameters). 256 4. Requirements on Application Protocols 258 The JOSE secure object formats describe how cryptographic processing 259 is done on secured content, ensuring that the recipient an object is 260 able to properly decrypt an encrypted object or verify a signature. 261 In order to make use of JOSE, however, applications will need to 262 specify several aspects of how JOSE is to be used: 264 o What application content is to be protected 266 o Which cryptographic algorithms are to be used 268 o How application protocol entities establish keys 270 o Whether keys are to be explicitly indicated in JOSE objects, or 271 associated by application context 273 o What serializations of JOSE objects are to be used 275 5. Use Cases 277 Several working groups developing application-layer protocols have 278 expressed a desire to use the JOSE data formats in their designs for 279 end-to-end security features. In this section, we summarize the use 280 cases proposed by these groups and discuss the requirements that they 281 imply for the JOSE object formats. 283 5.1. Security Tokens 285 Security tokens are a common use case for object-based security, for 286 example, SAML assertions [OASIS.saml-core-2.0-os]. Security tokens 287 are used to convey information about a subject entity ("claims" or 288 "assertions") from an issuer to a recipient. The security features 289 of a token format enable the recipient to verify that the claims came 290 from the issuer and, if the object is confidentiality-protected, that 291 they were not visible to other parties. 293 Security tokens are used in federation protocols such as SAML 2.0 294 [OASIS.saml-core-2.0-os], WS-Federation [WS-Federation], Mozilla 295 Persona [Persona], and OpenID Connect [OpenID.Messages], as well as 296 in resource authorization protocols such as OAuth 2.0 [RFC6749], 297 including for OAuth bearer tokens [RFC6750]. In some cases, security 298 tokens are used for client authentication and for access control 299 [I-D.ietf-oauth-jwt-bearer][I-D.ietf-oauth-saml2-bearer]. 301 JSON Web Token (JWT) [I-D.ietf-oauth-json-web-token] is a security 302 token format based on JSON and JOSE. It is used with Mozilla 303 Persona, OpenID Connect, and OAuth. Because JWTs are often used in 304 contexts with limited space (e.g., HTTP query parameters), it is a 305 core requirement for JWTs, and thus JOSE, to have a compact, URL-safe 306 representation. 308 5.2. OAuth 310 The OAuth protocol defines a mechanism for distributing and using 311 authorization tokens using HTTP [RFC6749]. A Client that wishes to 312 access a protected resource requests authorization from the Resource 313 Owner. If the Resource Owner allows this access, he directs an 314 Authorization Server to issue an access token to the Client. When 315 the Client wishes to access the protected resource, he presents the 316 token to the relevant Resource Server, which verifies the validity of 317 the token before providing access to the protected resource. 319 +---------------+ +---------------+ 320 | | | | 321 | Resource |<........>| Authorization | 322 | Server | | Server | 323 | | | | 324 +---------------+ +---------------+ 325 ^ | 326 | | 327 | | 328 | | 329 | | 330 +------------|--+ +--|------------+ 331 | +----------------+ | 332 | | | Resource | 333 | Client | | Owner | 334 | | | | 335 +---------------+ +---------------+ 337 Figure 1: The OAuth process 339 In effect, this process moves the token from the Authorization Server 340 (as a sender of the object) to the Resource Server (recipient), via 341 the Client as well as the Resource Owner (the latter because of the 342 HTTP mechanics underlying the protocol). So again we have a case 343 where an application object is transported via untrusted 344 intermediaries. 346 This application has two essential security requirements: Integrity 347 and data origin authentication. Integrity protection is required so 348 that the Resource Owner and the Client cannot modify the permission 349 encoded in the token. Although the Resource Owner is ultimately the 350 entity that grants authorization, it is not trusted to modify the 351 authorization token, since this could, for example, grant access to 352 resources not owned by the Resource Owner. 354 Data origin authentication is required so that the Resource Server 355 can verify that the token was issued by a trusted Authorization 356 Server. 358 Confidentiality protection may also be needed, if the Authorization 359 Server is concerned about the visibility of permissions information 360 to the Resource Owner or Client. For example, permissions related to 361 social networking might be considered private information. Note, 362 however, that OAuth already requires that the underlying HTTP 363 transactions be protected by TLS, so tokens are already 364 confidentiality-protected from entities other than the Resource Owner 365 and Client. 367 The confidentiality and integrity needs are met by the basic 368 requirements for signed and encrypted object formats, whether the 369 signing and encryption are provided using asymmetric or symmetric 370 cryptography. The choice of which mechanism is applied will depend 371 on the relationship between the two servers, namely whether they 372 share a symmetric key or only public keys. 374 Authentication requirements will also depend on deployment 375 characteristics. Where there is a relatively strong binding between 376 the resource server and the authorization server, it may suffice for 377 the Authorization Server issuing a token to be identified by the key 378 used to sign the token. This requires that the protocol carry either 379 the public key of the Authorization Server or an identifier for the 380 public or symmetric key. In OAuth, the "client_id" parameter 381 identifies the key to be used. 383 There may also be more advanced cases, where the Authorization 384 Server's key is not known in advance to the Resource Server. This 385 may happen, for instance, if an entity instantiated a collection of 386 Authorization Servers (say for load balancing), each of which has an 387 independent key pair. In these cases, it may be necessary to also 388 include a certificate or certificate chain for the Authorization 389 Server, so that the Resource Server can verify that the Authorization 390 Server is an entity that it trusts. 392 The HTTP transport for OAuth imposes a particular constraint on the 393 encoding. In the OAuth protocol, tokens frequently need to be passed 394 as query parameters in HTTP URIs [RFC2616], after having been 395 base64url encoded [RFC4648]. While there is no specified limit on 396 the length of URIs (and thus of query parameters), in practice, URIs 397 of more than 2,048 characters are rejected by some user agents. For 398 some mobile browsers, this limit is even smaller. So this use case 399 requires that a JOSE object have sufficiently small size even after 400 signing, possibly encrypting, while still being simple to include in 401 an HTTP URI query parameter. 403 5.3. Federation 405 Security tokens are used in two federated identity protocols, which 406 have similar requirements to the general considerations discussed 407 above: 409 o The OpenID Connect protocol [OpenID.Messages] is a simple, REST/ 410 JSON-based identity federation protocol layered on OAuth 2.0. It 411 uses the JWT and JOSE formats both to represent security tokens 412 and to provide security for other protocol messages (performing 413 signing and optionally encryption). OpenID Connect negotiates the 414 algorithms to be used and distributes information about the keys 415 to be used using protocol elements that are not part of the JWT 416 and JOSE header parameters. 418 o The Mozilla Persona [Persona] system is a simple single-sign-on 419 (SSO) protocol that uses JWTs that are signed JOSE JWS objects to 420 represent information about identities, applications, and keys for 421 participating entities. Persona distributes the keys used as 422 claims in JWT messages and not by using JOSE header parameters. 424 5.4. XMPP 426 The Extensible Messaging and Presence Protocol (XMPP) routes messages 427 from one end client to another by way of XMPP servers [RFC6120]. 428 There are typically two servers involved in delivering any given 429 message: The first client (Alice) sends a message for another client 430 (Bob) to her server (A). Server A uses Bob's identity and the DNS to 431 locate the server for Bob's domain (B), then delivers the message to 432 that server. Server B then routes the message to Bob. 434 +-------+ +----------+ +----------+ +-----+ 435 | Alice |-->| Server A |-->| Server B |-->| Bob | 436 +-------+ +----------+ +----------+ +-----+ 438 Figure 2: Delivering an XMPP message 440 The untrusted-intermediary problems are especially acute for XMPP 441 because in many current deployments, the holder of an XMPP domain 442 outsources the operation of the domain's servers to a different 443 entity. In this environment, there is a clear risk of exposing the 444 domain holder's private information to the domain operator. XMPP 445 already has a defined mechanism for end-to-end security using S/MIME, 446 but it has failed to gain widespread deployment [RFC3923], in part 447 because of key management challenges and because of the difficulty of 448 processing S/MIME objects. 450 The XMPP working group is in the process of developing a new end-to- 451 end encryption system with an encoding based on JOSE and a clearer 452 key management system [I-D.miller-xmpp-e2e]. The process of sending 453 an encrypted message in this system involves two steps: First, the 454 sender generates a symmetric Session Master Key (SMK), encrypts the 455 message content (including a per-message Content Master Key), and 456 sends the encrypted message to the desired set of recipients. 457 Second, each recipient "dials back" to the sender, providing his 458 public key. The sender then responds with the relevant SMK, wrapped 459 with the recipient's public key. 461 +-------+ +----------+ +----------+ +-----+ 462 | Alice |<->| Server A |<->| Server B |<->| Bob | 463 +-------+ +----------+ +----------+ +-----+ 464 | | | | 465 |------------Encrypted--message--------->| 466 | | | | 467 |<---------------Public-key--------------| 468 | | | | 469 |---------------Wrapped SMK------------->| 470 | | | | 472 Figure 3: Delivering a secure XMPP message 474 The main thing that this system requires from the JOSE formats is 475 confidentiality protection via content encryption, plus an integrity 476 check via a MAC derived from the same symmetric key. The separation 477 of the key exchange from the transmission of the encrypted content, 478 however, requires that the JOSE encrypted object format allow wrapped 479 symmetric keys to be carried separately from the encrypted payload. 480 In addition, the encrypted object will need to have a tag for the key 481 that was used to encrypt the content, so that the recipient (Bob) can 482 present the tag to the sender (Alice) when requesting the wrapped 483 key. 485 Another important feature of XMPP is that it allows for the 486 simultaneous delivery of a message to multiple recipients. In the 487 diagrams above, Server A could deliver the message not only to Server 488 B (for Bob) but also to Servers C, D, E, etc. for other users. In 489 such cases, to avoid the multiple "dial back" transactions implied by 490 the above mechanism, XMPP systems will likely re-use a given SMK for 491 multiple individual messages, refreshing the SMK on a periodic and/or 492 event-driven basis (e.g., when the recipient's presence changes). 493 They might also cache public keys for end recipients, so that wrapped 494 keys can be sent along with content on future messages. This implies 495 that the JOSE encrypted object format must support the provision of 496 multiple versions of the same wrapped SMK (much as a CMS 497 EnvelopedData structure can include multiple RecipientInfo 498 structures). 500 In the current draft of the XMPP end-to-end security system, each 501 party is authenticated by virtue of the other party's trust in the 502 XMPP message routing system. The sender is authenticated to the 503 receiver because he can receive messages for the identifier "Alice" 504 (in particular, the request for wrapped keys), and can originate 505 messages for that identifier (the wrapped key). Likewise, the 506 receiver is authenticated to the sender because he received the 507 original encrypted message and originated the request for wrapped 508 key. So the authentication here requires not only that XMPP routing 509 be done properly, but also that TLS be used on every hop. Moreover, 510 it requires that the TLS channels have strong authentication, since a 511 man in the middle on any of the three hops can masquerade as Bob and 512 obtain the key material for an encrypted message. 514 Because this authentication is quite weak (depending on the use of 515 transport-layer security on three hops) and unverifiable by the 516 endpoints, it is possible that the XMPP working group will integrate 517 some sort of credentials for end recipients, in which case there 518 would need to be a way to associate these credentials with JOSE 519 objects. 521 Finally, it's worth noting that XMPP is based on XML, not JSON. So 522 by using JOSE, XMPP will be carrying JSON objects within XML. It is 523 thus a desirable property for JOSE objects to be encoded in such a 524 way as to be safe for inclusion in XML. Otherwise, an explicit CDATA 525 indication must be given to the parser to indicate that it is not to 526 be parsed as XML. One way to meet this requirement would be to apply 527 base64url encoding, but for XMPP messages of medium-to-large size, 528 this could impose a fair degree of overhead. 530 5.5. ALTO 532 Application-Layer Traffic Optimization (ALTO) is a system for 533 distributing network topology information to end devices, so that 534 those devices can modify their behavior to have a lower impact on the 535 network [RFC6708]. The ALTO protocol distributes topology 536 information in the form of JSON objects carried in HTTP 537 [RFC2616][I-D.ietf-alto-protocol]. The basic version of ALTO is 538 simply a client-server protocol, so simple use of HTTPS suffices for 539 this case [RFC2818]. However, there is beginning to be some 540 discussion of use cases for ALTO in which these JSON objects will be 541 distributed through a collection of intermediate servers before 542 reaching the client, while still preserving the ability of the client 543 to authenticate the original source of the object. Even the base 544 ALTO protocol notes that "ALTO clients obtaining ALTO information 545 must be able to validate the received ALTO information to ensure that 546 it was generated by an appropriate ALTO server." 548 In this case, the security requirements are straightforward. JOSE 549 objects carrying ALTO payloads will need to bear digital signatures 550 from the originating servers, which will be bound to certificates 551 attesting to the identities of the servers. There is no requirement 552 for confidentiality in this case, since ALTO information is generally 553 public. 555 The more interesting questions are encoding questions. ALTO objects 556 are likely to be much larger than payloads in the two cases above, 557 with sizes of up to several megabytes. Processing of such large 558 objects can be done more quickly if it can be done in a single pass, 559 which may be possible if JOSE objects require specific orderings of 560 fields within the JSON structure. 562 In addition, because ALTO objects are also encoded as JSON, they are 563 already safe for inclusion in a JOSE object. Signed JOSE objects 564 will likely carry the signed data in a string alongside the 565 signature. JSON objects have the property that they can be safely 566 encoded in JSON strings. All they require is that unnecessary white 567 space be removed, a much simpler transformation than, say base64url 568 encoding. This raises the question of whether it might be possible 569 to optimize the JOSE encoding for certain "JSON-safe" cases. 571 Finally, it may be desirable for ALTO to have a "detached signature" 572 mechanism, that is, a way to encode signature information separate 573 from the protected content. This would allow the ALTO protocol to 574 include the signature in an HTTPS header, with the signed content as 575 the HTTPS entity body. 577 5.6. Emergency Alerting 579 Emergency alerting is an emerging use case for IP networks 580 [I-D.ietf-atoca-requirements]. Alerting systems allow authorities to 581 warn users of impending danger by sending alert messages to connected 582 devices. For example, in the event of hurricane or tornado, alerts 583 might be sent to all devices in the path of the storm. 585 The most critical security requirement for alerting systems is that 586 it must not be possible for an attacker to send false alerts to 587 devices. Such a capability would potentially allow an attacker to 588 create wide-spread panic. In practice, alert systems prevent these 589 attacks both by controls on sending messages at points where alerts 590 are originated, as well as by having recipients of alerts verify that 591 the alert was sent by an authorized source. The former type of 592 control implemented with local security on hosts from which alerts 593 can be originated. The latter type implemented by digital signatures 594 on alert messages (using channel-based or object-based mechanisms). 595 With an object-based mechanism, the signature value is encoded in a 596 secure object. With a channel-based mechanism, the alert is "signed" 597 by virtue of being sent over an authenticated, integrity-protected 598 channel. 600 Alerts typically reach end recipients via a series of intermediaries. 601 For example, while a national weather service might originate a 602 hurricane alert, it might first be delivered to a national gateway, 603 and then to network operators, who broadcast it to end subscribers. 605 +------------+ +------------+ +------------+ 606 | Originator | | Originator | | Originator | 607 +------------+ +------------+ +------------+ 608 | . . 609 +-----------------+.................. 610 | 611 V 612 +---------+ 613 | Gateway | 614 +---------+ 615 | 616 +------------+------------+ 617 | | 618 V V 619 +---------+ +---------+ 620 | Network | | Network | 621 +---------+ +---------+ 622 | | 623 +------+-----+ +------+-----+ 624 | | | | 625 V V V V 626 +--------+ +--------+ +--------+ +--------+ 627 | Device | | Device | | Device | | Device | 628 +--------+ +--------+ +--------+ +--------+ 630 Figure 4: Delivering an emergency alert 632 In order to verify alert signatures, recipients must be provisioned 633 with the proper public keys for trusted alert authorities. This 634 trust may be "piece-wise" along the path the alert takes. For 635 example, the alert relays operated by networks might have a full set 636 of certificates for all alert originators, while end devices may only 637 trust their local alert relay. Or devices might require that a 638 device be signed by an authorized originator and by its local 639 network's relay. 641 This scenario creates a need for multiple signatures on alert 642 documents, so that an alert can bear signatures from any or all of 643 the entities that processed it along the path. In order to minimize 644 complexity, these signatures should be "modular", in the sense that a 645 new signature can be added without a need to alter or recompute 646 previous signatures. 648 5.7. Web Cryptography 650 The W3C Web Cryptography API defines a standard cryptographic API for 651 the Web [WebCrypto]. If a browser exposes this API, then JavaScript 652 provided as part of a Web page can ask the browser to perform 653 cryptographic operations, such as digest, MAC, encryption, or digital 654 signing. 656 One of the key reasons to have the browser perform cryptographic 657 operations is to avoid allowing JavaScript code to access the keying 658 material used for these operations. For example, this separation 659 would prevent code injected through a cross-site scripting (XSS) 660 attack from reading and exfiltrating keys stored within a browser. 661 While the malicious code could still use the key while running in the 662 browser, this vulnerability can only be exercised while the 663 vulnerable page is active in a user's browser. 665 However, the WebCryptography API also provides a key export 666 functionality, which can allow JavaScript to extract a key from the 667 API in wrapped form. For example, the JavaScript might provide a 668 public key for which the corresponding private key is held by another 669 device. The wrapped key provided by the API could then be used to 670 safely transport the key to the new device. While this could 671 potentially allow malicious code to export a key, the need for an 672 explicit export operation provides a control point, allowing for user 673 notification or consent verification. 675 The Web Cryptography API also allows browsers to impose limitations 676 on the usage of the keys it handles. For example, a symmetric key 677 might be marked as usable only for encryption, and not for MAC. When 678 a key is exported in wrapped form, these attributes should be carried 679 along with it. 681 The Web Cryptography API thus requires formats to express several 682 forms of keys. Obviously, the public key from an asymmetric key pair 683 can be freely imported to and exported from the browser, so there 684 needs to be a format for public keys. There is also a need for a 685 format to express private keys and symmetric keys. For non-public 686 keys, the primary need is for a wrapped form, where the 687 confidentiality and integrity of the key is assured 688 cryptographically; these protections should also apply to any 689 attributes of the key. It may also be useful to define a direct, 690 unwrapped format, for use within a security boundary. 692 5.8. Constrained Devices 694 This section describes use cases for constrained devices as defined 695 in [I-D.ietf-lwig-terminology]. Typical issues with this type of 696 devices are limited memory, limited power supply, low processing 697 power, and severe message size limitations for the communication 698 protocols. 700 5.8.1. Example: MAC based on ECDH-derived key 702 Suppose a small, low power device maker has decided on using the 703 output of the JOSE working group as their encryption and 704 authentication framework. The device maker has a limited budget for 705 both gates and power. For this reason there are a number of short 706 cuts and design decisions that have been made in order to minimize 707 these needs. 709 The design team has determined that the use of message authentication 710 codes (MAC) is going to be sufficient to provide the necessary 711 authentication. However, although a MAC is going to be used, they do 712 not want to use a single long term shared secret. Instead they have 713 adopted the following proposal for computing a shared secret that can 714 be validated: 716 o An Elliptic-Curve Diffie-Hellman (ECDH) key is generated for the 717 device at the time of manufacturing. (Or as part of the 718 configuration process during installation.) 720 o An ECDH public key for the controller is configured at the time of 721 configuration. 723 o The configuration system performs the ECDH computation and 724 configures the device with the resulting shared secret. This 725 process eliminates the need for the device to be able to perform 726 the required exponentiation processing. The security requirements 727 on protecting this computed shared secret are the same as the 728 requirements on protecting the private ECDH key. 730 o A counter and an increment value are configured onto the device. 732 o When a message is to be sent by the device, the counter is 733 incremented and a new MAC key is computed from the ECDH secret and 734 the counter value. A custom Key Derivation Function (KDF) 735 function is used when is based on the AES-CBC is used to derive 736 the required MAC key. The MAC key is then used to compute the MAC 737 value for the message. 739 In a similar manner the KDF function can used to compute an AEAD 740 algorithm key when the system needs to provide confidentially for the 741 message. The controller, being a larger device will perform the 742 exponentiation step and use a random number generator to generate the 743 sender nonce value. 745 5.8.2. Object security for CoAP 747 This use case deals with constrained devices of class C0/C1 (see 748 [I-D.ietf-lwig-terminology]). These devices communicate using 749 RESTful requests and responses transferred using the CoAP protocol 750 [I-D.ietf-core-coap]. To simplify matters, all communication is 751 assumed to be unicast, i.e. these security measures don't cover 752 multicast or broadcast. 754 In this type of setting it may be too costly to use session based 755 security (e.g. to run a 4 pass authentication protocol) since 756 receiving and in particular sending consumes a lot of power, in 757 particular for wireless devices. Therefore to just secure the CoAP 758 payload by replacing a plain text payload of a request or response 759 with a JWE object is an important alternative solution, which allows 760 a trade-off between protection (the CoAP headers are not protected) 761 and performance. 763 In a simple setting, consider the payload of a CoAP GET response from 764 a sensor type device. The information in a sensor reading may be 765 privacy or business sensitive and needs both integrity protection and 766 encryption. 768 However some sensor readings are very short, say a few bytes, and in 769 this case default encryption and integrity protection algorithms 770 (such as 128 bit AES with HMAC_SHA256) may cause a dramatic message 771 expansion of the payload, even disregarding JWE headers. 773 Also the value of certain sensor readings may decline rapidly, e.g. 774 traffic or environmental measurements, so it must be possible to 775 reduce the security overhead. 777 This leads to the following requirements which could be covered by 778 specific JWE/JWS profiles: 780 o The size of the secure object shall be as small as possible. 781 Receiving an object may cost orders of magnitude more in terms of 782 power than performing say public key cryptography on the object, 783 in particular in a wireless setting. 785 o Integrity protection: The object shall be able to support 786 integrity protection, i.e. have a field containing a digital 787 signature, both public key signatures and keyed message 788 authentication codes shall be supported. 790 o Encryption: The object shall be able to support encryption as an 791 optional addition to integrity protection. It shall be possible 792 to exclude certain fields from encryption which are needed before 793 verifying integrity or decrypting the object. 795 o Cipher suites: It should be possible to support a variety of 796 cipher suites to support the constrained devices use cases. For 797 example: 799 * Block ciphers with block sizes of e.g. 96 bits, in addition to 800 the standard 128 bits 802 * Modes of operation for block ciphers that do not expand the 803 message size to a block boundary, such as AES-GCM. 805 * Cipher suites that support combined encryption and MAC 806 calculation (i.e., AEAD modes for block ciphers). 808 6. Requirements 810 This section summarizes the requirements from the above uses cases, 811 and lists further requirements not directly derived from the above 812 use cases. There are also some constraints that are not hard 813 requirements, but which are still desirable properties for the JOSE 814 system to have. 816 6.1. Functional Requirements 818 F1 Define formats for secure objects that provide the following 819 security properties: 821 * Digital signature (integrity/authentication under an asymmetric 822 key pair) 824 * Message authentication (integrity/authentication under a 825 symmetric key) 827 * Authenticated encryption 829 F2 Define a format for public keys and private keys for asymmetric 830 cryptographic algorithms, with associated attributes, including a 831 wrapped form for private keys. 833 F3 Define a format for symmetric keys with associated attributes, 834 allowing for both wrapped and unwrapped keys. 836 F4 Define a JSON serialization for each of the above objects. An 837 object in this encoding must be valid according to the JSON ABNF 838 syntax [RFC4627]. 840 F5 Define a compact, URL-safe text serialization for the encrypted 841 signed object formats. 843 F6 Allow for attributes associated to wrapped keys to be bound to 844 them cryptographically 846 F7 Allow for wrapped keys to be separated from a secure object that 847 uses a symmetric key. In such cases, cryptographic components of 848 the secure object other than the wrapped key (e.g., ciphertext, 849 MAC values) must be independent of the wrapped form of the key. 850 For example, if an encrypted object is prepared for multiple 851 recipients, then only the wrapped key may vary, not the 852 ciphertext. 854 F8 Do not impose more overhead than is required to meet the 855 requirements in this document, especially when a large amount of 856 application content is being protected. 858 6.2. Security Requirements 860 S1 Provide mechanisms to avoid repeated use of the same symmetric key 861 for encryption or MAC computation. Instead, long-lived keys 862 should be used only for key wrapping, not for direct encryption/ 863 MAC. It should be possible to use any of the key management 864 techniques provided in CMS [RFC5652]: 866 * Key transport (wrapping for a public key) 868 * Key encipherment (wrapping for a symmetric key) 870 * Key agreement (wrapping for a DH public key) 872 * Password-based encryption (wrapping under a key derived from a 873 password) 875 S2 Where long-lived symmetric keys are used directly for 876 cryptographic operations (i.e., where requirement S1 is not met), 877 provide deployment guidance on key management practices, such as 878 the need to limit key lifetimes. 880 S3 Use cryptographic algorithms in a manner compatible with major 881 validation processes. For example, if a FIPS standard allows 882 algorithm A to be used for purpose X but not purpose Y, then JOSE 883 should not recommend using algorithm A for purpose Y. 885 S4 Support operation with or without pre-negotiation. It must be 886 possible to create or process secure objects without any 887 configuration beyond key provisioning. If it is possible for keys 888 to be derived from application context, it must be possible for a 889 recipient to recognize when it does not have the appropriate key. 891 6.3. Desiderata 893 D1 Maximize compatibility with the W3C WebCrypto specifications, 894 e.g., by coordinating with the WebCrypto working group to 895 encourage alignment of algorithms and algorithm identifiers. 897 D2 Avoid JSON canonicalization to the extent possible. That is, all 898 other things being equal, techniques that rely on fixing a 899 serialization of an object (e.g., by base64url encoding it) are 900 preferred over those that require converting an object to a 901 canonical form. 903 D3 Maximize the extent to which the inputs and outputs of JOSE 904 cryptographic operations can be controlled by the applications, as 905 opposed to involving processing specific to JOSE. This allows 906 JOSE the flexibility to address the needs of many cryptographic 907 protocols. For example, in some cases, might allow JOSE objects 908 to be translated to legacy formats such as CMS without the need 909 for re-encryption or re-signing. 911 7. IANA Considerations 913 This document makes no request of IANA. 915 8. Security Considerations 917 The primary focus of this document is the requirements for a JSON- 918 based secure object format. At the level of general security 919 considerations for object-based security technologies, the security 920 considerations for this format are the same as for CMS [RFC5652]. 921 The primary difference between the JOSE format and CMS is that JOSE 922 is based on JSON, which does not have a canonical representation. 923 The lack of a canonical form means that it is difficult to determine 924 whether two JSON objects represent the same information, which could 925 lead to vulnerabilities in some usages of JOSE. 927 9. References 928 9.1. Normative References 930 [RFC4627] Crockford, D., "The application/json Media Type for 931 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 933 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 934 RFC 4949, August 2007. 936 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 937 Authenticated-Enveloped-Data Content Type", RFC 5083, 938 November 2007. 940 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 941 RFC 5652, September 2009. 943 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 944 Protocol (XMPP): Core", RFC 6120, March 2011. 946 [RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 947 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 948 Requirements", RFC 6708, September 2012. 950 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", 951 RFC 6749, October 2012. 953 [W3C.REC-xml] 954 Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, 955 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC- 956 xml, October 2000, . 958 [WebCrypto] 959 Sleevi, R. and D. Dahl, "Web Cryptography API", 960 January 2013. 962 9.2. Informative References 964 [CAP] Botterell, A. and E. Jones, "Common Alerting Protocol 965 v1.1", October 2005. 967 [I-D.ietf-alto-protocol] 968 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 969 draft-ietf-alto-protocol-17 (work in progress), July 2013. 971 [I-D.ietf-atoca-requirements] 972 Schulzrinne, H., Norreys, S., Rosen, B., and H. 973 Tschofenig, "Requirements, Terminology and Framework for 974 Exigent Communications", draft-ietf-atoca-requirements-03 975 (work in progress), March 2012. 977 [I-D.ietf-core-coap] 978 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 979 Application Protocol (CoAP)", draft-ietf-core-coap-18 980 (work in progress), June 2013. 982 [I-D.ietf-jose-json-web-algorithms] 983 Jones, M., "JSON Web Algorithms (JWA)", 984 draft-ietf-jose-json-web-algorithms-14 (work in progress), 985 July 2013. 987 [I-D.ietf-jose-json-web-encryption] 988 Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web 989 Encryption (JWE)", draft-ietf-jose-json-web-encryption-14 990 (work in progress), July 2013. 992 [I-D.ietf-jose-json-web-key] 993 Jones, M., "JSON Web Key (JWK)", 994 draft-ietf-jose-json-web-key-14 (work in progress), 995 July 2013. 997 [I-D.ietf-jose-json-web-signature] 998 Jones, M., Bradley, J., and N. Sakimura, "JSON Web 999 Signature (JWS)", draft-ietf-jose-json-web-signature-14 1000 (work in progress), July 2013. 1002 [I-D.ietf-lwig-terminology] 1003 Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1004 Constrained Node Networks", draft-ietf-lwig-terminology-05 1005 (work in progress), July 2013. 1007 [I-D.ietf-oauth-json-web-token] 1008 Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1009 (JWT)", draft-ietf-oauth-json-web-token-11 (work in 1010 progress), July 2013. 1012 [I-D.ietf-oauth-jwt-bearer] 1013 Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token 1014 (JWT) Profile for OAuth 2.0 Client Authentication and 1015 Authorization Grants", draft-ietf-oauth-jwt-bearer-06 1016 (work in progress), July 2013. 1018 [I-D.ietf-oauth-saml2-bearer] 1019 Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0 1020 Profile for OAuth 2.0 Client Authentication and 1021 Authorization Grants", draft-ietf-oauth-saml2-bearer-17 1022 (work in progress), July 2013. 1024 [I-D.miller-xmpp-e2e] 1025 Miller, M., "End-to-End Object Encryption and Signatures 1026 for the Extensible Messaging and Presence Protocol 1027 (XMPP)", draft-miller-xmpp-e2e-06 (work in progress), 1028 June 2013. 1030 [ITU.X690.2002] 1031 International Telecommunications Union, "Information 1032 Technology - ASN.1 encoding rules: Specification of Basic 1033 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1034 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1035 X.690, 2002. 1037 [OASIS.saml-core-2.0-os] 1038 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1039 "Assertions and Protocol for the OASIS Security Assertion 1040 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1041 2.0-os, March 2005. 1043 [OpenID.Messages] 1044 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., 1045 Mortimore, C., and E. Jay, "OpenID Connect Messages 1.0", 1046 May 2013, 1047 . 1050 [Persona] Mozilla, "Mozilla Persona", April 2013. 1052 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1053 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1054 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1056 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1058 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 1059 Transport Layer Security", RFC 3207, February 2002. 1061 [RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption 1062 for the Extensible Messaging and Presence Protocol 1063 (XMPP)", RFC 3923, October 2004. 1065 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1066 Internet Protocol", RFC 4301, December 2005. 1068 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1069 Encodings", RFC 4648, October 2006. 1071 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1072 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1074 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1075 October 2008. 1077 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1078 Mail Extensions (S/MIME) Version 3.2 Message 1079 Specification", RFC 5751, January 2010. 1081 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 1082 Framework: Bearer Token Usage", RFC 6750, October 2012. 1084 [W3C.xmldsig-core] 1085 Eastlake, D., Reagle , J., and D. Solo, "XML-Signature 1086 Syntax and Processing", W3C Recommendation xmldsig-core, 1087 October 2000, . 1089 [W3C.xmlenc-core] 1090 Eastlake, D. and J. Reagle , "XML Encryption Syntax and 1091 Processing", W3C Candidate Recommendation xmlenc-core, 1092 August 2002, . 1094 [WS-Federation] 1095 Kaler, C., McIntosh, M., Goodner, M., and A. Nadalin, "Web 1096 Services Federation Language (WS-Federation) Version 1.2", 1097 May 2009, . 1100 Appendix A. Acknowledgements 1102 Thanks to Matt Miller for discussions related to XMPP end-to-end 1103 security model, and to Mike Jones for considerations related to 1104 security tokens and XML security. Thanks to Mark Watson for raising 1105 the need for representing symmetric keys and binding attributes to 1106 them. Thanks to Ludwig Seitz for contributing the constrained device 1107 use case. 1109 Appendix B. Document History 1111 [[ to be removed by the RFC editor before publication as an RFC ]] 1113 -03 1115 o Replaced the "small device" case with the "constrained device" 1116 case 1118 o Added S2 to cover cases where the WG decides not to implement S1 1119 o Addressed multiple other WGLC comments 1121 -02 1123 o Referenced the JWS, JWE, JWK, and JWA specifications making the 1124 "signed object format", "encrypted object format", "key format", 1125 and algorithms resulting from these use cases concrete. 1127 o Added "Requirements on Application Protocols" section. 1129 o Broke former huge "Security Tokens and Authorization" Use Case 1130 section into "Security Tokens", "OAuth", and "Federation" Use Case 1131 sections. 1133 o Cited Mozilla Persona as a single-sign-on (SSO) system using JWTs 1134 and JOSE data formats. 1136 o Spelling and grammar corrections. 1138 -01 1140 o Added the "Small Devices" use case 1142 -00 1144 o Created the initial IETF draft based upon 1145 draft-barnes-jose-use-cases-01 with some additions. 1147 Author's Address 1149 Richard Barnes 1150 BBN Technologies 1151 1300 N 17th St 1152 Arlington, VA 22209 1153 US 1155 Email: rlb@ipv.sx