Thank you Roman! We just published draft 11 <https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-11.html>with the two updates below, please let us know if they address your comments satisfactorily. Cheers V.
*new language *for explaining levels, in *Protocol Overview*. [..]Other methods of determining the authentication level by which the access token was obtained are possible, per agreement by the authorization server and the protected resource, but are beyond the scope of this specification. *It is worthwhile to remark that the notion of "authentication level", as used in this document, represents an assessment the resource server performs on specific authentication methods, to arbitrarily determine whether it meets its own security criteria for the requested resource. "Authentication level" in this specification does not imply, requires nor refers to an absolute hierarchy of authentication methods expressed in interoperable fashion. The notion of level emerges from the fact that the resource server will accept some methods and reject others, hence establishing a way of comparing methods that meets the intuitive notion of "step up" .* Although the case[..] *new language *for token caching in the same section. This document doesn't recommend any specific token caching strategy, as that will be dependent on the characteristics of every particular scenario *and remains application-dependent as in the core OAuth cases.* On Thu, Feb 2, 2023 at 11:31 AM Roman Danyliw <r...@cert.org> wrote: > *This message originated outside your organization.* > > ------------------------------ > > Hi Vittorio! > > > > Thanks for all of the proposed changes and explanations on where it might > not make sense. I’ve snipped the below thread down to the open issues. > Bottom line, I think just a bit more explanatory text will help the reader > understand the framing concepts or push the responsibility to applications. > > > > Roman > > > > *From:* Vittorio Bertocci <vittorio.berto...@auth0.com> > *Sent:* Thursday, January 12, 2023 4:11 PM > *To:* Roman Danyliw <r...@cert.org> > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] AD review of > draft-ietf-oauth-step-up-authn-challenge-08 > > > > Thank you Roman for the super prompt and thorough review! > > We went ahead and published draft -10 incorporating your feedback and the > changes described below. We are happy to make further changes as necessary, > of course. > > Comments Inline > > > > >** The text uses the phrase "authentication level" a few times. Was that > a phrase that was heavily negotiated? To me a level implies that some > notion of linear progression -- level-n+1 is "more security" than level-n; > and that there is some notion of hierarchy of level-n-1, level-n, and > level-n+1. I didn't see that in the construct of an acr claim. My skim of > the OIDC materials suggests that an acr is a label assigned to set a > requirements for a token. > > > > We use the term “authentication level” banking on the same intuition that > propelled “step UP” in mainstream use. The concept of authentication level > doesn’t require an absolute or even partial ordering on the domain, or that > to be encoded in ACR. All that’s needed for the “authentication level” > intuition to play out is for a RS to accept multiple ACR values, and to > consider the authentication strength associated with certain values of ACR > to meet its own bar for accessing a given resource. The RS interpretation > of ACR can be entirely private, without relying on commonly accepted > standard values, and its resulting hierarchy doesn’t need to be absolute or > even a proper lattice. We presented this spec at various conferences, and > the audience never seemed to have a hard time grasping the concept. On the > other hand, we cannot be sure that they were thinking the above… they might > just have assumed the absolute order you described :) Would some clarifying > language summarizing the above help, in your opinion? > > > > [Roman] Thanks for explaining. Can you add a bit more language to explain > the terminology of “level” just as you did in the above text. > > >Is there a reference that can be provided to explain the hierarchy of > levels? > > > > See above about whether an absolute hierarchy is strictly required. That > said, the ACR definition in > https://openid.net/specs/openid-connect-core-1_0.html#IDToken > <https://urldefense.com/v3/__https://openid.net/specs/openid-connect-core-1_0.html*IDToken__;Iw!!PwKahg!_zbGkZjN_9BTg1p6SQhtRIYniS_xtA5qNV331p9BEMUPLOPijPp-egdOjHpWxCSN7ozvPdwWtayEdloQ$> > hints at the use of NIST assurance levels in ACR values, pointing at > https://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html#anchor11 > <https://urldefense.com/v3/__https://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html*anchor11__;Iw!!PwKahg!_zbGkZjN_9BTg1p6SQhtRIYniS_xtA5qNV331p9BEMUPLOPijPp-egdOjHpWxCSN7ozvPdwWtZoi9e7M$> > and mapping to > https://pages.nist.gov/800-63-3-Implementation-Resources/63B/AAL/ > <https://urldefense.com/v3/__https://pages.nist.gov/800-63-3-Implementation-Resources/63B/AAL/__;!!PwKahg!_zbGkZjN_9BTg1p6SQhtRIYniS_xtA5qNV331p9BEMUPLOPijPp-egdOjHpWxCSN7ozvPdwWtVbIayre$> > . > > Given that those are all mentioned in the ACR definition in OIDC core, I > am not sure if it would make a big difference echoing them here, especially > given that the RS isn’t forced to stick with that. What do you think? > > > > [Roman] Per the previous comment, if you can generally explain that > “level” terminology as being figurative, I don’t think a reference is > needed. > > > > > The text seems to be suggesting that a caching strategy might be needed > but noting that the specifics will have to be application specific. It > also reminds the reader that tokens are supposed to be opaque and not > inspected. If tokens are supposed to be treated as opaque, how exactly > does one know which token to pull from the cache? Can the text provide > guidance on what non-token properties is should be using as an index? > Would it be acr_values + max_age + resource? > > > > We postulate that clients save and reuse tokens. Clients (and in > particular, SDKs used by clients) already do this today, using a variety of > strategies and cache index designs that aren’t explicitly described in > detail by any OAuth specification. Those solutions already rely on > information that can only be inferred by request and response parameters > (resourceID, path, scopes, etc), without the need to access the token’s > content. The step-up spec doesn’t change this: the application’s flow keeps > invoking resources according to the resource shape (identifier, path, etc) > and app needs (eg the API method parameters passed in specific calls) > without any need to understand ACR. in other words, if an app obtained a > token A for calling the resource http://myapi.com > <https://urldefense.com/v3/__http://myapi.com__;!!PwKahg!_zbGkZjN_9BTg1p6SQhtRIYniS_xtA5qNV331p9BEMUPLOPijPp-egdOjHpWxCSN7ozvPdwWtQes3NbU$> > and that token works for http://myapi.com/method1 > <https://urldefense.com/v3/__http://myapi.com/method1__;!!PwKahg!_zbGkZjN_9BTg1p6SQhtRIYniS_xtA5qNV331p9BEMUPLOPijPp-egdOjHpWxCSN7ozvPdwWtaHBeOlV$> > and http://myapi.com/metho > <https://urldefense.com/v3/__http://myapi.com/method1__;!!PwKahg!_zbGkZjN_9BTg1p6SQhtRIYniS_xtA5qNV331p9BEMUPLOPijPp-egdOjHpWxCSN7ozvPdwWtaHBeOlV$>d2, > but generates an error and a step-up challenge when attempting to use token > A for invoking http://myapi.com/metho > <https://urldefense.com/v3/__http://myapi.com/method1__;!!PwKahg!_zbGkZjN_9BTg1p6SQhtRIYniS_xtA5qNV331p9BEMUPLOPijPp-egdOjHpWxCSN7ozvPdwWtaHBeOlV$>d3, > leading to obtaining token B… the token caching index doesn’t need to > change to include ACR values, as future code invoking the resource and > method will simply refer to resource identifier and method path, all we are > telling the developer is not to override A with B but the way those tokens > will be retrieved from the cache doesn’t require direct knowledge of ACR. > We can’t really predict what every app needs to use to index its cache, API > method is one example but other scenarios be just as common (e.g. monetary > size of a transaction, which would be encoded by parameters rather than > methods). > > TL;DR: token caching doesn’t require remembering particular ACR values, > and every app might need to include in the cache index different parameters > hence it’s tricky for us to provide guidance. Does that clarify? I know > it’s confusing. > > > > [Roman] It does and I appreciate the difficulty in being specific now. > Could you perhaps say something to the fact that caching will have to be > application specific. >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
