Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

From: Vittorio Bertocci <[email-masked]>
Date: Fri, 3 Apr 2020 09:03:14 +0000

Thanks Annabelle and George!  I am consolidating replies to both your latest comments in this mail. This seems a hard rock to lift, but it also seems to be the last one 😊.

The TL;DR is, I am not completely opposed to relaxing the constraints and turning them into security considerations, but I think we’d miss an opportunity to make things clearer for developers. At the same time I wouldn’t want to make this profile too patronizing, hence I appreciate the opportunity to discuss.

[Annabelle]

  >. There may be no "scope" parameter.  The "scope" parameter is OPTIONAL in authorization requests. So an AS/RS operator could decide they're going to omit "scope" entirely and use multiple resource parameters instead. Since there are no scopes, there is no opportunity for confusion.

I am a BIG fan of ATs with no scope- all the scenarios where there’s no delegation (1st parties etc) shouldn’t use scopes at all. The current language in the profile does allow for scope-less ATs, and given that the goal is to prevent confusion, I agree that there’s no need to restrict the audience to one single resource if there are no scopes at all to misinterpret.

I would be in favor to allow multiple resources in audience in that case.

Unfortunately it’s not as simple as just saying “If the incoming request incudes multiple resource indicators and no scope, accept it and use the incoming resource indicators list as aud value” – mostly because there is a very large number of production systems where the request includes no scopes and one resource indicator, but the resulting token includes a collection of scopes the user already consented to for that resource- but I am sure we can get to acceptable language that expresses the concept “if there are multiple resource indicators in the request and the rest of the rules in S.3 the resulting AT won’t contain a scope claim, the resulting AT must use that resource indicators list as aud value”.

> An AS/RS operator may use "scope" to indicate a role or policy (or set of policies) that the client wants, and allow the client to narrow their permissions using "resource" parameters. This would allow the client to obtain narrowly scoped access tokens for specific use cases without needing to define separate roles/policies for each. In this case, a JWT AT with a multi-valued "aud" claim and a "scope" claim would seem appropriate, as the scope claim is intended to apply to all of the audience values.

I agree that deployments like the one you describe might exist, in fact I am sure they do. However it seems really a brittle approach, given that it makes a specific assumption (scopes are valid across all the resources) that isn’t enshrined anywhere and if future updates to that deployment violate that assumption, that would lead to the scope confusion the current language in the profile is trying to prevent. We offer very little guidance in that respect: the main place were multiple resources are even mentioned is resource indicators, and all the samples (I know, non-normative) use scopes unambiguously tied to a specific resource (more on that later) making the multi-resource scope even more of a special case.

Stepping back a bit - the intent behind those resource-scope restrictions is to provide a bit more guidance on scopes and resources than we did in the past, and narrowing the range of cases developers would need to take into account when implementing the profile.

In my experience the lack of more prescriptive guidance led to deployments and interpretations that, while remaining fully within the boundary of what the spec allows, are often questionable from the security and arch perspective.

(*)I acknowledge that I might be swinging too far in the opposite direction, and perhaps a similar effect could be achieved by adding an “Authorization Considerations” section where implementers are warned about the danger of scope confusion rather than downright forbidding multi resources audiences when including scopes as well. I still like the simplicity and clarity of the current restriction, but of course I am open to feedback.

> The mapping between audience and scope may be unambiguous. There are a lot of deployments to which the blast radius risk you're trying to address by requiring "aud" simply does not apply

There are certainly cases where scope strings unambiguously map to specific resources, but once again, that’s a strong assumption to make and one I feel cannot be made lightly. Resource indicators use very simple examples (contacts, calendar) that are hard to generalize to scenarios where the number and lifecycle of resources truly calls for the use of indicators identifying a resource in a large multitenant system usually entails large identifiers, and stuffing those in the scope to prevent ambiguity can be expensive from both provisioning and token, request size angles.

>It may seem innocuous to require these deployments to explicitly include a broad audience like "api.example.com" anyway, that can lead to implementers ignoring the requirement (leading to interop issues), not validating it (also leading to interop issues or security issues if the deployment wants to start actually using it for real), or doing something funky with it since there isn't anything "real" that the value needs to conform to.

Every spec guidance risks not being followed. But in this particular case, use of a logical audience is quite mainstream – we had a similar discussion for resource indicators and that’s why the spec ended up including logical identifiers as one of the resource parameter flavor. “real” is a relative term, given that there are already many different ways in which a logical resource might map to different “physical” artifacts (see heroku’s late binding URLs). Collective audiences are in common use for poor man’s trusted subsystems: not endorsing the approach, but bringing circumstantial evidence that broad audiences aren’t that uncommon or hard to grok for developers already today. Finally, turning off validation is actually not that trivial in many SDKs, given that they mostly reuse/derive from OIDC and the audience check is mandatory: I saw more often people disabling iss check than aud. None of this means that the errors you describe cannot happen: but I think they aren’t more likely than any other guidance in the spec.

I do ack the more generic point that, like in the preceding case, this might suggest that the current guidance is too strict- see (*)

[George]

>I think one of the problems we have in being super specific about how the JWT access token is constructed is that is means it's not possible for many organizations to follow. How scopes are implemented is very varied across deployments which means that some may conform to the perspective of the spec and many may not.

You are right, the spec  is an opinionated take- I agree that many organizations used scopes in very different ways, and I think it is the result of giving very little guidance on scopes and resources, with the consequence that some choices might have been less wise than others.

With the current guidance I attempted to capture a narrower set of scenarios where some of the most obvious issues (like scope confusion) can be averted, while still satisfying most of the cases I observed in the sample JWT ATs: I am not trying to overindex on those cases, and I don’t mean to imply that the profile should strictly follow those, but in the spirit of eliminating ambiguity as much as possible, this single resource narrowing seemed a solid core to build robust implementations on- fully aware of the fact that many current implementations would not conform (tho I am not sure how many implementations already adopted resource indicators or equivalent).

In any case, see (*)- I think I can be convinced to turn the current restrictions into security/authorization considerations- but I would reluctantly do so as I think we’d perpetuate a lot of the ambiguity we have in this space today.

>Personally, I'm not a big fan of trying to use scopes for fine-grain authorization. I don't think that is what they were intended for when originally designed. (This can be seen by the RAR spec introducing a completely different way of specifying fine-grain authorization context.) Even in multi-tenant systems, I don't see issues with using sub-resource scopes as each tenant should define the scopes that make sense for that tenant. I don't think the AS needs to understand the scopes, just provide a mechanism to issue the correct scope under user consent to the client and let the RS apply the authorization policy when it gets the scopes out of the token.

I am not crazy about that either- especially given that when fine grained authZ is involved very, very often what developers really want are user privileges and scopes are just abused in lieu of privileges simply because the spec doesn’t address the non-delegation scenario hence a screwdriver ends up being used as a hammer.

Nonetheless, if scopes are used- mandating that every scope is tied to the resource does lead to huge tokens and significant management overhead if you have lots of resources whose identifier must be globally unique, nonreassignable etc etc hence very large – and the AS doesn’t need to understand the semantic of each scope but it does need to know whether a scope can be requested for a given resource, plus any policy the admin might want to execute at token issuance time (eg this scope requires 2FA) hence juggling large numbers of large strings can be hard for the AS – and RS. In any case, the use of multiple resources in the aud in the wild appeared to be very rare, hence even if there would be a foolproof way of defining a resource-scope mapping, I would not spend cycles defining it here… and leaving it as exercise for the reader wouldn’t work per the above. As in (*) we could relax the constraint here and just warn people against scope confusion, but I feel we’d be missing an opportunity.

------

On 3/24/20, 17:00, "Richard Backman, Annabelle" <[email-masked]> wrote:

    To borrow a term from ML, I think the "aud", "scope", and resource indicator-related text is overfitted to a specific set of deployment scenarios, and a specific way of using scopes and resource indicators.

    Consider the following:

    1. There may be no "scope" parameter

    The "scope" parameter is OPTIONAL in authorization requests. So an AS/RS operator could decide they're going to omit "scope" entirely and use multiple resource parameters instead. Since there are no scopes, there is no opportunity for confusion. In this case, a JWT AT with a multi-valued "aud" claim and no "scope" claim would seem appropriate. While multiple resource indicators could be pushed into a single scope string, this introduces opportunities for serious security impacting encoding/decoding/parsing bugs. The more I think about it, the more "I don't have to deal with parsing a scope string" seems like a compelling reason to go this route... __

    2. The scopes may apply to all audiences

    An AS/RS operator may use "scope" to indicate a role or policy (or set of policies) that the client wants, and allow the client to narrow their permissions using "resource" parameters. This would allow the client to obtain narrowly scoped access tokens for specific use cases without needing to define separate roles/policies for each. In this case, a JWT AT with a multi-valued "aud" claim and a "scope" claim would seem appropriate, as the scope claim is intended to apply to all of the audience values.

    3. The mapping between audience and scope may be unambiguous

    There are a lot of deployments to which the blast radius risk you're trying to address by requiring "aud" simply does not apply. It may seem innocuous to require these deployments to explicitly include a broad audience like "api.example.com" anyway, that can lead to implementers ignoring the requirement (leading to interop issues), not validating it (also leading to interop issues or security issues if the deployment wants to start actually using it for real), or doing something funky with it since there isn't anything "real" that the value needs to conform to.

    –

    Annabelle Backman (she/her)

    AWS Identity

    https://aws.amazon.com/identity/

    On 3/24/20, 3:31 PM, "OAuth on behalf of Vittorio Bertocci" <[email-masked] on behalf of vittorio.bertocci=[email-masked]> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

    Thanks George for the super thorough review and feedback!

    Inline

      >  Section 1. Introduction

         ï¿½ï¿½ï¿½ second line: scenario should be plural --> scenarios

         ï¿½ï¿½ï¿½ second sentence: "are not ran by" --> "are not run by"

        ï¿½ï¿½ cofidentiality --> confidentiality

    Fixed. Thanks!

    >     Section 2.2.1 Authentication Information Claims

         ï¿½ï¿½ï¿½ I'm not sure that this definition of `auth_time` allows for the

        case where a user is required to solve an additional challenge.

    If the challenge entails going back to the AS, then I believe the language (in the initial paragraph of 2.2.1 and in auth_time itself)  accommodates for that and does require the auth_time to be updated.

    If you hit the AS and present an authentication factor (such as your challenge) and obtain a new token in the process, the auth_time will reflect the time of your latest authentication just like an id_token would in the same circumstances (think protected route in a web app requiring step up auth) and (likely) associated session artifacts (think RTs or cookies with sliding expiration, the challenge would count as activity and move the expiration).

    >     ï¿½ï¿½ï¿½ I think there is a difference between session_start_time and last

        auth_time. This feels more like it's defining the session_start_time

        concept.

    >    ï¿½ï¿½ These same issues can apply to the `acr` and `amr` values as well.

    Per the above, the intent is more to express the last time the user performed any authentication action rather than the start time. The intent is to provide information as current as possible, as it might be relevant to the RS decisions whereas the history before current conditions might not be consequential.

      >   ï¿½ï¿½ Even if for this secondary challenge a new refresh_token is issued,

        it is unlikely many relying parties will want to treat that as issuing a

        new session. The goal is to keep the user logged in to a single session.

    Could you expand on the practical implications of the above? The intent isn't as much to reflect session identifying information per se, but to provide the RS with the most up to date information about the circumstances in which the current AT was obtained. The fact that a session was initially established using acr level 0 doesn’t really matter if the AT I am receiving now has been obtained after a stepup that brought acr to 1, if my RS cares auth authentication levels my authorization decision shouldn't be influenced by whether somewhere the session artifact didn’t change its sessionID after the stepup. Same for acr, auth_time

    >     Section 2.2.3 Authorization Claims

         ï¿½ï¿½ I find the statement "All the individual scope strings in the scope

        claim MUST have meaning for the resource indicated in the aud claim"

        somewhat problematic. In many deployments today for 1st party clients to

        the authorization server and taking into account mobile applications,

        the access token most like contains scopes for many of the 1st party

        backend APIs. It's possible to get around this by setting the 'aud'

        claim to something like "com.example.apis" and hence all the issued

        scopes map to that audience claim but that is just working around the

        MUST in the spec. Given the lack of specificity of the 'aud' claim and

       the 'resource indicator' claim for that matter, pretty much anything can

        be made to comply. In that context, it seems like RECOMMEND is a better

        normative clause.

    For 1st party solutions, I would argue that delegation might not be the right primitive hence I wouldn't necessarily use scopes to express permissions; but that's a rabbit hole I'll try to avoid for the time being __

    For the aud, I think that what you characterized as workaround would actually be by design. The aud defines the applicability of the current token, so that in case of leakage the blast radius of the incident can be contained. If the solution designed decides that this particular token should be reusable across multiple assets, I think it makes sense for the aud to reflect that explicitly. That's the system designing volunteering a scope xpansion of the scope, and given that it has security implications I think it's good to require it to be an explicit, opt in action. At the same time, given that scopes are often used to define permissions, I believe it makes sense to find mechanisms to minimize the chance that RSes would misinterpret the applicability of a scope (see discussion with Takahiko/Nikos). Summing all the above, I'd be inclined to keep the MUST.

    > Section 3. Requesting a JWT Access Token

         ï¿½ï¿½ Per my comments above I suspect that requiring all JWT access tokens

        to include an audience claim will just devolve to audience claims that

        are somewhat pointless (in order to meet this MUST in the spec). Given

        the mobile app environment today, it is unreasonable to ask the mobile

        apps to downscope every access token before making an API call to the

        backend APIs which is what the spirit of audience and resource

        indicators seem to imply.

    Partly addressed in the preceding point, but this is a great opportunity to clarify the intent further. The mobile client isn't required to downscope; rather, the fact that a token cab be applied to a broad range of API should be clearly identified and expressed by the logical audience. The system designer can even choose to have a single token that can be used to call any API, containing every scope for every API; the profile only asks for this choice to be manifest, by choosing an appropriate audience identifier and acknowledging that all the scopes in the token are applicable to the same logical resource (that is, the aggregate of all the APIs).

         >  ï¿½ï¿½ Why MUST the AS reject a request with more than one resource

        parameter? If a request comes in with no resource parameter and multiple

        scopes the AS is not required to reject that request. Is there much of a

        semantic difference between the two? In the case of no resource

        parameter and multiple scopes the AS might issue an access token with

        multiple audience values (as is allowed by RFC 7519).

    This is another consequence of making extra clear what the token refers to, and what the intended semantic of the scopes is. The idea is that the token is always restricted to ONE specific audience. The profile allows for different mechanisms for the AS to determine what value the audience should be, including via inference from scopes, but coherently with the scope confusion prevention principle, if that inference cannot lead to a single resource identifier in the audience, the request should be rejected.

    The intent is really to be as simple as unambiguous as possible, and capture what most mainstream providers already do in JWT ATs. If a RS has more sophisticated requirements, they can always decide to do more and not follow the interop profile. Defining more complex rules to prevent scope/resource association confusion simply doesn’t seem to be justified by the frequency of the scenario in the wild.

    >  Also, the audience

        claim is not solely for resource indicator values but is defined to just

        be a string. To me it feels like the text is implying that the only

        valid audience value is also a resource indicator (which from previous

        discussions on the list it was implied they have a slightly different

        semantic).

    Section 3 of the profile does define aud as a resource indicator, enumerating an exhaustive list of possible requests that all end in a resource indicator as aud, or an error. Did I miss some cases? I don’t recall specifics about aud values in this profile having other possible values, sorry for having missed that. Do you have a snippet referring to those discussions? Thx

        >  ï¿½ï¿½ The model described here works well if myco.example really only

        provides a single service. But if instead myco.example provides multiple

        services each with their own endpoints (srva.myco.example,

        srvb.myco.example) and scopes, for me this model begins to break down.

        Either mobile apps are required to downscope all tokens to just the

        service they are calling at that point in time (which can have latency

        and connectivity issues), or myco.example has to create a generic

        "audience" string that represents all of example.com which doesn't seem

        to be the spirit of the existing specs.

    I think that the granularity of the calls is fully within the control of the designer. If srva.myco.example and srvb.myco.example share analogous characteristics (same policies, lifecycle, resource ownership, etc) them it's perfectly valid to assign a logical myco.example audience encompassing them all, regardless of deployment model. If there are differences in terms of policies, auth strength requirements, lifecycle, risk and impact of a leak, or any other boundary, then the audience requirement will guarantee that those differences are reflected in tokens requested and cached, in the way in which access is partitioned, and so on and so forth. If there are security requirements such as the ones enumerated, the latency and connectivity issues aren’t a blocking factor; and if there aren't, nothing prevents you from having a logical audience value. From the expressive power point of view, the requirement of having a single audience doens't prevent you from doing any of the single token logic you are hinting at- especially if you plan to use specialized scopes anyway.

       >   ï¿½ï¿½ In summary, I feel that this text is binding too tightly resource

        indicators to the audience claim. What is described is perfectly

        reasonable in a use case that is applying resource indicators in this

        way but is not indicative of the widely deployed models that already exist.

    We might have different experiences here. The JWT access tokens from popular products I studied in the research I presented in Stuttgart were almost all using the aud claim in this way. I am sure that there are other models, and there was at least one exception, but in interop terms this seems to be the most common way of using JWT for ATs- and it has the advantage of being very simple and unambiguous.

    > Section 4. Validating JWT Access Tokens

         ï¿½ï¿½ Step 4. -- Can we change the wording to not require resource

        indicators? What about... "The resource server MUST validate that the

        'aud' claim contains a string that represents the audience of this

        resource server."

    Could you make an example in which you'd want to use an identifier that is not a resource indicator? Given that we have the spec, and "audience of the resource server" seems to be the exact semantic of resource indicators, it seemed a slam dunk to use it here...

       > Section 5. "cross-JWT confusion"

         ï¿½ï¿½ I think there may be confusion around what is meant by "distinct

        resources". In my example above, are srva.myco.example and

        srvb.myco.example "distinct resources"? or is the goal here to say that

        we want different audience values generated for cross-organization

        resources. For example, are mail.google.com and youtube.com "distinct

        resources"? or would an audience for google suffice in meeting the

        meaning of this paragraph?

    I think the key point here is - we don’t know. I agree the language isn't clear there. Let me expand on the intent, and perhaps we can get to a better formulation.

    OAuth2 doesn’t demand that RS and AS are run by the same entity, but that's the most common scenario. FB doesn't need to specify a resource, because the resource is implicit.. it's the FB graph, you can’t get a token for anything else. The only differentiator ends up being the scopes. Same for many other providers, google, Microsoft for its own Graph, etc.

    However many AS as a service don’t have the benefit of a default, implicit resource, especially in multi tenancy scenarios, given that they'll need to issue tokens for a number of different recipients. Whether resources are cross organization, or cross department, or following any other arbitrary segregation/factoring model is something we cannot infer- it's up to the developer to determine that. What I am trying to express here is that the operator of the AS as a service (or any other form of "AS for rent") should surface resources as a primitive for modeling and identifying intended recipients of ATs. Does tis help? How would you express that?

    >      ï¿½ I'm having the same confusion in the next paragraph regarding the

        phrase "different resources". Are services provided by the same company

        "different resources" or are they all considered the same resource. Can

        an access token be issued with scopes for both mail.google.com and

        youtube.com? And if not, why note? Preventing this puts undue burden on

        mobile based applications.

    See preceding point. We can't enter in the merit of what constitutes a resource, as that depends on the modeling of the domain specific problem the developer is tackling. The highest order bit is that if two entities (API, etc.. intended token recipients) have different security characteristics (e.g. leaking a token for one has different consequences than if you'd leak a token for the other), they should be modeled as different resources. And if they are different resources, we should do what we can to avoid confusion in how we express access grants to them (hence the big discussion on multiresource, scope confusion, etc).

    ---------

    On 3/24/20, 10:39, "George Fletcher" <[email-masked]> wrote:

        Feedback on the spec...

        Section 1. Introduction

         ï¿½ï¿½ï¿½ second line: scenario should be plural --> scenarios

         ï¿½ï¿½ï¿½ second sentence: "are not ran by" --> "are not run by"

        Section 2.2.1 Authentication Information Claims

         ï¿½ï¿½ï¿½ I'm not sure that this definition of `auth_time` allows for the

        case where a user is required to solve an additional challenge. Take the

        case of a user who is required to pass a secondary challenge before the

        "stock purchase" action can be completed. According to the current spec

        definition, the `auth_time` value MUST NOT be updated when this

        secondary challenge is completed.

         ï¿½ï¿½ï¿½ I think there is a difference between session_start_time and last

        auth_time. This feels more like it's defining the session_start_time

        concept.

         ï¿½ï¿½ These same issues can apply to the `acr` and `amr` values as well.

         ï¿½ï¿½ Even if for this secondary challenge a new refresh_token is issued,

        it is unlikely many relying parties will want to treat that as issuing a

        new session. The goal is to keep the user logged in to a single session.

        Section 2.2.3 Authorization Claims

         ï¿½ï¿½ I find the statement "All the individual scope strings in the scope

        claim MUST have meaning for the resource indicated in the aud claim"

        somewhat problematic. In many deployments today for 1st party clients to

        the authorization server and taking into account mobile applications,

        the access token most like contains scopes for many of the 1st party

        backend APIs. It's possible to get around this by setting the 'aud'

        claim to something like "com.example.apis" and hence all the issued

        scopes map to that audience claim but that is just working around the

        MUST in the spec. Given the lack of specificity of the 'aud' claim and

        the 'resource indicator' claim for that matter, pretty much anything can

        be made to comply. In that context, it seems like RECOMMEND is a better

        normative clause.

        Section 3. Requesting a JWT Access Token

         ï¿½ï¿½ Per my comments above I suspect that requiring all JWT access tokens

        to include an audience claim will just devolve to audience claims that

        are somewhat pointless (in order to meet this MUST in the spec). Given

        the mobile app environment today, it is unreasonable to ask the mobile

        apps to downscope every access token before making an API call to the

        backend APIs which is what the spirit of audience and resource

        indicators seem to imply.

         ï¿½ï¿½ Why MUST the AS reject a request with more than one resource

        parameter? If a request comes in with no resource parameter and multiple

        scopes the AS is not required to reject that request. Is there much of a

        semantic difference between the two? In the case of no resource

        parameter and multiple scopes the AS might issue an access token with

        multiple audience values (as is allowed by RFC 7519). Also, the audience

        claim is not solely for resource indicator values but is defined to just

        be a string. To me it feels like the text is implying that the only

        valid audience value is also a resource indicator (which from previous

        discussions on the list it was implied they have a slightly different

        semantic).

         ï¿½ï¿½ The model described here works well if myco.example really only

        provides a single service. But if instead myco.example provides multiple

        services each with their own endpoints (srva.myco.example,

        srvb.myco.example) and scopes, for me this model begins to break down.

        Either mobile apps are required to downscope all tokens to just the

        service they are calling at that point in time (which can have latency

        and connectivity issues), or myco.example has to create a generic

        "audience" string that represents all of example.com which doesn't seem

        to be the spirit of the existing specs.

         ï¿½ï¿½ In summary, I feel that this text is binding too tightly resource

        indicators to the audience claim. What is described is perfectly

        reasonable in a use case that is applying resource indicators in this

        way but is not indicative of the widely deployed models that already exist.

        Section 4. Validating JWT Access Tokens

         ï¿½ï¿½ Step 4. -- Can we change the wording to not require resource

        indicators? What about... "The resource server MUST validate that the

        'aud' claim contains a string that represents the audience of this

        resource server."

        Section 5. "cross-JWT confusion"

         ï¿½ï¿½ I think there may be confusion around what is meant by "distinct

        resources". In my example above, are srva.myco.example and

        srvb.myco.example "distinct resources"? or is the goal here to say that

        we want different audience values generated for cross-organization

        resources. For example, are mail.google.com and youtube.com "distinct

        resources"? or would an audience for google suffice in meeting the

        meaning of this paragraph?

         ï¿½ I'm having the same confusion in the next paragraph regarding the

        phrase "different resources". Are services provided by the same company

        "different resources" or are they all considered the same resource. Can

        an access token be issued with scopes for both mail.google.com and

        youtube.com? And if not, why note? Preventing this puts undue burden on

        mobile based applications.

        Section 6. Privacy

         ï¿½ï¿½ cofidentiality --> confidentiality

        Thanks,

        George

    _______________________________________________

    OAuth mailing list

    [email-masked]

    https://www.ietf.org/mailman/listinfo/oauth

---

From: George Fletcher <[email-masked]>
Date: Fri, 3 Apr 2020 16:21:04 -0400

Thanks Vittorio for the thorough response!

I agree that how scopes are handled is very different across 
deployments. Scopes used for an RP with a mobile app (e.g. something 
like OpenTable) are going to be very different than a multi-tenant 
enterprise system with fixed services and roles that all tenants much 
use. I'm not sure it is possible to clearly map this disparate set of 
deployments into a common set of spec language. It's possible to define 
a solution that is maybe "majority" but anyone wanting to conform with a 
different deployment strategy will just "munge" the 'aud' value to make 
their deployment work. I'm not sure that adds a lot of value. I think I 
would prefer a multi-valued 'aud' claim of "mail.example, 
contacts.example, news.example" over a generic "api.example". The former 
provides value to limit the scope of the token where the latter does not.

I agree that scopes were not well specified in 6749/6750 and now it's a 
bit of the wild west. Some treat scopes as capabilities, some treat them 
as roles, some as attributes, some as flags for specific token behavior 
and the list goes on:)

Personally, I'd prefer using RECOMMENDED for the current defined spec 
language without making that model required.

If we truly want interoperable access_tokens cross IDPs, then I think we 
have a lot more spec work to do than describing the token format. This 
is a important and necessary building block, but behaviors and how they 
map may be outside the scope of this work.

Thanks,
George

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 3 Apr 2020 20:38:54 +0000

I would support relaxing the language that clearly targets the issue – authorization confusion – such as:

The AS MUST NOT issue a JWT access token if the authorization granted by the token would be ambiguous.

The current draft language basically takes a heuristic approach to this, prohibiting certain patterns that might lead to this scenario. If we target the issue directly and provide Security Considerations text elaborating on some of the ways this can occur, we allow deployments to determine whether or not it applies in their context.

We can’t fix the fact that scopes are ambiguous and entirely implementation specific. That horse left the barn with 6749. If we try to address this by introducing new limitations on scopes within specs like this one, we’re going to end up with each new spec imposing its own restrictions, which will artificially limit the spec’s utility and may introduce incompatibilities between specs due to inconsistent restrictions. Developers will be left to try to piece it all together to figure out if their use case is permitted.

The way we dig ourselves out of this hole is through Rich Authorization Requests. That draft is our opportunity to get this right, via “a lot more spec work” as George put it. Incidentally, if we think about RAR in the context of JWT access tokens, it’s immediately obvious why a multi-value aud claim needs to be allowed. If my token contains an “authorization” claim containing a RAR object that grants fine-grained authorization on different resources across different endpoints, my aud value should be able to match that. It’d be silly to have to have an aud claim of “api.app.example” if my authorization is tightly bound to “email.app.example” and “contacts.app.example” through RAR.

–

From: George Fletcher <[email-masked]>
Organization: AOL LLC
Date: Friday, April 3, 2020 at 1:22 PM
To: Vittorio Bertocci <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>, Vittorio Bertocci <vittorio.bertocci=[email-masked]>, Hannes Tschofenig <[email-masked]>, oauth <[email-masked]>, Vittorio Bertocci <[email-masked]>
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

I agree that how scopes are handled is very different across deployments. Scopes used for an RP with a mobile app (e.g. something like OpenTable) are going to be very different than a multi-tenant enterprise system with fixed services and roles that all tenants much use. I'm not sure it is possible to clearly map this disparate set of deployments into a common set of spec language. It's possible to define a solution that is maybe "majority" but anyone wanting to conform with a different deployment strategy will just "munge" the 'aud' value to make their deployment work. I'm not sure that adds a lot of value. I think I would prefer a multi-valued 'aud' claim of "mail.example, contacts.example, news.example" over a generic "api.example". The former provides value to limit the scope of the token where the latter does not.

I agree that scopes were not well specified in 6749/6750 and now it's a bit of the wild west. Some treat scopes as capabilities, some treat them as roles, some as attributes, some as flags for specific token behavior and the list goes on:)

Personally, I'd prefer using RECOMMENDED for the current defined spec language without making that model required.

If we truly want interoperable access_tokens cross IDPs, then I think we have a lot more spec work to do than describing the token format. This is a important and necessary building block, but behaviors and how they map may be outside the scope of this work.

Thanks,
George

[Annabelle]

[George]

------

On 3/24/20, 17:00, "Richard Backman, Annabelle" <[email-masked]><mailto:[email-masked]> wrote:

    Consider the following:

    –

    AWS Identity

    On 3/24/20, 3:31 PM, "OAuth on behalf of Vittorio Bertocci" <[email-masked] on behalf of vittorio.bertocci=[email-masked]><mailto:[email-masked]=[email-masked]> wrote:

    Inline

    Fixed. Thanks!

        concept.

        normative clause.

        semantic).

        resource server."

    ---------

    On 3/24/20, 10:39, "George Fletcher" <[email-masked]><mailto:[email-masked]> wrote:

        Feedback on the spec...

        Section 1. Introduction

        concept.

        normative clause.

        semantic).

        resource server."

        Section 6. Privacy

        Thanks,

        George

    OAuth mailing list

    [email-masked]<mailto:[email-masked]>

---

From: Denis <[email-masked]>
Date: Thu, 9 Apr 2020 18:25:46 +0200

I have three concerns, two of them being related to privacy.

1) Privacy has not really been a concern in the WG since originally the 
AT and the RS were co-located. However, this draft now recognizes
that there may exist cases where "the authorization server and resource 
server are not co-located, are not ran by the same entity,
or are otherwise separated by some boundary".

*In such cases*, it is important to be able to make sure that an 
authorization server will NOT be able to know where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL 
NOT be able to know where an AT requested by a given client will be used:
*Authorization servers SHALL not have the **capability to act as "Big 
Brother"* and thus SHALL not be able to know which resources are going
to be accessed by clients.

This means that, in such cases, an authorization server SHALL not be 
able to know for which resource server an AT has been targeted.

It is a fact that most solutions currently deployed support a built-in 
*"Spy by desig**n"* architecture instead of a *"Privacy by design"* 
architecture.

However, for security reasons an AT still needs to be targeted.

The problem to be solved is the following:

  * for security reasons, the AT must be targeted.
  * for privacy reasons, the AS must be kept ignorant of the name of the
    target.

One way to solve the problem is to consider that the AT is composed of a 
sequence of two structures: a signed structure and an unsigned structure.

The signed structure contains a "salted aud claim".
The unsigned structure contains a "aud salt claim".

In practice, the "salted aud claim" will be composed of both a one way 
hash function algorithm identifier and a hash value.

Before requesting an AT to an AS, the client chooses a resource server 
and select a resource indicator value corresponding to the identifier 
the resource server.
It then chooses a random value which it uses as a "aud salt claim" and 
then computes a hash value by using a one-way hash function which combines
one of the resource indicators of the RS with the "aud salt claim". Both 
the one way hash function algorithm identifier and the computed  hash value
are then included into the "salted aud claim".

The AT request then contains a "salted aud claim" instead of an"aud 
claim". The AT blindly copies this value into the AT which is then 
identified as
a "salted aud claim" instead of an "aud claim".

When the AT is received by the client, it adds to the AT the unsigned 
part to the AT which contains the "aud salt claim" and sends both the 
signed
and the unsigned part of the AT to the RS.

When the RS receives the AT, using the one way hash function algorithm 
identifier contained in the "salted aud claim", it combines each of its 
resource indicators
with the "aud salt claim" contained in the unsigned part of the AT and 
verifies whether it matches with the hash value contained in the "salted 
aud claim".
If none of these resource indicators is providing a match, then the RS 
SHALL rejected the AT.

The implication is to allow an AT to contain both a signed part and an 
unsigned part.

In addition, the "aud claim" should be multi-valued where, as a 
consequence, both the "salted aud claim" with the "aud salt claim" would 
also be multi-valued.

2) Within clause 6, "Privacy Considerations", the text states:

As JWT access tokens carry information by value, it now becomes
possible for requestors and receivers to directly peek inside the
token claims collection.The client MUST NOT inspect the content of
the access token: the authorization server and the resource server
might decide to change token format at any time (...).

On the contrary, a client SHALL be able to inspect the content of the 
access token to make sure that the AS has not included in the AT some 
private information
that should not be present, before forwarding the AT to the RS. It is 
possible for an AS to change the format of the AT, but the RS will not 
necessarily be in synch
with the RS.

Since there are now cases where "the authorization server and resource 
server are not co-located, are not ran by the same entity, or are 
otherwise separated
by some boundary", a key point is that an AS and a RS DO NOT necessarily 
need to know each other. The RS only needs to trust the AS. (full stop)

This means that an identifier of the profile of the AT should be able to 
be included into the AT. This allows for future extensions.

In any case, the "MUST NOT" in the quoted sentence should be removed or 
changed or the whole sentence should be removed..

3) Within clause 2.2.2 (second paragraph):

This profile does not introduce any mechanism for a client to
directly request the presence of specific claims in JWT access
tokens, as the authorization server can determine what additional
claims are required by a particular resource server by taking in
consideration the client_id of the client, the scope and the resource
parameters included in the request.

Allowing a client to only specify a scope and a resource is very 
restrictive.

What would be the title of an RFC that would allow the client to request 
the presence of specific claims in JWT access ?

If such a restriction is kept, would the current title of this RFC still 
be inappropriate
"JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" ?

Denis

DP Security Consulting

---

From: Vittorio Bertocci <[email-masked]>
Date: Fri, 10 Apr 2020 06:28:59 +0000

Hi Denis,
Thank you for your feedback!
Inline

> Privacy has not really been a concern in the WG since originally the AT and the RS were co-located.
Colocation of AS and RS was a frequent occurrence, but by no mean mandatory… AFAIK one of the drivers for the changes between OAuth1 and OAuth2 was providing the ability of supporting topologies where AS and RS are distinct right out of the box.
The scenario where AS and RS are distinct was always possible in Outh2, and and not by accident. The JWT AT just happens to be particularly handy in empowering the RS to validate incoming tokens without having to phone home to the AS every time, hence it gives the opportunity to discuss implications of that scenario more in depth, but doesn’t really introduce anything that wasn’t possible before. Even the possibility of a token format passing info by value isn’t forbidden, default OAuth2 ATs are not mandatorily opaque- they just happen not to have a well defined format.

>In such cases, it is important to be able to make sure that an authorization server will NOT be able to know where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL NOT be able to know where an AT requested by a given client will be used:
Authorization servers SHALL not have the capability to act as "Big Brother" and thus SHALL not be able to know which resources are going
to be accessed by clients.
The scenario in which a token issuer isn’t aware of where the client will spend the corresponding token is important, but it is more the province of SSI than mainstream OAuth2 usage today.
Mainstream OAuth2 in current use, regardless of the AT format, typically do know for whom the token is being issued: a great deal of logic is predicated on that knowledge. Did the user consent for this client to access this particular resource? Does access to this resource warrant presenting a stronger authentication prompt? Are there other authorization considerations that influences whether the requested token should be issued? Those are considerations an AS need to be able to perform in the general case, regardless of the AT format. That doesn’t mean they MUST be done in every case, but making them impossible would deny a lot of very important scenarios for which JWT ATs (and ATs in general) are used for today.
The split structure you suggest is interesting, but I would recommend is enshrined in its own spec (maybe in the SSI orbit) rather than in an interop profile for the general AT case.

>On the contrary, a client SHALL be able to inspect the content of the access token to make sure that the AS has not included in the AT some private information
that should not be present, before forwarding the AT to the RS. It is possible for an AS to change the format of the AT, but the RS will not necessarily be in synch
with the RS.
I can see the value in doing what we can to prevent abuses, but I find this requirement problematic. The access token is an artifact meant to enable the client to access a resource. Its format remains a private matter between the RS and the AS, which retains the freedom to change it as they see fit without worrying about client code that takes a dependency on characteristics of the AT that might very well be transient. As far the client is concerned, the RS and the AS might switch their agreement from JWT AT to opaque tokens to be validated via introspection at any time, which would break any client side logic inspecting the AT and expecting it to be a JWT. The client has no control whatsoever on the content that is transmitted via opaque token, hence privacy-wise the fact that the content of the JWT is visible is more of a concern about such content being accessible on the client. One additional point: even if clients would be able to safely peek inside an AT without risking breaking their code, there’s no guarantee that the client would understand the semantic of the claims in the AT, as those are meant for consumption by the RS which can assign any semantic to them; nor the client can reliably trust the content of the claims, given that the AS could and sometimes will encrypt their content for the intended recipient (another reason for which the AS in the general case needs to know the intended recipient).

>. It is possible for an AS to change the format of the AT, but the RS will not necessarily be in synch with the RS.
I don’t understand this sentence. Is the last RS meant to be AS?
Assuming that’s the case: It doesn’t look very likely that an RS would simply accept tokens from an AS without some out of band negotiation, nor it seems very likely that an AS would issue tokens for resources it doesn’t know- see above. Such scenarios might exist, but they don’t seem to model common business solutions or the typical deployment, where an API will be protected by middleware/gateway with precise assumptions on how to validate incoming tokens. There might be changes that are inconsequential (order of claims, additional claims) but anything more substantive would likely simply break the solution.

> This means that an identifier of the profile of the AT should be able to be included into the AT. This allows for future extensions.
Can you expand on the exact scenario you are thinking of that calls for a version? If it’s a matter of extensions, those should always be possible – it’s more breaking changes that require versioning, but I don’t recall precedents in similar specs.
If this is aimed at mitigating the “AS changes format without telling RS”, I don’t think that would work – besides of being unnecessary per the above considerations, this wouldn’t protect the RS from changes well within the current spec (which allows adding arbitrary claims as long as it’s done according to JWT rules), from changes within the claim content (eg private string formats) and from complete departures from the use of JWT for ATs.

> Allowing a client to only specify a scope and a resource is very restrictive.
Specifying scope or using resource indicators are all the mechanisms I am aware of that OAuth2 offers for specifying what an access token should be for- at least at the time in which the spec was incepted. In fact, resource indicators was not even RFC and in market vendors used proprietary functional equivalents. What other interoperable mechanisms would you offer in addition to the ones listed here?

From: OAuth <[email-masked]> on behalf of Denis <[email-masked]>
Date: Thursday, April 9, 2020 at 09:26
To: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

1) Privacy has not really been a concern in the WG since originally the AT and the RS were co-located. However, this draft now recognizes
that there may exist cases where "the authorization server and resource server are not co-located, are not ran by the same entity,
or are otherwise separated by some boundary".

In such cases, it is important to be able to make sure that an authorization server will NOT be able to know where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL NOT be able to know where an AT requested by a given client will be used:
Authorization servers SHALL not have the capability to act as "Big Brother" and thus SHALL not be able to know which resources are going
to be accessed by clients.
This means that, in such cases, an authorization server SHALL not be able to know for which resource server an AT has been targeted.
It is a fact that most solutions currently deployed support a built-in "Spy by design" architecture instead of a "Privacy by design" architecture.
However, for security reasons an AT still needs to be targeted.

  *   for security reasons, the AT must be targeted.
  *   for privacy reasons, the AS must be kept ignorant of the name of the target.
One way to solve the problem is to consider that the AT is composed of a sequence of two structures: a signed structure and an unsigned structure.

In practice, the "salted aud claim" will be composed of both a one way hash function algorithm identifier and a hash value.
Before requesting an AT to an AS, the client chooses a resource server and select a resource indicator value corresponding to the identifier the resource server.
It then chooses a random value which it uses as a "aud salt claim" and then computes a hash value by using a one-way hash function which combines
one of the resource indicators of the RS with the "aud salt claim". Both the one way hash function algorithm identifier and the computed  hash value
are then included into the "salted aud claim".
The AT request then contains a "salted aud claim" instead of an"aud claim". The AT blindly copies this value into the AT which is then identified as
a "salted aud claim" instead of an "aud claim".
When the AT is received by the client, it adds to the AT the unsigned part to the AT which contains the "aud salt claim" and sends both the signed
and the unsigned part of the AT to the RS.

When the RS receives the AT, using the one way hash function algorithm identifier contained in the "salted aud claim", it combines each of its resource indicators
with the "aud salt claim" contained in the unsigned part of the AT and verifies whether it matches with the hash value contained in the "salted aud claim".
If none of these resource indicators is providing a match, then the RS SHALL rejected the AT.

The implication is to allow an AT to contain both a signed part and an unsigned part.

In addition, the "aud claim" should be multi-valued where, as a consequence, both the "salted aud claim" with the "aud salt claim" would also be multi-valued.

   token claims collection.  The client MUST NOT inspect the content of

On the contrary, a client SHALL be able to inspect the content of the access token to make sure that the AS has not included in the AT some private information
that should not be present, before forwarding the AT to the RS. It is possible for an AS to change the format of the AT, but the RS will not necessarily be in synch
with the RS.

Since there are now cases where "the authorization server and resource server are not co-located, are not ran by the same entity, or are otherwise separated
by some boundary", a key point is that an AS and a RS DO NOT necessarily need to know each other. The RS only needs to trust the AS. (full stop)

This means that an identifier of the profile of the AT should be able to be included into the AT. This allows for future extensions.

In any case, the "MUST NOT" in the quoted sentence should be removed or changed or the whole sentence should be removed..

Allowing a client to only specify a scope and a resource is very restrictive.

What would be the title of an RFC that would allow the client to request the presence of specific claims in JWT access ?

If such a restriction is kept, would the current title of this RFC still be inappropriate
"JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" ?

Denis
DP Security Consulting

---

From: Denis <[email-masked]>
Date: Fri, 10 Apr 2020 11:07:35 +0200

Hi Vittorio,

Thank you for your fast response.

You wrote:

    "/It doesn’t look very likely that an RS would simply accept tokens
    from an AS without some out of band negotiatio/n, "

and also:

    "/As far the client is concerned, the RS and the AS might switch
    their agreement/"

With such sentences, it seems that you mandate a direct negotiation 
between the AS and the RS which, by implication,
means that the AS and the RS must know each other, which is exactly what 
I want to avoid. Such some out of band negotiation
can simply be done by publishing which AT formats the AS is able to 
generate and which AT formats the RS is able to accept.
An AS can publish metadata relevant to the JWT access tokens it issues 
and a RS can do the same.

In this way, the client could consult both published lists and choose 
which common format, if any, would be appropriate.
This means that the client should be able in its AT request to specify 
the format of the AT, thus avoiding any direct some
out of band negotiation between the AS and the RS.

You continue saying:

    " /nor it seems very likely that an AS would issue tokens for
    resources it doesn’t know/".

This is where we have a major difference in our points of views. The 
number of AS is likely to be several order of magnitudes higher
compared to the number of RS. Every time a RS is being established, it 
should not have to make itself known to any AS.

This is why I wrote:

    /"a key point is that an AS and a RS DO NOT necessarily need to know
    each other. *The RS only needs to trust the AS*/*.*/(full stop)"/

You are assuming that an AS and a RS necessarily need to know each other.

You wrote:

    "/The scenario in which a token issuer isn’t aware of where the
    client will spend the corresponding token is important,
    but it is more the province of SSI than mainstream OAuth2 usage today"./

Today, as soon as an AT is targeted, the AS will be aware where the 
client is likely to spend the AT. The reality is that the scenario
in which a token issuer will not be aware of where the client will spend 
the corresponding token is today completely out of the scope
of OAuth2 usages (unfortunately, it is not a matter of mainstream or not).

For that reason, if the spec. continues to prevent to implement "Privacy 
by design" architectures and worse, mandates "Spy by design"
architectures, this should be clearly advertised in the Privacy 
Considerations section.

You recommend to specify the split AT structure I suggest in its own 
spec rather than in an interop profile for the general AT case.
The current title of the document is: "JSON Web Token (JWT) Profile for 
OAuth 2.0 Access Tokens". The content of the document
is much more than what the title implies since the introduction states :

    "Besides defining a common set of mandatory and optional claims, the
    profile provides clear indications on how determine the content of
    the issued JWT access token, how an authorization server can publish
    metadata relevant to the JWT access tokens it issues, and how
    a resource server should validate incoming JWT access tokens".

The document specifies a protocol with severe limitations in the 
authorization requests parameters and with severe limitations for the 
validation of AT.
If the spec. stays like that, it should rather be called:

  * "JSON Web Token (JWT) *Basic Protocol* for OAuth 2.0 Access Tokens" or
  * "JSON Web Token (JWT) *Basic Protocol and Profile* for OAuth 2.0
    Access Tokens".

In the future, a true Profile for OAuth 2.0 Access Tokens could then be 
written.

The case where a client would be able to inspect the content of a 
generated AT, indeed comes into contradiction with the case where the AS 
would encrypt
its content for the intended recipient and you advocate that it is 
another reason "for which the AS in the general case needs to know the 
intended recipient".
It is not the general case, but a specific case, which is more difficult 
to deploy than the simplest case where RS only need to know the AS that 
they trust.
It is a trade off /for the client/ to be able to inspect itself the AT 
of to make sure that only the RS will be able to inspect the AT.

I wrote:

    "This means that an identifier of the profile of the AT should be
    able to be included into the AT. This allows for future extensions."

You replied:

    "Can you expand on the exact scenario you are thinking of that calls
    for a version?"

Identifier formats for AT should be able to be included into :

  * the metadata published by the AS,
  * the metadata published by the RS, and
  * the AT itself.

The sketch of the scenario would be as follows.

The client consults both the metadata published by the AS and the 
metadata published by the RS and tries to find matches between token 
formats.
If there are several matches, it will choose,if possible, a match where 
it can access and understand the content of the AT. It will then inform 
the AS
of its choice by adding the identifier of the profile of the AT in the 
AT request. The AS will also include the identifier of the profile of 
the AT in the AT
so that the RS, when it receives the AT, can unambiguously decode the AT.

Finally, I will copy the end of your email.

     > Allowing a client to only specify a scope and a resource is very
    restrictive.
    Specifying scope or using resource indicators are all the mechanisms
    I am aware of that OAuth2 offers for specifying what an access token
    should be for - at least at the time in which the spec was incepted.
    (...) .

    What other interoperable mechanisms would you offer in addition to
    the ones listed here?

The client should be able to specify in its AT request additional 
attributes whose semantic is well described by the attributes description
found in section 5.1 of [OpenID.Core] or the attributes description 
found in [RFC7662] or other identity related specifications.

*Another new and last comment*: it is quite odd that there is no formal 
description of an AT profile anywhere in the current document.
A syntax description would greatly enhance interoperability.

Denis

> /> Privacy has not really been a concern in the WG since originally 
> the AT and the RS were co-located./
>
> Colocation of AS and RS was a frequent occurrence, but by no mean 
> mandatory… AFAIK one of the drivers for the changes between OAuth1 and 
> OAuth2 was providing the ability of supporting topologies where AS and 
> RS are distinct right out of the box.
>
> The scenario where AS and RS are distinct was always possible in 
> Outh2, and and not by accident. The JWT AT just happens to be 
> particularly handy in empowering the RS to validate incoming tokens 
> without having to phone home to the AS every time, hence it gives the 
> opportunity to discuss implications of that scenario more in depth, 
> but doesn’t really introduce anything that wasn’t possible before. 
> Even the possibility of a token format passing info by value isn’t 
> forbidden, default OAuth2 ATs are not mandatorily opaque- they just 
> happen not to have a well defined format.
>
> */>In such cases/*/, it is important to be able to make sure that an 
> *Authorization servers SHALL not have the capability to act as "Big 
> to be accessed by clients./
>
> The scenario in which a token issuer isn’t aware of where the client 
> will spend the corresponding token is important, but it is more the 
> province of SSI than mainstream OAuth2 usage today.
> Mainstream OAuth2 in current use, regardless of the AT format, 
> typically do know for whom the token is being issued: a great deal of 
> logic is predicated on that knowledge. Did the user consent for this 
> client to access this particular resource? Does access to this 
> resource warrant presenting a stronger authentication prompt? Are 
> there other authorization considerations that influences whether the 
> requested token should be issued? Those are considerations an AS need 
> to be able to perform in the general case, regardless of the AT 
> format. That doesn’t mean they MUST be done in every case, but making 
> them impossible would deny a lot of very important scenarios for which 
> JWT ATs (and ATs in general) are used for today.
>
> The split structure you suggest is interesting, but I would recommend 
> is enshrined in its own spec (maybe in the SSI orbit) rather than in 
> an interop profile for the general AT case.
>
> />On the contrary, a client SHALL be able to inspect the content of 
> the access token to make sure that the AS has not included in the AT 
> some private information
> with the RS.///
> I can see the value in doing what we can to prevent abuses, but I find 
> this requirement problematic. The access token is an artifact meant to 
> enable the client to access a resource. Its format remains a private 
> matter between the RS and the AS, which retains the freedom to change 
> it as they see fit without worrying about client code that takes a 
> dependency on characteristics of the AT that might very well be 
> transient. As far the client is concerned, the RS and the AS might 
> switch their agreement from JWT AT to opaque tokens to be validated 
> via introspection at any time, which would break any client side logic 
> inspecting the AT and expecting it to be a JWT. The client has no 
> control whatsoever on the content that is transmitted via opaque 
> token, hence privacy-wise the fact that the content of the JWT is 
> visible is more of a concern about such content being accessible on 
> the client. One additional point: even if clients would be able to 
> safely peek inside an AT without risking breaking their code, there’s 
> no guarantee that the client would understand the semantic of the 
> claims in the AT, as those are meant for consumption by the RS which 
> can assign any semantic to them; nor the client can reliably trust the 
> content of the claims, given that the AS could and sometimes will 
> encrypt their content for the intended recipient (another reason for 
> which the AS in the general case needs to know the intended recipient).
>
> />. It is possible for an AS to change the format of the AT, but the 
> RS will not necessarily be in synch with the RS. /
>
> Assuming that’s the case: It doesn’t look very likely that an RS would 
> simply accept tokens from an AS without some out of band negotiation, 
> nor it seems very likely that an AS would issue tokens for resources 
> it doesn’t know- see above. Such scenarios might exist, but they don’t 
> seem to model common business solutions or the typical deployment, 
> where an API will be protected by middleware/gateway with precise 
> assumptions on how to validate incoming tokens. There might be changes 
> that are inconsequential (order of claims, additional claims) but 
> anything more substantive would likely simply break the solution.
>
> /> This means that an identifier of the profile of the AT should be 
> able to be included into the AT. This allows for future extensions.///
>
> Can you expand on the exact scenario you are thinking of that calls 
> for a version? If it’s a matter of extensions, those should always be 
> possible – it’s more breaking changes that require versioning, but I 
> don’t recall precedents in similar specs.
>
> If this is aimed at mitigating the “AS changes format without telling 
> RS”, I don’t think that would work – besides of being unnecessary per 
> the above considerations, this wouldn’t protect the RS from changes 
> well within the current spec (which allows adding arbitrary claims as 
> long as it’s done according to JWT rules), from changes within the 
> claim content (eg private string formats) and from complete departures 
> from the use of JWT for ATs.
>
> />//Allowing a client to only specify a scope and a resource is very 
> restrictive./
>
> Specifying scope or using resource indicators are all the mechanisms I 
> am aware of that OAuth2 offers for specifying what an access token 
> should be for- at least at the time in which the spec was incepted. In 
> fact, resource indicators was not even RFC and in market vendors used 
> proprietary functional equivalents. What other interoperable 
> mechanisms would you offer in addition to the ones listed here?
>
> *From: *OAuth <[email-masked]> on behalf of Denis 
> <[email-masked]>
> *Date: *Thursday, April 9, 2020 at 09:26
> *To: *oauth <[email-masked]>
> *Subject: *Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for 
> OAuth 2.0 Access Tokens"
>
> 1) Privacy has not really been a concern in the WG since originally 
> the AT and the RS were co-located. However, this draft now recognizes
> that there may exist cases where "the authorization server and 
> resource server are not co-located, are not ran by the same entity,
> *Authorization servers SHALL not have the capability to act as "Big 
> *"Spy by design"* architecture instead of a *"Privacy by design"* 
> architecture.
>
> One way to solve the problem is to consider that the AT is composed of 
> a sequence of two structures: a signed structure and an unsigned 
> structure.
>
> one of the resource indicators of the RS with the "aud salt claim". 
> Both the one way hash function algorithm identifier and the computed  
> hash value
> identifier contained in the "salted aud claim", it combines each of 
> its resource indicators
> verifies whether it matches with the hash value contained in the 
> "salted aud claim".
> consequence, both the "salted aud claim" with the "aud salt claim" 
> would also be multi-valued.
>
>
> by some boundary", a key point is that an AS and a RS DO NOT 
> necessarily need to know each other. The RS only needs to trust the 
> AS. (full stop)
>
> This means that an identifier of the profile of the AT should be able 
> to be included into the AT. This allows for future extensions.
>
> In any case, the "MUST NOT" in the quoted sentence should be removed 
> or changed or the whole sentence should be removed..
>
>
> What would be the title of an RFC that would allow the client to 
> request the presence of specific claims in JWT access ?
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 11 Apr 2020 19:14:49 -0700

Hi Denis,

I am going to top-post because the quoting in this thread has become pretty
mangled.

First off, thank you for calling out the text in the document about
scenarios where "the authorization server and resource server are not
co-located, are not run by the same entity, or are otherwise separated by
some boundary"; this does indeed present some consequences for the privacy
considerations of the protocol that will need to be addressed in some
manner, though not necessarily the one that you envision.  I will try to
remember to check for this point when the document progresses to IESG
Evaluation.

You outline some interesting protocol proposals, such as letting the client
choose the token profile type, mandating (in at least some cases)
visibility into the token contents for the client, and letting the client
add additional token parameters in its request, but it seems pretty clear
to me that while these would make for an interesting protocol, that
protocol would fundamentally not be OAuth 2.0.  As such, it doesn't seem
appropriate to attempt to require them as part of this specific document.

I would also note that framing things as a contrast between "privacy by
design" and "spy by design" seems designed to evoke an emotional reaction,
and as such are actively harmful to rational technical debate.  I implore
you to focus on the facts of what data flows where and which aspects of
such flows are desirable and undesirable in the various situations under
consideration.

Finally, I'll note that though I am mostly just an observer here and not an
implementor, it's my sense that OAuth 2.0 as currently deployed involves a
relatively large number of RSes speaking to a comparable or smaller number of
ASes, and that it is common for AS implementations to have significant
amounts of logic dedicated to knowing the capabilities of the RSes they
serve.  Many of your comments do not seem consistent with this worldview,
and I invite the other WG participants to clarify if my understanding is
incorrect.

Thanks,

Ben

---

From: Denis <[email-masked]>
Date: Sun, 12 Apr 2020 17:47:03 +0200

Hi Benjamin,

Since there is tomorrow a virtual meeting and additionally I am locked 
down, by exception, I reply today.

We both agree that when the authorization server and resource server are 
not co-located, are not run by the same entity,
or are otherwise separated by some boundary" this does indeed present 
some consequences for the privacy considerations
of the protocol that will need to be addressed in some manner.

Today OAuth 2.0 has not been constructed taking into consideration this 
case, i.e. it has not been designed taking into consideration
"Privacy by Design". The fact is that OAuth 2.0 has nothing specific to 
take care of privacy principles.

There would be a simple way to solve some of my concerns: to remove in 
the Introduction (Section 1) lines 7 to 10 :

    The approach is particularly common in
    topologies where the authorization server and resource server are not
    co-located, are not ran by the same entity, or are otherwise
    separated by some boundary.

Let us now assume that privacy concerns would be addressed in either 
OAuth 2.1. or OAuth 3.0.

This spec. is supposed to be targeted to OAuth 2.0 but the header at the 
top of the page omits to mention it. Currently, it is :

    Internet-Draft       OAuth Access Token JWT Profile           March 2020

It should rather be:

    Internet-Draft       OAuth *2.0* Access Token JWT Profile          
    March 2020

There is however a problem to be solved now: to allow to easily 
distinguish between OAuth 2.0 JWT and future JWT versions.

In addition, there will be the need to be able to carry unsigned 
parameters associated with an OAuth 2.1. or OAuth 3.0 JWT.

An historical example was to be able to distinguish the version of a 
X.509 public key certificate using a version parameter.
Something similar should be done.

Section 6 (Privacy Considerations) should be modified.

The MUST NOT (inspect the content of the access token) should be removed.

Some text, like the following text, should be added:

    In topologies where the authorization server and resource server are
    not co-located, are not ran by the same entity, or are otherwise
    separated by some boundary, some privacy concerns arise. For
    security reasons, some clients may want to target their access tokens
    but, for privacy reasons, may be unwilling to disclose to
    authorization servers an identification of the resource servers they
    will access,
    so that authorisation servers will be unable to know which resources
    servers are being accessed. This profile does not contain provisions
    to address this case.

    For data minimization, openness and transparency, some clients may
    want to be able to specify with a fine granularity which of their
    identity attributes
    should be incorporated into an access token and may want verify that
    only the requested identity attributes have indeed been
    incorporated. This profile
    supports a scope parameter that allows to specify in advance which
    identity attributes should be incorporated, but the semantics of
    this parameter
    is specific to every authorisation server. Presently, there is not
    standardized way to define, with a fine granularity, which identity
    attributes will be
    incorporated into an access token.

My last new comment remains valid: it is quite odd that there is no 
formal description of an AT profile anywhere in the current document.
A syntax description would greatly enhance interoperability.

Denis

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 13 Apr 2020 20:12:50 +0000

There are use cases where the AS can be expected to know (and in fact needs to know) which RSes a token will be used with, and use cases where there is value in obscuring this fact. This spec should not be limited to only one or the other. The work you suggest to support obscuring the RS identity is not unique to any particular access token format, and is therefore out of scope for this document.

Likewise, token format negotiation is an interesting concept, but by its nature is not bound to any specific format. If you are interested in pursuing that work, I suggest submitting it as a separate I-D. A JWT access token profile provides significant value without this addition, so I don’t see any benefit in trying to incorporate it into this draft.

Note that permitting the client to inspect the access token does not prevent the AS and RS from exchanging information about the client or resource owner, as this could be done via proprietary claims with encrypted values or via separate service-to-service interactions between the RS and AS. It should also be noted that in many cases (notably ones where the AS and RS are closely affiliated) encrypting the access token preserves the resource owner’s privacy by preventing the client from seeing information that the resource owner has shared with the AS and RS but not the client.

Lastly I am against adding a mechanism for requesting arbitrary claims to be included in the access token. The purpose of the access token is to serve as credentials that the client can use to access protected resources. If the client wants claims, they should request the appropriate scopes and retrieve them from a profile or userinfo endpoint, or use OIDC. The information required by the resource server should be understood by the AS based on the resource indicators and scopes in the request. If this is not the case, then that suggests there is a trust boundary between the AS and RS and therefore needs to make its own authorization request. Since OAuth 2.0 access tokens represent an authorization grant to the client, it would be inappropriate to bundle the resource server’s authorization request into the client’s authorization request.

–

From: OAuth <[email-masked]> on behalf of Denis <[email-masked]>
Date: Sunday, April 12, 2020 at 8:48 AM
To: Benjamin Kaduk <[email-masked]>
Cc: Vittorio Bertocci <[email-masked]>, oauth <[email-masked]>
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Hi Benjamin,

Since there is tomorrow a virtual meeting and additionally I am locked down, by exception, I reply today.

We both agree that when the authorization server and resource server are not co-located, are not run by the same entity,
or are otherwise separated by some boundary" this does indeed present some consequences for the privacy considerations
of the protocol that will need to be addressed in some manner.

Today OAuth 2.0 has not been constructed taking into consideration this case, i.e. it has not been designed taking into consideration
"Privacy by Design". The fact is that OAuth 2.0 has nothing specific to take care of privacy principles.

There would be a simple way to solve some of my concerns: to remove in the Introduction (Section 1) lines 7 to 10 :

Let us now assume that privacy concerns would be addressed in either OAuth 2.1. or OAuth 3.0.

This spec. is supposed to be targeted to OAuth 2.0 but the header at the top of the page omits to mention it. Currently, it is :
Internet-Draft       OAuth Access Token JWT Profile           March 2020
It should rather be:
Internet-Draft       OAuth 2.0 Access Token JWT Profile           March 2020
There is however a problem to be solved now: to allow to easily distinguish between OAuth 2.0 JWT and future JWT versions.

In addition, there will be the need to be able to carry unsigned parameters associated with an OAuth 2.1. or OAuth 3.0 JWT.

An historical example was to be able to distinguish the version of a X.509 public key certificate using a version parameter.
Something similar should be done.

Some text, like the following text, should be added:
In topologies where the authorization server and resource server are not co-located, are not ran by the same entity, or are otherwise
separated by some boundary, some privacy concerns arise. For security reasons, some clients may want to target their access tokens
but, for privacy reasons, may be unwilling to disclose to authorization servers an identification of the resource servers they will access,
so that authorisation servers will be unable to know which resources servers are being accessed. This profile does not contain provisions
to address this case.

For data minimization, openness and transparency, some clients may want to be able to specify with a fine granularity which of their identity attributes
should be incorporated into an access token and may want verify that only the requested identity attributes have indeed been incorporated. This profile
supports a scope parameter that allows to specify in advance which identity attributes should be incorporated, but the semantics of this parameter
is specific to every authorisation server. Presently, there is not standardized way to define, with a fine granularity, which identity attributes will be
incorporated into an access token.
My last new comment remains valid: it is quite odd that there is no formal description of an AT profile anywhere in the current document.
A syntax description would greatly enhance interoperability.

Denis

Hi Denis,

mangled.

Evaluation.

consideration.

incorrect.

Thanks,

Ben

Hi Vittorio,

You wrote:

and also:

    their agreement/"

You continue saying:

This is why I wrote:

You wrote:

Considerations section.

validation of AT.

    Access Tokens".

written.

would encrypt

intended recipient".

they trust.

I wrote:

You replied:

    for a version?"

  * the AT itself.

formats.

the AS

the AT in the AT

    restrictive.

    (...) .

    the ones listed here?

Denis

Hi Denis,

Inline

some private information

necessarily be in synch

with the RS.///

restrictive./

*From: *OAuth <[email-masked]><mailto:[email-masked]> on behalf of Denis

<[email-masked]><mailto:[email-masked]>

*To: *oauth <[email-masked]><mailto:[email-masked]>

OAuth 2.0 Access Tokens"

architecture.

  * for privacy reasons, the AS must be kept ignorant of the name of

    the target.

structure.

the resource server.

then computes a hash value by using a one-way hash function which

combines

hash value

identified as

signed

its resource indicators

"salted aud claim".

SHALL rejected the AT.

unsigned part.

private information

necessarily be in synch

with the RS.

otherwise separated

AS. (full stop)

restrictive.

If such a restriction is kept, would the current title of this RFC

still be inappropriate

Denis

DP Security Consulting

OAuth mailing list