On Wed, Nov 28, 2018 at 2:51 PM n-sakimura <n-sakim...@nri.co.jp> wrote:
> That works. > > In fact, I would further go and say MUST NOT but that probably is too much > for a security consideration. > > Personally I think it's fine for a MUST NOT to appear in a security consideration section of a BCP. If you break it, then you're not following the BCP. We did exactly this in BCP 212: "This best current practice requires that native apps MUST NOT use embedded user-agents to perform authorization requests " William 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
