doc: Add RFC documents

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]
+