Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt

From: [email-masked]
Date: Mon, 16 Dec 2019 14:48:53 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
        Author          : Vittorio Bertocci
	Filename        : draft-ietf-oauth-access-token-jwt-03.txt
	Pages           : 16
	Date            : 2019-12-16

Abstract:
   This specification defines a profile for issuing OAuth 2.0 access
   tokens in JSON web token (JWT) format.  Authorization servers and
   resource servers from different vendors can leverage this profile to
   issue and consume access tokens in interoperable manner.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-03
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 16 Dec 2019 14:50:26 -0800

Dear all,
I finally found the time to push a new draft of the JWT profile for ATs.
This version incorporates the feedback kindly provided by Brian and Aaron
at IETF105.
Unfortunately I didn't have a chance to participate to IETF106, hence we
didn't do much progress since then.
There are still two areas we didn't manage to reach consensus on:

1. Mechanisms for signaling whether the AT was obtained by a user or an
application

This point was the subject of intense debate on the list leading to IETF105.
One insight that emerged from the IETF105 discussion was that the use case
here is more about whether the AT has been obtained via a grant that
authenticated the client (regardless of what specific grant was used) vs a
public client grant- that information can be relevant to a resource as it
determines whether the identity of the client can be used in authorization
decisions (in the former case) or not (in the public client case). If
that's the scenario we are truly after, a simple, possibly optional boolean
claim (say AuthenticatedClient) would suffice.
Note for the people who didn't read the spec: I removed any reference to
this already in draft-ietf-oauth-access-token-jwt-01. I think this is an
important and useful info and standardizing it would be beneficial for
middleware and SDK creators, but ultimately this is an interop profile
hence if there's no strong desire to reach an agreement here, I am also OK
with dropping the matter and not address this function in the spec.
To summarize, I have two questions here:

A. Do we believe it's worth it to formalize in the profile a mechanism to
indicate whether the client th obtained the AT authenticated itself with
the AS?
B. If yes, are you OK wiht an optional bool claim here?

2. Claims indicating session properties

This is one area where I am far more passionate about, as it represents a
fundamental aspect that production systems (and in particular 1st party
solutions) already rely on in the current proprietary JTW ATs.
The profile currently includes the claims auth_time, acr and amr -
capturing the values of those properties at the time of the latest
authentication the user performed in the session used to issue the current
AT: at session creation, at auth step up time and so on.
Those are values that API need in order to make authorization decisions; in
the case of 1st party APIs, the AT is the only artifact they ever receive
hence there is no other way for an API to determine whether the caller
performed say MFA in order to obtain the current AT.
Since the first draft, some people signaled concerns about the current
mechanisms thru which those claims get their value. For example, it has
been proposed to maintain the original values of auth_time, acr & amr and
introduce additional claims to indicate changes (like stepup).
I am not clear on what cold go wrong with the current approach, hence I
don't have an immediate grasp of how changes like the above would help.
If the people uncomfortable with the current proposal could detail their
concern, we can brainstorm ways to make that info available to API in a
safer way. To summarize:

A. Do you have concerns with the current auth_time, arm, acr proposal? Can
you spell them out? (please read the relevant parts of the spec before
chiming in :))
B. If yes, what can we do to make that info available to RSs in a way that
makes you comfortable?

Thanks

V.

On Mon, Dec 16, 2019 at 2:49 PM <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 17 Dec 2019 01:28:37 +0000

1. Regarding AuthenticatedClient:
Does a mobile app that uses Dynamic Client Registration to establish a client secret count as an “authenticated client”? What if that registration included an assertion signed by a trusted entity (e.g., device management software) using a certificate that had been pushed to the device? Without some kind of NIST LoA-style definition of “authenticated”, a single Boolean “AuthenticatedClient” value is too ambiguous to be useful. However, I’m skeptical that we could find consensus on what that definition should be, and it may be better to define client analogs to `acr` and `amr` that provide standard ways of expressing client authentication details without getting prescriptive about what kind of authentication is “good enough.”

2. Regarding authentication session properties:
I’m confused by the definitions given for `auth_time`, `acr`, and `amr`. For `auth_time`, it says:

“…its value will either remain the same for all the JWT access tokens issued within that session or be updated to the time of latest authentication if reauthentication occurred mid-session…”

But the “For example” at the end of that definition implies that `auth_time` will not be updated. The definitions for `acr` and `amr` say the same, but also say that the “…same considerations presented for auth_time apply…” What’s the intention here: are they fixed, updated, or is it up to the deployment to decide?

I’d like to better understand the use case for putting these in the access token. If the RS is making authorization decisions based on these claims, that implies that the RS cannot rely on the AS to determine (e.g., from the requested scope) the required authentication method(s), freshness, etc. If the AS could be relied upon for this, then presumably it would not issue RTs and ATs for a scope without requiring the end user to meet the appropriate authentication requirements. If this is the case, then the RS must have a way to signal to the client (and then the AS) that a step-up authentication is required. Is there an existing mechanism through which they could do this? All I can come up with is cramming the information into the scope attribute of a WWW-Authenticate challenge, but that has the same scope opacity violation problem as described in this draft’s Security Considerations. Without a clear way to express the step-up requirements, this feels incomplete.

3. Regarding access tokens that are used to access different resource servers:
Reading between the lines, I *think* the intention is that a JWT access token that is intended to be used to access two different resources at two different RSes should look something like:

{
"aud": "https://generic-resource-indicator.example.com/",
"scope": "resource_foo resource_bar",
...
}

And the expectation is that each RS should recognize that generic audience. Is this correct? If so it seems to go against the spirit of resource indicators as indicating the target or location of a resource. It’s stretching that definition, at the very least.

But as I said, I’m reading between the lines here. If this is the intention, it should be clearly stated. Alternatively, remove (or change to a SHOULD) the requirement that multi-value `aud` claims must only contain aliases for the same resource indicator.

–
Annabelle Richard Backman
AWS Identity

From: OAuth <[email-masked]> on behalf of Vittorio Bertocci <Vittorio=[email-masked]>
Date: Monday, December 16, 2019 at 2:51 PM
To: IETF oauth WG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt

Dear all,
I finally found the time to push a new draft of the JWT profile for ATs. This version incorporates the feedback kindly provided by Brian and Aaron at IETF105.
Unfortunately I didn't have a chance to participate to IETF106, hence we didn't do much progress since then.
There are still two areas we didn't manage to reach consensus on:

1. Mechanisms for signaling whether the AT was obtained by a user or an application

This point was the subject of intense debate on the list leading to IETF105.
One insight that emerged from the IETF105 discussion was that the use case here is more about whether the AT has been obtained via a grant that authenticated the client (regardless of what specific grant was used) vs a public client grant- that information can be relevant to a resource as it determines whether the identity of the client can be used in authorization decisions (in the former case) or not (in the public client case). If that's the scenario we are truly after, a simple, possibly optional boolean claim (say AuthenticatedClient) would suffice.
Note for the people who didn't read the spec: I removed any reference to this already in draft-ietf-oauth-access-token-jwt-01. I think this is an important and useful info and standardizing it would be beneficial for middleware and SDK creators, but ultimately this is an interop profile hence if there's no strong desire to reach an agreement here, I am also OK with dropping the matter and not address this function in the spec.
To summarize, I have two questions here:
A. Do we believe it's worth it to formalize in the profile a mechanism to indicate whether the client th obtained the AT authenticated itself with the AS?
B. If yes, are you OK wiht an optional bool claim here?

This is one area where I am far more passionate about, as it represents a fundamental aspect that production systems (and in particular 1st party solutions) already rely on in the current proprietary JTW ATs.
The profile currently includes the claims auth_time, acr and amr - capturing the values of those properties at the time of the latest authentication the user performed in the session used to issue the current AT: at session creation, at auth step up time and so on.
Those are values that API need in order to make authorization decisions; in the case of 1st party APIs, the AT is the only artifact they ever receive hence there is no other way for an API to determine whether the caller performed say MFA in order to obtain the current AT.
Since the first draft, some people signaled concerns about the current mechanisms thru which those claims get their value. For example, it has been proposed to maintain the original values of auth_time, acr & amr and introduce additional claims to indicate changes (like stepup).
I am not clear on what cold go wrong with the current approach, hence I don't have an immediate grasp of how changes like the above would help.
If the people uncomfortable with the current proposal could detail their concern, we can brainstorm ways to make that info available to API in a safer way. To summarize:
A. Do you have concerns with the current auth_time, arm, acr proposal? Can you spell them out? (please read the relevant parts of the spec before chiming in :))
B. If yes, what can we do to make that info available to RSs in a way that makes you comfortable?

Thanks

V.

On Mon, Dec 16, 2019 at 2:49 PM <[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 16 Dec 2019 20:19:37 -0800

Thanks Annabelle.

Does a mobile app that uses Dynamic Client Registration to establish a
> client secret count as an “authenticated client”?

I think it should count, tho I am not sure what the RS would do with it.
Dynamic client registration would likely not have much use for this.
In the cases I have seen, the idea is that a client (whose clientID is
already known to the RS) can obtain tokens thru different grants, some of
them confidential and others public; and the resource wants to know whether
this particular token was obtained proving the identity of the client so
that it can decide whether to grant extra privileges for that
particular client in the current call. This scenario does not require the
extra details about authentication method/strength you mention that, I
agree, would be pretty hard to reach consensus on.
TL;DR: there is at least one scenario that is satisfied by the simple bool,
as the previous knowledge of the client solves the issues you mention out
of band.

authentication session properties:

 Let me try another angle. Say that I perform an authz code grant asking
for AT, ID_T and RT- obtaining AT', ID_T' and RT'.
The values of auth_time, acr and amr in AT' will be the same as the
corresponding claims in ID_T'. When the client uses RT' to obtain AT`N,
AT'N+1 etc etc, the values of those claims will remain the same for every
AT'n obtained by RT'.
Now, imagine that something happens (ignore what for the time being) that
causes the client to perform a step up auth, which requires the user to
perform interactive auth hence results in a new authz grant. The client
will obtain a new tuple  AT", ID_T" and RT". The exact same rules described
for the ' tuple apply, with the new values determined by the new
authentication: AT" auth_time/acr/amr will be the same as ID_T", and those
values will remain unchanged for every AT"n derived by RT".
If we want this to apply to the implicit flow as well, you can substitute
the RT with the session artifact.
Does that help clarifying the intent? If yes, do you feel that the current
language does not describe this?

use case for putting these in the access token

I am not trying to create a complete framework for handling step up and the
like, I am trying to create an interoperable representation of those values
no matter how they were obtained.
Consider the case in which an API allows certain operations only if a given
amr value is present in the token. Whether that amr is required upfront on
first authentication, as step up or any other reason is out of scope for
this profile IMO: the AS might have all sorts of heuristics that determine
that (user membership to a given group or role; geofencing; risk scoring;
etc) that have nothing to do with scopes requested, and are not statically
determined by RS-AS communications.
Now, I agree that formalizing how a RS communicates to the AS via the
client the need to step up and in what terms would be super useful; however
I think that's well beyond the scope of this profile. Various vendors
already have their own mechanisms for handling step up signaling from RS to
AS (I am very familiar with the Microsoft one) and all I am looking for is
a way of standardizing how to represent the outcomes, so that API gateways
and SDK providers can provide tools that work across vendors; and possibly
reuse some of the reasoning that was already done for id_tokens.
TL;DR: I think we are doing something useful in formalizing how to embed
that info an ATs even if we don't force vendors to give up their current
mechanisms to populate those values.

Regarding access tokens that are used to access different resource servers

The intent is to explicitly disallow the use of an AT with multiple
resource servers. If a client wants to talk with 2 different RSes, the
client should ask for 2 different ATs.
The spec is unambiguous on this IMO, here's the language I use in 03.

If it receives a request for an access token containing more than one
   resource parameter, an authorization server issuing JWT access tokens
   MUST reject the request and fail with "invalid_request" as described
   in section 4.1.2.1 of [RFC6749]
<https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2.1> or
with "invalid_target" as defined
   in section 2 of [ResourceIndicators
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-03#ref-ResourceIndicators>].
See Section 2.2
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-03#section-2.2>
and Section 5 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-03#section-5>
   for more details on how this measure ensures there's no confusion on
   to what resource the access token granted scopes apply.

  Is it possible you are referring to an older draft?

On Mon, Dec 16, 2019 at 5:28 PM Richard Backman, Annabelle <richanna=
[email-masked]> wrote:

> Does a mobile app that uses Dynamic Client Registration to establish a
> client secret count as an “authenticated client”? What if that registration
> included an assertion signed by a trusted entity (e.g., device management
> software) using a certificate that had been pushed to the device? Without
> some kind of NIST LoA-style definition of “authenticated”, a single Boolean
> “AuthenticatedClient” value is too ambiguous to be useful. However, I’m
> skeptical that we could find consensus on what that definition should be,
> and it may be better to define client analogs to `acr` and `amr` that
> provide standard ways of expressing client authentication details without
> getting prescriptive about what kind of authentication is “good enough.”
>
>
>
> “…its value will either remain the same for all the JWT access tokens
> issued within that session or be updated to the time of latest
> authentication if reauthentication occurred mid-session…”
>
>
>
> But the “For example” at the end of that definition implies that
> `auth_time` will not be updated. The definitions for `acr` and `amr` say
> the same, but also say that the “…same considerations presented for
> auth_time apply…” What’s the intention here: are they fixed, updated, or is
> it up to the deployment to decide?
>
>
>
> I’d like to better understand the use case for putting these in the access
> token. If the RS is making authorization decisions based on these claims,
> that implies that the RS cannot rely on the AS to determine (e.g., from the
> requested scope) the required authentication method(s), freshness, etc. If
> the AS could be relied upon for this, then presumably it would not issue
> RTs and ATs for a scope without requiring the end user to meet the
> appropriate authentication requirements. If this is the case, then the RS
> must have a way to signal to the client (and then the AS) that a step-up
> authentication is required. Is there an existing mechanism through which
> they could do this? All I can come up with is cramming the information into
> the scope attribute of a WWW-Authenticate challenge, but that has the same
> scope opacity violation problem as described in this draft’s Security
> Considerations. Without a clear way to express the step-up requirements,
> this feels incomplete.
>
>
>
> Reading between the lines, I **think** the intention is that a JWT access
> token that is intended to be used to access two different resources at two
> different RSes should look something like:
>
>
>
> {
>
> And the expectation is that each RS should recognize that generic
> audience. Is this correct? If so it seems to go against the spirit of
> resource indicators as indicating the target or location of a resource.
> It’s stretching that definition, at the very least.
>
>
>
> But as I said, I’m reading between the lines here. If this is the
> intention, it should be clearly stated. Alternatively, remove (or change to
> a SHOULD) the requirement that multi-value `aud` claims must only contain
> aliases for the same resource indicator.
>
>
>
> –
>
> *From: *OAuth <[email-masked]> on behalf of Vittorio Bertocci
> <Vittorio=[email-masked]>
> *Date: *Monday, December 16, 2019 at 2:51 PM
> *To: *IETF oauth WG <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [OAUTH-WG] I-D Action:
> draft-ietf-oauth-access-token-jwt-03.txt
>
>
>
> Dear all,
> Those are values that API need in order to make authorization decisions;
> in the case of 1st party APIs, the AT is the only artifact they ever
> receive hence there is no other way for an API to determine whether the
> caller performed say MFA in order to obtain the current AT.

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 16 Dec 2019 20:35:39 -0800

Re: aliases, I see where the confusion is coming from!
I updated the request section, but the session 2.2 data structure still
mentions the aliases. That should be cleaned up as well.
In any case the intent was always to only allow a singe resource per AT,
the alias list was only for helping in cases where an AS identifies the
same resource thru multiple IDs and the actual aud value depends on what ID
the client requested. However we discussed this with Brian and he convinced
me that it was just too ambiguous- your remark reinforces that impression.
I’ll clean up 2.2 and eliminate references to aliases from there as well.
Thanks!

On Mon, Dec 16, 2019 at 20:19 Vittorio Bertocci <[email-masked]> wrote:

> TL;DR: there is at least one scenario that is satisfied by the simple
> bool, as the previous knowledge of the client solves the issues you mention
> out of band.
>
> I am not trying to create a complete framework for handling step up and
> the like, I am trying to create an interoperable representation of those
> values no matter how they were obtained.
> Consider the case in which an API allows certain operations only if a
> given amr value is present in the token. Whether that amr is required
> upfront on first authentication, as step up or any other reason is out of
> scope for this profile IMO: the AS might have all sorts of heuristics that
> determine that (user membership to a given group or role; geofencing; risk
> scoring; etc) that have nothing to do with scopes requested, and are not
> statically determined by RS-AS communications.
>    in section 4.1.2.1 of [RFC6749] <https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2.1> or with "invalid_target" as defined
>    in section 2 of [ResourceIndicators <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-03#ref-ResourceIndicators>].  See Section 2.2 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-03#section-2.2> and Section 5 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-03#section-5>
>> I’d like to better understand the use case for putting these in the
>> access token. If the RS is making authorization decisions based on these
>> claims, that implies that the RS cannot rely on the AS to determine (e.g.,
>> from the requested scope) the required authentication method(s), freshness,
>> etc. If the AS could be relied upon for this, then presumably it would not
>> issue RTs and ATs for a scope without requiring the end user to meet the
>> Reading between the lines, I **think** the intention is that a JWT
>> access token that is intended to be used to access two different resources
>> at two different RSes should look something like:
>>
>>
>>
>> {
>>
>> One insight that emerged from the IETF105 discussion was that the use
>> case here is more about whether the AT has been obtained via a grant that
>> A. Do you have concerns with the current auth_time, arm, acr proposal?
>> Can you spell them out? (please read the relevant parts of the spec before
>> chiming in :))

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 17 Dec 2019 08:27:40 +0100

Hi Vittorio,

> On 17. Dec 2019, at 05:19, Vittorio Bertocci <Vittorio=[email-masked]> wrote:
> 
> In the cases I have seen, the idea is that a client (whose clientID is already known to the RS) can obtain tokens thru different grants, some of them confidential and others public;

just to make sure I understood correctly. Are you saying the client has credentials but is not authenticated using those in all potential scenarios? Can you pls. explain the rationale?

best,
Torsten.

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 17 Dec 2019 11:37:18 -0800

Hi Torsten!
>
> just to make sure I understood correctly. Are you saying the client has
> credentials but is not authenticated using those in all potential
> scenarios? Can you pls. explain the rationale?

Yes, that's the scenario. In Azure AD you create an app registration that
generates a clientID you can then use for web apps (confidential), native
clients (public) and the like. I believe you can do the same in google if
you create a clientID using "other" as app type, but I am not sure. I am
not 100% certain about the rationale, but I suspect it could be a way of
say optimizing consent (if I consent for scope X for the iOS version of
app1, I will not be prompted again when I access the web version of app1),
provisioning across tenants or grouping app policy options.
Even before that multi-type app registration option was introduced, AD has
ways of making confidential cleitns behave like public ones: web apps that
do have credentials, but whose clientID can be used in implicit hence
getting tokens without using app credentials.
Whether that's a good idea or not, the features have been there for a while
and there are large numbers of apps in the wild alowing for this. Let me
stress that I consider this area a nice to have and I am happy to drop it
if it's too problematic (in fact it's not in the current spec language).

On Mon, Dec 16, 2019 at 11:28 PM Torsten Lodderstedt <torsten=
[email-masked]> wrote:

> them confidential and others public;
>
> just to make sure I understood correctly. Are you saying the client has
> credentials but is not authenticated using those in all potential
> scenarios? Can you pls. explain the rationale?
>
> best,
> Torsten.
>
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 17 Dec 2019 19:39:09 +0000

> In any case the intent was always to only allow a singe resource per AT…

My confusion actually comes from the last paragraph of §3, where it says “If a scope parameter is present in the request, the authorization server SHOULD use it to infer the value of the default resource indicator to be used in the aud claim.” I interpreted that to leave room for an AS inferring the same “generic” resource indicator for resources served by different RSes. The one-RS-per-AT model is an ideal that simply doesn’t match reality. Clients don’t want to have to juggle a bunch of different tokens, nor should they need to. I’m coming to think that we shouldn’t actually use `aud` and `scope` in JWT ATs at all, and instead adopt the structure RAR defines used for the `authorization_details` parameter (I think some iteration is required, but it seems natural for these two to describe authorizations in the same or compatible ways).

> …the resource wants to know whether this particular token was obtained proving the identity of the client…

I’m skeptical of the idea that there is just one level of client identity proofing that RSes might care about. There might be some clear lines that can be drawn, but we should be explicit about what those lines represent, e.g., “client authenticated using pre-established credential”, “client is running on end user-controlled device”, etc.

> I am not trying to create a complete framework for handling step up and the like, I am trying to create an interoperable representation of those values no matter how they were obtained.

Without taking the whole picture into account, there is significant risk that we will define something that turns out to be woefully insufficient (or worse, establishes an anti-pattern). That said, I agree that it’s probably not appropriate for this draft, and recommend dropping these claims. They can always be defined in a separate draft, along with the other elements necessary to communicate step-up requirements.

–

From: Vittorio Bertocci <Vittorio=[email-masked]>
Date: Monday, December 16, 2019 at 9:31 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: IETF oauth WG <[email-masked]>, Vittorio Bertocci <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt

Re: aliases, I see where the confusion is coming from!
I updated the request section, but the session 2.2 data structure still mentions the aliases. That should be cleaned up as well.
In any case the intent was always to only allow a singe resource per AT, the alias list was only for helping in cases where an AS identifies the same resource thru multiple IDs and the actual aud value depends on what ID the client requested. However we discussed this with Brian and he convinced me that it was just too ambiguous- your remark reinforces that impression. I’ll clean up 2.2 and eliminate references to aliases from there as well.
Thanks!

On Mon, Dec 16, 2019 at 20:19 Vittorio Bertocci <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Annabelle.

Does a mobile app that uses Dynamic Client Registration to establish a client secret count as an “authenticated client”?
I think it should count, tho I am not sure what the RS would do with it. Dynamic client registration would likely not have much use for this.
In the cases I have seen, the idea is that a client (whose clientID is already known to the RS) can obtain tokens thru different grants, some of them confidential and others public; and the resource wants to know whether this particular token was obtained proving the identity of the client so that it can decide whether to grant extra privileges for that particular client in the current call. This scenario does not require the extra details about authentication method/strength you mention that, I agree, would be pretty hard to reach consensus on.
TL;DR: there is at least one scenario that is satisfied by the simple bool, as the previous knowledge of the client solves the issues you mention out of band.

authentication session properties:
 Let me try another angle. Say that I perform an authz code grant asking for AT, ID_T and RT- obtaining AT', ID_T' and RT'.
The values of auth_time, acr and amr in AT' will be the same as the corresponding claims in ID_T'. When the client uses RT' to obtain AT`N, AT'N+1 etc etc, the values of those claims will remain the same for every AT'n obtained by RT'.
Now, imagine that something happens (ignore what for the time being) that causes the client to perform a step up auth, which requires the user to perform interactive auth hence results in a new authz grant. The client will obtain a new tuple  AT", ID_T" and RT". The exact same rules described for the ' tuple apply, with the new values determined by the new authentication: AT" auth_time/acr/amr will be the same as ID_T", and those values will remain unchanged for every AT"n derived by RT".
If we want this to apply to the implicit flow as well, you can substitute the RT with the session artifact.
Does that help clarifying the intent? If yes, do you feel that the current language does not describe this?

use case for putting these in the access token
I am not trying to create a complete framework for handling step up and the like, I am trying to create an interoperable representation of those values no matter how they were obtained.
Consider the case in which an API allows certain operations only if a given amr value is present in the token. Whether that amr is required upfront on first authentication, as step up or any other reason is out of scope for this profile IMO: the AS might have all sorts of heuristics that determine that (user membership to a given group or role; geofencing; risk scoring; etc) that have nothing to do with scopes requested, and are not statically determined by RS-AS communications.
Now, I agree that formalizing how a RS communicates to the AS via the client the need to step up and in what terms would be super useful; however I think that's well beyond the scope of this profile.. Various vendors already have their own mechanisms for handling step up signaling from RS to AS (I am very familiar with the Microsoft one) and all I am looking for is a way of standardizing how to represent the outcomes, so that API gateways and SDK providers can provide tools that work across vendors; and possibly reuse some of the reasoning that was already done for id_tokens.
TL;DR: I think we are doing something useful in formalizing how to embed that info an ATs even if we don't force vendors to give up their current mechanisms to populate those values.

Regarding access tokens that are used to access different resource servers
The intent is to explicitly disallow the use of an AT with multiple resource servers. If a client wants to talk with 2 different RSes, the client should ask for 2 different ATs.
The spec is unambiguous on this IMO, here's the language I use in 03.

   in section 4.1.2.1 of [RFC6749]<https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2.1> or with "invalid_target" as defined

   in section 2 of [ResourceIndicators<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-03#ref-ResourceIndicators>].  See Section 2.2<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-03#section-2.2> and Section 5<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-03#section-5>

On Mon, Dec 16, 2019 at 5:28 PM Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]>> wrote:
1. Regarding AuthenticatedClient:
Does a mobile app that uses Dynamic Client Registration to establish a client secret count as an “authenticated client”? What if that registration included an assertion signed by a trusted entity (e.g., device management software) using a certificate that had been pushed to the device? Without some kind of NIST LoA-style definition of “authenticated”, a single Boolean “AuthenticatedClient” value is too ambiguous to be useful. However, I’m skeptical that we could find consensus on what that definition should be, and it may be better to define client analogs to `acr` and `amr` that provide standard ways of expressing client authentication details without getting prescriptive about what kind of authentication is “good enough.”

I’d like to better understand the use case for putting these in the access token. If the RS is making authorization decisions based on these claims, that implies that the RS cannot rely on the AS to determine (e.g., from the requested scope) the required authentication method(s), freshness, etc. If the AS could be relied upon for this, then presumably it would not issue RTs and ATs for a scope without requiring the end user to meet the appropriate authentication requirements. If this is the case, then the RS must have a way to signal to the client (and then the AS) that a step-up authentication is required. Is there an existing mechanism through which they could do this? All I can come up with is cramming the information into the scope attribute of a WWW-Authenticate challenge, but that has the same scope opacity violation problem as described in this draft’s Security Considerations. Without a clear way to express the step-up requirements, this feels incomplete..

{

–

From: OAuth <[email-masked]<mailto:[email-masked]>> on behalf of Vittorio Bertocci <Vittorio=[email-masked]<mailto:[email-masked]>>
Date: Monday, December 16, 2019 at 2:51 PM
To: IETF oauth WG <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt

Dear all,

This point was the subject of intense debate on the list leading to IETF105..

Thanks

V.

Abstract:

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp..ietf.org/internet-drafts/<ftp://ftp.ietf.org/internet-drafts/>

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 17 Dec 2019 12:02:59 -0800

>
> The one-RS-per-AT model is an ideal that simply doesn’t match reality.

That's a pretty strong statement :) I have worked with a very large number
of developers, on a very large number of applications. I don't dispute that
your experience might be different, but the one AT per RS is daily reality
for hundreds of thousands of apps in production today. That's real by any
measure of reality. The fact that AD offers RTs that behave like TGTs makes
it possible.
RAR is an interesting development, but it's in the inception phase. The aud
and scopes claims are already in nearly all the proprietary JWT
implementations in production today, as shown in the research I presented
when the draft was adopted by the WG, hence it seems natural to include
them in an interop profile.
Nothing prevents us from developing it further as new approaches gain
traction on the market, but for the time being I think the value of this
would be to bring some order in existing implementations and contain abuses
such as id_tokens used in lieu of access tokens today.

I’m skeptical of the idea that there is just one level of client identity
> proofing that RSes might care about.

In the scenario that led me to include this item in the discussion,
knowledge of that level isn't necessary. Again, I agree it would be useful
to define those levels, but I don't think it would be in scope here. If
inclusion of that info in the JWT AT would be conditional to do all that
work, I'd much rather drop that aspect in favor of making faster progress.

Without taking the whole picture into account, there is significant risk
> that we will define something that turns out to be woefully insufficient
> (or worse, establishes an anti-pattern). That said, I agree that it’s
> probably not appropriate for this draft, and recommend dropping these
> claims. They can always be defined in a separate draft, along with the
> other elements necessary to communicate step-up requirements.

Could you expand on a concrete scenario that would lead to an antipattern
because of the presence of those claims in the profile?
There is already logic out there predicated on those claim values,
precisely because ID_token defines them and vendors latch onto them. I am
concerned that if we don't include those claims in the profile, people will
simply keep using ID_tokens for calling APIs.

On Tue, Dec 17, 2019 at 11:39 AM Richard Backman, Annabelle <
[email-masked]> wrote:

> My confusion actually comes from the last paragraph of §3, where it says
> “If a scope parameter is present in the request, the authorization server
> SHOULD use it to infer the value of the default resource indicator to be
> used in the aud claim.” I interpreted that to leave room for an AS
> inferring the same “generic” resource indicator for resources served by
> different RSes. The one-RS-per-AT model is an ideal that simply doesn’t
> match reality. Clients don’t want to have to juggle a bunch of different
> tokens, nor should they need to. I’m coming to think that we shouldn’t
> actually use `aud` and `scope` in JWT ATs at all, and instead adopt the
> structure RAR defines used for the `authorization_details` parameter (I
> think some iteration is required, but it seems natural for these two to
> describe authorizations in the same or compatible ways).
>
>
>
>
>
> I’m skeptical of the idea that there is just one level of client identity
> proofing that RSes might care about. There might be some clear lines that
> can be drawn, but we should be explicit about what those lines represent,
> e.g., “client authenticated using pre-established credential”, “client is
> running on end user-controlled device”, etc.
>
>
>
>
>
> Without taking the whole picture into account, there is significant risk
> that we will define something that turns out to be woefully insufficient
> (or worse, establishes an anti-pattern). That said, I agree that it’s
> probably not appropriate for this draft, and recommend dropping these
> claims. They can always be defined in a separate draft, along with the
> other elements necessary to communicate step-up requirements.
>
>
>
> –
>
> *From: *Vittorio Bertocci <Vittorio=[email-masked]>
> *Date: *Monday, December 16, 2019 at 9:31 PM
> *To: *"Richard Backman, Annabelle" <[email-masked]>
> *Cc: *IETF oauth WG <[email-masked]>, Vittorio Bertocci <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action:
> I think that's well beyond the scope of this profile.. Various vendors
> this feels incomplete..
> ftp://ftp..ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 17 Dec 2019 21:38:02 +0100

> Am 17.12.2019 um 21:03 schrieb Vittorio Bertocci <Vittorio=[email-masked]>:
> 
> 
> That's a pretty strong statement :) I have worked with a very large number of developers, on a very large number of applications. I don't dispute that your experience might be different, but the one AT per RS is daily reality for hundreds of thousands of apps in production today. That's real by any measure of reality.

I second this statement. I have worked in a large deployment that strictly uses per RS ATs.

> The fact that AD offers RTs that behave like TGTs makes it possible. 

Funny, I assume any solution based on or inspired by Kerberos (like ours) works that way ;-)

> RAR is an interesting development, but it's in the inception phase. The aud and scopes claims are already in nearly all the proprietary JWT implementations in production today, as shown in the research I presented when the draft was adopted by the WG, hence it seems natural to include them in an interop profile.

Scopes can be used to identify RSs in the authorization request (and turned into aud in a token), but that’s not interoperable. Resource indicators is the first step towards interoperable means to obtain RS-specific tokens, RAR is the next evolution.

> Nothing prevents us from developing it further as new approaches gain traction on the market, but for the time being I think the value of this would be to bring some order in existing implementations and contain abuses such as id_tokens used in lieu of access tokens today.

I think including scope and aud in the JWT profile is ok but it’s not sufficient for true interoperability.

> 
>> I’m skeptical of the idea that there is just one level of client identity proofing that RSes might care about. 
> In the scenario that led me to include this item in the discussion, knowledge of that level isn't necessary. Again, I agree it would be useful to define those levels, but I don't think it would be in scope here. If inclusion of that info in the JWT AT would be conditional to do all that work, I'd much rather drop that aspect in favor of making faster progress.
> 
> Could you expand on a concrete scenario that would lead to an antipattern because of the presence of those claims in the profile?
> There is already logic out there predicated on those claim values, precisely because ID_token defines them and vendors latch onto them. I am concerned that if we don't include those claims in the profile, people will simply keep using ID_tokens for calling APIs.
>  
> 
>> On Tue, Dec 17, 2019 at 11:39 AM Richard Backman, Annabelle <[email-masked]> wrote:
>>    in section 4.1.2.1 of [RFC6749] or with "invalid_target" as defined
>>    in section 2 of [ResourceIndicators].  See Section 2.2 and Section 5
>> On Mon, Dec 16, 2019 at 5:28 PM Richard Backman, Annabelle <richanna=[email-masked]> wrote:
>> 
>> This point was the subject of intense debate on the list leading to IETF105...
>> ftp://ftp...ietf.org/internet-drafts/
>>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 17 Dec 2019 21:12:26 +0000

> That's a pretty strong statement :)

One I should’ve clarified. 😃 I don’t mean that the one-RS-per-AT model is not used at all, just that it is not universal and comes with real, practical tradeoffs that may not be appropriate for all use cases. Consequently, we should not design fundamental specs that mandate its adoption.

> …knowledge of that level isn't necessary.

Either the RS and AS have a shared understanding of that level, or the RS is trusting the AS to decide what “AuthenticatedClient” means, and set it accordingly. The latter requires that the RS only supports ASes that have a shared (or substantially similar) understanding of what that level is, which is unlikely outside of a closed system. In that case, there isn’t a lot of value in providing a standard claim, as the closed system could just as easily define a proprietary one.

> Could you expand on a concrete scenario that would lead to an antipattern because of the presence of those claims in the profile?

If I could, then I wouldn’t be concerned about defining this piece of the puzzle without the rest of it. 😃

In your experience, are the existing systems that use these claims reading them from ID Tokens, or from JWT access tokens? Are these typically clients that are accessing their own RSes, using tokens vended by an IdP? (e.g., a SaaS product that gets tokens from a hosted IDaaS product) I ask because OIDC clients can specifiy max_age and acr_values, and if client and RS are owned by the same entity then they can do whatever proprietary thing they want to indicate the reason for an authorization failure.

–

From: Vittorio Bertocci <[email-masked]>
Date: Tuesday, December 17, 2019 at 12:04 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: Vittorio Bertocci <Vittorio=[email-masked]>, IETF oauth WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt

The one-RS-per-AT model is an ideal that simply doesn’t match reality.
That's a pretty strong statement :) I have worked with a very large number of developers, on a very large number of applications. I don't dispute that your experience might be different, but the one AT per RS is daily reality for hundreds of thousands of apps in production today. That's real by any measure of reality. The fact that AD offers RTs that behave like TGTs makes it possible.
RAR is an interesting development, but it's in the inception phase. The aud and scopes claims are already in nearly all the proprietary JWT implementations in production today, as shown in the research I presented when the draft was adopted by the WG, hence it seems natural to include them in an interop profile.
Nothing prevents us from developing it further as new approaches gain traction on the market, but for the time being I think the value of this would be to bring some order in existing implementations and contain abuses such as id_tokens used in lieu of access tokens today.

–

From: Vittorio Bertocci <Vittorio=[email-masked]<mailto:[email-masked]>>
Date: Monday, December 16, 2019 at 9:31 PM
To: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>
Cc: IETF oauth WG <[email-masked]<mailto:[email-masked]>>, Vittorio Bertocci <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt

{

–

Dear all,

Thanks

V.

Abstract:

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 17 Dec 2019 21:37:48 +0000

One more line jumped out at me, in §4:

> An authorization server MAY elect to use different keys to sign id_tokens and JWT access tokens.

While the jwks_uri metadata parameter can point to a set containing multiple keys, there is no way for an AP (or OIDC OP) to indicate which keys are used for which purpose. So while an AS might choose to use key_a to sign ID Tokens and key_b to sign JWT access tokens, there is no way for the AS to indicate this to clients and RSes. This means that an AS cannot rely upon the usage of different keys to differentiate ID Tokens from JWT access tokens or any other JWT that the AS might issue, unless they have some out-of-band mechanism for indicating key purpose. I think it’s worth calling this out in Security Considerations, as this may not be obvious to readers.

It’s also worth noting that “sign them with different keys” has been suggested as a technique for preventing JWTs issued for one purpose (e.g., a SET) from being mistaken for a JWT issued for another purpose (e.g., an ID Token). This draft quite reasonably and naturally reuses existing AS metadata, and in so doing breaks this technique. It serves as a good example of why explicit JWT typing is important.

–

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tuesday, December 17, 2019 at 11:39 AM
To: Vittorio Bertocci <Vittorio=[email-masked]>
Cc: IETF oauth WG <[email-masked]>, Vittorio Bertocci <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt

–

{

–

Dear all,

Thanks

V.

Abstract:

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 17 Dec 2019 13:42:00 -0800

>
> we should not design fundamental specs that mandate its adoption.

Thanks for clarifying! Here I go back to the intent, which is to provide an
interoperable projection of ATs in JWT. I think it's reasonable for an
interop profile to focus on the simplest case, which also happens to
reflect the most common strategy in all the concrete implementations
surveyed (nearly all the implementaitons considered had single value aud).
This profile does not explicitly disallow vendors from doing something else
if they so choose, but current usage does not justify specifying more
complex behaviors.

 there isn’t a lot of value in providing a standard claim, as the closed
> system could just as easily define a proprietary one.

This I do buy, and that's exactly the kind of feedback I was hoping to
get.  Unless someone resurrects the matter, I'll just drop this particular
aspect (which, again, was already not included in the spec).

are the existing systems that use these claims reading them from ID Tokens,
> or from JWT access tokens?

Both

 Are these typically clients that are accessing their own RSes, using
> tokens vended by an IdP?
Not the most frequent case. The case I have seen most frequently was with
custom clients accessing a vendor API- hence client and API owned by two
different entities (tho the programming model was dictated by the vendor
itself, hence the client developer had limited freedom).
Note that RSes receiving acr/amr might not necessarily have a strict
fail/succeed reaction to the incoming values: for example, the auth level
might determine whether the results returned include or exclude certain
elements.

On Tue, Dec 17, 2019 at 1:12 PM Richard Backman, Annabelle <
[email-masked]> wrote:

> One I should’ve clarified. 😃 I don’t mean that the one-RS-per-AT model
> is not used at all, just that it is not universal and comes with real,
> practical tradeoffs that may not be appropriate for all use cases.
> Consequently, we should not design fundamental specs that mandate its
> adoption.
>
>
>
>
>
> Either the RS and AS have a shared understanding of that level, or the RS
> is trusting the AS to decide what “AuthenticatedClient” means, and set it
> accordingly. The latter requires that the RS only supports ASes that have a
> shared (or substantially similar) understanding of what that level is,
> which is unlikely outside of a closed system. In that case, there isn’t a
> lot of value in providing a standard claim, as the closed system could just
> as easily define a proprietary one.
>
>
>
> > Could you expand on a concrete scenario that would lead to an
> antipattern because of the presence of those claims in the profile?
>
>
>
> In your experience, are the existing systems that use these claims reading
> them from ID Tokens, or from JWT access tokens? Are these typically clients
> that are accessing their own RSes, using tokens vended by an IdP? (e.g., a
> SaaS product that gets tokens from a hosted IDaaS product) I ask because
> OIDC clients can specifiy max_age and acr_values, and if client and RS are
> owned by the same entity then they can do whatever proprietary thing they
> want to indicate the reason for an authorization failure.
>
>
>
> –
>
> *From: *Vittorio Bertocci <[email-masked]>
> *Date: *Tuesday, December 17, 2019 at 12:04 PM
> *Cc: *Vittorio Bertocci <Vittorio=[email-masked]>, IETF oauth
> WG <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action:
> RAR is an interesting development, but it's in the inception phase. The
> aud and scopes claims are already in nearly all the proprietary JWT

---

From: Steinar Noem <[email-masked]>
Date: Wed, 18 Dec 2019 08:44:12 +0100

Hi Vittorio!

At HelseID we indicate the method that was used for client authentication
in our ATs. For us, this is the case both with or without a user.
If the client used a client-assertion for authentication we would give some
indication about the key material that was used. In our case that would be
either a x.509 enterprise certificate (that carries an organizational
number) or a key-pair.
We actually use a client analog to *amr*, as Anabelle suggests.

These claims add value for the resources that rely on for several reasons,
one being authorization policies for APIs that expose sensitive data.

- Steinar

-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| [email-masked] | [email-masked]  | +47 955 21 620 | www.udelt.no |

---

From: Brian Campbell <[email-masked]>
Date: Wed, 18 Dec 2019 14:08:44 -0700

> language does not describe this?

That makes sense. The current language for auth_time could be tightened up
somewhat, however. I think there's still potential for it to be interpreted
such that AT'N+1 would somehow magically get a new auth_time value based on
a step-up or re-auth that happened after, and independent of, the
authentication event that led to the code that obtained RT'. Which is
nonsensical. Also "authenticaiton" is spelled funny. Here's an attempt at
some words for auth_time:

Suggested(ish) Text:
   auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core].
      This claim represents the time at which the end user
      last authenticated during the session that was used to obtain the
token.
      This means that all the JWT access tokens
      obtained with a given refresh token will all have the same value
      of auth_time, corresponding to the instant in which the user
      authenticated to obtain the refresh token.

Current Text:
   auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core].
      Important: as this claim represents the time at which the end user
      last authenticated, its value will either remain the same for all
      the JWT access tokens issued within that session or be updated to
      the time of latest authentication if reauthentication occurred
      mid-session (as it is the case for step up authenticaiton and
      similar occurrences).  For example: all the JWT access tokens
      obtained with a given refresh token will all have the same value
      of auth_time, corresponding to the instant in which the user first
      authenticated to obtain the refresh token.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Brian Campbell <[email-masked]>
Date: Wed, 18 Dec 2019 14:19:00 -0700

-03 Sec 2.1 has:
 "The typ header parameter for a JWT access token MUST be at+jwt.  See
 the security considerations section for details on the importance of
   preventing JWT access tokens to be interpreted as id_tokens."

As previously mentioned in
https://mailarchive.ietf.org/arch/msg/oauth/BWH6BEhKt29aJ4TUYtcLckdCqO4
Connect doesn't say anything about checking the "typ" header of id tokens
so typing ATs with "at+jwt" doesn't actually do anything to prevent JWT
access tokens being used as id tokens. It can prevent misuse in the other
direction. But this document probably shouldn't overstate what typing the
JWT can accomplish.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 18 Dec 2019 14:30:18 -0700

> I’ll clean up 2.2 and eliminate references to aliases from there as well.

Yes, please clean up sec 2.2.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 18 Dec 2019 14:53:15 -0700

But there's more going on with aud that needs to be looked at and/or wasn't
updated.

I think this
    "The aud
      claim MAY include a list of individual resource indicators if they
      are all aliases referring to the same requested resource known by
      the authorization server."
should be removed from 2.2.

Resource Indicators is about how the client conveys the target to the AS
and says " The authorization server may use the exact 'resource' value as
the audience or it may map from that value to a more general URI or
abstract identifier for the given resource". The following from sec 3 is
more restrictive / prescriptive, which seems to reach beyond the scope of
the JWT access token profile.
   "If the request includes a resource parameter (as defined in
   [ResourceIndicators]), the resulting JWT access token aud claim MUST
   have the same value as the resource parameter in the request."

And sec 4 also has talk of aliases.
"   4.  The resource server MUST validate that the aud claim contains the
       resource indicator value corresponding to the identifier the
       resource server expects for itself.  The aud claim MAY contain an
       array with more than one element.  The JWT access token MUST be
       rejected if aud does not list the resource indicator of the
       current resource server as a valid audience, or if it contains
       additional audiences that are not known aliases of the resource
       indicator of the current resource server.
I'd suggest deleting everything after the comma.

If you really want to limit things to a single aud value (and my
understanding is that you do), maybe just place the restriction on the AS
to only issue with a single aud value.

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 18 Dec 2019 22:31:38 +0000

I think a proper explanation is a little too much to cram into a definition list entry. I suggest keeping those definitions light, and reference a subsection with something like the following text:

The `acr`, `amr`, and `auth_time` claims describe 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 [TokenExchange]).

These claims provide a snapshot view of authentication information at a specific point in time, and may not necessarily reflect the current status of the resource owner’s session at the authorization server, for example if the resource owner has since completed additional challenges, or signed out.  In order to obtain an up-to-date view of this information, the client must make a new authorization request.

We’re dancing around the idea of an “authorization session” here, which is something I think a lot of us intuitively understand but is not actually formally described anywhere. I’m not sure if explicitly describing it here would make things more or less confusing. 🤷🏻‍♀️

–

From: Brian Campbell <bcampbell=[email-masked]>
Date: Wednesday, December 18, 2019 at 1:09 PM
To: Vittorio Bertocci <[email-masked]>
Cc: "Richard Backman, Annabelle" <[email-masked]>, IETF oauth WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt

On Mon, Dec 16, 2019 at 9:20 PM Vittorio Bertocci <Vittorio=[email-masked]<mailto:[email-masked]>> wrote:

That makes sense. The current language for auth_time could be tightened up somewhat, however. I think there's still potential for it to be interpreted such that AT'N+1 would somehow magically get a new auth_time value based on a step-up or re-auth that happened after, and independent of, the authentication event that led to the code that obtained RT'. Which is nonsensical. Also "authenticaiton" is spelled funny. Here's an attempt at some words for auth_time:

Suggested(ish) Text:
      last authenticated during the session that was used to obtain the token.

Current Text:

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 23 Dec 2019 11:13:44 -0800

> Either the RS and AS have a shared understanding of that level, or the RS is trusting the AS to decide what “AuthenticatedClient” means, and set it accordingly. The latter requires that the RS only…

Talk of the different potential levels of authentication calls to mind RFC
8485's "Vectors of Trust" idiom, though, IIUC, it would require some
adaptation to be useful here.

-Ben

---

From: Justin Richer <[email-masked]>
Date: Mon, 23 Dec 2019 16:59:58 -0500

Vectors of Trust was meant to be used in place of things like AuthenticationContextReference (acr) and its kin, so this is a fair assessment. 

It does still require a shared understanding of what a given vector means by processing it in the context of its trust mark.

 — Justin

> On Dec 23, 2019, at 2:13 PM, Benjamin Kaduk <[email-masked]> wrote:
>