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

[Jaimandeep Singh <[e-mail]>]

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>