Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims
Hi Mike, Hi Justin, I guess you agree with me that fundamentally the JWT and the token introspection solve the same problem, namely to provide the authorization server with information that it can use to make an authorization decision. The difference is only in the way how the message flows. Now, to the argument that developers have not yet complained about the underspecified claims/attributes is not particularly good. We tend to hear about complains years later when things go wrong and then we cannot change them anymore. Tell me for the active claim what type of checks the authorization server is supposed to do. If the authorization server and the resource server are provided by different parties then it is important to be clear about what checks each of the two parties are supposed to be doing. If the active claim aims to outsource the authorization decision from the resource server to the authorization server then that's a completely different story than just doing some basic sanity check on some of the JWT claims. Ciao Hannes On 03/05/2015 08:36 AM, Mike Jones wrote: 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 Richer mailto:jric...@mit.edu Sent: 3/4/2015 6:43 PM To: Mike Jones mailto:michael.jo...@microsoft.com; Hannes Tschofenig mailto:hannes.tschofe...@gmx.net Cc: oauth@ietf.org mailto: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
Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims
Others will hate the idea as well for other reasons I expect. If we leave introspection aside it might be a way to deal with other specs going forward. Sent from my iPhone On Mar 5, 2015, at 2:02 PM, Justin Richer jric...@mit.edu wrote: And you're right that I *really* don't like this because it breaks existing implementations somewhat arbitrarily. Mike had suggested something similar. -- Justin On 3/5/2015 7:48 AM, John Bradley wrote: A middle ground, that perhaps no one will like is registering application specific claims in the JWT registry, but pretending them with a app namespace. Eg Int:active That prevents people from stepping on each other with short names, and gives a central place to look them up, without requiring all all alls to understand all claims. John B. Sent from my iPhone On Mar 5, 2015, at 1:25 PM, Justin Richer jric...@mit.edu wrote: I'm OK with a separate registry, my only question is whether or not there's a way to correlate and coordinate the values of the two registries. The concern with importing the JWT claims directly into introspection's response was that we'd potentially be stepping on an existing namespace. In practice, I don't think that's a concern, but I can see the argument. If we establish an introspection response registry, how do we continue to deconflict with the JWT registry? -- Justin On 3/5/2015 2:36 AM, Mike Jones wrote: 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 Richer Sent: 3/4/2015 6:43 PM To: Mike Jones; Hannes Tschofenig Cc: 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
Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims
And you're right that I *really* don't like this because it breaks existing implementations somewhat arbitrarily. Mike had suggested something similar. -- Justin On 3/5/2015 7:48 AM, John Bradley wrote: A middle ground, that perhaps no one will like is registering application specific claims in the JWT registry, but pretending them with a app namespace. Eg Int:active That prevents people from stepping on each other with short names, and gives a central place to look them up, without requiring all all alls to understand all claims. John B. Sent from my iPhone On Mar 5, 2015, at 1:25 PM, Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: I'm OK with a separate registry, my only question is whether or not there's a way to correlate and coordinate the values of the two registries. The concern with importing the JWT claims directly into introspection's response was that we'd potentially be stepping on an existing namespace. In practice, I don't think that's a concern, but I can see the argument. If we establish an introspection response registry, how do we continue to deconflict with the JWT registry? -- Justin On 3/5/2015 2:36 AM, Mike Jones wrote: 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 Richer mailto:jric...@mit.edu Sent: 3/4/2015 6:43 PM To: Mike Jones mailto:michael.jo...@microsoft.com; Hannes Tschofenig mailto:hannes.tschofe...@gmx.net Cc: oauth@ietf.org mailto: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
Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims
wrote: 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 Richer mailto:jric...@mit.edu Sent: 3/4/2015 6:43 PM To: Mike Jones mailto:michael.jo...@microsoft.com; Hannes Tschofenig mailto:hannes.tschofe...@gmx.net Cc: oauth@ietf.org mailto: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.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
Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims
A middle ground, that perhaps no one will like is registering application specific claims in the JWT registry, but pretending them with a app namespace. Eg Int:active That prevents people from stepping on each other with short names, and gives a central place to look them up, without requiring all all alls to understand all claims. John B. Sent from my iPhone On Mar 5, 2015, at 1:25 PM, Justin Richer jric...@mit.edu wrote: I'm OK with a separate registry, my only question is whether or not there's a way to correlate and coordinate the values of the two registries. The concern with importing the JWT claims directly into introspection's response was that we'd potentially be stepping on an existing namespace. In practice, I don't think that's a concern, but I can see the argument. If we establish an introspection response registry, how do we continue to deconflict with the JWT registry? -- Justin On 3/5/2015 2:36 AM, Mike Jones wrote: 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 Richer Sent: 3/4/2015 6:43 PM To: Mike Jones; Hannes Tschofenig Cc: 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
Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims
I'm OK with a separate registry, my only question is whether or not there's a way to correlate and coordinate the values of the two registries. The concern with importing the JWT claims directly into introspection's response was that we'd potentially be stepping on an existing namespace. In practice, I don't think that's a concern, but I can see the argument. If we establish an introspection response registry, how do we continue to deconflict with the JWT registry? -- Justin On 3/5/2015 2:36 AM, Mike Jones wrote: 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 Richer mailto:jric...@mit.edu Sent: 3/4/2015 6:43 PM To: Mike Jones mailto:michael.jo...@microsoft.com; Hannes Tschofenig mailto:hannes.tschofe...@gmx.net Cc: oauth@ietf.org mailto: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.org *Subject
Re: [OAUTH-WG] Alignment of JWT Claims and Token Introspection Claims
response. The thumbs up response can contain other information as well, such as scopes and client IDs and whatnot, which can help the RS make its authorization decision. But at its core, the active claim fundamentally says is this token any good at all, according to the AS that I asked? and the RS can make its primary authorization decision based on that. If the RS has made the decision to outsource the token validity check to the AS, then the RS either understands or doesn't care what checks the AS makes in its decision regardless of implementation or vendor. Either way, it will abide by them since that's the whole point of outsourcing that decision. And I think you're too quick to dismiss the lack of confusion on the part of developers, considering that they are in fact the target audience of specifications like this. If we're not writing these documents for developers, who are we writing them for? -- Justin On 3/5/2015 3:39 AM, Hannes Tschofenig wrote: Hi Mike, Hi Justin, I guess you agree with me that fundamentally the JWT and the token introspection solve the same problem, namely to provide the authorization server with information that it can use to make an authorization decision. The difference is only in the way how the message flows. Now, to the argument that developers have not yet complained about the underspecified claims/attributes is not particularly good. We tend to hear about complains years later when things go wrong and then we cannot change them anymore. Tell me for the active claim what type of checks the authorization server is supposed to do. If the authorization server and the resource server are provided by different parties then it is important to be clear about what checks each of the two parties are supposed to be doing. If the active claim aims to outsource the authorization decision from the resource server to the authorization server then that's a completely different story than just doing some basic sanity check on some of the JWT claims. Ciao Hannes On 03/05/2015 08:36 AM, Mike Jones wrote: 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 Richer mailto:jric...@mit.edu Sent: 3/4/2015 6:43 PM To: Mike Jones mailto:michael.jo...@microsoft.com; Hannes Tschofenig mailto:hannes.tschofe...@gmx.net Cc: oauth@ietf.org mailto: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
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] 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] 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
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] 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
