Return-Path: 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 24618C15792A for ; Thu, 31 Oct 2024 23:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QtcbB_j1p6Xb for ; Thu, 31 Oct 2024 23:14:01 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EF68C169403 for ; Thu, 31 Oct 2024 23:14:01 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-2fb3c3d5513so15183071fa.1 for ; Thu, 31 Oct 2024 23:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730441639; x=1731046439; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=BgZaSlqguHDRcJ7k6ujSA6rq78UT9N7z9gZwPCHET5A=; b=Z//UfdMuW8g93Bbk0DLbk4uHjQ43s1vJB2mQb5IdoCXVuLyErRHrZ4RacDSjL7rnfz kJKolmkH8M5VQOsOC628hgPElc1bvUHNnBFn9g/F5PzCVjSyREQej7DwxUfVJh2s0Xys Y0UXyS1tgc+b7eYuOvaF/5DaYegyqg/wy56mp3ZB7zvzcAV0FT2/GrJtxsyMkZFN1QBd hsEUyNILGSaS0lnGThFg1HzDDVlYdO47+uEI+whUcQzOlSCP9pUoHGLaWDAU3LTnFQm+ NdW5VXhYM3qRpvYf7NZWWAKSWpOnTwFg8RUnt2e1Yppct4fw/tDWl80M74yxKxpSBi5f fMTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730441639; x=1731046439; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=BgZaSlqguHDRcJ7k6ujSA6rq78UT9N7z9gZwPCHET5A=; b=qHlMKtPej3MOQfeO5PsxEc7Uq6d97+ZUvtB+O6hVtJOh8mGBcuJjzAO6JhG0UKb+6H 8jtoOGXp9/ahbTcL0sEbxYP4qGxvYWPBan3qLeWSWW/IEUaGGCT57Zg2fdwGKpHNj2gl OKih+QP3Zk99HpwFdlYzqGb1h+Y5m9kwhPviTASxoUWAEwuy6JqV+tw+aZO072zibRU6 d/SbpccunLxvoafx3Xj9XOKc3UmXry1mesAca5+agnJFoaAXrQBByUFAl5XmeK+Ywaat opzm4Mjv+UqQnW8CzsVbJEMOewenz7Pr3qTqRE0hNQ0fZBBtOwt1DPvB1xQ19T7dhN3Q 4oNg== X-Gm-Message-State: AOJu0YwXCyiKZ5XnGH2l3h3WXPhgEZMFIpVhmjDws9cLlzZurY9iXpgU Ricp5xFcURYvbYTg+TNBjPrL4ikSgHv4vGdQJpUA0VqmpyS7+ywFbjBSguFiSqQYJvYvl1Bz8bd Bc9c+YS/f4FhRFIs8/Cx34QT4a0EPTvuYqH8= X-Google-Smtp-Source: AGHT+IFoJ7uGws41hTqXVs66Pe/xt1EwRtGpcoiB+9tYrRBj2JfYlgoEibwnQaOC1GNNzq6jsSSJEw1FxCZ3Z8WBbvY= X-Received: by 2002:a2e:4619:0:b0:2fb:b59:8167 with SMTP id 38308e7fff4ca-2fdecc2a016mr22230671fa.39.1730441638481; Thu, 31 Oct 2024 23:13:58 -0700 (PDT) MIME-Version: 1.0 From: Janak Amarasena Date: Thu, 31 Oct 2024 23:13:22 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="0000000000002a96870625d3d7eb" Message-ID-Hash: ATAPRQZBY5RZV7OOYVIL6WLLEXPTENZM X-Message-ID-Hash: ATAPRQZBY5RZV7OOYVIL6WLLEXPTENZM X-MailFrom: janakama360@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BOAUTH-WG=5D_Feedback_on_draft-ietf-oauth-first-party-apps-00?= List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000002a96870625d3d7eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, I have gone through the OAuth 2.0 for First Party Applications draft ( draft-ietf-oauth-first-party-apps-00) and have some feedback on it. I think this is a much needed standard. At my organization(WSO2) also we have seen a significant demand from customers requesting to do API centric authorization largely due to the need for seamless UX. We have seen places where organizations lean more towards UX disregarding security best practices. Due to the demand we ourselves did an extension for OAuth to solve the same problem this specification is addressing and at the time if this specification existed we would have definitely implemented this without going ahead with our own extension. Please find my feedback below; Under section 5.1. =E2=80=9CAuthorization Challenge Request=E2=80=9D the sp= ec lists the =E2=80=9Ccode_challenge=E2=80=9D and the "code_challenge_method" as optiona= l parameters. As this protocol establishes direct communication between the client and the AS I don=E2=80=99t see a real requirement to mention PKCE related parameter= s here. Please let me know if I have missed anything here. As I understood, using these two parameters in the authorization challenge request is useful only when the client expects that it will have to perform a redirect based authorization flow and also the AS supports PAR capabilities through the authorization_challenge_endpoint. I think this will be an edge case and given the spec mentions it supports all extensions applicable to the authorization endpoint I don=E2=80=99t see a major need t= o specifically mention these two parameters under this section. I think this could also cause confusion to implementers. Under section 5.2.2.1. =E2=80=9CRedirect to Web Error Response=E2=80=9D the= spec mentions In this case, the client is expected to initiate a new OAuth Authorization Code flow with PKCE according to [RFC6749] and [RFC7636]. If the client expects the frequency of this error response to be high, the client MAY include a PKCE ([RFC7636]) code_challenge in the initial authorization challenge request. This enables the authorization server to essentially treat the authorization challenge request as a PAR [RFC9126] request, and return the request_uri and expires_in as defined by [RFC9126] in the error response. The client then uses the request_uri value to build an authorization request as defined in [RFC9126] Section 4. I think it would be good to add some text to the spec mentioning the possibility to use the auth_session in this new authorization request such that the user can continue the login from where the user left off. Something similar is mentioned in section 6.1. for step-up authentication. I have some concerns with the authorization_challenge_endpoint being able to act as the PAR endpoint. I understand the improved experience gained here but this essentially creates two standard endpoints that can do similar things. Instead it might be possible to use the auth_session to maintain the complete context. However this could be overloading the expectations of the auth_session. Under section 5.3.1. =E2=80=9CAuth Session=E2=80=9D spec mentions; The auth_session value is completely opaque to the client, and as such the authorization server MUST adequately protect the value from inspection by the client, for example by using a random string or using a JWE if the authorization server is not maintaining state on the backend. I think the intention behind mandating to maintain the opaqueness is to protect any sensitive information. Depending on the AS implementation it could decide on using an auth_session value which is not opaque but also does not contain any sensitive data. I think it would be better to recommend that the AS uses adequate measures such as encryption in the event they are using something other than an opaque value that contains sensitive data. The current mandating will put an unnecessary burden on the AS to encrypt and decrypt data if it doesn=E2=80=99t contain sensitive info= rmation. In the same section it mentions; To mitigate the risk of session hijacking, the 'auth_session' MUST be bound to the device, and the authorization server MUST reject an 'auth_session' if it is presented from a different device than the one it was bound to. I completely agree on the need to mitigate the risk of session hijacking. However, in the current text, although it's not directly mentioned here, it will require the AS to have a proof of possession mechanism in place as pointed in Section 9 "Security Considerations". This can be a major barrier to implement this specification as the AS should also implement another specification. There can be different ways the implementation can solve this problem without needing proof of possession. For example if the auth_session is only transmitted between the AS and the client then it will be protected with TLS in transit and the client and AS can use independent mechanisms to protect the auth_session at rest. Since this specification applies only to first party applications the implementers will have full control over how the client and the AS protects the data, and therefore can make sure adequate protection is in place for the auth_session. Due to this I think it is better to change wording from mandating to a recommendation. Regarding section =E2=80=9C7. Resource Server Error Response=E2=80=9D I am = wondering whether this section is required at all as this spec makes no addition to RFC9470. I guess this section is there to provide clarity due to RFC9470 using the authorization endpoint in its text. Under section 9.5.1. DPoP: Demonstrating Proof-of-Possession it mentions = =E2=80=9C=E2=80=A6 The authorization server MUST ensure that the same key is used in all subsequent Authorization Challenge Requests, or in the eventual token request=E2=80=A6=E2=80=9D I think it was meant to say =E2=80=9C... Authoriz= ation Challenge Requests, and in the eventual token request=E2=80=A6=E2=80=9D Best Regards, Janak Amarasena --0000000000002a96870625d3d7eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I have gone through the OAuth 2.0 for First Party Appl= ications draft (draft-ietf-oauth-first-party-apps-00) and have= some feedback on it. I think this is a much needed standard. At my organiz= ation(WSO2) also we have seen a significant demand from customers requestin= g to do API centric authorization largely due to the need for seamless UX. = We have seen places where organizations lean more towards UX disregarding s= ecurity best practices. Due to the demand we ourselves did an extension for= OAuth to solve the same problem this specification is addressing and at th= e time if this specification existed we would have definitely implemented t= his without going ahead with our own extension.


Please = find my feedback below;

<= br>

Under section 5.1. =E2= =80=9CAuthorization Challenge Request=E2=80=9D the spec lists the =E2=80=9C= code_challenge=E2=80=9D and the "code_challenge_method" as option= al parameters. As this protocol establishes direct communication between th= e client and the AS I don=E2=80=99t see a real requirement to mention PKCE = related parameters here. Please let= me know if I have missed anything here.

As I understood, using these two parameters<= font face=3D"arial, sans-serif"> in the authorization challen= ge request is useful only when the client expects that it will have to perf= orm a redirect based authorization flow and also the AS supports PAR capabi= lities=C2=A0through the=C2=A0authorization_challenge_endpoint.=C2=A0I think = this will be an edge case and given the spec mentions it supports all exten= sions applicable to the authorization endpoint I don=E2=80=99t see a major = need to specifically mention these two parameters under this section. I thi= nk this could also cause confusion to implementers.


Und= er section 5.2.2.1. =E2=80=9CRedirect to Web Error Response=E2=80=9D the sp= ec mentions=C2=A0


=C2=A0=C2=A0=C2=A0In this case, the cli= ent is expected to initiate a new OAuth

=C2=A0=C2=A0=C2=A0Authorization Code flow with PKCE according= to [RFC6749] and

=C2=A0= =C2=A0=C2=A0[RFC7636].

=C2=A0=C2=A0=C2=A0If the client ex= pects the frequency of this error response to be

=C2=A0=C2=A0=C2=A0high, the client MAY include a PKC= E ([RFC7636]) code_challenge in the

=C2=A0=C2=A0=C2=A0initial authorization challenge request.=C2= =A0 This enables the

=C2=A0=C2=A0=C2=A0authorization server to essentially treat the = authorization challenge

= =C2=A0=C2=A0=C2=A0request as a PAR [RFC9126] request, and return the reques= t_uri and

=C2=A0=C2=A0=C2= =A0expires_in as defined by [RFC9126] in the error response.=C2=A0 The clie= nt

=C2=A0=C2=A0=C2=A0then = uses the request_uri value to build an authorization request as

=C2=A0=C2=A0=C2=A0defined in [RFC9126= ] Section 4.


<= p dir=3D"ltr" style=3D"line-height:1.2;margin-top:0pt;margin-bottom:0pt">I think it would be good to add som= e text to the spec mentioning the possibility to use the auth_session in th= is new authorization request such that the user can continue the login from= where the user left off. Something similar is mentioned in section 6.1. fo= r step-up authentication.=C2=A0


I have some concerns with the authorization_challenge_endpoint being abl= e to act as the PAR endpoint. I understand the improved experience gained h= ere but this essentially creates two standard endpoints that can do similar= things. Instead it might be possible to use the auth_session to maintain t= he complete context. However this could be overloading the expectations of = the auth_session.


Under section 5.3.1. =E2=80=9C= Auth Session=E2=80=9D spec mentions;


=C2=A0=C2=A0 The aut= h_session value is completely opaque to the client, and as

= = =C2=A0=C2=A0=C2=A0such the authorization s= erver MUST adequately protect the value from

=C2=A0=C2=A0=C2=A0inspection by the client, for example = by using a random string or

=C2=A0=C2=A0= =C2=A0the backend.


I think the intention behind = mandating to maintain the opaqueness is to protect any sensitive informatio= n. Depending on the AS implementation it could decide on using an auth_sess= ion value which is not opaque but also does not contain any sensitive data.= I think it would be better to recommend that the AS uses adequate measures= such as encryption in the event they are using something other than an opa= que value that contains sensitive data. The current mandating will put an u= nnecessary burden on the AS to encrypt and decrypt data if it doesn=E2=80= =99t contain sensitive information.


In the same = section it mentions;


=

=C2=A0=C2=A0To mitigate the= risk of session hijacking, the 'auth_session' MUST be

=C2=A0=C2=A0=C2=A0bound to th= e device, and the authorization server MUST reject an

=C2=A0=C2=A0=C2=A0'auth_session= 9; if it is presented from a different device than the

=C2=A0=C2=A0=C2=A0one it was bound to= .


I completely agree on the need to mitigate t= he risk of session hijacking. However, in the current text, although it'= ;s not directly mentioned here, it will require the AS to have a proof of p= ossession mechanism in place as pointed in Section 9 "Se= curity Considerations". This can be a major barrier to implement this s= pecification as the AS should also implement another specification. There c= an be different ways the implementation can solve this problem without need= ing proof of possession. For example if the auth_session is only transmitte= d between the AS and the client then it will be protected with TLS in trans= it and the client and AS can use independent mechanisms to protect the auth= _session at rest. Since this specification applies only to first party appl= ications the implementers will have full control over how the client and th= e AS protects the data, and therefore can make sure adequate protection is = in place for the auth_session. Due to this I think it is better to change w= ording from mandating to a recommendation.


Regarding se= ction =E2=80=9C7. Resource Server Error Response=E2=80=9D I am wondering wh= ether this section is required at all as this spec makes no addition to RFC= 9470. I guess this section is there to provide clarity due to RFC9470 using= the authorization endpoint in its text.=C2=A0


= Under section 9.5.1. DPoP: Demonstrating Proof-of-Possession it mentions = =E2=80=9C=E2=80=A6 The authorization server MUST ensure that the same key i= s used in all subsequent Authorization Challenge Requests, or in the eventual token request=E2=80=A6= =E2=80=9D I think it was meant to say =E2=80=9C... Authorization Challenge = Requests, and in the eventu= al token request=E2=80=A6=E2=80=9D


Best Regards,=

Janak Amarasena<= /font>


--0000000000002a96870625d3d7eb--