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

Warren Parad <wparad@rhosys.ch> Thu, 27 October 2022 12:22 UTC

Return-Path: <wparad@rhosys.ch>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C67C14F746 for <oauth@ietfa.amsl.com>; Thu, 27 Oct 2022 05:22:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHAQ3Mj3546a for <oauth@ietfa.amsl.com>; Thu, 27 Oct 2022 05:22:11 -0700 (PDT)
Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88653C14F727 for <oauth@ietf.org>; Thu, 27 Oct 2022 05:22:11 -0700 (PDT)
Received: by mail-il1-x134.google.com with SMTP id x16so850701ilm.5 for <oauth@ietf.org>; Thu, 27 Oct 2022 05:22:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hLIA6r8UfW4rjoLMQnNnp8OMOmY68HStuntlkEBF1Fw=; b=RGSbAB5Q7fNZrX+MrjNPXJlSlMK5c+XGM6UI/wvKXOB7Bu7SG7cK6jl6joIiQnajrJ vy3YXUqWZTV7eNmI+RS5V/dpKiNXp5JSnxSG9S2pYjfMcyQ4ui0yd5SF7k0m9wF+cm6R kTdV8OQiusAARFCaPoJ0sk/5mBz+iA4KxFxpebqqAgfPOKn+TMgqItmGB7fgJDA2eQlu NXgb66ZBIgDgyzZ+1RzvLwlrYWGyk3FDzPM9awzvxqM2FW9CuxXBfYoys1JrdPgOe0oi sLVB1zrnJNERM+ug8mVLL/9xVOmnclK6Vg8dTN46rwEeRuvspp+S1mdY26+Yn6lcETK+ GwVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hLIA6r8UfW4rjoLMQnNnp8OMOmY68HStuntlkEBF1Fw=; b=3W6WxTDDUMqfNNa5U6xLgcfKyCMHye/mF50k4YUYPx657v4Ymmz4f7wMb+S/Y4eWto pXR0HUw5N+iBTTrzkIj1ztG3cWr7m+pBbVYEgct9eeWIc3LWWHn68Xa2xvlcyH0B4Suj PoX71hH2K6uC4yYgp8Wvx/QtSZ0xfY1NmLgyJTulmfYZSu3c9wF5hvu4BgL9z9r6Q2j0 YXazzlLJUEB5UGmabH5RC6rEFZTwCbNPq5d3zc8OvBrlDPxaJx3Pjan/uEU4dJVCUd4M 6ZshObTiim/63JX5sC3GjHe7viVyB4X1xizFHWn9tQzN38s4VGjgFVA75/NyoIIPHhTv mpHQ==
X-Gm-Message-State: ACrzQf1b5CVeqLuoEvo0GjHEFcUEyFQ1InOGddCK0W4A7NhFWjQP7Bdz g4g8kd0G3nz/EhozKT6JbBUfjL1SuRs9ZdzEKKAR
X-Google-Smtp-Source: AMsMyM5A1ccvr6XmV6h9ABfjGY2GAiGZ6jvHtk5KoWKQUZ2Xl5Vu1DvCR4hcWW6MI6dLSLNDU9ri6QR0NAKcgZluAlA=
X-Received: by 2002:a05:6e02:156f:b0:2ff:775f:1efd with SMTP id k15-20020a056e02156f00b002ff775f1efdmr20971515ilu.140.1666873328894; Thu, 27 Oct 2022 05:22:08 -0700 (PDT)
MIME-Version: 1.0
References: <CADNypP9ypW35=CSJaOfaEqZGDLXGLjnMs4_x5Ue10-yP6BcVoQ@mail.gmail.com> <CADNypP95pWPndeBydEbThrrWrPCVDg2Jmor-68HFGHpqRqFtyA@mail.gmail.com> <DBAPR83MB04227E5BB028F94FD337032A915F9@DBAPR83MB0422.EURPRD83.prod.outlook.com> <CAEMK1uaBedVBcoBuf9NY53sa2MRKh2j5gXrnW65PCiGj6Rzu7g@mail.gmail.com> <CAEFJvaoHyDoj3mbKhSqZmwCjE-iNNk0ZF1V6X_b35SDbp9iXjQ@mail.gmail.com> <CA+k3eCSfy6_kDf1BYciiqdZVE93-VBt3WYYiD9fJNFN33_K3xw@mail.gmail.com> <790fb615-c9ef-27eb-6050-c0f179eac452@free.fr> <CA+k3eCTb7A0pbqa=iRa3vaPDUMQ=sEvyFitvKmfduSXc0fXPWg@mail.gmail.com> <e53f3c82-ab89-c5ec-ac2e-ab9fade7a5f6@free.fr> <CA+k3eCR3-8kod-99FnRPBaYyz9FbxBMvjHMDEQCP3FAjiM-bqA@mail.gmail.com> <CAODMz5FoFp4AWtwL5=uwSoKEpRMAQz=oveOOWUF4XkAbvj0iQA@mail.gmail.com> <CA+k3eCTrDLPMTk9u+HiUwL4yaQfv3ydW=5ov8o1=tsSkVYX4Tg@mail.gmail.com> <CAODMz5H6o3NG=GiPyt-9WUBCJDz+vunFxLwCqD51RqZ1euurow@mail.gmail.com> <CAEFJvar9h3=kz8FbyrBT7Ktka99nxZem2wLAwT+EDXpecFo=cQ@mail.gmail.com> <CAODMz5G5sL0yJaT1rKjEs+pZ4uJFFjW=s5qCHcUo5F7cfJbxeg@mail.gmail.com> <CAJot-L2DZx4BB9jdKUKFg+uv2EDCRQ-y9_OY1bKtpV=2KqyA=g@mail.gmail.com> <CA+k3eCRwQrMEK+yv96XbwcSUheynR9vf8FOUEHD-ezttCNRV_A@mail.gmail.com> <CAODMz5E8pJBiKvcjD=iFaZhmOteEfV3bskW3rsSVZt+DiF6iyg@mail.gmail.com> <CAJot-L3NX5ej77A_vta3ckMf7n8M_-MtXxE2pGx4dAdt6QKgig@mail.gmail.com> <CAODMz5FOjRm-77XywxDT9TrudBE8-dpM=9G3xOKzZwiYJ7gRag@mail.gmail.com> <CAODMz5HL4J+jwvyPAEgHAcQEUAemUtFb0wVHUo+BECA6uq6CPQ@mail.gmail.com> <CAJot-L0uBTSXkNOzc1haBAQTWS0NQU-jDLbLfnrSxrf__hD+GA@mail.gmail.com> <CAODMz5FshedXeC3J5w25V3SV+81LhDSi7mWGCwXcNswpu5h9zQ@mail.gmail.com> <CADNypP87RQYZOpynVyVRjEJPGMNi6sXbwesrFE=nCK18_2+Ttw@mail.gmail.com> <CAODMz5EFBgrMnhoGn_xWNr-D=Ov7VTKP2Xi-ZdmobFYN=vt_kw@mail.gmail.com> <CAEFJvaqFPiN1TePJ9=Ub6v1RvcHp_ERV0Bu0erNsy1okCLL2Qw@mail.gmail.com> <CAODMz5HTX78dwxbyb-4k=Mo5UrGoKD+rbZz9t1XD9RXjxpuw-Q@mail.gmail.com> <CAJot-L3=xe2JHfPtrXirXHuTo8ngdgz-kFfmunmOXTSGx2mxjQ@mail.gmail.com> <CAODMz5G5unRZvMyxM4Va61hXoEOmt3VJ_B1-yavPiTCy6vxHhw@mail.gmail.com>
In-Reply-To: <CAODMz5G5unRZvMyxM4Va61hXoEOmt3VJ_B1-yavPiTCy6vxHhw@mail.gmail.com>
From: Warren Parad <wparad@rhosys.ch>
Date: Thu, 27 Oct 2022 14:21:56 +0200
Message-ID: <CAJot-L1AFD5LDH+Zrt=CGaOVNE2M5pWmzZ+dnBZxau7WQxQrRg@mail.gmail.com>
To: Jaimandeep Singh <jaimandeep.phdcs21=40nfsu.ac.in@dmarc.ietf.org>
Cc: Vittorio Bertocci <vittorio@auth0.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a79ccb05ec0330c9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/BOOlpzMuL72LRIKkdUFxkt-2F7o>
Subject: Re: [OAUTH-WG] WGLC for Step-up Authentication
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Oct 2022 12:22:16 -0000

The RS shouldn't need to make any additional determination in the case of
scopes, since the AS won't grant the scope in the first place it is
extraneous information.

The token type (basic, bearer, mtls, dpop) is already contained in the
Authorization header so having it also in the token doesn't really serve a
second purpose.

Again, the "security assessment" would block the generation of the token in
first place. So in the case of google's apis, they just check the scopes.
Therefore the RS wouldn't need to make additional decisions.

Is there another existing live use case that directly informs the need to
introduce other parameters?

One could argue that acr values is the incorrect implementation and it
really should be "security level". A field with a numerical value that
could be directly tested by an RS, rather than the AS understanding the
different types of authentication mechanisms. I could personally get behind
that idea, and let the AS/user decide how to get to that security level.
But that's already the expected implementation as defined in OIDC, and this
RFC leaves that capability open.

So you can already get what you want using the existing acr field without
introducing additional complexity for either the RFC or RS.

On Thu, Oct 27, 2022, 13:49 Jaimandeep Singh <jaimandeep.phdcs21=
40nfsu.ac.in@dmarc.ietf.org> wrote:

> Dear Warren,
>
> After your suggestion, I tried digging up the old PRs in the github but
> could not locate anything related to 'client app parameters'. With due
> respect and permission of the chair, I would like to outline a use case and
> if it finds enough traction we can include it in the draft RFC or take it
> up as an additional RFC as suggested by Warren.
>
>
>> Rather than trying to dig up previous conversations, is there a concrete
>> new problem (hypothetical or otherwise) that would require addressing
>> additional parameters?
>
>
>
>> Is there a use case that would show up in the near future that wouldn't
>> be covered by this RFC in its current state?
>
>
> *What is the proposal*? It is proposed to include the
> authentication/identification of 'client app' as additional parameters in
> the access token. The advantage of including it in the current draft RFC is
> that it will provide additional data points for the RS to make decisions
> and will also make the draft RFC more versatile.
>
> *Is there an existing use case*? Let us see how Google handles the
> restricted scopes. Refer here
> <https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification>
> .
>
>> The Gmail and Fit APIs limit the apps that can seek permission to access
>> consumer data. These additional requirements for restricted scopes require
>> an app to demonstrate that they're a permitted application type and to
>> submit to additional reviews, which include a possible security assessment
>> by a third-party auditor.
>>
>
> Here, the problem of restricted or sensitive scopes is handled through the
> type of app and the security assessment of the apps requesting these scopes.
>
> The following data points related to the client app could be part of the
> access token for the RS to make decisions:
> a. Type of client app - confidential, public.
> b. How has it been identified i.e client ID only (public clients), using
> basic authentication, mTLS, PAR or other such techniques.
> c. Security assessment of the client app.
>
> Regards
>
>
> On Thu, Oct 27, 2022 at 2:19 PM Warren Parad <wparad=
> 40rhosys.ch@dmarc.ietf.org> wrote:
>
>> Having gone through the RFC process many times, I can share what a burden
>> it can be to create and manage the draft. So I can appreciate the level of
>> effort required when asking someone to revisit previous discussions. It
>> would be great if a github repo was used with PRs to track the changes, but
>> not everyone goes down that path.
>>
>> Rather than trying to dig up previous conversations, is there a concrete
>> new problem (hypothetical or otherwise) that would require addressing
>> additional parameters? From my standpoint, this is extensible in the
>> future. We aren't closing any doors here (or at least as far as I can
>> tell), so creating additional RFCs to add additional behavior is still
>> feasible. Is there a use case that would show up in the near future that
>> wouldn't be covered by this RFC in its current state?
>>
>> On Thu, Oct 27, 2022 at 4:29 AM Jaimandeep Singh <jaimandeep.phdcs21=
>> 40nfsu.ac.in@dmarc.ietf.org> wrote:
>>
>>> Dear Vittorio,
>>>
>>> Thanks for the update. I will really appreciate if you can summarise or
>>> refer to emails/other documents towards the discussions specific to
>>> inclusion/exclusion of 'client app parameters' from the signal flow.
>>>
>>> This will help in building the right perspective for me and any
>>> perceived areas of improvement in the draft RFC.
>>>
>>> Regards
>>>
>>>
>>> On Thu, 27 Oct, 2022, 7:04 am Vittorio Bertocci, <vittorio=
>>> 40auth0.com@dmarc.ietf.org> wrote:
>>>
>>>> The fact that nothing meeting the inclusion bar was identified does not
>>>> imply that no discussion took place. There were various attempts, in
>>>> particular during OSW, and nothing raised to the same prominence bar as the
>>>> parameters we did include on the specification.
>>>>
>>>> On Wed, Oct 26, 2022 at 17:54 Jaimandeep Singh <jaimandeep.phdcs21=
>>>> 40nfsu.ac.in@dmarc.ietf.org> wrote:
>>>>
>>>>> *This message originated outside your organization.*
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> Dear Rifaat,
>>>>>
>>>>> I respect your decision and wish all the best to the authors and
>>>>> members going forward.
>>>>>
>>>>> I would also like to bring to your kind attention that the discussions
>>>>> on Item No 5 which suggested inclusion of client app parameters in the
>>>>> signal flow could not be even started. I quote one of the previous emails
>>>>> by Vittorio dated 13 Oct 2022, in which he has stated
>>>>>
>>>>>> During the discussion we did inquire on other parameters/aspects that
>>>>>> would have the same direct applicability but nothing was identified.
>>>>>
>>>>>
>>>>> I was hoping for some discussions on this aspect given that the
>>>>> authors had acknowledged the lack of suggestions.
>>>>>
>>>>> Regards
>>>>>
>>>>> On Wed, 26 Oct, 2022, 11:01 pm Rifaat Shekh-Yusef, <
>>>>> rifaat.s.ietf@gmail.com> wrote:
>>>>>
>>>>>> Jaimandeep,
>>>>>>
>>>>>> With the chair hat on, and as the shepherd for this document, I think
>>>>>> that the authors addressed your comments in detail, and Warren provided you
>>>>>> with some valuable responses. I do not see a need for any further
>>>>>> discussion at this stage.
>>>>>>
>>>>>> The next step is the shepherd review, which could start a new
>>>>>> discussion about this document.
>>>>>>
>>>>>> Regards,
>>>>>>  Rifaat
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 25, 2022 at 2:11 PM Jaimandeep Singh <jaimandeep.phdcs21=
>>>>>> 40nfsu.ac.in@dmarc.ietf.org> wrote:
>>>>>>
>>>>>>> Dear Warren,
>>>>>>>
>>>>>>> It is always nice to read your elaborately written views. It helps
>>>>>>> in getting perspective.
>>>>>>>
>>>>>>> I have a slightly different take on the subject. What is the client
>>>>>>> application going to do with the "acr_values"? Ultimately, it is going to
>>>>>>> send these values to the authorization server in order to meet the required
>>>>>>> end-user authentication criteria. This is what I am referring to as reverse
>>>>>>> flow RS->client_app->AS.
>>>>>>>
>>>>>>> I'm on the fence of calling the "user agent" untrusted.
>>>>>>>
>>>>>>> Here we have to consider client applications that are other than
>>>>>>> browsers such as native apps and these apps can surely be called
>>>>>>> "untrusted". These native apps will first receive the "acr_values" from the
>>>>>>> RS and will then use the "user agent" to pass the values to the
>>>>>>> authorization server.
>>>>>>>
>>>>>>> I'd ask for at least one practical attack that this RFC enables (not
>>>>>>>> necessarily causes).
>>>>>>>
>>>>>>>
>>>>>>> Well I will start at the abstract level first. Wherever the trust
>>>>>>> boundaries are crossed it results in security complications. Here the data
>>>>>>> is moving from trusted (RS)->untrusted (client-app)->trusted(AS). Now,
>>>>>>> coming to specific examples,
>>>>>>>
>>>>>>> Example 1: OWASP Top10: API8:2019 Injection. Once the client_app
>>>>>>> presents the "acr_values" data to the authorization server it has to be
>>>>>>> sanitized, otherwise it can result in unintended command execution.
>>>>>>>
>>>>>>> Example 2: OWASP Top 10: API1:2019 Broken Object Level
>>>>>>> Authorization.  The client_app will use all possible combinations of
>>>>>>> "acr_values" to know the behaviour of the particular authorization
>>>>>>> endpoint/server.
>>>>>>>
>>>>>>> On Tue, Oct 25, 2022 at 5:23 PM Warren Parad <wparad@rhosys.ch>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I'm glad that we can move on from item No 1. Regarding this second
>>>>>>>> one, the AS is not required to be involved in this communication, as the RS
>>>>>>>> already has the capability to convey to the user agent why the access token
>>>>>>>> is denied. It just hasn't been standardized. There are lot's of reasons why
>>>>>>>> an access token or the user identity the token is for might not contain the
>>>>>>>> necessary authorization to access to the resource. I see here we are only
>>>>>>>> codifying that communication rather than opening any holes.
>>>>>>>>
>>>>>>>> What's the reason for needing to sign data from the RS, the RS
>>>>>>>> might not even be a client of the AS, so if theoretically necessary, we
>>>>>>>> would have to challenge our suggested implementation. Is there a specific
>>>>>>>> security problem you are thinking about?
>>>>>>>>
>>>>>>>> I'm on the fence of calling the "user agent" untrusted. Sure it is,
>>>>>>>> but the browsers have the expectation to expose the requests from the RS to
>>>>>>>> the user, if we blindly passed the acr_values from the RS directly to the
>>>>>>>> AS then there would be a problem, but signing the values wouldn't change
>>>>>>>> anything. In any case the user agent/client application can't be agnostic
>>>>>>>> to the acr_values because updating the acr actually does require user
>>>>>>>> input. While the user agent the user is using to interact with the RS might
>>>>>>>> not be the same one used for the AS in the acr needed value, for instance
>>>>>>>> the hypothetical SMS, still there is a user interaction.
>>>>>>>>
>>>>>>>> I'm not seeing any security issue here, and while exposing data to
>>>>>>>> a malicious attacker is always a concern, this is opt-in functionality by
>>>>>>>> the RS, so if they are concerned they need not implement the RFC. I'd ask
>>>>>>>> for at least one practical attack that this RFC enables (not necessarily
>>>>>>>> causes).
>>>>>>>>
>>>>>>>> On Tue, Oct 25, 2022 at 1:29 PM Jaimandeep Singh <
>>>>>>>> jaimandeep.phdcs21@nfsu.ac.in> wrote:
>>>>>>>>
>>>>>>>>> Dear Warren, Brian and Vittorio,
>>>>>>>>> My concerns regarding the additional complexity are well addressed
>>>>>>>>> by Warren. I am reproducing the same for sake of records in the email
>>>>>>>>> archive.
>>>>>>>>>
>>>>>>>>>> I'd love to see a situation where it is a better at the gateway
>>>>>>>>>> level. The problem is that, even if you could, you almost certainly
>>>>>>>>>> shouldn't, since doing so couples the gateway to the authorization
>>>>>>>>>> check/permissions validation of the service. The gateway now needs to
>>>>>>>>>> become away of how the underlying resources work.
>>>>>>>>>
>>>>>>>>> Even in simple scenarios, this becomes impossible to manage since
>>>>>>>>>> understanding the "business logic" is required to know "whether a user
>>>>>>>>>> should have access". That means the gateways are doomed from the start.
>>>>>>>>>
>>>>>>>>> As I mentioned it is possible, doing the check at the component
>>>>>>>>>> level can be augmented by a system that manages those permissions, which
>>>>>>>>>> different from doing the check at the gateway level. At least this is what
>>>>>>>>>> we advice the clients of our CIAM solution.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I would like to close the concerns regarding Item No-1 and move on
>>>>>>>>> towards Item No 2. I am reproducing the conversation for sake of ease of
>>>>>>>>> reference.
>>>>>>>>>
>>>>>>>>> *Item No 2*: Punching a security hole by requiring AS to act on
>>>>>>>>> information provided by the client applications (Reverse Flow).
>>>>>>>>> *Follow-up Comments-v2*. Refer Section abstract of draft RFC
>>>>>>>>>
>>>>>>>>>> This document also codifies a mechanism for a client to request
>>>>>>>>>> that an authorization server achieve a specific authentication strength or
>>>>>>>>>> freshness when processing an authorization request.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> a. In our journey of OAuth 2.0 we are still struggling with
>>>>>>>>> security issues related to access tokens from AS->clientapp->RS. Now, we
>>>>>>>>> are introducing a reverse flow, which is likely to introduce numerous other
>>>>>>>>> vulnerabilities. Whenever the communication crosses the boundaries from
>>>>>>>>> trusted -> untrusted -> trusted it creates its own set of security
>>>>>>>>> problems.
>>>>>>>>> b. Need for signing the values (error_codes) returned by the RS
>>>>>>>>> which can be verified by the AS. Therefore, we need to look at ways by
>>>>>>>>> which the RS returns a signed JWT token containing "acr_values" or other
>>>>>>>>> such parameters which are opaque to the client applications. I also
>>>>>>>>> appreciate that signed JWT will create its own complexities especially with
>>>>>>>>> regards to verifying the association between the RS and its public key.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Oct 24, 2022 at 6:18 PM Jaimandeep Singh <
>>>>>>>>> jaimandeep.phdcs21@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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/oauth/rNqEACxVM1OtDfT5SIQDybSK6kk/__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8QBorqkk$>,
>>>>>>>>>> part-2
>>>>>>>>>> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/oauth/U8c9JfHCnmcbX238zXWTuRgx2BE/__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p82wjeKpM$>
>>>>>>>>>> and part-3
>>>>>>>>>> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/oauth/SsollGVV01oPmYYTef25-SYVYok/__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8Ok6RPCU$>
>>>>>>>>>> .
>>>>>>>>>>
>>>>>>>>>> *Item No 1*: Striking at the core of OAuth 2.0 idea by coupling
>>>>>>>>>> end user authentication with authorization.
>>>>>>>>>> *Follow-up Comments-v3*. My original concern was the
>>>>>>>>>> introduction of tight coupling between end user authentication and the
>>>>>>>>>> OAuth 2.0. It was explained by Brian that the draft RFC does not intend to
>>>>>>>>>> introduce any coupling and just provides a channel of signal/information
>>>>>>>>>> flow between AS and RS via client app. It is just that the signal as of now
>>>>>>>>>> only contains data on the end-user authentication. This seems to be a
>>>>>>>>>> reasonable explanation and the point is not pressed further. However, this
>>>>>>>>>> has raised two sub concerns. One is mentioned in Item No5, so I am not
>>>>>>>>>> taking it up here.
>>>>>>>>>>
>>>>>>>>>> The other remaining sub concern is the complexity introduced due
>>>>>>>>>> to the introduction of the new channel. If we look from the higher level of
>>>>>>>>>> abstraction, earlier the events concerned were handled at the
>>>>>>>>>> interface/entry level, now the information about the events is passed on to
>>>>>>>>>> the other components of the system . All the other components may handle
>>>>>>>>>> the events as per their policies and can be out of sync with each other.
>>>>>>>>>>
>>>>>>>>>> Coming back to OAuth 2.0, earlier the authentication complexities
>>>>>>>>>> were handled by AS as per OIDC specs. Now, with the introduction of this
>>>>>>>>>> channel, the authentication event information is being passed on to the RS.
>>>>>>>>>> The requirement/behaviour of RS may not be in sync with the requirements of
>>>>>>>>>> AS. I had given a hypothetical example of one such complexity in my email
>>>>>>>>>> part-3. Just to give another flavour of the complexity I am quoting from
>>>>>>>>>> Section 5 of the draft RFC which acknowledges the existence of loops being
>>>>>>>>>> handled by OIDC specs.
>>>>>>>>>>
>>>>>>>>>> The recommended behavior will help prevent clients getting stuck
>>>>>>>>>>> in a loop where the authorization server keeps returning tokens that the
>>>>>>>>>>> resource server already identified as not meeting its requirements hence
>>>>>>>>>>> known to be rejected as well.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If the esteemed members are of the view that the benefits accrued
>>>>>>>>>> are more than the complexity introduced we can close the concern and move
>>>>>>>>>> ahead. I would request the members to give their views.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Oct 24, 2022 at 3:51 PM Warren Parad <wparad@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.phdcs21@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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/oauth/rNqEACxVM1OtDfT5SIQDybSK6kk/__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8QBorqkk$>
>>>>>>>>>>>> and part2
>>>>>>>>>>>> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/oauth/U8c9JfHCnmcbX238zXWTuRgx2BE/__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p82wjeKpM$>
>>>>>>>>>>>> .
>>>>>>>>>>>>
>>>>>>>>>>>> *Item No 1*: Striking at the core of OAuth 2.0 idea by
>>>>>>>>>>>> coupling end user authentication with authorization.
>>>>>>>>>>>> *Follow-up Comments-v2*.
>>>>>>>>>>>>
>>>>>>>>>>>>> by allowing a resource server to signal to a client that the
>>>>>>>>>>>>> authentication event associated with the access token of the current
>>>>>>>>>>>>> request doesn't meet its requirements (however the RS determines that) and
>>>>>>>>>>>>> convey that to the AS in the authorization request (via the user's browser)
>>>>>>>>>>>>> to remediate.
>>>>>>>>>>>>
>>>>>>>>>>>> In my view we are creating an information/signal channel
>>>>>>>>>>>> between AS and RS via client app. Both AS and RS may or may not act on this
>>>>>>>>>>>> information/signal depending upon their policies and is out of the scope of
>>>>>>>>>>>> the draft RFC. The forward path of this information/signal channel can
>>>>>>>>>>>> piggyback on the existing mechanism of the access tokens. However, no such
>>>>>>>>>>>> mechanism exists for the reverse path from RS to AS in the OAuth 2.0 specs.
>>>>>>>>>>>> The question then arises:-
>>>>>>>>>>>>
>>>>>>>>>>>> a. Do we need to restrict the signals only to the end user
>>>>>>>>>>>> authentication or are there any more signals to be considered. This
>>>>>>>>>>>> question was previously asked by Yusuf. I have suggested other options in
>>>>>>>>>>>> Item No 5 of this email.
>>>>>>>>>>>>
>>>>>>>>>>>> b. Are we comfortable in opening up a reverse channel from RS
>>>>>>>>>>>> to AS via client app which will potentially open OAuth 2.0 to
>>>>>>>>>>>> numerous other vulnerabilities as mentioned in Item No 2.
>>>>>>>>>>>>
>>>>>>>>>>>> c. These signals are already well handled at the entry point
>>>>>>>>>>>> i.e AS level through various specs like OIDC. Then, is there a need to
>>>>>>>>>>>> again send these signals to RS and then carry the response back to AS? Is
>>>>>>>>>>>> this not overly complicating the OAuth process? A hypothetical example of
>>>>>>>>>>>> such a complication is given below.
>>>>>>>>>>>>
>>>>>>>>>>>> Hypothetical example. Say tomorrow the draft RFC is implemented
>>>>>>>>>>>> and now a particular RS decides that its high value scopes can only be
>>>>>>>>>>>> accessed by end-users authenticated using MFA. This may result in a
>>>>>>>>>>>> scenario wherein, the end-user is not able to read his own emails if he
>>>>>>>>>>>> does not have MFA enabled. Alternatively, he may be locked out, in case the
>>>>>>>>>>>> email client application used by him does not support MFA. The concept of
>>>>>>>>>>>> "freshness!!" may result in the requirement of logging in every hour or
>>>>>>>>>>>> every day for accessing own emails.
>>>>>>>>>>>>
>>>>>>>>>>>> *Item No 2*: Punching a security hole by requiring AS to act
>>>>>>>>>>>> on information provided by the client applications (Reverse Flow).
>>>>>>>>>>>> *Follow-up Comments-v2*. Refer Abstract of draft RFC
>>>>>>>>>>>>
>>>>>>>>>>>>> This document also codifies a mechanism for a client to
>>>>>>>>>>>>> request that an authorization server achieve a specific authentication
>>>>>>>>>>>>> strength or freshness when processing an authorization request.
>>>>>>>>>>>>
>>>>>>>>>>>> In our journey of OAuth 2.0 we are still struggling with
>>>>>>>>>>>> security issues related to access tokens from AS->clientapp->RS. Now, we
>>>>>>>>>>>> are introducing a reververs flow, which will itself introduce numerous
>>>>>>>>>>>> other vulnerabilities. Whenever the communication crosses the boundaries
>>>>>>>>>>>> from trusted -> untrusted -> trusted it creates its own set of security
>>>>>>>>>>>> problems.
>>>>>>>>>>>>
>>>>>>>>>>>> *Item No 3*: Forcing AS to implement OIDC specifications will
>>>>>>>>>>>> render existing implementations non-compliant.
>>>>>>>>>>>> *Follow-up Comments-v2*.
>>>>>>>>>>>>
>>>>>>>>>>>>> I don't see how this as being biased. I see it as a pragmatic
>>>>>>>>>>>>> decision aimed at simplification and interoperability.
>>>>>>>>>>>>
>>>>>>>>>>>> Using two simple constructs may seem innocuous at first, but it
>>>>>>>>>>>> does give an impression that OIDC is the preferred mechanism for the
>>>>>>>>>>>> authentication of the end-user as compared to any other implementations.
>>>>>>>>>>>>
>>>>>>>>>>>> *Item No 4*: How much “Freshness” is fresh?
>>>>>>>>>>>> *Follow-up Comments-v2*. The parameters like "expires_in" have
>>>>>>>>>>>> already been defined in the original RFC 6749 without the need of the term
>>>>>>>>>>>> "Freshness".
>>>>>>>>>>>>
>>>>>>>>>>>> *Item No 5*: Why not include client app parameters in the
>>>>>>>>>>>> signal flow?
>>>>>>>>>>>> *Comments*. Vittorio's answer to Yusuf's email dated 13 Oct
>>>>>>>>>>>> 2022.
>>>>>>>>>>>>
>>>>>>>>>>>>> During the discussion we did inquire on other
>>>>>>>>>>>>> parameters/aspects that would have the same direct applicability but
>>>>>>>>>>>>> nothing was identified.
>>>>>>>>>>>>
>>>>>>>>>>>> We may consider including various parameters of the client app
>>>>>>>>>>>> in the step-up as it is intrinsic to the OAuth 2.0 specs and plays a big
>>>>>>>>>>>> role in how the permission is granted for restricted scopes.
>>>>>>>>>>>>
>>>>>>>>>>>> Let us see how Google handles the restricted scopes. Refer here
>>>>>>>>>>>> <https://urldefense.com/v3/__https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8e5K9vUI$>
>>>>>>>>>>>> .
>>>>>>>>>>>>
>>>>>>>>>>>>> The Gmail and Fit APIs limit the apps that can seek permission
>>>>>>>>>>>>> to access consumer data. These additional requirements for restricted
>>>>>>>>>>>>> scopes require an app to demonstrate that they're a permitted application
>>>>>>>>>>>>> type and to submit to additional reviews, which include a possible security
>>>>>>>>>>>>> assessment by a third-party auditor.
>>>>>>>>>>>>
>>>>>>>>>>>> Here, the problem of restricted or sensitive scopes is handled
>>>>>>>>>>>> through security assessment of the apps requesting these scopes.
>>>>>>>>>>>>
>>>>>>>>>>>> The signal related to the client app could therefore carry the
>>>>>>>>>>>> following information:
>>>>>>>>>>>> a. Type of client app
>>>>>>>>>>>> b. How has it been identified i.e using basic authentication,
>>>>>>>>>>>> mTLS or other such techniques.
>>>>>>>>>>>> c. Security assessment of the client app
>>>>>>>>>>>>
>>>>>>>>>>>> Wishing everyone a Happy Diwali
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Sat, Oct 22, 2022 at 12:49 AM Brian Campbell <bcampbell=
>>>>>>>>>>>> 40pingidentity.com@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.ch@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.in@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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/oauth/rNqEACxVM1OtDfT5SIQDybSK6kk/__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8QBorqkk$>
>>>>>>>>>>>>>>> ]:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Item No 1*: Striking at the core of OAuth 2.0 idea by
>>>>>>>>>>>>>>> coupling end user authentication with authorization.
>>>>>>>>>>>>>>> *Follow-on Comment*: Thx for bringing out that RFC 9068
>>>>>>>>>>>>>>> already has "acr'' as a claim. However, it is an OPTIONAL claim, whereas
>>>>>>>>>>>>>>> section 5 of the draft RFC recommends it to be a required parameter.
>>>>>>>>>>>>>>> Notwithstanding, in my view, the proposed draft is challenging the very
>>>>>>>>>>>>>>> premises of OAuth 2.0 by strongly coupling the authorization layer with the
>>>>>>>>>>>>>>> end user authentication. The OAuth 2.0 is supposed to be agnostic to the
>>>>>>>>>>>>>>> end user authentication. Are we comfortable with this coupling?
>>>>>>>>>>>>>>> *Recommendation*: The draft RFC should be made
>>>>>>>>>>>>>>> informational. If that is out of scope then all the proposed claims,
>>>>>>>>>>>>>>> parameters and headers should be made OPTIONAL.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Item No 2*: Punching a security hole by requiring AS to
>>>>>>>>>>>>>>> act on information provided by the client applications (Reverse Flow).
>>>>>>>>>>>>>>> *Follow-on Comment*: I would like to differ on this view.
>>>>>>>>>>>>>>> The client applications do require authentication in case of confidential
>>>>>>>>>>>>>>> clients (Refer Section 2.3 of RFC 6749). I would also like to point towards
>>>>>>>>>>>>>>> the Google OAuth 2.0 page which talks about 'creation of authorization
>>>>>>>>>>>>>>> credentials' by the client applications and can be accessed
>>>>>>>>>>>>>>> here
>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://developers.google.com/identity/protocols/oauth2/web-server__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8_XFxQmU$>
>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>    The point I am making is that the client application
>>>>>>>>>>>>>>> needs to authenticate itself with the OAuth 2.0 endpoint before starting
>>>>>>>>>>>>>>> the communication. Also, making AS act on information provided by
>>>>>>>>>>>>>>> client applications may lead to future vulnerabilities as client
>>>>>>>>>>>>>>> applications are not considered 'trusted' especially when we follow zero
>>>>>>>>>>>>>>> trust architecture.
>>>>>>>>>>>>>>> *Recommendation*.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> a. The example given in section 4 of draft RFC be updated to
>>>>>>>>>>>>>>> reflect the need of complete authentication of the client application
>>>>>>>>>>>>>>> before the "acr_values" or "max_age" values are accepted or acted upon by
>>>>>>>>>>>>>>> the OAuth 2.0 endpoint.
>>>>>>>>>>>>>>> b. Need for signing these values by the RS which can be
>>>>>>>>>>>>>>> verified by the AS. Therefore, we need to look at ways by which the RS
>>>>>>>>>>>>>>> returns a signed JWT token containing "acr_values" or other such claims
>>>>>>>>>>>>>>> which should also be opaque to the client applications.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Item No 3*: Forcing AS to implement OIDC specifications
>>>>>>>>>>>>>>> will render existing implementations non-compliant.
>>>>>>>>>>>>>>> *Follow-on Comment*: I fully agree to your statement that
>>>>>>>>>>>>>>> 'existing implementations aren't expected to comply with the new
>>>>>>>>>>>>>>> specification'. However, the point I am making is that we cannot be biased
>>>>>>>>>>>>>>> towards OIDC specifications and leave others non-compliant. We have to make
>>>>>>>>>>>>>>> future specifications such that it doesn't favour one over other.
>>>>>>>>>>>>>>> *Recommendations*: All the proposed claims, parameters and
>>>>>>>>>>>>>>> headers should be made OPTIONAL.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Item No 4*: How much “Freshness” is fresh?
>>>>>>>>>>>>>>> *Follow-on Comment*: The *term* "freshness" may have
>>>>>>>>>>>>>>> earlier precedent but the context is different.
>>>>>>>>>>>>>>> *Recommendation*. Let's not use a term which cannot be
>>>>>>>>>>>>>>> quantified and is open to different interpretations by
>>>>>>>>>>>>>>> readers/implementers.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Kind Regards
>>>>>>>>>>>>>>> Jaimandeep Singh
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Oct 21, 2022 at 2:53 AM Vittorio Bertocci <vittorio=
>>>>>>>>>>>>>>> 40auth0.com@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
>>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9068__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8gOHSzMU$>,
>>>>>>>>>>>>>>>> as referenced by the draft.
>>>>>>>>>>>>>>>> For what concerns the clientID considerations - the draft
>>>>>>>>>>>>>>>> is pretty clear on aiming to solve scenarios where the RS is the entity
>>>>>>>>>>>>>>>> deciding to reject incoming tokens for its own reasons, such as risk
>>>>>>>>>>>>>>>> assessment performed locally, that by definition cannot be determined
>>>>>>>>>>>>>>>> solely on the basis of the client identity.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2 - I have a hard time parsing this objection as well. A
>>>>>>>>>>>>>>>> client does NOT authenticate itself when hitting the authorization
>>>>>>>>>>>>>>>> endpoint, regardless of the client flavor;  whether the oauth spec accepts
>>>>>>>>>>>>>>>> a parameter or not isn't really relevant in an spec whose intent is to
>>>>>>>>>>>>>>>> _extend_ oauth; and saying that the client is untrusted doesn't mean that
>>>>>>>>>>>>>>>> the AS wouldn't comply with request parameters, because once again the
>>>>>>>>>>>>>>>> authorization endpoint doesn't require ANy client authentication.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 3- New RFCs don't override existing specs: they build on
>>>>>>>>>>>>>>>> existing specs by extending and/or constraining existing behaviors. Forward
>>>>>>>>>>>>>>>> compatibility would require the ability to predict the future, hence
>>>>>>>>>>>>>>>> existing implementations aren't expected to comply with the new
>>>>>>>>>>>>>>>> specification until they decide to add support for it. Now for this
>>>>>>>>>>>>>>>> particular specification, we might get lucky and have forward compatibility
>>>>>>>>>>>>>>>> in many implementations as products often implement both OAuth and OIDC in
>>>>>>>>>>>>>>>> the same codebase, but once again - that is definitely not required.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 4- Also in this case, I am not sure how to read this
>>>>>>>>>>>>>>>> objection. The use of the *term* "freshness" has precedent in IETF specs
>>>>>>>>>>>>>>>> (see rfc8747) and is commonly used in discussions on the list; and the
>>>>>>>>>>>>>>>> concept is very well known and understood, as the existence of the max_age
>>>>>>>>>>>>>>>> parameter attests; the fact that it is defined in OIDC doesn't really
>>>>>>>>>>>>>>>> matter in this context, it is common practice for RS to impose the same
>>>>>>>>>>>>>>>> constraint- one of the reasons that prompted us to draft this extension.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I hope this helps!
>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>> V.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Oct 20, 2022 at 10:10 AM Jaimandeep Singh
>>>>>>>>>>>>>>>> <jaimandeep.phdcs21=40nfsu.ac.in@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.com@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.in@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.com@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.ietf@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.ietf@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.com@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 <
>>>>>>>>>>>>>>>>>>>>>>> dima@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.com@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-bounces@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.ietf@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
>>>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8MsQyrSI$>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Regards and Best Wishes
>>>>>>>>>>>>>>> Jaimandeep Singh
>>>>>>>>>>>>>>> LinkedIn
>>>>>>>>>>>>>>> <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8MsQyrSI$>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8MsQyrSI$>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential
>>>>>>>>>>>>> and privileged material for the sole use of the intended recipient(s). Any
>>>>>>>>>>>>> review, use, distribution or disclosure by others is strictly prohibited.
>>>>>>>>>>>>> If you have received this communication in error, please notify the sender
>>>>>>>>>>>>> immediately by e-mail and delete the message and any file attachments from
>>>>>>>>>>>>> your computer. Thank you.*
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Regards and Best Wishes
>>>>>>>>>>>> Jaimandeep Singh
>>>>>>>>>>>> LinkedIn
>>>>>>>>>>>> <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Regards and Best Wishes
>>>>>>>>>> Jaimandeep Singh
>>>>>>>>>> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Regards and Best Wishes
>>>>>>>>> Jaimandeep Singh
>>>>>>>>> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Regards and Best Wishes
>>>>>>> Jaimandeep Singh
>>>>>>> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!4kl5AkuLPyb_vTDmDJ9IjbvadIZ0nulugBteXl41HkhMekNmfa-emLoXX72tKvOAl0-RLXu6Jn_JIjL1nLsLO2p8MsQyrSI$>
>>>>>>>
>>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>> _______________________________________________
>>> 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>
>