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

[Jaimandeep Singh <[e-mail]>]

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://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 <[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://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=
>>>>>>> [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://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=
>>>>>>>>>> [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, 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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>