As an implementer on both sides of the issue I'm struggling to understand how this problem would occur. I'm finding issues with the proposed problems:
1. Honest AS is compromised, assuming this does happen details on why adding iss to the AS response would prevent attacks is necessary for me. In other words, how would an AS be compromised in a way that would be identifiable through the issuer value? (my ignorant assumption is that a compromised AS is compromised enough that an attacker would be able to send the correct ISS) 2. Attacker AS is registered. I fully support the idea that this can and will happen, however from attempting to test-implement this proposal, I can't see how the authorization would be sent to the wrong token endpoint. Since there is no information in the AS auth code response, the client must already have the knowledge of where they are going to send the token, no mix-up can be executed. I would argue, if anything, adding the ISS parameter would open a new attack surface by providing clients an opportunity to blatantly trust the ISS parameter as the honest AS and thus actually sending the code there instead of sending it to one specified in the metadata document. My confusion is the following: - Are multi AS services utilizing authorization codes in a way where there could be a mix up attack for #2. - Is there a #3 that I'm missing which even in light of #1 & #2 I brought up that would still make this change valuable? Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress <https://bit.ly/37SSO1p>. On Tue, Dec 8, 2020 at 8:01 PM Dick Hardt <dick.ha...@gmail.com> wrote: > +1 > ᐧ > > On Tue, Dec 8, 2020 at 4:51 AM Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> > wrote: > >> All, >> >> This is a call for adoption for the following AS Issuer Identifier in >> Authorization Response as a WG document: >> >> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/ >> >> Please, provide your feedback on the mailing list by Dec 22nd. >> >> Regards, >> Rifaat & Hannes >> _______________________________________________ >> 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
