Re: [OAUTH-WG] Token Introspection: Misc Review Comments
On Mar 3, 2015, at 5:59 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hi Justin, Hi all, here are some random review comments: FROM: Since OAuth 2.0 [RFC6749] defines no direct relationship between the authorization server and the protected resource, only that they must have an agreement on the tokens themselves, there have been many different approaches to bridging this gap. TO: Since OAuth 2.0 [RFC6749] does not define a protocol between the authorization server and the resource server to retrieve meta-data associated with the access token different approaches to bridge this gap have been developed. Reason: OAuth 2.0 assumes a relationship between the authorization server and the resource server since otherwise the resource server wouldn't be able to trust the content of the access token. Thanks, this is more accurate. FROM: The introspection endpoint MUST be protected by TLS of at least version 1.2 RFC 5246 [RFC5246] and MAY support additional transport- layer mechanisms meeting its security requirements. TO: The introspection endpoint MUST be protected by TLS of at least version 1.2 RFC 5246 [RFC5246]. Reason: I have no idea what the additional transport layer mechanisms are. This has been common verbiage, but after Kathleen’s comments on Dyn-Reg we probably want to adopt that block of text instead anyway, which includes the TLS BCP reference. JWT is listed as an informative reference. I believe it needs to be normative because you depend on the registry being re-used. [JWT] Jones, M., Bradley, J., and N. Sakimura, JSON Web Token (JWT), draft-ietf-oauth-json-web-token (work in progress), July 2014. Good point, previous drafts didn’t reference the registry so this needs to be upgraded to normative. You write: The response MAY be cached by the protected resource. It might be worthwhile to say that it may be cached not longer than the lifetime of the token. It would also be good to mention that there is a trade-off between caching and a real-time check in terms of revocation. It’s always a tradeoff and we can give some guidance, but we’re not going to solve cache consistency here. Can you suggest text for how to strike this balance? You write: Specific implementations MAY extend this structure with their own service-specific pieces of information as top-level members of this JSON object. Here I would add that the inclusion of non-standardized tokens need to be based on the agreement between the authorization server and the resource server to avoid confusion and potentially elevation of authorization priviliges. That seems like reasonable guidance, can you suggest text? Thanks, — Justin Ciao Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth signature.asc Description: Message signed with OpenPGP using GPGMail ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims
Hi Hannes, thanks for the feedback. Responses inline. On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig hannes.tschofe...@gmx.net mailto:hannes.tschofe...@gmx.net wrote: Hi Justin, Hi all, in OAuth we provide two ways for a resource server to make an authorization decision. 1) The resource server receives a self-contained token that contains all the necessary information to make a local authorization decision. With the JWT we have created such a standardized information and data model. 2) With an access request from a client the resource server asks the authorization server for help. The authorization server provides information that help make the authorization decision. This is the token introspection approach. I believe the two approaches need to be aligned with regard to the information and the data model. Since both documents already use JSON as a way to encode information (=data model) and almost have an identical information model (the data that is being passed around). What needs to be done? * Use the term 'claims' in both documents. * Use the same registry (i.e., the registry established with the JWT). * Register the newly defined claims from the token introspection document in the claims registry. We’ve already done this in the latest draft. Or at least, that’s the intent of the current text — the registry is referenced and the new claims are registered. Can you specifically point to places where this needs to be improved upon? Then, I have a few comments on the new claims that are proposed: Here is the definition of the 'active' claim: active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The authorization server determines whether and when a given token is in an active state. This claim is not well-defined. You need to explain what active means. It could, for example, mean that the token is not yet expired. Then, there is of course the question why you are not returning the 'exp' claim together with the 'nbf' claim. The definition of “active” is really up to the authorization server, and I’ve yet to hear from an actual implementor who’s confused by this definition. When you’re the one issuing the tokens, you know what an “active” token means to you. Still, perhaps we can be even more explicit, such as: active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The specifics of a token’s active state will vary depending on the implementation of the authorization server, but generally this will indicate that a given token has been issued by this authorization server, has not been revoked by the resource owner, and is within its given time window of validity (e.g. not expired). Also, this is one of the places where the overlap between JWT and introspection claims don’t make sense. It doesn’t make any sense for a JWT to carry an “active” claim at all. Why would you have a JWT claim to be anything but active? We should register it with the JWT registry to avoid name collisions, but there’s nothing in the JWT registry that says “don’t use this inside of a JWT”. Do you have any advice on how to address this? client_id: What is the resource server going to do with the client_id? What authorization decision could it make? Whatever it wants to. If an RS can figure out something from the client_id, why not let it? The client_id is a piece of information about the context of the issuance of the token, and a common enough OAuth value for decision making. I have a couple of reactions when I read the 'user_id' claim: - I believe the inclusion of a user id field in the response could lead to further confusion regarding OAuth access token usage for authentication. This isn’t any different from having a userinfo-endpoint equivalent (like social graph or twitter API) and it’s got the same trouble. - Since you define it as a human readable identifier I am wondering whether you want to say something about the usage. Here it seems that it might be used for displaying something on a webpage rather than making an authorization decision but I might well be wrong. We added in “user_id” to our implementation due to developer demand — they wanted a username associated with the return value, but to leave the “sub” value the same as that defined by OpenID Connect. Note that this is in an environment where the username is a known quantity, and they’re not trying to do cross-domain authentication. They just want to know whose token this was so they can figure out whose data to return. It’s not used for display, but I tried to make the definition in contrast to the machine-facing “sub” value. - I am missing a discussion about the privacy implications of it. While there is a privacy consideration section I am wondering what controls the release of this sensitive information from the authorization server to the resource
Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline
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
Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims
The definition of “active” is really up to the authorization server, and I’ve yet to hear from an actual implementor who’s confused by this definition. When you’re the one issuing the tokens, you know what an “active” token means to you According to the spec as written the Introspection endpoint does not have to be an Authorization Sever and thus each could have defined “active” in different ways From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Wednesday, March 4, 2015 1:46 PM To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims Hi Hannes, thanks for the feedback. Responses inline. On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig hannes.tschofe...@gmx.netmailto:hannes.tschofe...@gmx.net wrote: Hi Justin, Hi all, in OAuth we provide two ways for a resource server to make an authorization decision. 1) The resource server receives a self-contained token that contains all the necessary information to make a local authorization decision. With the JWT we have created such a standardized information and data model. 2) With an access request from a client the resource server asks the authorization server for help. The authorization server provides information that help make the authorization decision. This is the token introspection approach. I believe the two approaches need to be aligned with regard to the information and the data model. Since both documents already use JSON as a way to encode information (=data model) and almost have an identical information model (the data that is being passed around). What needs to be done? * Use the term 'claims' in both documents. * Use the same registry (i.e., the registry established with the JWT). * Register the newly defined claims from the token introspection document in the claims registry. We’ve already done this in the latest draft. Or at least, that’s the intent of the current text — the registry is referenced and the new claims are registered. Can you specifically point to places where this needs to be improved upon? Then, I have a few comments on the new claims that are proposed: Here is the definition of the 'active' claim: active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The authorization server determines whether and when a given token is in an active state. This claim is not well-defined. You need to explain what active means. It could, for example, mean that the token is not yet expired. Then, there is of course the question why you are not returning the 'exp' claim together with the 'nbf' claim. The definition of “active” is really up to the authorization server, and I’ve yet to hear from an actual implementor who’s confused by this definition. When you’re the one issuing the tokens, you know what an “active” token means to you. Still, perhaps we can be even more explicit, such as: active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The specifics of a token’s active state will vary depending on the implementation of the authorization server, but generally this will indicate that a given token has been issued by this authorization server, has not been revoked by the resource owner, and is within its given time window of validity (e.g. not expired). Also, this is one of the places where the overlap between JWT and introspection claims don’t make sense. It doesn’t make any sense for a JWT to carry an “active” claim at all. Why would you have a JWT claim to be anything but active? We should register it with the JWT registry to avoid name collisions, but there’s nothing in the JWT registry that says “don’t use this inside of a JWT”. Do you have any advice on how to address this? client_id: What is the resource server going to do with the client_id? What authorization decision could it make? Whatever it wants to. If an RS can figure out something from the client_id, why not let it? The client_id is a piece of information about the context of the issuance of the token, and a common enough OAuth value for decision making. I have a couple of reactions when I read the 'user_id' claim: - I believe the inclusion of a user id field in the response could lead to further confusion regarding OAuth access token usage for authentication. This isn’t any different from having a userinfo-endpoint equivalent (like social graph or twitter API) and it’s got the same trouble. - Since you define it as a human readable identifier I am wondering whether you want to say something about the usage. Here it seems that it might be used for displaying something on a webpage rather than making an authorization decision but I might well be wrong. We added in “user_id” to our implementation due to developer demand — they wanted a username associated with the return value, but to leave the “sub” value the same as that defined by OpenID
Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline
It does so for the same reason that the JWT spec does - to promote interoperability. We can add wording along the likes of the JWE Compact Serialization MUST be used if you like. -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin Sent: Wednesday, March 04, 2015 3:26 PM To: Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline Why does the specification state encrypted to a key known to the recipient using the JWE Compact Serialization is this the only serialization allowed (there is no MUST) ? containing the symmetric key. -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, March 4, 2015 6:41 AM To: oauth@ietf.org Subject: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline 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
Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims
I have severe concerns with this approach. It’s not appropriate to register arbitrary JSON object member names as JWT claim names – especially when the JSON object member names are not even being used as JWT claim names. Please do not do this, as it would needlessly pollute the JWT claim name namespace with registered names that are application specific. Secondarily, I have concerns about these names and suggestions for how to address them. “active” – This claim is not presently adequately defined. And its definition will of necessity be specific to the introspection application. Therefore, it should not be registered as a general JWT claim name. A name I would be comfortable with for this concept would be urn:ietf:params:oauth:introspection:active, since it makes it clear what application the name is used with. “user_id” – The concept you’re describing is almost universally called “username”. User ID is typically the numeric account identifier (carried in the “sub” claim in a JWT), and so is not the right name for this. Compare it to the preferred_username claim in OpenID Connect. Please change this either to “username” or urn:ietf:params:oauth:introspection:username. “token_type” – While this is well-defined, the usage is fairly specific to this application. Again, adding the urn:ietf:params:oauth:introspection: name prefix would address this issue. If you give up registering these names in the JWT Claims registry, I’m OK with you using short names. But if you want them to live alongside other JWT claim names, please include the urn:ietf:params:oauth:introspection: in lieu of registration. Thank you, -- Mike From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Wednesday, March 04, 2015 1:46 PM To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims Hi Hannes, thanks for the feedback. Responses inline. On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig hannes.tschofe...@gmx.netmailto:hannes.tschofe...@gmx.net wrote: Hi Justin, Hi all, in OAuth we provide two ways for a resource server to make an authorization decision. 1) The resource server receives a self-contained token that contains all the necessary information to make a local authorization decision. With the JWT we have created such a standardized information and data model. 2) With an access request from a client the resource server asks the authorization server for help. The authorization server provides information that help make the authorization decision. This is the token introspection approach. I believe the two approaches need to be aligned with regard to the information and the data model. Since both documents already use JSON as a way to encode information (=data model) and almost have an identical information model (the data that is being passed around). What needs to be done? * Use the term 'claims' in both documents. * Use the same registry (i.e., the registry established with the JWT). * Register the newly defined claims from the token introspection document in the claims registry. We’ve already done this in the latest draft. Or at least, that’s the intent of the current text — the registry is referenced and the new claims are registered. Can you specifically point to places where this needs to be improved upon? Then, I have a few comments on the new claims that are proposed: Here is the definition of the 'active' claim: active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The authorization server determines whether and when a given token is in an active state. This claim is not well-defined. You need to explain what active means. It could, for example, mean that the token is not yet expired. Then, there is of course the question why you are not returning the 'exp' claim together with the 'nbf' claim. The definition of “active” is really up to the authorization server, and I’ve yet to hear from an actual implementor who’s confused by this definition. When you’re the one issuing the tokens, you know what an “active” token means to you. Still, perhaps we can be even more explicit, such as: active REQUIRED. Boolean indicator of whether or not the presented token is currently active. The specifics of a token’s active state will vary depending on the implementation of the authorization server, but generally this will indicate that a given token has been issued by this authorization server, has not been revoked by the resource owner, and is within its given time window of validity (e.g. not expired). Also, this is one of the places where the overlap between JWT and introspection claims don’t make sense. It doesn’t make any sense for a JWT to carry an “active” claim at all. Why would you have a JWT claim to be
Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims
I'm actually fine with keeping the introspection-specific elements out of the registry (see my note on active and how it doesn't fit in JWT below), but I do not want to give up the short names. The short names are already in production, especially active, which is well understood and used in practice today, and has been for years[1]. Changing this would fundamentally break all existing implementations for no good reason. I'm slightly more OK with changing user_id to username, since that's not as widely deployed to my knowledge (other implementers, please pipe up if I'm mistaken), and I'm well familiar with preffered_username in OIDC because I'm the one that put it in there [2]. :) While I prefer to leave it be at this stage, I think this is a less destructive change than active, scope, or client_id would be. For background to my stance regarding the registry: several revisions (and years) ago, the introspection draft re-defined several fields that overlapped with JWT and we were asked to correlate the two. Originally, we simply had a pointer to re-use the JWT claims as defined, and stacked our own claims on top. Later, we were asked to outright merge them, which is what we have right now. If the WG wants to back off that last change to the middle state -- where we re-use the JWT registry but don't write to it -- I'm very happy with that result and can work that (back) into the next draft. Though it does point out something strange about the standards process that we're running into here: JWT needed a place to register bits of metadata about a token, so it created one. This became the JWT registry, and now it's got hangings of being JWT-specific. When introspection came along with a need to talk about much the same kind of information, it makes sense to re-use the existing items but also that there would be things that are introspection-specific. -- Justin [1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03 [2] https://bitbucket.org/openid/connect/issue/584/messages-username-claim On 3/4/2015 6:28 PM, Mike Jones wrote: I have severe concerns with this approach. It’s not appropriate to register arbitrary JSON object member names as JWT claim names – especially when the JSON object member names are not even being used as JWT claim names. *Please do not do this*, as it would needlessly pollute the JWT claim name namespace with registered names that are application specific. Secondarily, I have concerns about these names and suggestions for how to address them. “active” – This claim is not presently adequately defined. And its definition will of necessity be specific to the introspection application. Therefore, it should not be registered as a general JWT claim name. A name I would be comfortable with for this concept would be urn:ietf:params:oauth:introspection:active, since it makes it clear what application the name is used with. “user_id” – The concept you’re describing is almost universally called “username”. User ID is typically the numeric account identifier (carried in the “sub” claim in a JWT), and so is not the right name for this. Compare it to the preferred_username claim in OpenID Connect. Please change this either to “username” or urn:ietf:params:oauth:introspection:username. “token_type” – While this is well-defined, the usage is fairly specific to this application. Again, adding the urn:ietf:params:oauth:introspection: name prefix would address this issue. If you give up registering these names in the JWT Claims registry, I’m OK with you using short names. But if you want them to live alongside other JWT claim names, please include the urn:ietf:params:oauth:introspection: in lieu of registration. Thank you, -- Mike *From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Justin Richer *Sent:* Wednesday, March 04, 2015 1:46 PM *To:* Hannes Tschofenig *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims Hi Hannes, thanks for the feedback. Responses inline. On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig hannes.tschofe...@gmx.net mailto:hannes.tschofe...@gmx.net wrote: Hi Justin, Hi all, in OAuth we provide two ways for a resource server to make an authorization decision. 1) The resource server receives a self-contained token that contains all the necessary information to make a local authorization decision. With the JWT we have created such a standardized information and data model. 2) With an access request from a client the resource server asks the authorization server for help. The authorization server provides information that help make the authorization decision. This is the token introspection approach. I believe the two approaches need to be aligned with regard to the information and the data model. Since both documents already use JSON as a way to encode
Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline
Why does the specification state encrypted to a key known to the recipient using the JWE Compact Serialization is this the only serialization allowed (there is no MUST) ? containing the symmetric key. -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, March 4, 2015 6:41 AM To: oauth@ietf.org Subject: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline 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
Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims
It sounds to me like you're making a good argument for this spec to have its own registry. Registries are easy to establish and use. From: Justin Richermailto:jric...@mit.edu Sent: 3/4/2015 6:43 PM To: Mike Jonesmailto:michael.jo...@microsoft.com; Hannes Tschofenigmailto:hannes.tschofe...@gmx.net Cc: oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims I'm actually fine with keeping the introspection-specific elements out of the registry (see my note on active and how it doesn't fit in JWT below), but I do not want to give up the short names. The short names are already in production, especially active, which is well understood and used in practice today, and has been for years[1]. Changing this would fundamentally break all existing implementations for no good reason. I'm slightly more OK with changing user_id to username, since that's not as widely deployed to my knowledge (other implementers, please pipe up if I'm mistaken), and I'm well familiar with preffered_username in OIDC because I'm the one that put it in there [2]. :) While I prefer to leave it be at this stage, I think this is a less destructive change than active, scope, or client_id would be. For background to my stance regarding the registry: several revisions (and years) ago, the introspection draft re-defined several fields that overlapped with JWT and we were asked to correlate the two. Originally, we simply had a pointer to re-use the JWT claims as defined, and stacked our own claims on top. Later, we were asked to outright merge them, which is what we have right now. If the WG wants to back off that last change to the middle state -- where we re-use the JWT registry but don't write to it -- I'm very happy with that result and can work that (back) into the next draft. Though it does point out something strange about the standards process that we're running into here: JWT needed a place to register bits of metadata about a token, so it created one. This became the JWT registry, and now it's got hangings of being JWT-specific. When introspection came along with a need to talk about much the same kind of information, it makes sense to re-use the existing items but also that there would be things that are introspection-specific. -- Justin [1] https://tools.ietf.org/html/draft-richer-oauth-introspection-03 [2] https://bitbucket.org/openid/connect/issue/584/messages-username-claim On 3/4/2015 6:28 PM, Mike Jones wrote: I have severe concerns with this approach. It’s not appropriate to register arbitrary JSON object member names as JWT claim names – especially when the JSON object member names are not even being used as JWT claim names. Please do not do this, as it would needlessly pollute the JWT claim name namespace with registered names that are application specific. Secondarily, I have concerns about these names and suggestions for how to address them. “active” – This claim is not presently adequately defined. And its definition will of necessity be specific to the introspection application. Therefore, it should not be registered as a general JWT claim name. A name I would be comfortable with for this concept would be urn:ietf:params:oauth:introspection:active, since it makes it clear what application the name is used with. “user_id” – The concept you’re describing is almost universally called “username”. User ID is typically the numeric account identifier (carried in the “sub” claim in a JWT), and so is not the right name for this. Compare it to the preferred_username claim in OpenID Connect. Please change this either to “username” or urn:ietf:params:oauth:introspection:username. “token_type” – While this is well-defined, the usage is fairly specific to this application. Again, adding the urn:ietf:params:oauth:introspection: name prefix would address this issue. If you give up registering these names in the JWT Claims registry, I’m OK with you using short names. But if you want them to live alongside other JWT claim names, please include the urn:ietf:params:oauth:introspection: in lieu of registration. Thank you, -- Mike From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Wednesday, March 04, 2015 1:46 PM To: Hannes Tschofenig Cc: oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims Hi Hannes, thanks for the feedback. Responses inline. On Mar 3, 2015, at 5:56 AM, Hannes Tschofenig hannes.tschofe...@gmx.netmailto:hannes.tschofe...@gmx.net wrote: Hi Justin, Hi all, in OAuth we provide two ways for a resource server to make an authorization decision. 1) The resource server receives a self-contained token that contains all the necessary information to make a local
[OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline
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
