idnits 2.17.1 draft-ietf-oauth-proof-of-possession-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 28, 2015) is 3157 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) == Missing Reference: 'RFC 7519' is mentioned on line 642, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-08) exists of draft-ietf-oauth-pop-architecture-01 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group M. Jones 3 Internet-Draft Microsoft 4 Intended status: Standards Track J. Bradley 5 Expires: February 29, 2016 Ping Identity 6 H. Tschofenig 7 ARM Limited 8 August 28, 2015 10 Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) 11 draft-ietf-oauth-proof-of-possession-04 13 Abstract 15 This specification defines how to express a declaration in a JSON Web 16 Token (JWT) that the presenter of the JWT possesses a particular key 17 and that the recipient can cryptographically confirm proof-of- 18 possession of the key by the presenter. This property is also 19 sometimes described as the presenter being a holder-of-key. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 29, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Representations for Proof-of-Possession Keys . . . . . . . . . 4 59 3.1. Confirmation Claim . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Representation of an Asymmetric Proof-of-Possession Key . 5 61 3.3. Representation of an Encrypted Symmetric 62 Proof-of-Possession Key . . . . . . . . . . . . . . . . . 6 63 3.4. Representation of a Key ID for a Proof-of-Possession 64 Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.5. Representation of a URL for a Proof-of-Possession Key . . 8 66 3.6. Specifics Intentionally Not Specified . . . . . . . . . . 8 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 9 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 6.1. JSON Web Token Claims Registration . . . . . . . . . . . . 11 71 6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 11 72 6.2. JWT Confirmation Methods Registry . . . . . . . . . . . . 11 73 6.2.1. Registration Template . . . . . . . . . . . . . . . . 11 74 6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 12 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 77 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 79 Appendix B. Document History . . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 This specification defines how to express a declaration in a JSON Web 85 Token (JWT) [JWT] that the presenter of the JWT possesses a 86 particular key and that the recipient can cryptographically confirm 87 proof-of-possession of the key by the presenter. This property is 88 also sometimes described as the presenter being a holder-of-key. See 89 [I-D.ietf-oauth-pop-architecture] for a further discussion of key 90 confirmation. 92 Envision the following two use cases. The first use case describes 93 the use of a symmetric proof-of-possession key and the second use 94 case uses an asymmetric proof-of-possession key. 96 An issuer generates a JWT and places an encrypted symmetric key 97 inside the newly introduced confirmation claim. This symmetric key 98 is encrypted with a key known only to the issuer and the recipient. 99 The entire JWT is then integrity protected by the issuer. The JWT is 100 then sent to the presenter. Since the presenter is unable to obtain 101 the encrypted symmetric key from the JWT itself, the issuer conveys 102 that symmetric key separately to the presenter. Now, the presenter 103 is in possession of the symmetric key as well as the JWT (which 104 includes the confirmation claim member). When the presenter needs to 105 present the JWT to the recipient, it also needs to demonstrate 106 possession of the symmetric key; the presenter, for example, uses the 107 symmetric key in a challenge/response protocol with the recipient. 108 The recipient is then able to verify that it is interacting with the 109 genuine presenter by decrypting the JWK contained inside the 110 confirmation claim of the JWT. By doing this, the recipient obtains 111 the symmetric key, which it then uses to verify cryptographically 112 protected messages exchanged with the presenter. This symmetric key 113 mechanism described above is conceptually similar to the use of 114 Kerberos tickets. 116 In the second case, consider a presenter that generates a public/ 117 private key pair. It then sends the public key to an issuer, which 118 creates a JWT and places a public key (or an identifier for it) 119 inside the newly introduced confirmation claim. The entire JWT is 120 integrity protected using a digital signature to protect it against 121 modifications. The JWT is then sent to the presenter. When the 122 presenter needs to present the JWT to the recipient, it also needs to 123 demonstrate possession of the private key. The presenter, for 124 example, uses the private key in a TLS exchange with the recipient or 125 signs a nonce with the private key. The recipient is able to verify 126 that it is interacting with the genuine presenter by extracting the 127 public key from the confirmation claim of the JWT (after verifying 128 the digital signature of the JWT) and utilizing it with the private 129 key in the TLS exchange or checking the nonce signature. 131 In both cases, the JWT may contain other claims that are needed by 132 the application. 134 1.1. Notational Conventions 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in RFC 139 2119 [RFC2119]. 141 Unless otherwise noted, all the protocol parameter names and values 142 are case sensitive. 144 2. Terminology 146 This specification uses terms defined in the JSON Web Token (JWT) 147 [JWT], JSON Web Key (JWK) [JWK], and JSON Web Encryption (JWE) [JWE] 148 specifications. 150 These terms are defined by this specification: 152 Issuer 153 Party that creates the JWT and binds the proof-of-possession key 154 to it. 156 Presenter 157 Party that proves possession of a private key (for asymmetric key 158 cryptography) or secret key (for symmetric key cryptography) to a 159 recipient. 161 Recipient 162 Party that receives the JWT containing the proof-of-possession key 163 information from the presenter. 165 3. Representations for Proof-of-Possession Keys 167 The issuer of a JWT declares that the presenter possesses a 168 particular key and that the recipient can cryptographically confirm 169 proof-of-possession of the key by the presenter by including a "cnf" 170 (confirmation) claim in the JWT whose value is a JSON object. 171 Members in the JSON object identify the proof-of-possession key. 173 The presenter can be identified in one of several ways by the JWT, 174 depending upon the application requirements. If the JWT contains a 175 "sub" (subject) claim, the presenter is normally the subject 176 identified by the JWT. (In some applications, the subject identifier 177 will be relative to the issuer identified by the "iss" (issuer) 178 claim.) If the JWT contains no "sub" (subject) claim, the presenter 179 is normally the issuer identified by the JWT using the "iss" (issuer) 180 claim. The case in which the presenter is the subject of the JWT is 181 analogous to SAML 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation 182 usage. At least one of the "sub" and "iss" claims MUST be present in 183 the JWT. Some use cases may require that both be present. 185 Another means used by some applications to identify the presenter is 186 an explicit claim, such as the "azp" (authorized party) claim defined 187 by OpenID Connect [OpenID.Core]. Ultimately, the means of 188 identifying the presenter is application-specific, as is the means of 189 confirming possession of the key that is communicated. 191 3.1. Confirmation Claim 193 The "cnf" (confirmation) claim is used in the JWT to contain members 194 used to identify the proof-of-possession key. Other members of the 195 "cnf" object may be defined because a proof-of-possession key may not 196 be the only means of confirming the authenticity of the token. This 197 is analogous to the SAML 2.0 [OASIS.saml-core-2.0-os] 198 SubjectConfirmation element, in which a number of different subject 199 confirmation methods can be included, including proof-of-possession 200 key information. When a recipient receives a "cnf" claim with a 201 member that it does not understand, it MUST ignore that member. 203 This specification establishes the IANA "JWT Confirmation Methods" 204 registry for these members in Section 6.2 and registers the members 205 defined by this specification. Other specifications can register 206 other members used for confirmation, including other members for 207 conveying proof-of-possession keys, possibly using different key 208 representations. 210 Note that if an application needs to represent multiple proof-of- 211 possession keys in the same JWT, one way for it to achieve this is to 212 use other claim names, in addition to "cnf", to hold the additional 213 proof-of-possession key information. These claims could use the same 214 syntax and semantics as the "cnf" claim. 216 3.2. Representation of an Asymmetric Proof-of-Possession Key 218 When the key held by the presenter is an asymmetric private key, the 219 "jwk" member is a JSON Web Key (JWK) [JWK] representing the 220 corresponding asymmetric public key. The following example 221 demonstrates such a declaration in the JWT Claims Set of a JWT: 223 { 224 "iss": "https://server.example.com", 225 "aud": "https://client.example.org", 226 "exp": "1361398824", 227 "cnf":{ 228 "jwk":{ 229 "kty": "EC", 230 "use": "sig", 231 "crv": "P-256", 232 "x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM", 233 "y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA" 234 } 235 } 236 } 238 The JWK MUST contain the required key members for a JWK of that key 239 type and MAY contain other JWK members, including the "kid" (key ID) 240 member. 242 The "jwk" member MAY also be used for a JWK representing a symmetric 243 key, provided that the JWT is encrypted so that the key is not 244 revealed to unintended parties. If the JWT is not encrypted, the 245 symmetric key MUST be encrypted as described below. 247 3.3. Representation of an Encrypted Symmetric Proof-of-Possession Key 249 When the key held by the presenter is a symmetric key, the "jwe" 250 member is an encrypted JSON Web Key (JWK) [JWK] encrypted to a key 251 known to the recipient using the JWE Compact Serialization containing 252 the symmetric key. The rules for encrypting a JWK are found in 253 Section 7 of the JSON Web Key [JWK] specification. 255 The following example illustrates a symmetric key that could 256 subsequently be encrypted for use in the "jwe" member: 258 { 259 "kty": "oct", 260 "alg": "HS256", 261 "k": "ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE" 262 } 264 The UTF-8 [RFC3629] encoding of this JWK is used as the JWE Plaintext 265 when encrypting the key. 267 The following example is a JWE Header that could be used when 268 encrypting this key: 270 { 271 "alg": "RSA-OAEP", 272 "enc": "A128CBC-HS256" 273 } 275 The following example JWT Claims Set of a JWT illustrates the use of 276 an encrypted symmetric key as the "jwe" member value: 278 { 279 "iss": "https://server.example.com", 280 "sub": "24400320", 281 "aud": "s6BhdRkqt3", 282 "nonce": "n-0S6_WzA2Mj", 283 "exp": 1311281970, 284 "iat": 1311280970, 285 "cnf":{ 286 "jwe": 287 "eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ. 288 (remainder of JWE omitted for brevity)" 289 } 290 } 292 3.4. Representation of a Key ID for a Proof-of-Possession Key 294 The proof-of-possession key can also be identified by the use of a 295 Key ID instead of communicating the actual key, provided the 296 recipient is able to obtain the identified key using the Key ID. In 297 this case, the issuer of a JWT declares that the presenter possesses 298 a particular key and that the recipient can cryptographically confirm 299 proof-of-possession of the key by the presenter by including a "cnf" 300 (confirmation) claim in the JWT whose value is a JSON object, with 301 the JSON object containing a "kid" (key ID) member identifying the 302 key. 304 The following example demonstrates such a declaration in the JWT 305 Claims Set of a JWT: 307 { 308 "iss": "https://server.example.com", 309 "aud": "https://client.example.org", 310 "exp": "1361398824", 311 "cnf":{ 312 "kid": "dfd1aa97-6d8d-4575-a0fe-34b96de2bfad" 313 } 314 } 316 The content of the "kid" value is application specific. For 317 instance, some applications may choose to use a JWK Thumbprint 319 [JWK.Thumbprint] value as the "kid" value. 321 3.5. Representation of a URL for a Proof-of-Possession Key 323 The proof-of-possession key can be passed by reference instead of 324 being passed by value. This is done using the "jku" (JWK Set URL) 325 member. Its value is a URI [RFC3986] that refers to a resource for a 326 set of JSON-encoded public keys represented as a JWK Set [JWK], one 327 of which is the proof-of-possession key. If there are multiple keys 328 in the referenced JWK Set document, a "kid" member MUST also be 329 included, with the referenced key's JWK also containing the same 330 "kid" value. 332 The protocol used to acquire the resource MUST provide integrity 333 protection; an HTTP GET request to retrieve the JWK Set MUST use 334 Transport Layer Security (TLS) [RFC5246]; and the identity of the 335 server MUST be validated, as per Section 6 of RFC 6125 [RFC6125]. 337 The following example demonstrates such a declaration in the JWT 338 Claims Set of a JWT: 340 { 341 "iss": "https://server.example.com", 342 "sub": "17760704", 343 "aud": "https://client.example.org", 344 "exp": "1440804813", 345 "cnf":{ 346 "jku": "https://keys.example.net/pop-keys.json", 347 "kid": "2015-08-28" 348 } 349 } 351 3.6. Specifics Intentionally Not Specified 353 Proof-of-possession is typically demonstrated by having the presenter 354 sign a value determined by the recipient using the key possessed by 355 the presenter. This value is sometimes called a "nonce" or a 356 "challenge". 358 The means of communicating the nonce and the nature of its contents 359 are intentionally not described in this specification, as different 360 protocols will communicate this information in different ways. 361 Likewise, the means of communicating the signed nonce is also not 362 specified, as this is also protocol-specific. 364 Note that another means of proving possession of the key when it is a 365 symmetric key is to encrypt the key to the recipient. The means of 366 obtaining a key for the recipient is likewise protocol-specific. 368 For examples using the mechanisms defined in this specification, see 369 [I-D.ietf-oauth-pop-architecture]. 371 4. Security Considerations 373 All of the normal security issues, especially in relationship to 374 comparing URIs and dealing with unrecognized values, that are 375 discussed in JWT [JWT] also apply here. 377 In addition, proof-of-possession introduces its own unique security 378 issues. Possessing the key is only valuable if it is kept secret. 379 Appropriate means must be used to ensure that unintended parties do 380 not learn the private key or symmetric key value. 382 Proof-of-possession via encrypted symmetric secrets is subject to 383 replay attacks. This attack can be avoided when a signed nonce or 384 challenge is used, since the recipient can use a distinct nonce or 385 challenged for each interaction. 387 Similarly to other information included in a JWT, it is necessary to 388 apply data origin authentication and integrity protection (via a 389 keyed message digest or a digital signature). Data origin 390 authentication ensures that the recipient of the JWT learns about the 391 entity that created the JWT, since this will be important for any 392 policy decisions. Integrity protection prevents an adversary from 393 changing any elements conveyed within the JWT payload. Special care 394 has to be applied when carrying symmetric keys inside the JWT, since 395 those not only require integrity protection, but also confidentiality 396 protection. 398 A recipient may not understand the newly introduced "cnf" claim and 399 may consequently treat it as a bearer token. While this is a 400 legitimate concern, it is outside the scope of this specification, 401 since demonstration the possession of the key associated with the 402 "cnf" claim is not covered by this specification. For more details, 403 please consult [I-D.ietf-oauth-pop-architecture]. 405 5. Privacy Considerations 407 A proof-of-possession key can be used as a correlation handle if the 408 same key is used with multiple parties. Thus, for privacy reasons, 409 it is recommended that different proof-of-possession keys be used 410 when interacting with different parties. 412 6. IANA Considerations 414 The following registration procedure is used for all the registries 415 established by this specification. 417 Values are registered on a Specification Required [RFC5226] basis 418 after a three-week review period on the oauth-pop-reg-review@ietf.org 419 mailing list, on the advice of one or more Designated Experts. 420 However, to allow for the allocation of values prior to publication, 421 the Designated Experts may approve registration once they are 422 satisfied that such a specification will be published. [[ Note to the 423 RFC Editor: The name of the mailing list should be determined in 424 consultation with the IESG and IANA. Suggested name: 425 oauth-pop-reg-review@ietf.org. ]] 427 Registration requests sent to the mailing list for review should use 428 an appropriate subject (e.g., "Request to register JWT Confirmation 429 Method: example"). 431 Within the review period, the Designated Experts will either approve 432 or deny the registration request, communicating this decision to the 433 review list and IANA. Denials should include an explanation and, if 434 applicable, suggestions as to how to make the request successful. 435 Registration requests that are undetermined for a period longer than 436 21 days can be brought to the IESG's attention (using the 437 iesg@ietf.org mailing list) for resolution. 439 Criteria that should be applied by the Designated Experts includes 440 determining whether the proposed registration duplicates existing 441 functionality, determining whether it is likely to be of general 442 applicability or whether it is useful only for a single application, 443 and whether the registration makes sense. 445 IANA must only accept registry updates from the Designated Experts 446 and should direct all requests for registration to the review mailing 447 list. 449 It is suggested that multiple Designated Experts be appointed who are 450 able to represent the perspectives of different applications using 451 this specification, in order to enable broadly-informed review of 452 registration decisions. In cases where a registration decision could 453 be perceived as creating a conflict of interest for a particular 454 Expert, that Expert should defer to the judgment of the other 455 Experts. 457 6.1. JSON Web Token Claims Registration 459 This specification registers the "cnf" claim in the IANA "JSON Web 460 Token Claims" registry [IANA.JWT.Claims] established by [JWT]. 462 6.1.1. Registry Contents 464 o Claim Name: "cnf" 465 o Claim Description: Confirmation 466 o Change Controller: IESG 467 o Specification Document(s): Section 3.1 of [[ this document ]] 469 6.2. JWT Confirmation Methods Registry 471 This specification establishes the IANA "JWT Confirmation Methods" 472 registry for JWT "cnf" member values. The registry records the 473 confirmation method member and a reference to the specification that 474 defines it. 476 6.2.1. Registration Template 478 Confirmation Method Value: 479 The name requested (e.g., "kid"). Because a core goal of this 480 specification is for the resulting representations to be compact, 481 it is RECOMMENDED that the name be short -- not to exceed 8 482 characters without a compelling reason to do so. This name is 483 case-sensitive. Names may not match other registered names in a 484 case-insensitive manner unless the Designated Experts state that 485 there is a compelling reason to allow an exception. 487 Confirmation Method Description: 488 Brief description of the confirmation method (e.g., "Key 489 Identifier"). 491 Change Controller: 492 For Standards Track RFCs, list the "IESG". For others, give the 493 name of the responsible party. Other details (e.g., postal 494 address, email address, home page URI) may also be included. 496 Specification Document(s): 497 Reference to the document or documents that specify the parameter, 498 preferably including URIs that can be used to retrieve copies of 499 the documents. An indication of the relevant sections may also be 500 included but is not required. 502 6.2.2. Initial Registry Contents 504 o Confirmation Method Value: "jwk" 505 o Confirmation Method Description: JSON Web Key Representing Public 506 Key 507 o Change Controller: IESG 508 o Specification Document(s): Section 3.2 of [[ this document ]] 510 o Confirmation Method Value: "jwe" 511 o Confirmation Method Description: Encrypted JSON Web Key 512 o Change Controller: IESG 513 o Specification Document(s): Section 3.3 of [[ this document ]] 515 o Confirmation Method Value: "kid" 516 o Confirmation Method Description: Key Identifier 517 o Change Controller: IESG 518 o Specification Document(s): Section 3.4 of [[ this document ]] 520 o Confirmation Method Value: "jku" 521 o Confirmation Method Description: JWK Set URL 522 o Change Controller: IESG 523 o Specification Document(s): Section 3.5 of [[ this document ]] 525 7. References 527 7.1. Normative References 529 [IANA.JWT.Claims] 530 IANA, "JSON Web Token Claims", 531 . 533 [JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 534 RFC 7516, May 2015, 535 . 537 [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, May 2015, 538 . 540 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 541 (JWT)", RFC 7519, May 2015, 542 . 544 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 545 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 546 RFC2119, March 1997, 547 . 549 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 550 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, 551 November 2003, . 553 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 554 Resource Identifier (URI): Generic Syntax", STD 66, 555 RFC 3986, DOI 10.17487/RFC3986, January 2005, 556 . 558 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 559 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 560 DOI 10.17487/RFC5226, May 2008, 561 . 563 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 564 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 565 RFC5246, August 2008, 566 . 568 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 569 Verification of Domain-Based Application Service Identity 570 within Internet Public Key Infrastructure Using X.509 571 (PKIX) Certificates in the Context of Transport Layer 572 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, 573 March 2011, . 575 7.2. Informative References 577 [I-D.ietf-oauth-pop-architecture] 578 Hunt, P., Richer, J., Mills, W., Mishra, P., and H. 579 Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security 580 Architecture", draft-ietf-oauth-pop-architecture-01 (work 581 in progress), March 2015. 583 [JWK.Thumbprint] 584 Jones, M. and N. Sakimura, "JSON Web Key (JWK) 585 Thumbprint", draft-ietf-jose-jwk-thumbprint (work in 586 progress), July 2015, . 589 [OASIS.saml-core-2.0-os] 590 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 591 "Assertions and Protocol for the OASIS Security Assertion 592 Markup Language (SAML) V2.0", OASIS Standard saml-core- 593 2.0-os, March 2005. 595 [OpenID.Core] 596 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 597 C. Mortimore, "OpenID Connect Core 1.0", November 2014, 598 . 600 Appendix A. Acknowledgements 602 The authors wish to thank Brian Campbell, James Manger, Justin 603 Richer, and Nat Sakimura for their reviews of the specification. 605 Appendix B. Document History 607 [[ to be removed by the RFC Editor before publication as an RFC ]] 609 -04 611 o Allowed the use of "jwk" for symmetric keys when the JWT is 612 encrypted. 614 o Added the "jku" (JWK Set URL) member. 616 o Added privacy considerations. 618 o Reordered sections so that the "cnf" (confirmation) claim is 619 defined before it is used. 621 o Noted that applications can define new claim names, in addition to 622 "cnf", to represent additional proof-of-possession keys, using the 623 same representation as "cnf". 625 o Applied wording clarifications suggested by Nat Sakimura. 627 -03 629 o Separated the "jwk" and "jwe" confirmation members; the former 630 represents a public key as a JWK and the latter represents a 631 symmetric key as a JWE encrypted JWK. 633 o Changed the title to indicate that a proof-of-possession key is 634 being communicated. 636 o Updated language that formerly assumed that the issuer was an 637 OAuth 2.0 authorization server. 639 o Described ways that applications can choose to identify the 640 presenter, including use of the "iss", "sub", and "azp" claims. 642 o Harmonized the registry language with that used in JWT [RFC 7519]. 644 o Addressed other issues identified during working group last call. 646 o Referenced the JWT and JOSE RFCs. 648 -02 650 o Defined the terms Issuer, Presenter, and Recipient and updated 651 their usage within the document. 653 o Added a description of a use case using an asymmetric proof-of- 654 possession key to the introduction. 656 o Added the "kid" (key ID) confirmation method. 658 o These changes address the open issues identified in the previous 659 draft. 661 -01 663 o Updated references. 665 -00 667 o Created the initial working group draft from 668 draft-jones-oauth-proof-of-possession-02. 670 Authors' Addresses 672 Michael B. Jones 673 Microsoft 675 Email: mbj@microsoft.com 676 URI: http://self-issued.info/ 678 John Bradley 679 Ping Identity 681 Email: ve7jtb@ve7jtb.com 682 URI: http://www.thread-safe.com/ 683 Hannes Tschofenig 684 ARM Limited 685 Austria 687 Email: Hannes.Tschofenig@gmx.net 688 URI: http://www.tschofenig.priv.at