Jaimandeep, With the chair hat on, and as the shepherd for this document, I think that the authors addressed your comments in detail, and Warren provided you with some valuable responses. I do not see a need for any further discussion at this stage.
The next step is the shepherd review, which could start a new discussion about this document. Regards, Rifaat On Tue, Oct 25, 2022 at 2:11 PM Jaimandeep Singh <jaimandeep.phdcs21= 40nfsu.ac...@dmarc.ietf.org> wrote: > Dear Warren, > > It is always nice to read your elaborately written views. It helps in > getting perspective. > > I have a slightly different take on the subject. What is the client > application going to do with the "acr_values"? Ultimately, it is going to > send these values to the authorization server in order to meet the required > end-user authentication criteria. This is what I am referring to as reverse > flow RS->client_app->AS. > > I'm on the fence of calling the "user agent" untrusted. > > Here we have to consider client applications that are other than browsers > such as native apps and these apps can surely be called "untrusted". These > native apps will first receive the "acr_values" from the RS and will then > use the "user agent" to pass the values to the authorization server. > > I'd ask for at least one practical attack that this RFC enables (not >> necessarily causes). > > > Well I will start at the abstract level first. Wherever the trust > boundaries are crossed it results in security complications. Here the data > is moving from trusted (RS)->untrusted (client-app)->trusted(AS). Now, > coming to specific examples, > > Example 1: OWASP Top10: API8:2019 Injection. Once the client_app presents > the "acr_values" data to the authorization server it has to be sanitized, > otherwise it can result in unintended command execution. > > Example 2: OWASP Top 10: API1:2019 Broken Object Level Authorization. The > client_app will use all possible combinations of "acr_values" to know the > behaviour of the particular authorization endpoint/server. > > On Tue, Oct 25, 2022 at 5:23 PM Warren Parad <wpa...@rhosys.ch> wrote: > >> I'm glad that we can move on from item No 1. Regarding this second one, >> the AS is not required to be involved in this communication, as the RS >> already has the capability to convey to the user agent why the access token >> is denied. It just hasn't been standardized. There are lot's of reasons why >> an access token or the user identity the token is for might not contain the >> necessary authorization to access to the resource. I see here we are only >> codifying that communication rather than opening any holes. >> >> What's the reason for needing to sign data from the RS, the RS might not >> even be a client of the AS, so if theoretically necessary, we would have to >> challenge our suggested implementation. Is there a specific security >> problem you are thinking about? >> >> I'm on the fence of calling the "user agent" untrusted. Sure it is, but >> the browsers have the expectation to expose the requests from the RS to the >> user, if we blindly passed the acr_values from the RS directly to the AS >> then there would be a problem, but signing the values wouldn't change >> anything. In any case the user agent/client application can't be agnostic >> to the acr_values because updating the acr actually does require user >> input. While the user agent the user is using to interact with the RS might >> not be the same one used for the AS in the acr needed value, for instance >> the hypothetical SMS, still there is a user interaction. >> >> I'm not seeing any security issue here, and while exposing data to a >> malicious attacker is always a concern, this is opt-in functionality by the >> RS, so if they are concerned they need not implement the RFC. I'd ask for >> at least one practical attack that this RFC enables (not necessarily >> causes). >> >> On Tue, Oct 25, 2022 at 1:29 PM Jaimandeep Singh < >> jaimandeep.phdc...@nfsu.ac.in> wrote: >> >>> Dear Warren, Brian and Vittorio, >>> My concerns regarding the additional complexity are well addressed by >>> Warren. I am reproducing the same for sake of records in the email archive. >>> >>>> I'd love to see a situation where it is a better at the gateway level. >>>> The problem is that, even if you could, you almost certainly shouldn't, >>>> since doing so couples the gateway to the authorization check/permissions >>>> validation of the service. The gateway now needs to become away of how the >>>> underlying resources work. >>> >>> Even in simple scenarios, this becomes impossible to manage since >>>> understanding the "business logic" is required to know "whether a user >>>> should have access". That means the gateways are doomed from the start. >>> >>> As I mentioned it is possible, doing the check at the component level >>>> can be augmented by a system that manages those permissions, which >>>> different from doing the check at the gateway level. At least this is what >>>> we advice the clients of our CIAM solution. >>> >>> >>> I would like to close the concerns regarding Item No-1 and move on >>> towards Item No 2. I am reproducing the conversation for sake of ease of >>> reference. >>> >>> *Item No 2*: Punching a security hole by requiring AS to act on >>> information provided by the client applications (Reverse Flow). >>> *Follow-up Comments-v2*. Refer Section abstract of draft RFC >>> >>>> This document also codifies a mechanism for a client to request that an >>>> authorization server achieve a specific authentication strength or >>>> freshness when processing an authorization request. >>> >>> >>> a. In our journey of OAuth 2.0 we are still struggling with security >>> issues related to access tokens from AS->clientapp->RS. Now, we are >>> introducing a reverse flow, which is likely to introduce numerous other >>> vulnerabilities. Whenever the communication crosses the boundaries from >>> trusted -> untrusted -> trusted it creates its own set of security >>> problems. >>> b. Need for signing the values (error_codes) returned by the RS which >>> can be verified by the AS. Therefore, we need to look at ways by which the >>> RS returns a signed JWT token containing "acr_values" or other such >>> parameters which are opaque to the client applications. I also appreciate >>> that signed JWT will create its own complexities especially with regards to >>> verifying the association between the RS and its public key. >>> >>> >>> On Mon, Oct 24, 2022 at 6:18 PM Jaimandeep Singh < >>> jaimandeep.phdc...@nfsu.ac.in> wrote: >>> >>>> Dear Warren, >>>> It seems reasonable to handle items one by one in order to reach >>>> convergence. I am taking up Item No1 in this email to achieve convergence >>>> and close the same. The previous suggestions can be referenced at >>>> part-1 >>>> <https://mailarchive.ietf.org/arch/msg/oauth/rNqEACxVM1OtDfT5SIQDybSK6kk/>, >>>> part-2 >>>> <https://mailarchive.ietf.org/arch/msg/oauth/U8c9JfHCnmcbX238zXWTuRgx2BE/> >>>> and part-3 >>>> <https://mailarchive.ietf.org/arch/msg/oauth/SsollGVV01oPmYYTef25-SYVYok/> >>>> . >>>> >>>> *Item No 1*: Striking at the core of OAuth 2.0 idea by coupling end >>>> user authentication with authorization. >>>> *Follow-up Comments-v3*. My original concern was the introduction of >>>> tight coupling between end user authentication and the OAuth 2.0. It was >>>> explained by Brian that the draft RFC does not intend to introduce any >>>> coupling and just provides a channel of signal/information flow between AS >>>> and RS via client app. It is just that the signal as of now only contains >>>> data on the end-user authentication. This seems to be a >>>> reasonable explanation and the point is not pressed further. However, this >>>> has raised two sub concerns. One is mentioned in Item No5, so I am not >>>> taking it up here. >>>> >>>> The other remaining sub concern is the complexity introduced due to the >>>> introduction of the new channel. If we look from the higher level of >>>> abstraction, earlier the events concerned were handled at the >>>> interface/entry level, now the information about the events is passed on to >>>> the other components of the system . All the other components may handle >>>> the events as per their policies and can be out of sync with each other. >>>> >>>> Coming back to OAuth 2.0, earlier the authentication complexities were >>>> handled by AS as per OIDC specs. Now, with the introduction of this >>>> channel, the authentication event information is being passed on to the RS. >>>> The requirement/behaviour of RS may not be in sync with the requirements of >>>> AS. I had given a hypothetical example of one such complexity in my email >>>> part-3. Just to give another flavour of the complexity I am quoting from >>>> Section 5 of the draft RFC which acknowledges the existence of loops being >>>> handled by OIDC specs. >>>> >>>> The recommended behavior will help prevent clients getting stuck in a >>>>> loop where the authorization server keeps returning tokens that the >>>>> resource server already identified as not meeting its requirements hence >>>>> known to be rejected as well. >>>> >>>> >>>> If the esteemed members are of the view that the benefits accrued are >>>> more than the complexity introduced we can close the concern and move >>>> ahead. I would request the members to give their views. >>>> >>>> >>>> On Mon, Oct 24, 2022 at 3:51 PM Warren Parad <wpa...@rhosys.ch> wrote: >>>> >>>>> I get the sense we are diverging from a resolution to your questions >>>>> rather that converging on one. Given that some of the items reference >>>>> each >>>>> other, would it be possible for you to prioritize which item you are most >>>>> concerned with? Then we could work through that one and then move on to >>>>> the >>>>> next point. By this email I'm now lost on the current issues with the spec >>>>> from your perspective which makes it hard, at least for me, to continue >>>>> this conversation. >>>>> >>>>> Is item 1 the primary concern you want to discuss or is it something >>>>> else? >>>>> >>>>> On Mon, Oct 24, 2022, 07:52 Jaimandeep Singh < >>>>> jaimandeep.phdc...@nfsu.ac.in> wrote: >>>>> >>>>>> Dear Brian, Warren and Vittorio, >>>>>> >>>>>> Thank You for taking out time and efforts in giving the detailed >>>>>> explanation. After spending considerable time on the explanations >>>>>> provided, >>>>>> my follow-up comments are given below for the considered view of the >>>>>> esteemed members. The original comments are at part1 >>>>>> <https://mailarchive.ietf.org/arch/msg/oauth/rNqEACxVM1OtDfT5SIQDybSK6kk/> >>>>>> and part2 >>>>>> <https://mailarchive.ietf.org/arch/msg/oauth/U8c9JfHCnmcbX238zXWTuRgx2BE/> >>>>>> . >>>>>> >>>>>> *Item No 1*: Striking at the core of OAuth 2.0 idea by coupling end >>>>>> user authentication with authorization. >>>>>> *Follow-up Comments-v2*. >>>>>> >>>>>>> by allowing a resource server to signal to a client that the >>>>>>> authentication event associated with the access token of the current >>>>>>> request doesn't meet its requirements (however the RS determines that) >>>>>>> and >>>>>>> convey that to the AS in the authorization request (via the user's >>>>>>> browser) >>>>>>> to remediate. >>>>>> >>>>>> In my view we are creating an information/signal channel between AS >>>>>> and RS via client app. Both AS and RS may or may not act on this >>>>>> information/signal depending upon their policies and is out of the scope >>>>>> of >>>>>> the draft RFC. The forward path of this information/signal channel can >>>>>> piggyback on the existing mechanism of the access tokens. However, no >>>>>> such >>>>>> mechanism exists for the reverse path from RS to AS in the OAuth 2.0 >>>>>> specs. >>>>>> The question then arises:- >>>>>> >>>>>> a. Do we need to restrict the signals only to the end user >>>>>> authentication or are there any more signals to be considered. This >>>>>> question was previously asked by Yusuf. I have suggested other options in >>>>>> Item No 5 of this email. >>>>>> >>>>>> b. Are we comfortable in opening up a reverse channel from RS to AS >>>>>> via client app which will potentially open OAuth 2.0 to numerous other >>>>>> vulnerabilities as mentioned in Item No 2. >>>>>> >>>>>> c. These signals are already well handled at the entry point i.e AS >>>>>> level through various specs like OIDC. Then, is there a need to again >>>>>> send >>>>>> these signals to RS and then carry the response back to AS? Is this not >>>>>> overly complicating the OAuth process? A hypothetical example of such a >>>>>> complication is given below. >>>>>> >>>>>> Hypothetical example. Say tomorrow the draft RFC is implemented and >>>>>> now a particular RS decides that its high value scopes can only be >>>>>> accessed >>>>>> by end-users authenticated using MFA. This may result in a scenario >>>>>> wherein, the end-user is not able to read his own emails if he does not >>>>>> have MFA enabled. Alternatively, he may be locked out, in case the email >>>>>> client application used by him does not support MFA. The concept of >>>>>> "freshness!!" may result in the requirement of logging in every hour or >>>>>> every day for accessing own emails. >>>>>> >>>>>> *Item No 2*: Punching a security hole by requiring AS to act on >>>>>> information provided by the client applications (Reverse Flow). >>>>>> *Follow-up Comments-v2*. Refer Abstract of draft RFC >>>>>> >>>>>>> This document also codifies a mechanism for a client to request that >>>>>>> an authorization server achieve a specific authentication strength or >>>>>>> freshness when processing an authorization request. >>>>>> >>>>>> In our journey of OAuth 2.0 we are still struggling with security >>>>>> issues related to access tokens from AS->clientapp->RS. Now, we are >>>>>> introducing a reververs flow, which will itself introduce numerous other >>>>>> vulnerabilities. Whenever the communication crosses the boundaries from >>>>>> trusted -> untrusted -> trusted it creates its own set of security >>>>>> problems. >>>>>> >>>>>> *Item No 3*: Forcing AS to implement OIDC specifications will render >>>>>> existing implementations non-compliant. >>>>>> *Follow-up Comments-v2*. >>>>>> >>>>>>> I don't see how this as being biased. I see it as a pragmatic >>>>>>> decision aimed at simplification and interoperability. >>>>>> >>>>>> Using two simple constructs may seem innocuous at first, but it does >>>>>> give an impression that OIDC is the preferred mechanism for the >>>>>> authentication of the end-user as compared to any other implementations. >>>>>> >>>>>> *Item No 4*: How much “Freshness” is fresh? >>>>>> *Follow-up Comments-v2*. The parameters like "expires_in" have >>>>>> already been defined in the original RFC 6749 without the need of the >>>>>> term >>>>>> "Freshness". >>>>>> >>>>>> *Item No 5*: Why not include client app parameters in the signal >>>>>> flow? >>>>>> *Comments*. Vittorio's answer to Yusuf's email dated 13 Oct 2022. >>>>>> >>>>>>> During the discussion we did inquire on other parameters/aspects >>>>>>> that would have the same direct applicability but nothing was >>>>>>> identified. >>>>>> >>>>>> We may consider including various parameters of the client app in the >>>>>> step-up as it is intrinsic to the OAuth 2.0 specs and plays a big role in >>>>>> how the permission is granted for restricted scopes. >>>>>> >>>>>> Let us see how Google handles the restricted scopes. Refer here >>>>>> <https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification> >>>>>> . >>>>>> >>>>>>> The Gmail and Fit APIs limit the apps that can seek permission to >>>>>>> access consumer data. These additional requirements for restricted >>>>>>> scopes >>>>>>> require an app to demonstrate that they're a permitted application type >>>>>>> and >>>>>>> to submit to additional reviews, which include a possible security >>>>>>> assessment by a third-party auditor. >>>>>> >>>>>> Here, the problem of restricted or sensitive scopes is handled >>>>>> through security assessment of the apps requesting these scopes. >>>>>> >>>>>> The signal related to the client app could therefore carry the >>>>>> following information: >>>>>> a. Type of client app >>>>>> b. How has it been identified i.e using basic authentication, mTLS or >>>>>> other such techniques. >>>>>> c. Security assessment of the client app >>>>>> >>>>>> Wishing everyone a Happy Diwali >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Oct 22, 2022 at 12:49 AM Brian Campbell <bcampbell= >>>>>> 40pingidentity....@dmarc.ietf.org> wrote: >>>>>> >>>>>>> Thanks Warren, it's a good reminder about REQUIRED/MUST/etc meaning >>>>>>> in the context of the given document. >>>>>>> >>>>>>> As far as references are concerned. IETF documents can reference >>>>>>> non-IETF documents. It's not at all uncommon. And a number of OAuth RFCs >>>>>>> and in-progress drafts do already reference OIDC; draft-ietf-oauth-v2-1, >>>>>>> draft-ietf-oauth-security-topics, rfc9068, rfc8725, rfc9101, rfc9126, >>>>>>> rfc9207 being just a partial list. >>>>>>> >>>>>>> >>>>>>> On Fri, Oct 21, 2022 at 6:39 AM Warren Parad <wparad= >>>>>>> 40rhosys...@dmarc.ietf.org> wrote: >>>>>>> >>>>>>>> REQUIRED always means "in the context of the RFC". >>>>>>>> >>>>>>>> I fully agree to your statement that 'existing implementations >>>>>>>>> aren't expected to comply with the new specification'. However, the >>>>>>>>> point I >>>>>>>>> am making is that we cannot be biased towards OIDC specifications and >>>>>>>>> leave >>>>>>>>> others non-compliant. We have to make future specifications such that >>>>>>>>> it >>>>>>>>> doesn't favour one over other. >>>>>>>> >>>>>>>> >>>>>>>> Regarding OAuth 2.0 references, we already have a AS metadata >>>>>>>> parameter and the AS doesn't have to return the acr values, which in >>>>>>>> itself >>>>>>>> is a signal. So switching the expectations to OPTIONAL, in my opinion >>>>>>>> would >>>>>>>> be a mistake. We aren't leaving others as "non-compliant". Sure they >>>>>>>> are >>>>>>>> "non-compliant" with this new RFC, but they aren't "non-compliant" with >>>>>>>> regards to OIDC nor OAuth2.0. >>>>>>>> >>>>>>>> On the flip side, I'm not sure how I feel about directly >>>>>>>> referencing the implementations found in OIDC. If there is a pattern we >>>>>>>> wish to adapt, it does follow for me that we explicitly document that >>>>>>>> pattern within the RFC and not link to the OIDC reference. >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Oct 21, 2022 at 2:04 PM Jaimandeep Singh >>>>>>>> <jaimandeep.phdcs21=40nfsu.ac...@dmarc.ietf.org> wrote: >>>>>>>> >>>>>>>>> Dear Vittorio, >>>>>>>>> >>>>>>>>> Thankyou for the detailed reply. My follow-on suggestions and >>>>>>>>> recommendations are given below for kind consideration please [The >>>>>>>>> original >>>>>>>>> suggestions can be found here >>>>>>>>> <https://mailarchive.ietf.org/arch/msg/oauth/rNqEACxVM1OtDfT5SIQDybSK6kk/> >>>>>>>>> ]: >>>>>>>>> >>>>>>>>> *Item No 1*: Striking at the core of OAuth 2.0 idea by coupling >>>>>>>>> end user authentication with authorization. >>>>>>>>> *Follow-on Comment*: Thx for bringing out that RFC 9068 already >>>>>>>>> has "acr'' as a claim. However, it is an OPTIONAL claim, whereas >>>>>>>>> section 5 >>>>>>>>> of the draft RFC recommends it to be a required parameter. >>>>>>>>> Notwithstanding, >>>>>>>>> in my view, the proposed draft is challenging the very premises of >>>>>>>>> OAuth >>>>>>>>> 2.0 by strongly coupling the authorization layer with the end user >>>>>>>>> authentication. The OAuth 2.0 is supposed to be agnostic to the end >>>>>>>>> user >>>>>>>>> authentication. Are we comfortable with this coupling? >>>>>>>>> *Recommendation*: The draft RFC should be made informational. If >>>>>>>>> that is out of scope then all the proposed claims, parameters and >>>>>>>>> headers >>>>>>>>> should be made OPTIONAL. >>>>>>>>> >>>>>>>>> *Item No 2*: Punching a security hole by requiring AS to act on >>>>>>>>> information provided by the client applications (Reverse Flow). >>>>>>>>> *Follow-on Comment*: I would like to differ on this view. The >>>>>>>>> client applications do require authentication in case of confidential >>>>>>>>> clients (Refer Section 2.3 of RFC 6749). I would also like to point >>>>>>>>> towards >>>>>>>>> the Google OAuth 2.0 page which talks about 'creation of authorization >>>>>>>>> credentials' by the client applications and can be accessed here >>>>>>>>> <https://developers.google.com/identity/protocols/oauth2/web-server> >>>>>>>>> . >>>>>>>>> The point I am making is that the client application needs to >>>>>>>>> authenticate itself with the OAuth 2.0 endpoint before starting the >>>>>>>>> communication. Also, making AS act on information provided by >>>>>>>>> client applications may lead to future vulnerabilities as client >>>>>>>>> applications are not considered 'trusted' especially when we follow >>>>>>>>> zero >>>>>>>>> trust architecture. >>>>>>>>> *Recommendation*. >>>>>>>>> >>>>>>>>> a. The example given in section 4 of draft RFC be updated to >>>>>>>>> reflect the need of complete authentication of the client application >>>>>>>>> before the "acr_values" or "max_age" values are accepted or acted >>>>>>>>> upon by >>>>>>>>> the OAuth 2.0 endpoint. >>>>>>>>> b. Need for signing these values by the RS which can be verified >>>>>>>>> by the AS. Therefore, we need to look at ways by which the RS returns >>>>>>>>> a >>>>>>>>> signed JWT token containing "acr_values" or other such claims which >>>>>>>>> should >>>>>>>>> also be opaque to the client applications. >>>>>>>>> >>>>>>>>> >>>>>>>>> *Item No 3*: Forcing AS to implement OIDC specifications will >>>>>>>>> render existing implementations non-compliant. >>>>>>>>> *Follow-on Comment*: I fully agree to your statement that >>>>>>>>> 'existing implementations aren't expected to comply with the new >>>>>>>>> specification'. However, the point I am making is that we cannot be >>>>>>>>> biased >>>>>>>>> towards OIDC specifications and leave others non-compliant. We have >>>>>>>>> to make >>>>>>>>> future specifications such that it doesn't favour one over other. >>>>>>>>> *Recommendations*: All the proposed claims, parameters and >>>>>>>>> headers should be made OPTIONAL. >>>>>>>>> >>>>>>>>> *Item No 4*: How much “Freshness” is fresh? >>>>>>>>> *Follow-on Comment*: The *term* "freshness" may have earlier >>>>>>>>> precedent but the context is different. >>>>>>>>> *Recommendation*. Let's not use a term which cannot be quantified >>>>>>>>> and is open to different interpretations by readers/implementers. >>>>>>>>> >>>>>>>>> Kind Regards >>>>>>>>> Jaimandeep Singh >>>>>>>>> >>>>>>>>> On Fri, Oct 21, 2022 at 2:53 AM Vittorio Bertocci <vittorio= >>>>>>>>> 40auth0....@dmarc.ietf.org> wrote: >>>>>>>>> >>>>>>>>>> Hi Jaimandeep, >>>>>>>>>> I have a bit of cognitive whiplash - your first message professed >>>>>>>>>> strong support for this work, further reinforced by a LinkedIn post >>>>>>>>>> where >>>>>>>>>> you mentioned that your own paper supports the ideas expressed in >>>>>>>>>> this spec >>>>>>>>>> (not linking it because it's gone, but I have a screenshot)- whereas >>>>>>>>>> in >>>>>>>>>> your latest message you raise objections that question the very >>>>>>>>>> existence of this document... anyway, to your comments: >>>>>>>>>> >>>>>>>>>> 1 - I don't understand what "striking at the very core of OAuth" >>>>>>>>>> really means in concrete terms, however passing ACR in an access >>>>>>>>>> token is >>>>>>>>>> already standard behavior as described in >>>>>>>>>> https://datatracker.ietf.org/doc/html/rfc9068, as referenced by >>>>>>>>>> the draft. >>>>>>>>>> For what concerns the clientID considerations - the draft is >>>>>>>>>> pretty clear on aiming to solve scenarios where the RS is the entity >>>>>>>>>> deciding to reject incoming tokens for its own reasons, such as risk >>>>>>>>>> assessment performed locally, that by definition cannot be determined >>>>>>>>>> solely on the basis of the client identity. >>>>>>>>>> >>>>>>>>>> 2 - I have a hard time parsing this objection as well. A client >>>>>>>>>> does NOT authenticate itself when hitting the authorization endpoint, >>>>>>>>>> regardless of the client flavor; whether the oauth spec accepts a >>>>>>>>>> parameter or not isn't really relevant in an spec whose intent is to >>>>>>>>>> _extend_ oauth; and saying that the client is untrusted doesn't mean >>>>>>>>>> that >>>>>>>>>> the AS wouldn't comply with request parameters, because once again >>>>>>>>>> the >>>>>>>>>> authorization endpoint doesn't require ANy client authentication. >>>>>>>>>> >>>>>>>>>> 3- New RFCs don't override existing specs: they build on existing >>>>>>>>>> specs by extending and/or constraining existing behaviors. Forward >>>>>>>>>> compatibility would require the ability to predict the future, hence >>>>>>>>>> existing implementations aren't expected to comply with the new >>>>>>>>>> specification until they decide to add support for it. Now for this >>>>>>>>>> particular specification, we might get lucky and have forward >>>>>>>>>> compatibility >>>>>>>>>> in many implementations as products often implement both OAuth and >>>>>>>>>> OIDC in >>>>>>>>>> the same codebase, but once again - that is definitely not required. >>>>>>>>>> >>>>>>>>>> 4- Also in this case, I am not sure how to read this objection. >>>>>>>>>> The use of the *term* "freshness" has precedent in IETF specs (see >>>>>>>>>> rfc8747) >>>>>>>>>> and is commonly used in discussions on the list; and the concept is >>>>>>>>>> very >>>>>>>>>> well known and understood, as the existence of the max_age parameter >>>>>>>>>> attests; the fact that it is defined in OIDC doesn't really matter >>>>>>>>>> in this >>>>>>>>>> context, it is common practice for RS to impose the same constraint- >>>>>>>>>> one of >>>>>>>>>> the reasons that prompted us to draft this extension. >>>>>>>>>> >>>>>>>>>> I hope this helps! >>>>>>>>>> Best, >>>>>>>>>> V. >>>>>>>>>> >>>>>>>>>> On Thu, Oct 20, 2022 at 10:10 AM Jaimandeep Singh >>>>>>>>>> <jaimandeep.phdcs21=40nfsu.ac...@dmarc.ietf.org> wrote: >>>>>>>>>> >>>>>>>>>>> *This message originated outside your organization.* >>>>>>>>>>> >>>>>>>>>>> ------------------------------ >>>>>>>>>>> >>>>>>>>>>> Dear Vittorio Bertocci, Brian Campbell and Rifaat, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> My sincere compliments to Vittorio and Brian for their >>>>>>>>>>> persistent efforts in making and improving the draft RFC and also >>>>>>>>>>> for >>>>>>>>>>> taking out valuable time and efforts to reply to any queries. >>>>>>>>>>> However, I >>>>>>>>>>> strongly feel that the following points should be addressed before >>>>>>>>>>> closing >>>>>>>>>>> the last call. >>>>>>>>>>> >>>>>>>>>>> Item No 1: Striking at the core of OAuth 2.0 idea by coupling >>>>>>>>>>> end user authentication with authorization. >>>>>>>>>>> >>>>>>>>>>> Explanation: OAuth 2.0 is an authorization protocol. Its >>>>>>>>>>> strength lies in the decoupling of the end user authentication with >>>>>>>>>>> the >>>>>>>>>>> authorization layer. The proposed draft proposes means of coupling >>>>>>>>>>> the two >>>>>>>>>>> by passage of authentication information down the complete OAuth >>>>>>>>>>> 2.0 chain >>>>>>>>>>> and then RECOMMENDS actions by AS based on this information, thereby >>>>>>>>>>> striking at the core idea of OAuth 2.0. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The idea of end user authentication information being >>>>>>>>>>> transferred to the AS is borrowed from OIDC, which sends this >>>>>>>>>>> information >>>>>>>>>>> through token ID in the form of JWT (Refer Section 2 of OIDC >>>>>>>>>>> specs). This >>>>>>>>>>> parameter is designed to be OPTIONAL in OIDC and is not further >>>>>>>>>>> passed in >>>>>>>>>>> the access tokens. In the draft RFC we are not only passing the >>>>>>>>>>> authentication information down the chain through access tokens but >>>>>>>>>>> also >>>>>>>>>>> acting on the information received from client applications >>>>>>>>>>> upstream. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The idea of fiddling with end user authentication is completely >>>>>>>>>>> foreign to the OAuth 2.0 specs. Following questions then arise: >>>>>>>>>>> >>>>>>>>>>> 1. >>>>>>>>>>> >>>>>>>>>>> Do we intend to extend the scope of OAuth 2.0 specs by >>>>>>>>>>> coupling it with the end-user authentication and striking at the >>>>>>>>>>> very core >>>>>>>>>>> idea of OAuth 2.0? >>>>>>>>>>> 2. >>>>>>>>>>> >>>>>>>>>>> OAuth 2.0 does require means of identification for the >>>>>>>>>>> client application either through client ID only in case of >>>>>>>>>>> public clients >>>>>>>>>>> or through basic authentication in case of confidential clients. >>>>>>>>>>> Is it not >>>>>>>>>>> better to look at step-up identification/authentication >>>>>>>>>>> requirements of the >>>>>>>>>>> client application i.e. the way the client application >>>>>>>>>>> identifies/authenticates itself with the AS instead of getting >>>>>>>>>>> involved >>>>>>>>>>> with the mechanics of end user authentication. The idea of client >>>>>>>>>>> application authentication is intrinsic to the OAuth 2.0 specs. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Item No 2: Punching a security hole by requiring AS to act on >>>>>>>>>>> information provided by the client applications (Reverse Flow). >>>>>>>>>>> >>>>>>>>>>> Explanation. Refer Section 4 of draft RFC >>>>>>>>>>> >>>>>>>>>>> The example request below, which might occur after receiving the >>>>>>>>>>>> challenge in Figure 2, indicates to the authorization server that >>>>>>>>>>>> the >>>>>>>>>>>> client would like the authentication to occur according to the >>>>>>>>>>>> authentication context class reference identified by myACR. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> GET https://as.example.net/authorize?client_id=s6BhdRkqt3 >>>>>>>>>>>> <https://urldefense.com/v3/__https://as.example.net/authorize?client_id=s6BhdRkqt3__;!!PwKahg!7gVZGCGaFSdlozdZ1AdZhFCyfxK8nxToBplJ45oqxst0UKwrmcGMaeEYQpCbT54MpXqFjVoQflkoFpwtN5sadjP3seHNQRw$> >>>>>>>>>>>> &response_type=code&scope=purchase&acr_values=myACR >>>>>>>>>>>> Figure 4: Authorization Request indicating acr_values >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> In OAuth 2.0 specs, the client application authenticates itself >>>>>>>>>>> with the AS before starting the flow. Here, in the example above >>>>>>>>>>> there are >>>>>>>>>>> two prominent flaws: >>>>>>>>>>> >>>>>>>>>>> 1. >>>>>>>>>>> >>>>>>>>>>> The unauthenticated rogue client makes a GET request to the >>>>>>>>>>> AS forcing the complete authentication breakdown at the end user >>>>>>>>>>> forcing >>>>>>>>>>> him to authenticate time over and again. >>>>>>>>>>> 2. >>>>>>>>>>> >>>>>>>>>>> Even if we take a scenario that the request is made by an >>>>>>>>>>> authenticated client, the original specs of OAuth 2.0 does not >>>>>>>>>>> mandate any >>>>>>>>>>> action based on the commands received from the client >>>>>>>>>>> application. In a >>>>>>>>>>> zero trust model we assume that the client is compromised. AS >>>>>>>>>>> acting on >>>>>>>>>>> commands of client applications and propagating them across the >>>>>>>>>>> ecosystem >>>>>>>>>>> to force the end user authentication may result in future unseen >>>>>>>>>>> vulnerabilities. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Item No 3: Forcing AS to implement OIDC specifications will >>>>>>>>>>> render existing implementations non-compliant. >>>>>>>>>>> >>>>>>>>>>> Explanation. Refer Section 5 of the draft specs. >>>>>>>>>>> >>>>>>>>>>> Although [OIDC] leaves the authorization server free to decide >>>>>>>>>>>> how to handle the inclusion of acr in ID Token when requested via >>>>>>>>>>>> acr_values, when it comes to access tokens in this specification >>>>>>>>>>>> it is >>>>>>>>>>>> RECOMMENDED that the requested acr value is treated as required for >>>>>>>>>>>> successfully fulfilling the request. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The *RECOMMENDED *and *required* “acr_values” in the access >>>>>>>>>>> tokens will render existing deployments of AS, which currently do >>>>>>>>>>> not >>>>>>>>>>> support OIDC, as non-compliant. >>>>>>>>>>> >>>>>>>>>>> Item No 4: How much “Freshness” is fresh? >>>>>>>>>>> >>>>>>>>>>> Explanation. The use of the word “Freshness” is not quantified >>>>>>>>>>> and does not convey any meaning. It is recommended to be removed >>>>>>>>>>> altogether. On the contrary it complicates the draft, making the >>>>>>>>>>> reader >>>>>>>>>>> assume that “freshness” of authentication is very important and >>>>>>>>>>> might >>>>>>>>>>> impact on the whole idea of access tokens and the OAuth 2.0 in the >>>>>>>>>>> first >>>>>>>>>>> place. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Oct 18, 2022 at 1:25 AM Brian Campbell <bcampbell= >>>>>>>>>>> 40pingidentity....@dmarc.ietf.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Thanks Jaimandeep, >>>>>>>>>>>> >>>>>>>>>>>> There are certainly some complementary aspects of the step-up >>>>>>>>>>>> work and adaptive risk based approaches. Both in conveying >>>>>>>>>>>> information >>>>>>>>>>>> in/with an access token that might be input into a risk score >>>>>>>>>>>> calculation >>>>>>>>>>>> and in signaling that a more recent and/or stronger user >>>>>>>>>>>> authentication >>>>>>>>>>>> is required when the calculated risk exceeds the allowed risk. >>>>>>>>>>>> >>>>>>>>>>>> On Sat, Oct 15, 2022 at 10:58 PM Jaimandeep Singh >>>>>>>>>>>> <jaimandeep.phdcs21=40nfsu.ac...@dmarc.ietf.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Dear Brian, >>>>>>>>>>>>> >>>>>>>>>>>>> I strongly support this work. I have recently written a >>>>>>>>>>>>> conference paper on supporting similar ideas titled '*Resilient >>>>>>>>>>>>> Risk based Adaptive Authentication and Authorization (RAD-AA) >>>>>>>>>>>>> Framework*'. >>>>>>>>>>>>> The paper is still in the pre-print stage and can be accessed >>>>>>>>>>>>> here >>>>>>>>>>>>> <https://urldefense.com/v3/__https://arxiv.org/abs/2208.02592__;!!PwKahg!7gVZGCGaFSdlozdZ1AdZhFCyfxK8nxToBplJ45oqxst0UKwrmcGMaeEYQpCbT54MpXqFjVoQflkoFpwtN5sadjP3zA283j8$>. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 1. The core idea is similar. Firstly, ability to revoke or >>>>>>>>>>>>> step-up the authentication requirements based on the risk score. >>>>>>>>>>>>> Secondly, >>>>>>>>>>>>> to limit the scope based on the risk score. >>>>>>>>>>>>> >>>>>>>>>>>>> 2. One of the factors determining the risk score is the way >>>>>>>>>>>>> the client application has authenticated with the Authorization >>>>>>>>>>>>> server. If >>>>>>>>>>>>> it has used basic auth the risk score is high as compared to mTLS. >>>>>>>>>>>>> >>>>>>>>>>>>> 3. Additionally the idea is to downgrade the scope of the >>>>>>>>>>>>> token in case the risk score is high. This could be achieved at >>>>>>>>>>>>> the >>>>>>>>>>>>> protected resource server end through introspection and at >>>>>>>>>>>>> authorization >>>>>>>>>>>>> server end while issuing new access when the older ones expire. >>>>>>>>>>>>> This can >>>>>>>>>>>>> avoid forcing the complete authentication cycle at client end. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Jaimandeep Singh >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Oct 12, 2022 at 3:25 AM Brian Campbell <bcampbell= >>>>>>>>>>>>> 40pingidentity....@dmarc.ietf.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I don't know offhand a better place or if your specific >>>>>>>>>>>>>> privacy consideration is already covered. Honestly, with that >>>>>>>>>>>>>> comment, I >>>>>>>>>>>>>> was just aiming to keep the scope of this document concise and >>>>>>>>>>>>>> relevant. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Oct 11, 2022 at 10:06 AM Denis <denis.i...@free.fr> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Brian, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I agree with you that "must not" is more appropriate in that >>>>>>>>>>>>>>> context. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I also agree with you that the "privacy implications of >>>>>>>>>>>>>>> opaque tokens are inherent to OAuth in general". >>>>>>>>>>>>>>> However, I have not reviewed all the RFCs and I wonder >>>>>>>>>>>>>>> whether such a privacy consideration has already been mentioned. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It would be nice to start to mention it, rather than to >>>>>>>>>>>>>>> continue to omit it. Do you see a better place to mention it ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Denis >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks Denis, I agree the word "cannot" isn't quite right >>>>>>>>>>>>>>> there. I struggled with trying to find the right wording (more >>>>>>>>>>>>>>> than I >>>>>>>>>>>>>>> probably should have) attempting to add a note/reminder without >>>>>>>>>>>>>>> getting >>>>>>>>>>>>>>> into normative sounding language. But I also wanted to make a >>>>>>>>>>>>>>> firm >>>>>>>>>>>>>>> statement. Words are hard sometimes. Oftentimes! But reading it >>>>>>>>>>>>>>> again >>>>>>>>>>>>>>> today, "cannot" doesn't work very well. I think changing to >>>>>>>>>>>>>>> "must not" is >>>>>>>>>>>>>>> appropriate. The privacy implications of opaque tokens are >>>>>>>>>>>>>>> inherent to >>>>>>>>>>>>>>> OAuth in general and I don't believe this draft is an >>>>>>>>>>>>>>> appropriate place to >>>>>>>>>>>>>>> attempt to give them treatment. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Oct 11, 2022 at 2:57 AM Denis <denis.i...@free.fr> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Brian, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The text states: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also recall that OAuth 2.0 [RFC6749] assumes access tokens >>>>>>>>>>>>>>>> are treated as >>>>>>>>>>>>>>>> opaque by clients. So, during the course of any token >>>>>>>>>>>>>>>> caching >>>>>>>>>>>>>>>> strategy, a client *cannot* inspect the content of the >>>>>>>>>>>>>>>> access token to >>>>>>>>>>>>>>>> determine the associated authentication information or >>>>>>>>>>>>>>>> other details. >>>>>>>>>>>>>>>> The token format might be unreadable to the client or might >>>>>>>>>>>>>>>> change at >>>>>>>>>>>>>>>> any time to become unreadable. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> A client *can *inspect the content of the access token. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> A better wording would be: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ... a client *should not *inspect the content of the >>>>>>>>>>>>>>>> access token ... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It would be worthwhile to add a Privacy Considerations >>>>>>>>>>>>>>>> section: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 10. Privacy Considerations >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Since access tokens are presumed to be opaque to clients, >>>>>>>>>>>>>>>> clients (and hence users) are not supposed to inspect the >>>>>>>>>>>>>>>> content of the >>>>>>>>>>>>>>>> access tokens. >>>>>>>>>>>>>>>> Authorizations Servers are able to disclose more >>>>>>>>>>>>>>>> information than strictly necessary about the authenticated >>>>>>>>>>>>>>>> user without >>>>>>>>>>>>>>>> the end user being >>>>>>>>>>>>>>>> able to know it. Such additional information may endanger >>>>>>>>>>>>>>>> the privacy of the user. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Denis >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I've published an -04. It has that very minor change. There >>>>>>>>>>>>>>>> was also an off-list discussion during WGLC that resulted in >>>>>>>>>>>>>>>> thinking it'd >>>>>>>>>>>>>>>> be worthwhile >>>>>>>>>>>>>>>> *to add a reminder that access tokens are opaque to clients*. >>>>>>>>>>>>>>>> So I took that as LC feedback and -04 adds a brief note >>>>>>>>>>>>>>>> towards that end. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/ >>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/__;!!PwKahg!7gVZGCGaFSdlozdZ1AdZhFCyfxK8nxToBplJ45oqxst0UKwrmcGMaeEYQpCbT54MpXqFjVoQflkoFpwtN5sadjP3CV1UVi4$> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Oct 10, 2022 at 1:22 PM Vittorio Bertocci <vittorio= >>>>>>>>>>>>>>>> 40auth0....@dmarc.ietf.org> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks Dima for the comment. Some thoughts: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > (editorial)... >>>>>>>>>>>>>>>>> Good point. "statically" would characterize the simplest >>>>>>>>>>>>>>>>> of the scenarios, but in fact any case where the AS is the >>>>>>>>>>>>>>>>> only arbiter of >>>>>>>>>>>>>>>>> the authn level works for the point we are trying to make. >>>>>>>>>>>>>>>>> We'll drop >>>>>>>>>>>>>>>>> "statically". Thanks! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > Apart from... >>>>>>>>>>>>>>>>> This spec focuses on empowering an RS to communicate its >>>>>>>>>>>>>>>>> ACR and freshness requirements, regardless of the reasons >>>>>>>>>>>>>>>>> leading the RS to >>>>>>>>>>>>>>>>> make that determination: the logic by which that happens is >>>>>>>>>>>>>>>>> explicitly out >>>>>>>>>>>>>>>>> of scope, and in many real life cases it might simply be >>>>>>>>>>>>>>>>> unknowable (eg >>>>>>>>>>>>>>>>> anomaly detection engines based on ML are often back boxes). >>>>>>>>>>>>>>>>> The mechanism >>>>>>>>>>>>>>>>> described here can be used alongside other mechanisms that >>>>>>>>>>>>>>>>> might require >>>>>>>>>>>>>>>>> the client to get the user to interact with the AS, as it is >>>>>>>>>>>>>>>>> the case for >>>>>>>>>>>>>>>>> insufficient_scope, but those remain distinct cases (eg >>>>>>>>>>>>>>>>> insufficient _scope >>>>>>>>>>>>>>>>> might not require any step up but simply explicit user >>>>>>>>>>>>>>>>> consent, and if it >>>>>>>>>>>>>>>>> does require a stepup, that's entirely determined by the AS >>>>>>>>>>>>>>>>> without any >>>>>>>>>>>>>>>>> communication with client or RS required). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Fri, Oct 7, 2022 at 17:43 Dima Postnikov < >>>>>>>>>>>>>>>>> d...@postnikov.net> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> *This message originated outside your organization.* >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ------------------------------ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Couple of quick comments from me: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 1) (Editorial) >In simple API authorization scenarios, an >>>>>>>>>>>>>>>>>> authorization server will statically determine what >>>>>>>>>>>>>>>>>> authentication technique >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In many scenarios, authorization servers will use >>>>>>>>>>>>>>>>>> *dynamic* decisioning to determine authentication >>>>>>>>>>>>>>>>>> techniques; it's just not exposed to the client in a way >>>>>>>>>>>>>>>>>> to make it actionable (which is why this specification's >>>>>>>>>>>>>>>>>> intent makes >>>>>>>>>>>>>>>>>> perfect sense). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2) Apart from authentication level, there might be other >>>>>>>>>>>>>>>>>> reasons why users might be forced to go through the >>>>>>>>>>>>>>>>>> authorization flow, for >>>>>>>>>>>>>>>>>> example, insufficient authorization / scopes / claims / etc. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> If there is a mechanism to let the client know, as a >>>>>>>>>>>>>>>>>> practitioner, i'd rather have the same approach for both >>>>>>>>>>>>>>>>>> authentication and >>>>>>>>>>>>>>>>>> authorization. There are a range of authorization policy >>>>>>>>>>>>>>>>>> engines in the >>>>>>>>>>>>>>>>>> market that could return "STEP UP is required" after looking >>>>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>>>> authentication, authorisation and many other real-time >>>>>>>>>>>>>>>>>> signals. It's just >>>>>>>>>>>>>>>>>> not standardized... >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Sat, Oct 8, 2022 at 7:30 AM Pieter Kasselman >>>>>>>>>>>>>>>>>> <pieter.kasselman=40microsoft....@dmarc.ietf.org> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I am very supportive of this work and have been working >>>>>>>>>>>>>>>>>>> through different use cases to see whether it can satisfy >>>>>>>>>>>>>>>>>>> the requirements >>>>>>>>>>>>>>>>>>> that arise from them. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> One observation from working through these uses cases is >>>>>>>>>>>>>>>>>>> that as customers move to Zero Trust architectures, we are >>>>>>>>>>>>>>>>>>> seeing customers >>>>>>>>>>>>>>>>>>> adopting finer grained policy segmentation. Consequently >>>>>>>>>>>>>>>>>>> customers are >>>>>>>>>>>>>>>>>>> planning to deploy segmented access control by data or >>>>>>>>>>>>>>>>>>> action sensitivity, >>>>>>>>>>>>>>>>>>> within a service. This approach to policy design makes it >>>>>>>>>>>>>>>>>>> more common for a >>>>>>>>>>>>>>>>>>> single service to depend on multiple authentication context >>>>>>>>>>>>>>>>>>> values or >>>>>>>>>>>>>>>>>>> combinations of authentication context values. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> An example of this is a policy that has multiple acr >>>>>>>>>>>>>>>>>>> values (e.g. acr1=password, acr2=FIDO, acr3=selfie check, >>>>>>>>>>>>>>>>>>> acr4=trusted >>>>>>>>>>>>>>>>>>> network). A customer may define a policy that requires >>>>>>>>>>>>>>>>>>> different >>>>>>>>>>>>>>>>>>> combinations of these acr values, for example, a file >>>>>>>>>>>>>>>>>>> server may requires >>>>>>>>>>>>>>>>>>> password for general access (e.g. acr1), FIDO >>>>>>>>>>>>>>>>>>> authentication (acr2) or >>>>>>>>>>>>>>>>>>> password access and being on a trusted network to read >>>>>>>>>>>>>>>>>>> sensitive data (acr >>>>>>>>>>>>>>>>>>> 2 of (acr1 + acr 4), FIDO authentication and password (acr1 >>>>>>>>>>>>>>>>>>> + acr2) for >>>>>>>>>>>>>>>>>>> accessing editing sensitive documents and a real-time >>>>>>>>>>>>>>>>>>> selfie check on top >>>>>>>>>>>>>>>>>>> of FIDO and presence on a trusted network (acr1 + acr2 + >>>>>>>>>>>>>>>>>>> acr3 + acr4) to >>>>>>>>>>>>>>>>>>> initiate a sensitive workflow (e.g. check-in code). Other >>>>>>>>>>>>>>>>>>> variations of >>>>>>>>>>>>>>>>>>> this includes database access with different types of >>>>>>>>>>>>>>>>>>> access requirement >>>>>>>>>>>>>>>>>>> for certain rows (row-level permissions) or columns (column >>>>>>>>>>>>>>>>>>> level >>>>>>>>>>>>>>>>>>> permissions) with different combinations of acr values. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I was curious if this type of scenario where multiple >>>>>>>>>>>>>>>>>>> authentication contexts and combinations of contexts are >>>>>>>>>>>>>>>>>>> required is >>>>>>>>>>>>>>>>>>> something others see (or are beginning to see) as well? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Cheers >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Pieter >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of *Rifaat >>>>>>>>>>>>>>>>>>> Shekh-Yusef >>>>>>>>>>>>>>>>>>> *Sent:* Thursday, September 22, 2022 3:02 PM >>>>>>>>>>>>>>>>>>> *To:* oauth <oauth@ietf.org> >>>>>>>>>>>>>>>>>>> *Subject:* Re: [OAUTH-WG] WGLC for Step-up >>>>>>>>>>>>>>>>>>> Authentication >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *Correction:* >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Please, review the document and provide your feedback on >>>>>>>>>>>>>>>>>>> the mailing list by *Oct 7th, 2022*. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Thu, Sep 22, 2022 at 9:52 AM Rifaat Shekh-Yusef < >>>>>>>>>>>>>>>>>>> rifaat.s.i...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> All, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This is to start a *WG Last Call *for the *Step-up >>>>>>>>>>>>>>>>>>> Authentication *document: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-03.html >>>>>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Farchive*2Fid*2Fdraft-ietf-oauth-step-up-authn-challenge-03.html&data=05*7C01*7Cpieter.kasselman*40microsoft.com*7C0078f809101147bc978308da9ca32020*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637994521713812011*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=18sfemyWqYb06PvUA9eTLaq0ccDY14*2F6ETo58JpE*2FJQ*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PwKahg!537tJQfGj3Z_Yi2waywl1VPGyDs9818JE-M-KNFgPtoB0O26a7ksRvAYrPyzfKKXsMKCVblAomtRXj8$> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Please, review the document and provide your feedback on >>>>>>>>>>>>>>>>>>> the mailing list by *Sep 30th, 2022*. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>> Rifaat & Hannes >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!537tJQfGj3Z_Yi2waywl1VPGyDs9818JE-M-KNFgPtoB0O26a7ksRvAYrPyzfKKXsMKCVblAbcE1GME$> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!7gVZGCGaFSdlozdZ1AdZhFCyfxK8nxToBplJ45oqxst0UKwrmcGMaeEYQpCbT54MpXqFjVoQflkoFpwtN5sadjP3O4Vq9Uo$> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!7gVZGCGaFSdlozdZ1AdZhFCyfxK8nxToBplJ45oqxst0UKwrmcGMaeEYQpCbT54MpXqFjVoQflkoFpwtN5sadjP3O4Vq9Uo$> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *CONFIDENTIALITY NOTICE: This email may contain >>>>>>>>>>>>>>>> confidential and privileged material for the sole use of the >>>>>>>>>>>>>>>> intended >>>>>>>>>>>>>>>> recipient(s). Any review, use, distribution or disclosure by >>>>>>>>>>>>>>>> others is >>>>>>>>>>>>>>>> strictly prohibited. If you have received this communication >>>>>>>>>>>>>>>> in error, >>>>>>>>>>>>>>>> please notify the sender immediately by e-mail and delete the >>>>>>>>>>>>>>>> message and >>>>>>>>>>>>>>>> any file attachments from your computer. Thank you.* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> OAuth mailing >>>>>>>>>>>>>>>> listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!7gVZGCGaFSdlozdZ1AdZhFCyfxK8nxToBplJ45oqxst0UKwrmcGMaeEYQpCbT54MpXqFjVoQflkoFpwtN5sadjP3O4Vq9Uo$> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential >>>>>>>>>>>>>>> and privileged material for the sole use of the intended >>>>>>>>>>>>>>> recipient(s). Any >>>>>>>>>>>>>>> review, use, distribution or disclosure by others is strictly >>>>>>>>>>>>>>> prohibited. >>>>>>>>>>>>>>> If you have received this communication in error, please notify >>>>>>>>>>>>>>> the sender >>>>>>>>>>>>>>> immediately by e-mail and delete the message and any file >>>>>>>>>>>>>>> attachments from >>>>>>>>>>>>>>> your computer. Thank you.* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential >>>>>>>>>>>>>> and privileged material for the sole use of the intended >>>>>>>>>>>>>> recipient(s). Any >>>>>>>>>>>>>> review, use, distribution or disclosure by others is strictly >>>>>>>>>>>>>> prohibited. >>>>>>>>>>>>>> If you have received this communication in error, please notify >>>>>>>>>>>>>> the sender >>>>>>>>>>>>>> immediately by e-mail and delete the message and any file >>>>>>>>>>>>>> attachments from >>>>>>>>>>>>>> your computer. Thank you.* >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!7gVZGCGaFSdlozdZ1AdZhFCyfxK8nxToBplJ45oqxst0UKwrmcGMaeEYQpCbT54MpXqFjVoQflkoFpwtN5sadjP3O4Vq9Uo$> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Regards and Best Wishes >>>>>>>>>>>>> Jaimandeep Singh >>>>>>>>>>>>> LinkedIn >>>>>>>>>>>>> <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential >>>>>>>>>>>> and privileged material for the sole use of the intended >>>>>>>>>>>> recipient(s). Any >>>>>>>>>>>> review, use, distribution or disclosure by others is strictly >>>>>>>>>>>> prohibited. >>>>>>>>>>>> If you have received this communication in error, please notify >>>>>>>>>>>> the sender >>>>>>>>>>>> immediately by e-mail and delete the message and any file >>>>>>>>>>>> attachments from >>>>>>>>>>>> your computer. Thank you.* >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!7gVZGCGaFSdlozdZ1AdZhFCyfxK8nxToBplJ45oqxst0UKwrmcGMaeEYQpCbT54MpXqFjVoQflkoFpwtN5sadjP3O4Vq9Uo$> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Regards and Best Wishes >>>>>>>>>>> Jaimandeep Singh >>>>>>>>>>> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Regards and Best Wishes >>>>>>>>> Jaimandeep Singh >>>>>>>>> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>>> privileged material for the sole use of the intended recipient(s). Any >>>>>>> review, use, distribution or disclosure by others is strictly >>>>>>> prohibited. >>>>>>> If you have received this communication in error, please notify the >>>>>>> sender >>>>>>> immediately by e-mail and delete the message and any file attachments >>>>>>> from >>>>>>> your computer. Thank you.* >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards and Best Wishes >>>>>> Jaimandeep Singh >>>>>> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7> >>>>>> >>>>> >>>> >>>> -- >>>> Regards and Best Wishes >>>> Jaimandeep Singh >>>> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7> >>>> >>> >>> >>> -- >>> Regards and Best Wishes >>> Jaimandeep Singh >>> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7> >>> >> > > -- > Regards and Best Wishes > Jaimandeep Singh > LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7> > _______________________________________________ > 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
