[OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline

[Hannes Tschofenig <[e-mail]>]

Hi all,

as the deadline is approaching I would like to close the open issues of
the document. There are two open issues listed in the document and I
propose ways to resolve them below

Open Issue #1:

"In some conversations, we have said that it is the issuer of the JWT
   that possesses the key, and in some conversations, we have said that
   it is the presenter of the JWT that possesses the key.  Which
   description should we use?
"

There are the following parties in the entire picture (as the PoP
architecture document illustrates quite nicely):

* Issuer: Party that creates the JWT and binds a key to the token.
The key may be a symmetric key or a public key. To bind the key to the
JWT the issuer needs to compute a digital signature or a keyed message
digest over the JWT.

* Presenter: Party that demonstrates possession of a private key (for
asymmetric key cryptography) and secret key (for symmetric key
cryptography) to a recipient.

* Recipient: Party that receives the JWT together with the proof of
possession of the key (typically in form of a digital signature or a
keyed message digest).

Mapping this terminology to the OAuth context would look as follows:
 - Issuer: OAuth Authorization Server
 - Presenter: OAuth Client
 - Recipient: OAuth Resource Server

Adding the above-mentioned terminology to the terminology section (and
deleting the currently listed presenter) would resolve the issue IMHO.

Open Issue#2:

Mike added an editorial note to the introduction saying:
"
 [[ Editorial Note: This paragraph needs to be updated to provide more
   context and possibly also to describe the use of asymmetric keys
   instead.  It's not clear that the symmetric case is as useful or
   valuable, and it is certainly more complicated.]]
"

The design team work clearly indicated that both symmetric and
asymmetric cryptography has to be supported. The JWT mechanism actually
supports both and hence we should also describe both. What can, however,
be done is to also describe the asymmetric key case and here is my text
proposal for the introduction.

----
1.  Introduction

   This specification defines how to bind a key to a JSON Web
   Token (JWT) [JWT]. Three parties act in such a scenario:

* Issuer: Party that creates the JWT and binds a key to the token.
The key may be a symmetric key or a public key. To bind the key to
the JWT the issuer needs to compute a digital signature or a keyed
message digest over the JWT.

* Presenter: Party that demonstrates possession of a private key
(for asymmetric key cryptography) and secret key (for symmetric
key cryptography) to a recipient. This property is also sometimes
described as the presenter being a holder-of-key.

* Recipient: Party that receives the JWT together with the proof of
possession of the key (typically in form of a digital signature or a
keyed message digest).

[I-D.ietf-oauth-pop-architecture] describes the use of
proof-of-possession semantics for JSON Web Tokens (JWTs) for the use
with OAuth.

   Envision the following two use cases. The first use case describes
   the use of a symmetric key and the second use case focuses on
   asymmetric cryptography.

   An OAuth 2.0 authorization server generates a JWT
   and places an encrypted symmetric key inside the newly introduced
   confirmation claim.  This symmetric key is encrypted with a key known
   only to the authorization server and the recipient. The entire JWT
   is then integrity protected.  The JWT is then sent to the
   presenter.  Since the presenter is unable to obtain the
   encrypted symmetric key from the JWT itself, the authorization
   server conveys that symmetric key separately to the presenter.  Now,
   the presenter is in possession of the symmetric key as well as the
   JWT (which includes the confirmation claim member).  When the
   presenter needs to present the JWT to the recipient, it also needs
   to demonstrate possession of the symmetric key; the presenter, for
   example, uses the symmetric key in a challenge/response protocol
   with the recipient.  The recipient is able to verify that it is
   interacting with the genuine presenter by decrypting the JWK
   contained inside 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.

   This symmetric key mechanism described above is conceptually similar
   to the use of Kerberos tickets.

   In the second case consider a presenter that generates a public /
   private key pair. It then sends the public key to an OAuth 2.0
   authorization server, which creates a JWT and places an public key
   (or a fingerprint of it) inside the newly introduced confirmation
   claim. The entire JWT is then integrity protected using a digital
   signature to protect it against modifications.

   The JWT is then sent to the presenter. When the presenter needs to
   present the JWT to the recipient, it also needs to demonstrate
   possession of the private key. The presenter, for example, uses the
   private key in TLS exchange with the recipient.  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) and utilizing
   it with the private key in the TLS exchange.

   The asymmetric key mechanism described above is conceptually similar
   to a certificate.

   In both cases the JWT may contain various claims that are included
   based on the policy of the authorization server.

----

Due to the IETF draft submission deadline we would appreciate a response
by next Sunday.

Ciao
Hannes