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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
