Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
Jim Willeke <jim@willeke.com> Fri, 30 November 2018 22:47 UTC
Return-Path: <jim@willeke.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 B66E6131047 for <oauth@ietfa.amsl.com>; Fri, 30 Nov 2018 14:47:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.358
X-Spam-Level:
X-Spam-Status: No, score=-3.358 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=willeke-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 kGshgWbfMPnl for <oauth@ietfa.amsl.com>; Fri, 30 Nov 2018 14:47:36 -0800 (PST)
Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 87407130F19 for <oauth@ietf.org>; Fri, 30 Nov 2018 14:47:36 -0800 (PST)
Received: by mail-oi1-x22e.google.com with SMTP id b141so6107586oii.12 for <oauth@ietf.org>; Fri, 30 Nov 2018 14:47:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Wf2uA1TXJc1k5Rkp8aXY8ZVMUdSBCRX+0Y1L7G3UYm0=; b=VODfAfD3z5QMzFEnpg/LVDrYqaIzyCLFNgcxNGWPJXmXp3OySXhoOIjOH/FO/i9CH5 +8XrADQh5HtQ48m0eelUMUdmks6fe6/TeHJVHFXL4HhHtyqdbO1svQXmJCo/jouNGjoC mpnW4t4qfb5EG9hbjyvFXf1PJc0uV9H6hGb+F7YUehcZY6MFbXfWNIXH2t5wSlYCU8O7 /15WZeqPoxfSuoSmO7m9vLtGNDhK0rNv4KqQOQ2WFc/prG/mvEhBVEayG8qoCzcJFZPh pXzLKBiUBc8Cj0zreqLmvN5v2V7SF9HONuoNYAWstt4s0aAAyV+XaddvsK6FE+yb8dSz UTXA==
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; bh=Wf2uA1TXJc1k5Rkp8aXY8ZVMUdSBCRX+0Y1L7G3UYm0=; b=a8vPH2al7CzNycGf6JP0MOtNM3kusH+pqz2rAYGDSezW2oy7/ZWCr8uo5JHDRWLw7x QCzhIK1shHIw1j5Zrz5FGvlW+f884iFXZdo/skHzYbEBjjJl3hByWp5mk4BUJDyePZCI lp/2J59G12UuQgMN3CRZgp773ETdKUkV7wbtlEw4eL2lkEZzc451EJcfIz4QWJApjo9P NUo/eumGHE3YqJAQOppbIycglX8tXuw3gatr6MJBOedgtohzTHB6uP2KTBikiKMfxpZR WlFzFTVwuLXs3G8aWEw+Diyx0e0BwLKh/noEvnII1qC6DohIQm2x1FcWLtkw764cnvdd LXXA==
X-Gm-Message-State: AA+aEWZQJsclCbOmZTL66hv/X7YwDf1YFvIUhGikBHyY/zi43z8zOlO+ Hqz2StxN9JuKw5+9fBB4TPVlXkDDoGMysCIBSBuyM+Gl
X-Google-Smtp-Source: AFSGD/W1OejQNkRy8aoOOwNWlxKZcj9ftXk737PuWoVldh7oEhOGEilEm4Kb8KOJa06mhP+yWd0l6VwTbAhyciROxxw=
X-Received: by 2002:aca:4208:: with SMTP id p8mr4658026oia.331.1543618055375; Fri, 30 Nov 2018 14:47:35 -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> <CA+k3eCROjoT8Tp-L5X_oTKvusFAwjZwa5La007SJc0aGrwVs-Q@mail.gmail.com> <558F050A-AC67-45B5-8D55-A025444539A2@lodderstedt.net> <CA+k3eCQq1F1oMcezjPj=xmrSwuzVomFXPQLot1kVBUZEt4+agA@mail.gmail.com> <CAD9ie-vi2+zzoc6LyBnF+5Fw57Yu3MadkOGD1g7N9RNiDR=8Pg@mail.gmail.com>
In-Reply-To: <CAD9ie-vi2+zzoc6LyBnF+5Fw57Yu3MadkOGD1g7N9RNiDR=8Pg@mail.gmail.com>
From: Jim Willeke <jim@willeke.com>
Date: Fri, 30 Nov 2018 17:46:58 -0500
Message-ID: <CAB3ntOtEa_YkSnvPcDjRxrOe8Y5Zgxb7hDY_NjPjuRRrU6renA@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dc2309057be99527"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/HuAGRsZOOEcrwb_RebFyyqs0RVU>
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: Fri, 30 Nov 2018 22:47:41 -0000
+1 for the change. -- -jim Jim Willeke On Fri, Nov 30, 2018 at 5:36 PM Dick Hardt <dick.hardt@gmail.com> wrote: > + 1 to the change > > I'd suggest we work to define terms such as "sender constrained" in the > BCP so that it is clear what is meant by it. > > On Fri, Nov 30, 2018 at 2:24 PM Brian Campbell <bcampbell= > 40pingidentity.com@dmarc.ietf.org> wrote: > >> Kind of, yes. I guess so. I think. It's just semantics. But yeah. Key >> constrained might be more appropriate. But the Security Topics document >> probably should allow for both/either. >> >> I don't think that these are necessarily terms with widely agreed upon or >> understood meaning. But it was pointed out to me that the OAuth 2.0 Pop >> Architecture draft defines sender constraint and key confirmation as >> different things ( >> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-6.2 >> and >> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-6.3 >> <https://tools.ietf..org/html/draft-ietf-oauth-pop-architecture-08#section-6.3>). >> And the definitions their do kind of make sense when thinking about the >> words used. The line between sender and key constrained isn't exactly clear >> but it seems MTLS and token binding access tokens are more key constrained >> than sender. The -08 version of the MTLS draft dropped the use of the >> "sender constrained" terminology based on that feedback. >> >> I dunno. Maybe the Security Topics could say something in a terminology >> section that says when sender or key constrained is used within they can be >> taken to mean the same concept. Or something like that. >> >> On Fri, Nov 30, 2018 at 1:42 PM Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>> Hi Brian, >>> >>> we use „sender constrained tokens“ throughout the BCP to denote tokens >>> bound to a sender in possession of a certain key/secret and I thought that >>> was established terminology in the group. Are you suggesting „key >>> constrained” would be more appropriate? >>> >>> kind regards, >>> Torsten. >>> >>> Am 30.11.2018 um 21:02 schrieb Brian Campbell < >>> bcampbell@pingidentity.com>: >>> >>> As was pointed out to me in WGLC review of the MTLS document, >>> "sender-constrained" has or is likely to be interpreted with a pretty >>> specific meaning of the token being bound to the client and the client >>> authenticating itself to the resource and the resource checking all that >>> matches up. That makes the text more restrictive than is likely intended. >>> Perhaps the text should say something like "sender or key constrained" to >>> allow for different variants of PoP access tokens? >>> >>> >>> >>> On Thu, Nov 29, 2018 at 11: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 >>>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly >>> prohibited... If you have received this communication in error, please >>> notify the sender immediately by e-mail and delete the message and any file >>> attachments from your computer. Thank you.* >>> >>> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly >> prohibited... If you have received this communication in error, please >> notify the sender immediately by e-mail and delete the message and any file >> attachments from your computer. 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-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