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
tir. 17. des. 2019 kl. 02:28 skrev Richard Backman, Annabelle <richanna=
40amazon....@dmarc.ietf.org>:
> 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 <oauth-boun...@ietf.org> on behalf of Vittorio Bertocci
> <Vittorio=40auth0....@dmarc.ietf.org>
> *Date: *Monday, December 16, 2019 at 2:51 PM
> *To: *IETF oauth WG <oauth@ietf.org>
> *Cc: *"i-d-annou...@ietf.org" <i-d-annou...@ietf.org>
> *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 <internet-dra...@ietf.org> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Vennlig hilsen
Steinar Noem
Partner Udelt AS
Systemutvikler
| stei...@udelt.no | h...@udelt.no | +47 955 21 620 | www.udelt.no |
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
