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