+1 I would also like to ensure there is a clear definition of "sender constrained" tokens in this BCP.
Aaron On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Hi all, > > based on your feedback on the list and off list, Daniel and I polished the > text. That’s our proposal: > > — > In order to avoid these issues, clients MUST NOT use the implicit > grant (response type "token") or any other response type issuing access > tokens in the authorization response, such as "token id_token" and "code > token id_token“, > unless the issued access tokens are sender-constrained and access token > injection in > the authorization response is prevented. > — > > Explantation: > - we wanted to have the right balance between a generic definition of the > response types we do not recommend/allow to be used and a > concrete/actionable list of the affected response types. > - we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported > by William > > We look forward to seeing your feedback. > > kind regards, > Torsten. > > > Am 29.11.2018 um 15:15 schrieb John Bradley <ve7...@ve7jtb.com>: > > > > I am ok with that. > > > > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt < > tors...@lodderstedt.net wrote: > > > > > Am 28.11.2018 um 23:50 schrieb n-sakimura <n-sakim...@nri.co.jp>: > > > > > > That works. > > > > Good! > > > > I just realized this text has an issue with „token“ (only). It would > allow „token“ to be used if the token would sender constrained. This > completely ignores the fact implicit also shall be abandoned because of its > vulnerability for access token injection. > > > > I therefore propose a modified text: > > > > In order to avoid these issues, Clients SHOULD NOT use the implicit > > grant. Furthermore, clients SHOULD only use other response types > causing the authorization server to > > issue an access token in the authorization response, if the > particular response type detects access token > > injection and the issued access tokens are sender-constrained. > > > > Or we just state: > > > > In order to avoid these issues, Clients SHOULD NOT use the response > type „token". The response types > > „token id_token“ and „code token id_token“ SOULD NOT be used, if the > issued access tokens are not > > sender-constrained. > > > > > > > > In fact, I would further go and say MUST NOT but that probably is too > much for a security consideration. > > > > > > > Mike suggested to go with a SHOULD NOT to get the message out but give > implementors time to move/change. > > > > > Best, > > > > > > Nat > > > > > > Nat Sakimura / n-sakim...@nri.co.jp / +81-90-6013-6276 > > > > > > > このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。 > > > > > > PLEASE READ :This e-mail is confidential and intended for the named > recipient only. > > > If you are not an intended recipient, please notify the sender and > delete this e-mail. > > > > > > 差出人: Torsten Lodderstedt <tors...@lodderstedt..net> > > > 送信日時: 水曜日, 11月 28, 2018 11:38 午後 > > > 宛先: n-sakimura > > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org > > > 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization > code instead of implicit > > > > > > Hi Nat, > > > > > >> Am 28.11.2018 um 21:10 schrieb n-sakimura <n-sakim...@nri.co.jp>: > > >> > > >> I would support > > >> > > >> 1) clearly defining Implicit as the flow that returns access token > from the authorization endpoint ( some people confuses implicit as the flow > that returns ID Token in the front channel) > > > > > > That’s the current text: > > > > > > In order to avoid these issues, Clients SHOULD NOT use the implicit > > > grant or any other response type causing the authorization server to > > > issue an access token in the authorization response. > > > > > > What would you like to modify? > > > > > >> > > >> 2) Banning the returning of the access token that are not sender > constrained from the authorization endpoint > > > > > > In order to avoid these issues, Clients SHOULD NOT use the implicit > > > grant or any other response type causing the authorization server to > > > issue an access token in the authorization response, if this access > tokens is not sender-constraint. > > > > > > What about this? > > > > > > kind regards, > > > Torsten. > > > > > >> > > >> Best, > > >> > > >> Nat > > >> > > >> > > >> Outlook for iOS を入手 > > >> > > >> 差出人: OAuth <oauth-boun...@ietf.org> (Dick Hardt <dick.ha...@gmail.com> > の代理) > > >> 送信日時: 水曜日, 11月 28, 2018 8:58 午後 > > >> 宛先: Hannes Tschofenig > > >> Cc: oauth@ietf.org > > >> 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization > code instead of implicit > > >> > > >> +1 > > >> > > >> While there are various mechanisms to alleviate some of the issues of > implicit, I don't think we can recommend specifics, and there may be future > ones in the future. I think we all agree that implicit without any > mitigation is problematic. > > >> > > >> How about we recommend against using implicit alone? > > >> > > >> > > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig < > hannes.tschofe...@arm.com> wrote: > > >> Hi all, > > >> > > >> The authors of the OAuth Security Topics draft came to the conclusion > that it is not possible to adequately secure the implicit flow against > token injection since potential solutions like token binding or JARM are in > an early stage of adoption. For this reason, and since CORS allows > browser-based apps to send requests to the token endpoint, Torsten > suggested to use the authorization code instead of the implicit grant in > call cases in his presentation (see > https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01 > ). > > >> > > >> A hum in the room at IETF#103 concluded strong support for his > recommendations. We would like to confirm the discussion on the list. > > >> > > >> Please provide a response by December 3rd. > > >> > > >> Ciao > > >> > > >> Hannes & Rifaat > > >> > > >> > > >> > > >> IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > >> _______________________________________________ > > >> 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- ---- Aaron Parecki aaronparecki.com @aaronpk <http://twitter.com/aaronpk>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
