Looking at Roman’s question on LoA definitions. RFC6711 defined an IANA registry for ACR short names.
It might be worth referencing that. The registration is a bit SAML oriented but can be used for any protocol, including OIDC. John B. > On Feb 17, 2023, at 4:57 PM, Vittorio Bertocci > <vittorio=40auth0....@dmarc.ietf.org> wrote: > > 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 > <mailto: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 >> <mailto:vittorio.berto...@auth0.com>> >> Sent: Thursday, January 12, 2023 4:11 PM >> To: Roman Danyliw <r...@cert.org <mailto:r...@cert.org>> >> Cc: oauth@ietf.org <mailto: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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
