> On Mar 4, 2015, at 3:40 PM, Hannes Tschofenig <hannes.tschofe...@gmx.net> > wrote: > > 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? > "
> The presenter > 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. > That looks OK > 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. > Agreed we need both. > ---- > 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. > In the asymmetric case if the client has a secure element having it generate the key and send the keys and sending public key to the AS is more secure than having the AS generate it. We support both ways. I suppose it is OK to mention only one in the introduction. I will spend some time on it now that MWC is almost over. John B. > ---- > > Due to the IETF draft submission deadline we would appreciate a response > by next Sunday. > > Ciao > Hannes > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
