> Am 17.12.2019 um 21:03 schrieb Vittorio Bertocci > <[email protected]>: > > >> 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.
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. > >> 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 protected]> wrote: >> > 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. >> >> >> >> – >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> From: Vittorio Bertocci <[email protected]> >> Date: Monday, December 16, 2019 at 9:31 PM >> To: "Richard Backman, Annabelle" <[email protected]> >> Cc: IETF oauth WG <[email protected]>, Vittorio Bertocci <[email protected]>, >> "[email protected]" <[email protected]> >> 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 protected]> 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. >> >> >> >> 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] or with "invalid_target" as defined >> in section 2 of [ResourceIndicators]. See Section 2.2 and 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 >> <[email protected]> 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 <[email protected]> on behalf of Vittorio Bertocci >> <[email protected]> >> Date: Monday, December 16, 2019 at 2:51 PM >> To: IETF oauth WG <[email protected]> >> Cc: "[email protected]" <[email protected]> >> 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 <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
