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

[Vittorio Bertocci <[e-mail]>]

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=
[e-mail]> 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.”
>
>
>
> 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 <[e-mail]> on behalf of Vittorio Bertocci
> <Vittorio=[e-mail]>
> *Date: *Monday, December 16, 2019 at 2:51 PM
> *To: *IETF oauth WG <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *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?
>
>
> 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 <[e-mail]> wrote:
>
>
> 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/
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>