summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7800.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7800.txt')
-rw-r--r--doc/rfc/rfc7800.txt843
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc7800.txt b/doc/rfc/rfc7800.txt
new file mode 100644
index 0000000..4ace977
--- /dev/null
+++ b/doc/rfc/rfc7800.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Jones
+Request for Comments: 7800 Microsoft
+Category: Standards Track J. Bradley
+ISSN: 2070-1721 Ping Identity
+ H. Tschofenig
+ ARM Limited
+ April 2016
+
+
+ Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
+
+Abstract
+
+ This specification describes how to declare in a JSON Web Token (JWT)
+ that the presenter of the JWT possesses a particular proof-of-
+ possession key and how the recipient can cryptographically confirm
+ proof of possession of the key by the presenter. Being able to prove
+ possession of a key is also sometimes described as the presenter
+ being a holder-of-key.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7800.
+
+Copyright Notice
+
+ Copyright (c) 2016 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+Jones, et al. Standards Track [Page 1]
+
+RFC 7800 Proof-of-Possession Key for JWTs April 2016
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 5
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Representations for Proof-of-Possession Keys . . . . . . . . 5
+ 3.1. Confirmation Claim . . . . . . . . . . . . . . . . . . . 6
+ 3.2. Representation of an Asymmetric Proof-of-Possession Key . 7
+ 3.3. Representation of an Encrypted Symmetric Proof-of-
+ Possession Key . . . . . . . . . . . . . . . . . . . . . 7
+ 3.4. Representation of a Key ID for a Proof-of-Possession Key 8
+ 3.5. Representation of a URL for a Proof-of-Possession Key . . 9
+ 3.6. Specifics Intentionally Not Specified . . . . . . . . . . 10
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
+ 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
+ 6.1. JSON Web Token Claims Registration . . . . . . . . . . . 12
+ 6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 12
+ 6.2. JWT Confirmation Methods Registry . . . . . . . . . . . . 12
+ 6.2.1. Registration Template . . . . . . . . . . . . . . . . 12
+ 6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 13
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . 13
+ 7.2. Informative References . . . . . . . . . . . . . . . . . 14
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
+
+1. Introduction
+
+ This specification describes how a JSON Web Token [JWT] can declare
+ that the presenter of the JWT possesses a particular proof-of-
+ possession (PoP) key and how the recipient can cryptographically
+ confirm proof of possession of the key by the presenter. Proof of
+ possession of a key is also sometimes described as the presenter
+ being a holder-of-key. The [OAUTH-POP-ARCH] specification describes
+ key confirmation, among other confirmation mechanisms. This
+ specification defines how to communicate confirmation key information
+ in JWTs.
+
+ Envision the following two use cases. The first use case employs a
+ symmetric proof-of-possession key and the second use case employs an
+ asymmetric proof-of-possession key.
+
+
+
+
+
+
+
+
+
+Jones, et al. Standards Track [Page 2]
+
+RFC 7800 Proof-of-Possession Key for JWTs April 2016
+
+
+ +--------------+
+ | | +--------------+
+ | |--(3) Presentation of -->| |
+ | | JWT w/ Encrypted | |
+ | Presenter | PoP Key | |
+ | | | |
+ | |<-(4) Communication ---->| |
+ | | Authenticated by | |
+ +--------------+ PoP Key | |
+ ^ ^ | |
+ | | | |
+ (1) Sym. (2) JWT w/ | Recipient |
+ | PoP | Encrypted | |
+ | Key | PoP Key | |
+ v | | |
+ +--------------+ | |
+ | | | |
+ | | | |
+ | |<-(0) Key Exchange for ->| |
+ | Issuer | Key Encryption Key | |
+ | | | |
+ | | | |
+ | | +--------------+
+ +--------------+
+
+ Figure 1: Proof of Possession with a Symmetric Key
+
+ In the case illustrated in Figure 1, (1) either the presenter
+ generates a symmetric key and privately sends it to the issuer or the
+ issuer generates a symmetric key and privately sends it to the
+ presenter. The issuer generates a JWT with an encrypted copy of this
+ symmetric key in the confirmation claim. This symmetric key is
+ encrypted with a key known only to the issuer and the recipient,
+ which was previously established in step (0). The entire JWT is
+ integrity protected by the issuer. The JWT is then (2) sent to the
+ presenter. Now, the presenter is in possession of the symmetric key
+ as well as the JWT (which includes the confirmation claim). When the
+ presenter (3) presents the JWT to the recipient, it also needs to
+ demonstrate possession of the symmetric key; the presenter, for
+ example, (4) uses the symmetric key in a challenge/response protocol
+ with the recipient. The recipient is then able to verify that it is
+ interacting with the genuine presenter by decrypting the key in the
+ confirmation claim of the JWT. By doing this, the recipient obtains
+ the symmetric key, which it then uses to verify cryptographically
+ protected messages exchanged with the presenter (4). This symmetric
+ key mechanism described above is conceptually similar to the use of
+ Kerberos tickets.
+
+
+
+
+Jones, et al. Standards Track [Page 3]
+
+RFC 7800 Proof-of-Possession Key for JWTs April 2016
+
+
+ Note that for simplicity, the diagram above and associated text
+ describe the direct use of symmetric keys without the use of derived
+ keys. A more secure practice is to derive the symmetric keys
+ actually used from secrets exchanged, such as the key exchanged in
+ step (0), using a Key Derivation Function (KDF) and use the derived
+ keys, rather than directly using the secrets exchanged.
+
+ +--------------+
+ | | +--------------+
+ | |--(3) Presentation of -->| |
+ | | JWT w/ Public | |
+ | Presenter | PoP Key | |
+ | | | |
+ | |<-(4) Communication ---->| |
+ | | Authenticated by | |
+ +--------------+ PoP Key | |
+ | ^ | |
+ | | | |
+ (1) Public (2) JWT w/ | Recipient |
+ | PoP | Public | |
+ | Key | PoP Key | |
+ v | | |
+ +--------------+ | |
+ | | | |
+ | | | |
+ | | | |
+ | Issuer | | |
+ | | | |
+ | | | |
+ | | +--------------+
+ +--------------+
+
+ Figure 2: Proof of Possession with an Asymmetric Key
+
+ In the case illustrated in Figure 2, the presenter generates a
+ public/private key pair and (1) sends the public key to the issuer,
+ which creates a JWT that contains the public key (or an identifier
+ for it) in the confirmation claim. The entire JWT is integrity
+ protected using a digital signature to protect it against
+ modifications. The JWT is then (2) sent to the presenter. When the
+ presenter (3) presents the JWT to the recipient, it also needs to
+ demonstrate possession of the private key. The presenter, for
+ example, (4) uses the private key in a Transport Layer Security (TLS)
+ exchange with the recipient or (4) signs a nonce with the private
+ key. The recipient is able to verify that it is interacting with the
+ genuine presenter by extracting the public key from the confirmation
+ claim of the JWT (after verifying the digital signature of the JWT)
+
+
+
+
+Jones, et al. Standards Track [Page 4]
+
+RFC 7800 Proof-of-Possession Key for JWTs April 2016
+
+
+ and utilizing it with the private key in the TLS exchange or by
+ checking the nonce signature.
+
+ In both cases, the JWT may contain other claims that are needed by
+ the application.
+
+1.1. Notational Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in RFC
+ 2119 [RFC2119].
+
+ Unless otherwise noted, all the protocol parameter names and values
+ are case sensitive.
+
+2. Terminology
+
+ This specification uses terms defined in the JSON Web Token [JWT],
+ JSON Web Key [JWK], and JSON Web Encryption [JWE] specifications.
+
+ These terms are defined by this specification:
+
+ Issuer
+ Party that creates the JWT and binds the proof-of-possession key
+ to it.
+
+ Presenter
+ Party that proves possession of a private key (for asymmetric key
+ cryptography) or secret key (for symmetric key cryptography) to a
+ recipient.
+
+ Recipient
+ Party that receives the JWT containing the proof-of-possession key
+ information from the presenter.
+
+3. Representations for Proof-of-Possession Keys
+
+ By including a "cnf" (confirmation) claim in a JWT, the issuer of the
+ JWT declares that the presenter possesses a particular key and that
+ the recipient can cryptographically confirm that the presenter has
+ possession of that key. The value of the "cnf" claim is a JSON
+ object and the members of that object identify the proof-of-
+ possession key.
+
+ The presenter can be identified in one of several ways by the JWT
+ depending upon the application requirements. If the JWT contains a
+ "sub" (subject) claim [JWT], the presenter is normally the subject
+
+
+
+Jones, et al. Standards Track [Page 5]
+
+RFC 7800 Proof-of-Possession Key for JWTs April 2016
+
+
+ identified by the JWT. (In some applications, the subject identifier
+ will be relative to the issuer identified by the "iss" (issuer) claim
+ [JWT].) If the JWT contains no "sub" claim, the presenter is
+ normally the issuer identified by the JWT using the "iss" claim. The
+ case in which the presenter is the subject of the JWT is analogous to
+ Security Assertion Markup Language (SAML) 2.0
+ [OASIS.saml-core-2.0-os] SubjectConfirmation usage. At least one of
+ the "sub" and "iss" claims MUST be present in the JWT. Some use
+ cases may require that both be present.
+
+ Another means used by some applications to identify the presenter is
+ an explicit claim, such as the "azp" (authorized party) claim defined
+ by OpenID Connect [OpenID.Core]. Ultimately, the means of
+ identifying the presenter is application specific, as is the means of
+ confirming possession of the key that is communicated.
+
+3.1. Confirmation Claim
+
+ The "cnf" claim is used in the JWT to contain members used to
+ identify the proof-of-possession key. Other members of the "cnf"
+ object may be defined because a proof-of-possession key may not be
+ the only means of confirming the authenticity of the token. This is
+ analogous to the SAML 2.0 [OASIS.saml-core-2.0-os]
+ SubjectConfirmation element in which a number of different subject
+ confirmation methods can be included (including proof-of-possession
+ key information).
+
+ The set of confirmation members that a JWT must contain to be
+ considered valid is context dependent and is outside the scope of
+ this specification. Specific applications of JWTs will require
+ implementations to understand and process some confirmation members
+ in particular ways. However, in the absence of such requirements,
+ all confirmation members that are not understood by implementations
+ MUST be ignored.
+
+ This specification establishes the IANA "JWT Confirmation Methods"
+ registry for these members in Section 6.2 and registers the members
+ defined by this specification. Other specifications can register
+ other members used for confirmation, including other members for
+ conveying proof-of-possession keys using different key
+ representations.
+
+ The "cnf" claim value MUST represent only a single proof-of-
+ possession key; thus, at most one of the "jwk", "jwe", and "jku" (JWK
+ Set URL) confirmation values defined below may be present. Note that
+ if an application needs to represent multiple proof-of-possession
+ keys in the same JWT, one way for it to achieve this is to use other
+ claim names, in addition to "cnf", to hold the additional proof-of-
+
+
+
+Jones, et al. Standards Track [Page 6]
+
+RFC 7800 Proof-of-Possession Key for JWTs April 2016
+
+
+ possession key information. These claims could use the same syntax
+ and semantics as the "cnf" claim. Those claims would be defined by
+ applications or other specifications and could be registered in the
+ IANA "JSON Web Token Claims" registry [IANA.JWT.Claims].
+
+3.2. Representation of an Asymmetric Proof-of-Possession Key
+
+ When the key held by the presenter is an asymmetric private key, the
+ "jwk" member is a JSON Web Key [JWK] representing the corresponding
+ asymmetric public key. The following example demonstrates such a
+ declaration in the JWT Claims Set of a JWT:
+
+ {
+ "iss": "https://server.example.com",
+ "aud": "https://client.example.org",
+ "exp": 1361398824,
+ "cnf":{
+ "jwk":{
+ "kty": "EC",
+ "use": "sig",
+ "crv": "P-256",
+ "x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",
+ "y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA"
+ }
+ }
+ }
+
+ The JWK MUST contain the required key members for a JWK of that key
+ type and MAY contain other JWK members, including the "kid" (Key ID)
+ member.
+
+ The "jwk" member MAY also be used for a JWK representing a symmetric
+ key, provided that the JWT is encrypted so that the key is not
+ revealed to unintended parties. The means of encrypting a JWT is
+ explained in [JWT]. If the JWT is not encrypted, the symmetric key
+ MUST be encrypted as described below.
+
+3.3. Representation of an Encrypted Symmetric Proof-of-Possession Key
+
+ When the key held by the presenter is a symmetric key, the "jwe"
+ member is an encrypted JSON Web Key [JWK] encrypted to a key known to
+ the recipient using the JWE Compact Serialization containing the
+ symmetric key. The rules for encrypting a JWK are found in Section 7
+ of the JSON Web Key [JWK] specification.
+
+
+
+
+
+
+
+Jones, et al. Standards Track [Page 7]
+
+RFC 7800 Proof-of-Possession Key for JWTs April 2016
+
+
+ The following example illustrates a symmetric key that could
+ subsequently be encrypted for use in the "jwe" member:
+
+ {
+ "kty": "oct",
+ "alg": "HS256",
+ "k": "ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE"
+ }
+
+ The UTF-8 [RFC3629] encoding of this JWK is used as the JWE Plaintext
+ when encrypting the key.
+
+ The following example is a JWE Header that could be used when
+ encrypting this key:
+
+ {
+ "alg": "RSA-OAEP",
+ "enc": "A128CBC-HS256"
+ }
+
+ The following example JWT Claims Set of a JWT illustrates the use of
+ an encrypted symmetric key as the "jwe" member value:
+
+ {
+ "iss": "https://server.example.com",
+ "sub": "24400320",
+ "aud": "s6BhdRkqt3",
+ "nonce": "n-0S6_WzA2Mj",
+ "exp": 1311281970,
+ "iat": 1311280970,
+ "cnf":{
+ "jwe":
+ "eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ.
+ (remainder of JWE omitted for brevity)"
+ }
+ }
+
+3.4. Representation of a Key ID for a Proof-of-Possession Key
+
+ The proof-of-possession key can also be identified by the use of a
+ Key ID instead of communicating the actual key, provided the
+ recipient is able to obtain the identified key using the Key ID. In
+ this case, the issuer of a JWT declares that the presenter possesses
+ a particular key and that the recipient can cryptographically confirm
+ proof of possession of the key by the presenter by including a "cnf"
+ claim in the JWT whose value is a JSON object with the JSON object
+ containing a "kid" member identifying the key.
+
+
+
+
+Jones, et al. Standards Track [Page 8]
+
+RFC 7800 Proof-of-Possession Key for JWTs April 2016
+
+
+ The following example demonstrates such a declaration in the JWT
+ Claims Set of a JWT:
+
+ {
+ "iss": "https://server.example.com",
+ "aud": "https://client.example.org",
+ "exp": 1361398824,
+ "cnf":{
+ "kid": "dfd1aa97-6d8d-4575-a0fe-34b96de2bfad"
+ }
+ }
+
+ The content of the "kid" value is application specific. For
+ instance, some applications may choose to use a JWK Thumbprint
+ [JWK.Thumbprint] value as the "kid" value.
+
+3.5. Representation of a URL for a Proof-of-Possession Key
+
+ The proof-of-possession key can be passed by reference instead of
+ being passed by value. This is done using the "jku" member. Its
+ value is a URI [RFC3986] that refers to a resource for a set of JSON-
+ encoded public keys represented as a JWK Set [JWK], one of which is
+ the proof-of-possession key. If there are multiple keys in the
+ referenced JWK Set document, a "kid" member MUST also be included
+ with the referenced key's JWK also containing the same "kid" value.
+
+ The protocol used to acquire the resource MUST provide integrity
+ protection. An HTTP GET request to retrieve the JWK Set MUST use TLS
+ [RFC5246] and the identity of the server MUST be validated, as per
+ Section 6 of RFC 6125 [RFC6125].
+
+ The following example demonstrates such a declaration in the JWT
+ Claims Set of a JWT:
+
+ {
+ "iss": "https://server.example.com",
+ "sub": "17760704",
+ "aud": "https://client.example.org",
+ "exp": 1440804813,
+ "cnf":{
+ "jku": "https://keys.example.net/pop-keys.json",
+ "kid": "2015-08-28"
+ }
+ }
+
+
+
+
+
+
+
+Jones, et al. Standards Track [Page 9]
+
+RFC 7800 Proof-of-Possession Key for JWTs April 2016
+
+
+3.6. Specifics Intentionally Not Specified
+
+ Proof of possession is typically demonstrated by having the presenter
+ sign a value determined by the recipient using the key possessed by
+ the presenter. This value is sometimes called a "nonce" or a
+ "challenge".
+
+ The means of communicating the nonce and the nature of its contents
+ are intentionally not described in this specification, as different
+ protocols will communicate this information in different ways.
+ Likewise, the means of communicating the signed nonce is also not
+ specified, as this is also protocol specific.
+
+ Note that another means of proving possession of the key when it is a
+ symmetric key is to encrypt the key to the recipient. The means of
+ obtaining a key for the recipient is likewise protocol specific.
+
+ For examples using the mechanisms defined in this specification, see
+ [OAUTH-POP-ARCH].
+
+4. Security Considerations
+
+ All of the security considerations that are discussed in [JWT] also
+ apply here. In addition, proof of possession introduces its own
+ unique security issues. Possessing a key is only valuable if it is
+ kept secret. Appropriate means must be used to ensure that
+ unintended parties do not learn private key or symmetric key values.
+
+ Applications utilizing proof of possession should also utilize
+ audience restriction, as described in Section 4.1.3 of [JWT], as it
+ provides different protections. Proof of possession can be used by
+ recipients to reject messages from unauthorized senders. Audience
+ restriction can be used by recipients to reject messages intended for
+ different recipients.
+
+ A recipient might not understand the "cnf" claim. Applications that
+ require the proof-of-possession keys communicated with it to be
+ understood and processed must ensure that the parts of this
+ specification that they use are implemented.
+
+ Proof of possession via encrypted symmetric secrets is subject to
+ replay attacks. This attack can, for example, be avoided when a
+ signed nonce or challenge is used since the recipient can use a
+ distinct nonce or challenge for each interaction. Replay can also be
+ avoided if a sub-key is derived from a shared secret that is specific
+ to the instance of the PoP demonstration.
+
+
+
+
+
+Jones, et al. Standards Track [Page 10]
+
+RFC 7800 Proof-of-Possession Key for JWTs April 2016
+
+
+ As is the case with other information included in a JWT, it is
+ necessary to apply data origin authentication and integrity
+ protection (via a keyed message digest or a digital signature). Data
+ origin authentication ensures that the recipient of the JWT learns
+ about the entity that created the JWT since this will be important
+ for any policy decisions. Integrity protection prevents an adversary
+ from changing any elements conveyed within the JWT payload. Special
+ care has to be applied when carrying symmetric keys inside the JWT
+ since those not only require integrity protection but also
+ confidentiality protection.
+
+5. Privacy Considerations
+
+ A proof-of-possession key can be used as a correlation handle if the
+ same key is used with multiple parties. Thus, for privacy reasons,
+ it is recommended that different proof-of-possession keys be used
+ when interacting with different parties.
+
+6. IANA Considerations
+
+ The following registration procedure is used for all the registries
+ established by this specification.
+
+ Values are registered on a Specification Required [RFC5226] basis
+ after a three-week review period on the jwt-reg-review@ietf.org
+ mailing list, on the advice of one or more Designated Experts.
+ However, to allow for the allocation of values prior to publication,
+ the Designated Experts may approve registration once they are
+ satisfied that such a specification will be published.
+
+ Registration requests sent to the mailing list for review should use
+ an appropriate subject (e.g., "Request to Register JWT Confirmation
+ Method: example"). Registration requests that are undetermined for a
+ period longer than 21 days can be brought to the IESG's attention
+ (using the iesg@ietf.org mailing list) for resolution.
+
+ Criteria that should be applied by the Designated Experts include
+ determining whether the proposed registration duplicates existing
+ functionality, determining whether it is likely to be of general
+ applicability or whether it is useful only for a single application,
+ and evaluating the security properties of the item being registered
+ and whether the registration makes sense.
+
+ It is suggested that multiple Designated Experts be appointed who are
+ able to represent the perspectives of different applications using
+ this specification in order to enable broadly informed review of
+ registration decisions. In cases where a registration decision could
+ be perceived as creating a conflict of interest for a particular
+
+
+
+Jones, et al. Standards Track [Page 11]
+
+RFC 7800 Proof-of-Possession Key for JWTs April 2016
+
+
+ Expert, that Expert should defer to the judgment of the other
+ Experts.
+
+6.1. JSON Web Token Claims Registration
+
+ This specification registers the "cnf" claim in the IANA "JSON Web
+ Token Claims" registry [IANA.JWT.Claims] established by [JWT].
+
+6.1.1. Registry Contents
+
+ o Claim Name: "cnf"
+ o Claim Description: Confirmation
+ o Change Controller: IESG
+ o Specification Document(s): Section 3.1 of [RFC7800]
+
+6.2. JWT Confirmation Methods Registry
+
+ This specification establishes the IANA "JWT Confirmation Methods"
+ registry for JWT "cnf" member values. The registry records the
+ confirmation method member and a reference to the specification that
+ defines it.
+
+6.2.1. Registration Template
+
+ Confirmation Method Value:
+ The name requested (e.g., "kid"). Because a core goal of this
+ specification is for the resulting representations to be compact,
+ it is RECOMMENDED that the name be short -- not to exceed eight
+ characters without a compelling reason to do so. This name is
+ case sensitive. Names may not match other registered names in a
+ case-insensitive manner unless the Designated Experts state that
+ there is a compelling reason to allow an exception.
+
+ Confirmation Method Description:
+ Brief description of the confirmation method (e.g., "Key
+ Identifier").
+
+ Change Controller:
+ For Standards Track RFCs, list the "IESG". For others, give the
+ name of the responsible party. Other details (e.g., postal
+ address, email address, home page URI) may also be included.
+
+ Specification Document(s):
+ Reference to the document or documents that specify the parameter,
+ preferably including URIs that can be used to retrieve copies of
+ the documents. An indication of the relevant sections may also be
+ included but is not required.
+
+
+
+
+Jones, et al. Standards Track [Page 12]
+
+RFC 7800 Proof-of-Possession Key for JWTs April 2016
+
+
+6.2.2. Initial Registry Contents
+
+ o Confirmation Method Value: "jwk"
+ o Confirmation Method Description: JSON Web Key Representing Public
+ Key
+ o Change Controller: IESG
+ o Specification Document(s): Section 3.2 of [RFC7800]
+ o Confirmation Method Value: "jwe"
+ o Confirmation Method Description: Encrypted JSON Web Key
+ o Change Controller: IESG
+ o Specification Document(s): Section 3.3 of [RFC7800]
+
+ o Confirmation Method Value: "kid"
+ o Confirmation Method Description: Key Identifier
+ o Change Controller: IESG
+ o Specification Document(s): Section 3.4 of [RFC7800]
+
+ o Confirmation Method Value: "jku"
+ o Confirmation Method Description: JWK Set URL
+ o Change Controller: IESG
+ o Specification Document(s): Section 3.5 of [RFC7800]
+
+7. References
+
+7.1. Normative References
+
+ [IANA.JWT.Claims]
+ IANA, "JSON Web Token Claims",
+ <http://www.iana.org/assignments/jwt>.
+
+ [JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
+ RFC 7516, DOI 10.17487/RFC7156, May 2015,
+ <http://www.rfc-editor.org/info/rfc7516>.
+
+ [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517,
+ DOI 10.17487/RFC7157, May 2015,
+ <http://www.rfc-editor.org/info/rfc7517>.
+
+ [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
+ (JWT)", RFC 7519, DOI 10.17487/RFC7159, May 2015,
+ <http://www.rfc-editor.org/info/rfc7519>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+
+
+
+
+Jones, et al. Standards Track [Page 13]
+
+RFC 7800 Proof-of-Possession Key for JWTs April 2016
+
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
+ 2003, <http://www.rfc-editor.org/info/rfc3629>.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66,
+ RFC 3986, DOI 10.17487/RFC3986, January 2005,
+ <http://www.rfc-editor.org/info/rfc3986>.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ DOI 10.17487/RFC5226, May 2008,
+ <http://www.rfc-editor.org/info/rfc5226>.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246,
+ DOI 10.17487/RFC5246, August 2008,
+ <http://www.rfc-editor.org/info/rfc5246>.
+
+ [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
+ Verification of Domain-Based Application Service Identity
+ within Internet Public Key Infrastructure Using X.509
+ (PKIX) Certificates in the Context of Transport Layer
+ Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
+ 2011, <http://www.rfc-editor.org/info/rfc6125>.
+
+7.2. Informative References
+
+ [JWK.Thumbprint]
+ Jones, M. and N. Sakimura, "JSON Web Key (JWK)
+ Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
+ 2015, <http://www.rfc-editor.org/info/rfc7638>.
+
+ [OASIS.saml-core-2.0-os]
+ Cantor, S., Kemp, J., Philpott, R., and E. Maler,
+ "Assertions and Protocol for the OASIS Security Assertion
+ Markup Language (SAML) V2.0", OASIS Standard saml-core-
+ 2.0-os, March 2005,
+ <http://docs.oasis-open.org/security/saml/v2.0/>.
+
+ [OAUTH-POP-ARCH]
+ Hunt, P., Ed, Richer, J., Mills, W., Mishra, P., and H.
+ Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security
+ Architecture", Work in Progress, draft-ietf-oauth-pop-
+ architecture-07, December 2015.
+
+
+
+
+
+
+Jones, et al. Standards Track [Page 14]
+
+RFC 7800 Proof-of-Possession Key for JWTs April 2016
+
+
+ [OpenID.Core]
+ Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
+ C. Mortimore, "OpenID Connect Core 1.0", November 2014,
+ <http://openid.net/specs/openid-connect-core-1_0.html>.
+
+Acknowledgements
+
+ The authors wish to thank Brian Campbell, Stephen Farrell, Barry
+ Leiba, Kepeng Li, Chris Lonvick, James Manger, Kathleen Moriarty,
+ Justin Richer, and Nat Sakimura for their reviews of the
+ specification.
+
+Authors' Addresses
+
+ Michael B. Jones
+ Microsoft
+
+ Email: mbj@microsoft.com
+ URI: http://self-issued.info/
+
+
+ John Bradley
+ Ping Identity
+
+ Email: ve7jtb@ve7jtb.com
+ URI: http://www.thread-safe.com/
+
+
+ Hannes Tschofenig
+ ARM Limited
+ Austria
+
+ Email: Hannes.Tschofenig@gmx.net
+ URI: http://www.tschofenig.priv.at
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jones, et al. Standards Track [Page 15]
+