Re: [OAUTH-WG] WGLC for Step-up Authentication

[Warren Parad <[e-mail]>]

I can try to rephrase my response if it helps to make it clearer, which
part of what I said do you find confusing?

On Fri, Oct 28, 2022 at 8:07 AM Jaimandeep Singh <jaimandeep.phdcs21=
[e-mail]> wrote:

> Dear Warren,
>
> To borrow from one of Vittorio's emails, 'I have a bit of cognitive
> whiplash'. I do not find myself on the same page for any of the points
> mentioned by you. All the points given in your email can equally be pitched
> against the current draft RFC.
>
> I was of opinion that we need to have more data points flowing from AS to
> RS to enable the RS in making better decision with regards to grant of
> resources.
>
> RS is the ultimate authority in deciding which scopes it will allow.  I
> have already given the use case of Google API and how it can be extended to
> the RS for holistic decision making while granting the access to protected
> resources.
>
> Hope that helps
>
> Regards
>
>
> On Thu, 27 Oct, 2022, 5:52 pm Warren Parad, <wparad=
> [e-mail]> wrote:
>
>> The RS shouldn't need to make any additional determination in the case of
>> scopes, since the AS won't grant the scope in the first place it is
>> extraneous information.
>>
>> The token type (basic, bearer, mtls, dpop) is already contained in the
>> Authorization header so having it also in the token doesn't really serve a
>> second purpose.
>>
>> Again, the "security assessment" would block the generation of the token
>> in first place. So in the case of google's apis, they just check the
>> scopes. Therefore the RS wouldn't need to make additional decisions.
>>
>> Is there another existing live use case that directly informs the need to
>> introduce other parameters?
>>
>> One could argue that acr values is the incorrect implementation and it
>> really should be "security level". A field with a numerical value that
>> could be directly tested by an RS, rather than the AS understanding the
>> different types of authentication mechanisms. I could personally get behind
>> that idea, and let the AS/user decide how to get to that security level.
>> But that's already the expected implementation as defined in OIDC, and this
>> RFC leaves that capability open.
>>
>> So you can already get what you want using the existing acr field without
>> introducing additional complexity for either the RFC or RS.
>>
>> On Thu, Oct 27, 2022, 13:49 Jaimandeep Singh <jaimandeep.phdcs21=
>> [e-mail]> wrote:
>>
>>> Dear Warren,
>>>
>>> After your suggestion, I tried digging up the old PRs in the github but
>>> could not locate anything related to 'client app parameters'. With due
>>> respect and permission of the chair, I would like to outline a use case and
>>> if it finds enough traction we can include it in the draft RFC or take it
>>> up as an additional RFC as suggested by Warren.
>>>
>>>
>>>> Rather than trying to dig up previous conversations, is there a
>>>> concrete new problem (hypothetical or otherwise) that would require
>>>> addressing additional parameters?
>>>
>>>
>>>
>>>> Is there a use case that would show up in the near future that wouldn't
>>>> be covered by this RFC in its current state?
>>>
>>>
>>> *What is the proposal*? It is proposed to include the
>>> authentication/identification of 'client app' as additional parameters in
>>> the access token. The advantage of including it in the current draft RFC is
>>> that it will provide additional data points for the RS to make decisions
>>> and will also make the draft RFC more versatile.
>>>
>>> *Is there an existing use case*? 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
>>> the type of app and the security assessment of the apps requesting these
>>> scopes.
>>>
>>> The following data points related to the client app could be part of the
>>> access token for the RS to make decisions:
>>> a. Type of client app - confidential, public.
>>> b. How has it been identified i.e client ID only (public clients), using
>>> basic authentication, mTLS, PAR or other such techniques.
>>> c. Security assessment of the client app.
>>>
>>> Regards
>>>
>>>
>>> On Thu, Oct 27, 2022 at 2:19 PM Warren Parad <wparad=
>>> [e-mail]> wrote:
>>>
>>>> Having gone through the RFC process many times, I can share what a
>>>> burden it can be to create and manage the draft. So I can appreciate the
>>>> level of effort required when asking someone to revisit previous
>>>> discussions. It would be great if a github repo was used with PRs to track
>>>> the changes, but not everyone goes down that path.
>>>>
>>>> Rather than trying to dig up previous conversations, is there a
>>>> concrete new problem (hypothetical or otherwise) that would require
>>>> addressing additional parameters? From my standpoint, this is extensible in
>>>> the future. We aren't closing any doors here (or at least as far as I can
>>>> tell), so creating additional RFCs to add additional behavior is still
>>>> feasible. Is there a use case that would show up in the near future that
>>>> wouldn't be covered by this RFC in its current state?
>>>>
>>>> On Thu, Oct 27, 2022 at 4:29 AM Jaimandeep Singh <jaimandeep.phdcs21=
>>>> [e-mail]> wrote:
>>>>
>>>>> Dear Vittorio,
>>>>>
>>>>> Thanks for the update. I will really appreciate if you can summarise
>>>>> or refer to emails/other documents towards the discussions specific to
>>>>> inclusion/exclusion of 'client app parameters' from the signal flow.
>>>>>
>>>>> This will help in building the right perspective for me and any
>>>>> perceived areas of improvement in the draft RFC.
>>>>>
>>>>> Regards
>>>>>
>>>>>
>>>>> On Thu, 27 Oct, 2022, 7:04 am Vittorio Bertocci, <vittorio=
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> The fact that nothing meeting the inclusion bar was identified does
>>>>>> not imply that no discussion took place. There were various attempts, in
>>>>>> particular during OSW, and nothing raised to the same prominence bar as the
>>>>>> parameters we did include on the specification.
>>>>>>
>>>>>> On Wed, Oct 26, 2022 at 17:54 Jaimandeep Singh <jaimandeep.phdcs21=
>>>>>> [e-mail]> wrote:
>>>>>>
>>>>>>> *This message originated outside your organization.*
>>>>>>>
>>>>>>> ------------------------------
>>>>>>>
>>>>>>> Dear Rifaat,
>>>>>>>
>>>>>>> I respect your decision and wish all the best to the authors and
>>>>>>> members going forward.
>>>>>>>
>>>>>>> I would also like to bring to your kind attention that the
>>>>>>> discussions on Item No 5 which suggested inclusion of client app parameters
>>>>>>> in the signal flow could not be even started. I quote one of the previous
>>>>>>> emails by Vittorio dated 13 Oct 2022, in which he has stated
>>>>>>>
>>>>>>>> During the discussion we did inquire on other parameters/aspects
>>>>>>>> that would have the same direct applicability but nothing was identified.
>>>>>>>
>>>>>>>
>>>>>>> I was hoping for some discussions on this aspect given that the
>>>>>>> authors had acknowledged the lack of suggestions.
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> On Wed, 26 Oct, 2022, 11:01 pm Rifaat Shekh-Yusef, <
>>>>>>> [e-mail]> wrote:
>>>>>>>
>>>>>>>> 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=[e-mail]> 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 <[e-mail]>
>>>>>>>>> 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 <
>>>>>>>>>> [e-mail]> 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 <
>>>>>>>>>>> [e-mail]> 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/oauth/rNqEACxVM1OtDfT5SIQDybSK6kk/__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8QBorqkk$>,
>>>>>>>>>>>> part-2
>>>>>>>>>>>> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/oauth/U8c9JfHCnmcbX238zXWTuRgx2BE/__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p82wjeKpM$>
>>>>>>>>>>>> and part-3
>>>>>>>>>>>> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/oauth/SsollGVV01oPmYYTef25-SYVYok/__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8Ok6RPCU$>
>>>>>>>>>>>> .
>>>>>>>>>>>>
>>>>>>>>>>>> *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 <[e-mail]>
>>>>>>>>>>>> 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 <
>>>>>>>>>>>>> [e-mail]> 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/oauth/rNqEACxVM1OtDfT5SIQDybSK6kk/__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8QBorqkk$>
>>>>>>>>>>>>>> and part2
>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/oauth/U8c9JfHCnmcbX238zXWTuRgx2BE/__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p82wjeKpM$>
>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *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://urldefense.com/v3/__https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8e5K9vUI$>
>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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=
>>>>>>>>>>>>>> [e-mail]> 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=
>>>>>>>>>>>>>>> [e-mail]> 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=[e-mail]> 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/oauth/rNqEACxVM1OtDfT5SIQDybSK6kk/__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8QBorqkk$>
>>>>>>>>>>>>>>>>> ]:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *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://urldefense.com/v3/__https://developers.google.com/identity/protocols/oauth2/web-server__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8_XFxQmU$>
>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>    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=[e-mail]> 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
>>>>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9068__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8gOHSzMU$>,
>>>>>>>>>>>>>>>>>> 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=[e-mail]> 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=[e-mail]> 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=[e-mail]> 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=[e-mail]> 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 <
>>>>>>>>>>>>>>>>>>>>>> [e-mail]> 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 <
>>>>>>>>>>>>>>>>>>>>>>> [e-mail]> 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=[e-mail]> 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 <
>>>>>>>>>>>>>>>>>>>>>>>>> [e-mail]> 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=[e-mail]>
>>>>>>>>>>>>>>>>>>>>>>>>>> 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 <[e-mail]> *On
>>>>>>>>>>>>>>>>>>>>>>>>>>> Behalf Of *Rifaat Shekh-Yusef
>>>>>>>>>>>>>>>>>>>>>>>>>>> *Sent:* Thursday, September 22, 2022 3:02 PM
>>>>>>>>>>>>>>>>>>>>>>>>>>> *To:* oauth <[e-mail]>
>>>>>>>>>>>>>>>>>>>>>>>>>>> *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 <[e-mail]> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!7gVZGCGaFSdlozdZ1AdZhFCyfxK8nxToBplJ45oqxst0UKwrmcGMaeEYQpCbT54MpXqFjVoQflkoFpwtN5sadjP3O4Vq9Uo$>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>>>>>>>>>>> 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 [e-mail]://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
>>>>>>>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8MsQyrSI$>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Regards and Best Wishes
>>>>>>>>>>>>>>>>> Jaimandeep Singh
>>>>>>>>>>>>>>>>> LinkedIn
>>>>>>>>>>>>>>>>> <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8MsQyrSI$>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8MsQyrSI$>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *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
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8MsQyrSI$>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>
>>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>
>>>
>>> --
>>> Regards and Best Wishes
>>> Jaimandeep Singh
>>> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
>>>
>>