Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
Aaron Parecki <aaron@parecki.com> Sat, 01 December 2018 02:18 UTC
Return-Path: <aaron@parecki.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13D712D4EF for <oauth@ietfa.amsl.com>; Fri, 30 Nov 2018 18:18:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level:
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vqdun-Q5ROzM for <oauth@ietfa.amsl.com>; Fri, 30 Nov 2018 18:18:14 -0800 (PST)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56911293FB for <oauth@ietf.org>; Fri, 30 Nov 2018 18:18:13 -0800 (PST)
Received: by mail-io1-xd32.google.com with SMTP id u19so6131021ioc.2 for <oauth@ietf.org>; Fri, 30 Nov 2018 18:18:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pLSd8NtgZ59CuEZKrHXnMjnH5WMcCZINONYZBzlWeuY=; b=REJqW7V/vsYmWPKrPuLqarCPBELrC5BcbXnGXuqg2QKTgz5O2MNCThfU8smysPnLwM eda+omikYTsLSJos5EsbgoMZY6oL2k8Vpc8/cfWjmzQmikDWub+xc1wHMTEFQnORa1y0 OawK6C4R2Ol1huhgup5G5x2qDCh3jCw7WMiDXboOt8m4zvSeCS1QTnUzqgqkp0OIqrGl +nSE0gzAsks44AGKKYZTTT0Atp/Fi8jZvZTczbDKE1+N60XgXDFy78XF0DgshYNPu2Fe Wk1tTT/X6AlnLG+HgT5Sgu6k+QzywcP9uJL1x4UJVSfXh1NLnTkffAj0yaP6pw2blzsq iWzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pLSd8NtgZ59CuEZKrHXnMjnH5WMcCZINONYZBzlWeuY=; b=QiLLo9Z79wHnDK2+hA3GgdeYDaaeYYGqcJxPShUNIYmgjAV/aXZ4+x/y4lut+T59Q5 TIE2GNDW2kefwVLrOSJjtFp5kbfi0i4ZJE/Inx1N96wmRxd/SQ9p3rtekea0bP2NMPsT 48pzEHrcRhZoTeXyjYMWo3rNnM+34zp22/7OGoVFdCmb1v0TQYSjk55IxEdk+lb0sov2 CccWqUoaN2Rg8My9KGa5fkNLrYZXQ2HpOKlDawTHKTwJkYIUasvvcX7pNHQLyqmRQVhD efyqClozP0C0Ljg9o0TiUKYz4wDm+gXu0ffXk2EW1P2j83ckpEOeWhjYjo1H+WQR0jIY RiKw==
X-Gm-Message-State: AA+aEWah0xyMuyxlU+wgVGUEzca8MKvPTbmIm/YugFnh3wQGO2UXud+p aCg+K+0mNW6rduGAYdnssYDNAN5wmNE=
X-Google-Smtp-Source: AFSGD/UvchD3Ljt4zLpuXCAC7lcr8m512ShD/ffwiz1Uro5Y07YQVdCOvHb7JaafRa1OUYlvyjTpWg==
X-Received: by 2002:a6b:7019:: with SMTP id l25mr7073163ioc.145.1543630692586; Fri, 30 Nov 2018 18:18:12 -0800 (PST)
Received: from mail-io1-f54.google.com (mail-io1-f54.google.com. [209.85.166.54]) by smtp.gmail.com with ESMTPSA id u68-v6sm1874339itd.1.2018.11.30.18.18.10 for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Nov 2018 18:18:10 -0800 (PST)
Received: by mail-io1-f54.google.com with SMTP id f6so6133687iob.1 for <oauth@ietf.org>; Fri, 30 Nov 2018 18:18:10 -0800 (PST)
X-Received: by 2002:a6b:b502:: with SMTP id e2mr6200133iof.43.1543630690131; Fri, 30 Nov 2018 18:18:10 -0800 (PST)
MIME-Version: 1.0
References: <VI1PR0801MB211266BA6F6E06FFB3081425FAD80@VI1PR0801MB2112.eurprd08.prod.outlook.com> <CAD9ie-v3onmKc498cg_-a0AD58ZV=aZANtz=UV+Q0f=9N3nSzQ@mail.gmail.com> <OSBPR01MB2869E83F37046C7FCD4463DDF9D10@OSBPR01MB2869.jpnprd01.prod.outlook.com> <9FF3F589-0423-4CBC-B323-481F771D097C@lodderstedt.net> <OSBPR01MB28690F77DFFB2A85BDB83FBAF9D10@OSBPR01MB2869.jpnprd01.prod.outlook.com> <D6C66E6A-687B-4997-B830-980BE25994C2@lodderstedt.net> <CAANoGhL9aD75AV9QQRdeGE1=4ynjTnULNVr0PXXvt20ipsb4Rw@mail.gmail.com> <FE51CE20-7A49-4A13-A180-6A7C481F3965@lodderstedt.net>
In-Reply-To: <FE51CE20-7A49-4A13-A180-6A7C481F3965@lodderstedt.net>
From: Aaron Parecki <aaron@parecki.com>
Date: Fri, 30 Nov 2018 18:17:57 -0800
X-Gmail-Original-Message-ID: <CAGBSGjrzeeR5QQ=nA=gTj0q7sRvRVc0DDacbxB+ED87ymHSOuA@mail.gmail.com>
Message-ID: <CAGBSGjrzeeR5QQ=nA=gTj0q7sRvRVc0DDacbxB+ED87ymHSOuA@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Daniel Fett <fett@danielfett.de>, IETF oauth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f32470057bec8678"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Z1Ms0RLx4k_XgMnrIb8OlRdzM00>
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Dec 2018 02:18:17 -0000
+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 < torsten@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 <ve7jtb@ve7jtb.com>: > > > > I am ok with that. > > > > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt < > torsten@lodderstedt.net wrote: > > > > > Am 28.11.2018 um 23:50 schrieb n-sakimura <n-sakimura@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-sakimura@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 <torsten@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-sakimura@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-bounces@ietf.org> (Dick Hardt <dick.hardt@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.Tschofenig@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-WG] OAuth Security Topics -- Recommend aut… Hannes Tschofenig
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Mike Jones
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Aaron Parecki
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Neil Madden
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… John Bradley
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Mike Jones
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… George Fletcher
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… John Bradley
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Daniel Fett
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Neil Madden
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Daniel Fett
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Neil Madden
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Daniel Fett
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Neil Madden
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Daniel Fett
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… George Fletcher
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Hans Zandbelt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… John Bradley
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Antonio Sanso
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Antonio Sanso
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… George Fletcher
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… n-sakimura
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Neil Madden
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Jim Manico
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Vladimir Dzhuvinov
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Nat Sakimura
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Jim Manico
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Nat Sakimura
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security T… John Bradley
- Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security T… Torsten Lodderstedt
- Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security T… John Bradley
- Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security T… William Denniss
- Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security T… Torsten Lodderstedt
- Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security T… Torsten Lodderstedt
- Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security T… Nat Sakimura
- Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security T… n-sakimura
- Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security T… n-sakimura
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Dick Hardt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… n-sakimura
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Richard Backman, Annabelle
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… n-sakimura
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… William Denniss
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Nat Sakimura
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Petteri Stenius
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… John Bradley
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… John Bradley
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… n-sakimura
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… William Denniss
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Dave Tonge
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Neil Madden
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Brian Campbell
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Brian Campbell
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Dick Hardt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Jim Willeke
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Aaron Parecki
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Hannes Tschofenig
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… n-sakimura
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Hannes Tschofenig
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Daniel Fett
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Hannes Tschofenig
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Vittorio Bertocci
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Dominick Baier
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… John Bradley
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… John Bradley
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Brian Campbell
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Brian Campbell
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Dick Hardt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Marius Scurtescu
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Nat Sakimura
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Nat Sakimura
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Tomek Stojecki
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Tomek Stojecki
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Tomek Stojecki
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… David Waite
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Vittorio Bertocci
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Vittorio Bertocci
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Vittorio Bertocci
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Justin Richer
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Phil Hunt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Vittorio Bertocci
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… David Waite
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Vittorio Bertocci
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Phil Hunt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… David Waite
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Jim Manico
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… David Waite
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Nov Matake
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Nov Matake
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Jim Manico
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Brock Allen
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Vittorio Bertocci
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… David Waite
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Vittorio Bertocci
- Re: [OAUTH-WG] OAuth Security Topics -- Recommend… Phil Hunt