Hi Aaron, Thx for your suggestions. I have reviewed the recordings and I would suggest following:
1. Design Consideration: The two components of the OAuth 2.0 ecosystem authorization server (step 1) and protected resource server (step 2) may appear independent, but from systems perspective there is a linear dependency between them. Directly engaging with step 2, even in a limited capacity, threatens the established sequence and poses substantial security and architectural implications. 2. Information Disclosure: Say I have my HIPPA record stored on a protected resource server, I don't want any app to even know that I have such a resource available with a protected resource server in the first place. The concept of exposing the mere existence of such data raises a glaring concern. Looking at Google, it has a fine-grained authorization strategy that meticulously limits access for its RESTRICTED scopes only to apps that meet certain security benchmarks. Once, the malicious apps come to know of the prized data at the resource server, it will lead to targeted phishing attacks, as was highlighted during the 117 meeting, underscoring the fragility of this approach. 3. The Imperative of Gradation and Minimal Exposure: Even if we have to go down this path, there is a definite need to mitigate the perils of overexposure. Instead we can look at gradation strategy, wherein the scopes could be categorized into levels, spanning from generic (Level 0) to tightly controlled (Level 5) access. There is no requirement of secondary URI in this appch. For instance, the sensitive scopes like level 3 and above, may mandate clients to support DPoP and OAuth 2.1. There is no need to divulge if a particular resource is present or not and not even the address of the authorization server. Thanks Jaimandeep Singh On Sat, Aug 26, 2023 at 7:03 AM Aaron Parecki <aaron= 40parecki....@dmarc.ietf.org> wrote: > Hi Jaimandeep, > > As with many OAuth extensions, this is not obligatory to implement unless > you need the functionality it provides. Many of the concerns you mention > are referenced in the security considerations section of the draft already, > and we would of course be happy to further expand that section as > appropriate. > > As we presented during the last two IETF meetings, there are many use > cases that would benefit from this draft that currently don't have an > interoperable solution. I would suggest you review those presentation > recordings so better understand the use cases. > > Aaron > > > > > On Fri, Aug 25, 2023 at 12:31 PM Jaimandeep Singh <jaimandeep.phdcs21= > 40nfsu.ac...@dmarc.ietf.org> wrote: > >> I do not support the adoption because of following: >> >> 1. Increased Attack Surface and Information Disclosure: The proposed >> draft inherently expands the attack surface by allowing the retrieval of >> detailed information about the protected resources held with a >> particular resource server, as outlined in section 3.1. We are >> inadvertently exposing the resources supported by the protected resource >> server. The secondary URIs which correspond to each of the protected >> resources further expands the potential attack vectors. To illustrate, if a >> protected resource server supports resources from 1 to 10, and a client >> requests metadata for all these resources, it leads to 11 requests (1 + >> 10). This exposes a total of 11 URIs to potential attackers with >> information disclosure. >> >> 2. Lack of Client Verification and Potential DDoS Vulnerability: There is >> absence of client application verification before it accesses the APIs. >> This can lead to the possibility of malicious client applications >> initiating Distributed Denial of Service (DDoS) attacks. >> >> 3. Impact on Processing Time due to Multiple Resources: The need to >> wildcard match/support numerous secondary URIs based on the number of >> protected resources could lead to increased processing time. >> >> 4. Strengthening the Existing System with Adequate Error Codes: Our >> existing OAuth RFC, can handle this issue gracefully by incorporating error >> codes. This ensures that, at the very least, access tokens are verified >> before any specific information is disclosed. >> >> Thanks >> Jaimandeep Singh >> >> On Thu, Aug 24, 2023 at 12:32 AM Rifaat Shekh-Yusef < >> rifaat.s.i...@gmail.com> wrote: >> >>> All, >>> >>> This is an official call for adoption for the *Protected Resource >>> Metadata* draft: >>> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/ >>> >>> Please, reply on the mailing list and let us know if you are in favor of >>> adopting this draft as WG document, by *Sep 6th.* >>> >>> Regards, >>> Rifaat & Hannes >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> -- >> Regards and Best Wishes >> Jaimandeep Singh >> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > -- 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
