> Something else we may want to provide is some clear recommendations on when to use CIBA vs Device Authorization Grant etc
I think this would be really helpful. Both specs support "decoupled" flows, but they were designed for different use cases and have different trade-offs. CIBA provides a few more options when it comes to securing decoupled flows that could make the attacks in the original email harder to implement, e.g. - user code (mainly an "anti-spam" parameter) - binding_message - login_hint_token / id_token_hint to bootstrap the flow I'm looking forward to the discussion around this on Thursday Dave On Fri, 18 Mar 2022 at 13:43, Pieter Kasselman <pieter.kasselman= 40microsoft....@dmarc.ietf.org> wrote: > Hi Shane, > > > > Agreed that CIBA is interesting in this context as an alternative to > Device Authorization Grant. > > > > Having the user initiate the request makes it harder for an adversary to > manipulate the context, but I think it also shifts the point of attack. Now > instead of getting the user to enter a user code, you have to get the user > to enter their “user_hint”. This does put it on par with any regular > phishing attack (at least the attack did not become easier). I do think > mitigations on the back-end can help to further reduce the risks for both > Device Authorization Grant and CIBA. > > > > Something else we may want to provide is some clear recommendations on > when to use CIBA vs Device Authorization Grant etc (e.g. use CIBA if the > user can provide input, use Device Authorization Grant if there is no input > device). All of this may seem obvious for experts familiar with this space, > but being explicit will help implementors who has expertise elsewhere. > > > > From looking at various protocols, whenever we attempt to use the user as > a secure transport between their authentication device and the device on > which the service will be delivered, we open an opportunity for social > engineering attacks. Keeping that opening as small and constrained as > possible and then mitigating against errors in judgement will help the > overall security posture. > > > > Cheers > > > > Pieter > > > > *From:* Shane B Weeden <swee...@au1.ibm.com> > *Sent:* Thursday 17 March 2022 21:21 > *To:* Pieter Kasselman <pieter.kassel...@microsoft.com> > *Cc:* oauth@ietf.org > *Subject:* [EXTERNAL] Re: [OAUTH-WG] Device Authorization Grant and > Illicit Consent Exploits > > > > Isn’t this essentially what is mitigated in the FAPI-compliant OIDC CIBA > by: > > 1. Requiring the client to initiate the flow with signed request > parameters which include, via some hint, the resource owner for whom > authentication is being requested > > 2. Requiring that the OP check that the resource owner approving the grant > is the same as that the client associated with the request in step 1 > > > > I realise this requires that the client obtains an indication of the > username of the resource owner up front to kick things off, but short of > this I cannot think of any practical mitigation. > > > > > > > > On 18 Mar 2022, at 7:09 am, Pieter Kasselman < > pieter.kasselman=40microsoft....@dmarc.ietf.org> wrote: > > > > ant problem by enabling authorization flows on devices that are unable to > support a browsers or have limited input capabilities. However, looking > back over the past 18-24 months, there have been a number of practical > exploits published that use social en > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- -- Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2022 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
