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