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

[George Fletcher]

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

On 4/3/20 5:03 AM, Vittorio Bertocci wrote:

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 

[OAUTH-WG] I don't feel like it was good night my love

[laylafrobisher1010]

Sent from Samsung tablet.Rachel is not going to be able to make a difference 
between being in detox program has been on used to make it an excellent way to 
get out of the house ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Digest, Vol 137, Issue 110

[Andre Triverio]

Allez-vous cesser de m'envoyer des mails !
Je n'en veux pas !
Et pour se desabonner, tout est fait pouir ne pas y réussir !

Le lun. 30 mars 2020 à 18:41,  a écrit :

> Send OAuth mailing list submissions to
> oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
> oauth-requ...@ietf.org
>
> You can reach the person managing the list at
> oauth-ow...@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>1. RAR - Example JWT for Payment (Jared Jennings)
>2. Re: Error Responses in JWT Profile for OAuth 2.0 Access
>   Tokens (Karl McGuinness)
>
>
> --
>
> Message: 1
> Date: Mon, 30 Mar 2020 08:18:49 -0500
> From: Jared Jennings 
> To: oauth 
> Subject: [OAUTH-WG] RAR - Example JWT for Payment
> Message-ID:
> <
> camvrk+lp6be1-dz3bmpst+3opxws_cp7gvsnea7-t7km1ue...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I have a question about the example and maybe it's more for
> clarification than anything.
>
> The example contains type and also location.
> A couple of things
> 1. Would it add clarity if the domain was the same for both? vs.
> someorg.com
> / example.com
> 2. While only an example, would it bring clerity to past examples if the
> type was https://schema.example.com/payment_initiation and the location
> was
> https://api.example.com/payments
>
> or am I missing something what the values represent?
>
> Here's the example I am referring to on page 17.
>
> {
>   "iss": "https://as.example.com;,
>   "sub": "24400320",
>   "aud": "a7AfcPcsl2",
>   "exp": 1311281970,
>   "acr": "psd2_sca",
>   "txn": "8b4729cc-32e4-4370-8cf0-5796154d1296",
>   "authorization_details": [
>  {
> "type": "https://www.someorg.com/payment_initiation;,
> "actions": [
>"initiate",
>"status",
>"cancel"
> ],
> "locations": [
>"https://example.com/payments;
> ],
> "instructedAmount": {
>"currency": "EUR",
>"amount": "123.50"
> },
> "creditorName": "Merchant123",
> "creditorAccount": {
>"iban": "DE02100100109307118603"
> },
> "remittanceInformationUnstructured": "Ref Number Merchant"
>  }
>   ],
>   "debtorAccount": {
>  "iban": "DE40100100103307118608",
>  "user_role": "owner"
>   }
>]
>
>
> -Jared
> Skype:jaredljennings
> Signal:+1 816.730.9540
> WhatsApp: +1 816.678.4152
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200330/cdb44a38/attachment.html
> >
>
> --
>
> Message: 2
> Date: Mon, 30 Mar 2020 16:38:04 +
> From: Karl McGuinness 
> To: "vittorio.bertocci=40auth0@dmarc.ietf.org"
> 
> Cc: Aaron Parecki , OAuth WG 
> Subject: Re: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0
> Access Tokens
> Message-ID: <90853492-d222-463a-9db0-ba0ec8282...@okta.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Vittorio,
>
> I was chatting with Aaron offline about this issue and my concern is the
> addition of Authentication Information Claims in this spec opens up more
> interoperability issues that can?t be addressed with just a JWT Access
> Token spec.
>
> OAuth 2.0 AFAIK, doesn?t define any behaviors around resource owner
> authentication assurance with respect to issuing, introspecting, or
> presenting access tokens.
>
>   *   Token introspection
>   *   Token validation error responses
>   *   Token refresh
>   *   Client Remediation (oidc defined prompt=login, max_age, and
> acr_values)
>   *   Metadata
>
> This spec is defining AS behaviors that are orthogonal to the format and
> should be available via token introspection for example
>
>
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-2.2.1
>
>
> The claims listed in this section reflect in the access token the the
>types and strength of authentication that the authentication server
>enforced prior to returning the authorization response to the client.
>Their values are fixed, and remain the same across all access tokens
>that derive from a given authorization response, whether the access
>token was obtained directly in the response (e.g., via the implicit
>flow) or after one or more token exchanges (e.g., obtaining a fresh
>access token using a refresh token, or exchanging one access token
>for another via [RFC8693]).
>
>
> I was hoping one of the 

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

[Vittorio Bertocci]

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 

Re: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access Tokens

[Vittorio Bertocci]

Hi Karl,
Thanks for the comment. I agree that having a framework for further clarifying 
authentication assurance would allow SDK owner to provide even more 
functionality out of the box.
I also agree that the definition of such a framework for authentication 
assurance goes beyond the scope of the current profile. Nonetheless, defining 
in tis profile what claims should be used for carry that information isn’t 
without interop value, as it discourages the introduction of different claims 
to carry that info and at least helps SDKs to identify those claims in the 
incoming tokens and expose their values their object model/events collection, 
saving the end developer at least some work; and if more guidance about the 
values of those claims will eventually emerge, it will be easier to dovetail 
further SDK logic downstream than if we would have left even the transport 
claims entirely unspecified.
Thanks
V.
PS: if you want to draft such a spec, I am sure there would be interest in 
reviewing it 

From: Karl McGuinness 
Date: Monday, March 30, 2020 at 09:38
To: "vittorio.bertocci=40auth0@dmarc.ietf.org" 
Cc: Aaron Parecki , OAuth WG 
Subject: Re: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access 
Tokens

Hi Vittorio,

I was chatting with Aaron offline about this issue and my concern is the 
addition of Authentication Information Claims in this spec opens up more 
interoperability issues that can’t be addressed with just a JWT Access Token 
spec.

OAuth 2.0 AFAIK, doesn’t define any behaviors around resource owner 
authentication assurance with respect to issuing, introspecting, or presenting 
access tokens.

  *   Token introspection
  *   Token validation error responses
  *   Token refresh
  *   Client Remediation (oidc defined prompt=login, max_age, and acr_values)
  *   Metadata
This spec is defining AS behaviors that are orthogonal to the format and should 
be available via token introspection for example

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-2.2.1


The claims listed in this section reflect in the access token the the

   types and strength of authentication that the authentication server

   enforced prior to returning the authorization response to the client.

   Their values are fixed, and remain the same across all access tokens

   that derive from a given authorization response, whether the access

   token was obtained directly in the response (e.g., via the implicit

   flow) or after one or more token exchanges (e.g., obtaining a fresh

   access token using a refresh token, or exchanging one access token

   for another via [RFC8693]).


I was hoping one of the outcomes of this spec was toolkit/sdk interop for 
clients and resource servers.   I don’t see how this possible if all the 
semantics around requesting, validating, and remediating resource owner 
authentication assurance is implementation specific.   The end-to-end scenarios 
are not achievable with just OAuth 2.0 which breaks interop.

I think there is a real need to define resource owner authentication assurance 
interoperability for access tokens, but I fear this may require its own spec.

-Karl

Karl McGuinness
Chief Product Architect
www.okta.com


On Mar 25, 2020, at 12:59 PM, 
vittorio.bertocci=40auth0@dmarc.ietf.org
 wrote:

This message originated outside your organization.

Thanks Aaron!
You are right, we could be clearer re:errors. AFAIK the only errors we can
rely on from an RS are in RFC6750, and the entire section is about what to
look for in an incoming AT to validate, hence it doesn't look like we have
much choice but to return invalid_token for every error in the validation
checks enumerated in Section 4. I can definitely add a paragraph to that
effect (does it have to be a section?).

The re-authentication part is tricky. Technically we are still rejecting the
incoming token, hence the above should still apply.
I am not aware of tools we can use from the primitives defined in the OAuth2
family of standards for telling people how to make reauthentication happen-
and making reauth happen can be quite involved. In Azure AD there are semi
proprietary mechanisms that can be used to signal the need to repeat
authentication, say for triggering a step-up auth, by sending back together
with the error response a challenge that can in turn be used by the client
to communicate policy requirements to the AS (which is assumed to support
OIDC and accept/understand those policies in form of claim). Giving
equivalent guidance but relying only on standards seems tricky, especially
without making strong assumptions about how auth happens (e.g can we assume
OIDC?).
To solve this for the profile, I see two main ways forward:
A) We warn the reader that it's on them to decide how to signal the reauth
requirement from the API to the client, and how to use that in the