Re: [OAUTH-WG] BCP: Client collaborative attacks

It is worth mentioning “client collaborative attacks” or “authorization sharing attacks” because OAuth can make them easier (by packaging authority into an access token), compared to the alternative of user’s signing-in to an RS directly. But it is tricky to describe; none of the suggestions

Re: [OAUTH-WG] BCP: Client collaborative attacks

Thank you Seán, this is an excellent analysis and makes this attack much easier to understand. I completely agree with your rewritten text, both that it better describes the situation as well as the conclusion that it ends up being a bit too general for the BCP. --- Aaron Parecki

Re: [OAUTH-WG] BCP: Client collaborative attacks

I hadn't come across this idea before, it's an interesting angle and for me it's a nice new example to help highlight the difference between authZ and authN. It reminds me of sharing access cards to get into computer labs in college. Some thoughts: - It took me a while to figure out the agent,

[OAUTH-WG] BCP: Client collaborative attacks

Hi Daniel, Following the conversation we had today, hereafter is a proposal for addressing client collaborative attacks. I propose to add a new section 4.16. 4.16 Client collaborative attacks Two clients may agree to collaborate. In such a situation, one client transmits to another client

Re: [OAUTH-WG] New draft: Mix-up prevention - adding "iss" parameter to the authorization response

To capture my comment from the interim meeting call, I would like to see some explicit text in this draft (as well as the Security BCP section that will reference this draft) that clarifies this parameter is not needed and this attack is not relevant if a client only interacts with one

Re: [OAUTH-WG] New draft: Mix-up prevention - adding "iss" parameter to the authorization response

I'd suggest removing the "of an OAuth authorization grant" bit from the abstract. The term 'authorization grant' has meaning from https://tools.ietf.org/html/rfc6749?#section-1.3 that doesn't really work there in the abstract. On Mon, Oct 26, 2020 at 8:33 AM Karsten Meyer zu Selhausen <

Re: [OAUTH-WG] New draft: Mix-up prevention - adding "iss" parameter to the authorization response

Hi Karsten, Thanks for the write up. I would like to suggest the name authorization_response_iss_parameter_supported, instead of iss_parameter_supported. To make it explicit and unambiguous that it's about the authZ response. Vladimir On 26/10/2020 16:33, Karsten Meyer zu Selhausen wrote: > >

[OAUTH-WG] New draft: Mix-up prevention - adding "iss" parameter to the authorization response

Hello WG, adding the issuer identifier to the authorization response as a countermeasure to mix-up attacks is well-known on this list and already part of the security BCP (see 4.4.2 ). However, the "iss" parameter is