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 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 and mapping to https://pages.nist.gov/800-63-3-Implementation-Resources/63B/AAL/. 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 and that token works for http://myapi.com/method1 and http://myapi.com/metho<http://myapi.com/method1>d2, but generates an error and a step-up challenge when attempting to use token A for invoking http://myapi.com/metho<http://myapi.com/method1>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
