Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
Vittorio Bertocci <Vittorio@auth0.com> Thu, 06 December 2018 01:15 UTC
Return-Path: <vittorio.bertocci@auth0.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 144DE1200B3 for <oauth@ietfa.amsl.com>; Wed, 5 Dec 2018 17:15:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=auth0.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 i-LBiiVmYOMf for <oauth@ietfa.amsl.com>; Wed, 5 Dec 2018 17:15:24 -0800 (PST)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 C05AE1286E3 for <oauth@ietf.org>; Wed, 5 Dec 2018 17:15:23 -0800 (PST)
Received: by mail-lf1-x133.google.com with SMTP id e26so16214810lfc.2 for <oauth@ietf.org>; Wed, 05 Dec 2018 17:15:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QNSND7jrag5Knm0fScXpiiAi9y0a1xDCBAo9vC5jedI=; b=fTQJqXopK9cPgm5V2XZaPpN4rgm6knyP6XLRPo4freC8zzhFHXhOSI71H7OtDZGI2l MmES/yhvp9BHKod3gmPFjFHUWg+FsrRDcl6x5H6dEjj679WzuDoEkv02h6LSn3Dg5yKm wpWmW2DZhfyTJPraQOo2dWGTDLy6KERBUybYLGHB8rhcpIZqxPPlV1l9ItbXwjtcBQub MIL/vahtir1MJKR2IqG2wKED7+gofa1zZ4fE/Uh22V0BCT9yjAT3eoyd/eBcHZc1iPOi TPXBbHBEWKgE3BKSnaqfiv0mfOv01dYPFEK8CFLHFYfZoy+nm30TqRihEu+5wAlWlZP+ hjfQ==
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=QNSND7jrag5Knm0fScXpiiAi9y0a1xDCBAo9vC5jedI=; b=Llr+E3zHFNPai8n4f9O3zm0cX5Gi2bNZAKYCgE9WBd7AfwoYGS0yRPp01qOQxyjrpO 1HzBtapX5xz91wZ7mYJgLNLAlacFdU8tEu5PjE04VFT1TteT/XEYVXVbjb5YU5R+JxS1 m3fYkPdzHmkH9QNavnm/dTpcWl/kKGKsKatQKwMrYUV7AO8a51yoxsvE3RTq149DrBnd 95EVU8Nep5Ivi2juiF6sQ2sjCQVyU+GVBfXMRGBccAJ4WLpFt2Dyb9YMTZFy1UqB7dQG jhblpLKdNbIxXNjWW2ZK+/TwU7Q/WNv+396605lKX6pGCGq4g417p21RxTyJaPW0t6LK 23Ig==
X-Gm-Message-State: AA+aEWayQutwqzTvF18IGmIme7OXOwkYUg/mRv7LDDDVL+BMeYOlQGnn L9hJyeLPPDvoeliaps4//7LMIqO5rG/nMqX9VhV8kg==
X-Google-Smtp-Source: AFSGD/U157HZTd7OLNLBCNXXDKGBwECTRcEZR6z9CFwomgISr+HT3qhAnOO9rAnXWI8ZF5CLqs0PYahEC7sAJVt6KWc=
X-Received: by 2002:a19:d486:: with SMTP id l128mr14859350lfg.114.1544058921559; Wed, 05 Dec 2018 17:15:21 -0800 (PST)
MIME-Version: 1.0
References: <VI1PR0801MB211299BED6B61582DC33B873FACB0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <CAGBSGjqHKVveZor-oKUWzsQ0Rg5Fk_d2dns_eQFqfvXJynyQaQ@mail.gmail.com> <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <5B60008C-C6A7-44CC-B045-9A8C1248ED30@lodderstedt.net> <CA+k3eCTjRWo-OF+Q=KotOJzfBw1uSe7w_bHWDhDKi3WRjQsH9Q@mail.gmail.com> <VI1PR0801MB21121BCD21DE8ABAF055E603FAAC0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <E0F62B7E-9C58-493A-BEFD-91D7441BB5BF@lodderstedt.net> <0BD84A8F-0A71-45CC-BE20-89FBC8FF18D2@lodderstedt.net> <df7c80be-477e-bb4a-cc29-edb233571a2f@ve7jtb.com> <A6E974DC-59C2-43E2-9534-CAD2EE695941@lodderstedt.net> <CAGBSGjoVox6Ab274DbHfEBaXibk8OFeXy6g3SEXxRP1TauPBvQ@mail.gmail.com> <CAANoGhL0F4a0v1_8ROx8NqcjTA93rzgV=rWoUpwXPR6DR65yOw@mail.gmail.com> <7FEF0314-88F2-46C7-A22D-C794CC1BB6A0@lodderstedt.net> <CAGBSGjpdyGE0Lzp4vUgXBRzZhxjVYXn_7K4yZLx-7hnNss7fsQ@mail.gmail.com> <CA+k3eCRNYEP=LwC-7ZG-C5gkQPXaJQJfY6tXa81C02F-B9Jn-g@mail.gmail.com> <CAGBSGjoDYaYQViCtZmp8Lh=0hWLc2_LGtxhdGU49f=0M2JPTVQ@mail.gmail.com>
In-Reply-To: <CAGBSGjoDYaYQViCtZmp8Lh=0hWLc2_LGtxhdGU49f=0M2JPTVQ@mail.gmail.com>
From: Vittorio Bertocci <Vittorio@auth0.com>
Date: Wed, 05 Dec 2018 17:15:10 -0800
Message-ID: <CAO_FVe6hqXDOArVLZe6wg4YqH1+9q8nKzLdWYjwVnay1nxQMuA@mail.gmail.com>
To: aaron@parecki.com
Cc: Brian Campbell <bcampbell@pingidentity.com>, IETF oauth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000884630057c503bd4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/_qHx3cLWUqSO4k7Wth-eA7GWB_s>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
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: Thu, 06 Dec 2018 01:15:30 -0000
As mentioned during IIW when this pattern was borught up: I think readers should receive a stronger warning about the known challenges of that approach. Namely, assuming that the developer wants to perform API calls from the browser: - Making the app backend the true client for the AS is tantamount to making the app backend act as an AS for the JS running in the browser. The traffic between the JS layer and its backend for getting the initial token, renewing tokens, doing stepup auth and the like is not codified in any normative document- hence it's not threat modeled. Leaving it as exercise to the reader without proper warnings seems reckless - Various important providers indicate in the access token whether it was issued to a confidential client or to a public one- and resources can rely on that to make authorization decisions (for example allowing access only to specific confidential clients). By having an app backend to act as a proxy and pass those access tokens along to the JS layer, a resource might be fooled into thinking that the caller is a confidential client, while in fact the client is just a public client. Implementers choosing to use the proxy pattern should either ensure resources refrain from using the nature of the client (as certified by the access token) as input to authorization decisions, or should have a way to signal to the AS that the tokens requested are meant to be actually used by a weaker client hence should not mark the ATs as issued to a confidential client. I am not suggesting that the document should necessarily contain this level of detail, but I do think we should hint at those two challenges so that readers have a better idea of the risks inherent to the approach with today's tools. Related to this: if we think this pattern is common, we should consider producing formal guidance on how to handle the necessary exchanges- or we'll end up with a babel of proprietary ways of connecting the JS frontent to the backend, with huge waste of cycles across the industry. On Tue, Dec 4, 2018 at 10:57 AM Aaron Parecki <aaron@parecki.com> wrote: > Thanks for all the discussion here. I've added the paragraph described to > the document in a new "Architectural Considerations" section. Currently in > the GitHub source code but not yet published as a new IETF draft, which > will be coming shortly. > https://github.com/aaronpk/oauth-browser-based-apps > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk <http://twitter.com/aaronpk> > > > > On Mon, Dec 3, 2018 at 9:53 AM Brian Campbell <bcampbell@pingidentity.com> > wrote: > >> I would also like to see something to that effect. I feel that sometimes >> because SPAs use APIs, there's an unchallenged assumption that OAuth also >> has to be used with the in-browser code accessing those APIs. Even if the >> details are out of scope for this document, some text like the below at >> least gives a nod to the possibility of different approaches, which may >> ultimately be more secure and easier to mange. >> https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-00#section-5.1 >> kinda does this too but I'm a +1 for a little something along the lines of >> what is being discussed recently in this thread. >> >> >> >> On Mon, Dec 3, 2018 at 7:57 AM Aaron Parecki <aaron@parecki.com> wrote: >> >>> I support adding something to that effect, but would like to make it >>> clear that this removes the app from being covered under this BCP. How >>> about: >>> >>> --- >>> Implementations MAY consider moving the authorization code exchange and >>> handling of access and refresh tokens to a backend component in order to >>> avoid the risks inherent in handling access tokens from a purely browser >>> based app. In this case, the backend component can be a confidential client >>> and can be secured accordingly. >>> >>> Security of the connection between code running in the browser and this >>> backend component is assumed to utilize browser-level protection >>> mechanisms. Details are out of scope of this document. >>> --- >>> >>> >>> >>> >>> On Mon, Dec 3, 2018 at 3:15 AM Torsten Lodderstedt < >>> torsten@lodderstedt.net <torsten@lodderstedt..net>> wrote: >>> >>>> Interesting. Even on this list people felt to see that moving some >>>> logic to a backend could solve some of the problems raised. What I want to >>>> convey is: the solution to a problem in the OAuth space does not >>>> necessarily need to be found on the OAuth protocol level. That’s a best >>>> practice in the same way as some OAuth pattern. >>>> >>>> What I’m suggesting is a statement in the BCP like >>>> >>>> — >>>> Implementations MAY consider to move authorization code exchange and >>>> handling of access and refresh tokens to a backend component in order to >>>> fulfill their security goals. >>>> >>>> Security of the connection between code running in the browser and this >>>> backend component is assumed to utilize browser-level protection >>>> mechanisms. Details are out of scope of this document. >>>> — >>>> >>>> > Am 03.12.2018 um 11:19 schrieb John Bradley <ve7jtb@ve7jtb.com>: >>>> > >>>> > This is my point. >>>> > >>>> > From a security perspective we have a server based confidential >>>> client... The fact that it has a angular or other JS UI protected by a >>>> cookie seems to not be especially relucent to OAuth. >>>> > >>>> > Perhaps from the developer point of view they have a JS SPA and the >>>> only difference to them is in one case they are including the OAuth client >>>> and in the other they are using a server based proxy. So they see it as the >>>> same. >>>> > >>>> > Perhaps it is perspective. >>>> > >>>> > On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki <aaron@parecki.com wrote: >>>> > In this type of deployment, as far as OAuth is concerned, isn't the >>>> backend web server a confidential client? Is there even anything unique to >>>> this situation as far as OAuth security goes? >>>> > >>>> > I wouldn't have expected an Angular app that talks to its own server >>>> backend that's managing OAuth credentials to fall under the umbrella of >>>> this BCP. >>>> > >>>> > ---- >>>> > Aaron Parecki >>>> > aaronparecki.com >>>> > >>>> > >>>> > >>>> > On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt < >>>> torsten@lodderstedt.net> wrote: >>>> > the UI is rendered in the frontend, UI control flow is in the >>>> frontend... just a different cut through the web app’s layering >>>> > >>>> > All Angular apps I have seen so far work that way. And it makes a lot >>>> of sense to me. The backend can aggregate and optimize access to the >>>> underlying services without the need to fully expose them. >>>> > >>>> > Am 02.12.2018 um 00:44 schrieb John Bradley <ve7jtb@ve7jtb.com>: >>>> > >>>> >> How is that different from a regular server client with a web >>>> interface if the backed is doing the API calls to the RS? >>>> >> >>>> >> >>>> >> >>>> >> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: >>>> >>> I forgot to mention another (architectural) option: split an >>>> application into frontend provided by JS in the browser and a backend, >>>> which takes care of the business logic and handles tokens and API access. >>>> Replay detection at the interface between SPA and backend can utilize >>>> standard web techniques (see OWASP). The backend in turn can use mTLS for >>>> sender constraining. >>>> >>> >>>> >>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt < >>>> torsten@lodderstedt.net>: >>>> >>> >>>> >>>> IMHO the best mechanism at hand currently to cope with token >>>> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay >>>> detection) and issue short living and privilege restricted access tokens. >>>> >>>> >>>> >>>> Sender constrained access tokens in SPAs need adoption of token >>>> binding or alternative mechanism. mtls could potentially work in >>>> deployments with automated cert rollout but browser UX and interplay with >>>> fetch needs some work. We potentially must consider to warm up application >>>> level PoP mechanisms in conjunction with web crypto. Another path to be >>>> evaluated could be web auth. >>>> >>>> >>>> >>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig < >>>> Hannes.Tschofenig@arm.com>: >>>> >>>> >>>> >>>>> I share the concern Brian has, which is also the conclusion I >>>> came up with in my other email sent a few minutes ago. >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Brian Campbell >>>> >>>>> Sent: Friday, November 30, 2018 11:43 PM >>>> >>>>> To: Torsten Lodderstedt <torsten@lodderstedt.net> >>>> >>>>> Cc: oauth <oauth@ietf.org> >>>> >>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt < >>>> torsten@lodderstedt.net> wrote: >>>> >>>>> >>>> >>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen < >>>> brockallen@gmail.com>: >>>> >>>>> > >>>> >>>>> > So you mean at the resource server ensuring the token was >>>> really issued to the client? Isn't that an inherent limitation of all >>>> bearer tokens (modulo HTTP token binding, which is still some time off)? >>>> >>>>> >>>> >>>>> Sure. That’s why the Security BCP recommends use of TLS-based >>>> methods for sender constraining access tokens ( >>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2) >>>> Token Binding for OAuth ( >>>> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well >>>> as Mutual TLS for OAuth ( >>>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options >>>> available. >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> Unfortunately even when using the token endpoint, for SPA / >>>> in-browser client applications, the potential mechanisms for >>>> sender/key-constraining access tokens don't work very well or maybe don't >>>> work at all. So I don't know that the recommendation is very realistic. >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> 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. >>>> >>>>> >>>> >>>>> 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 <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 >>> >> >> *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-WG] draft-parecki-oauth-browser-based-apps… Hannes Tschofenig
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Joseph Heenan
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Simon Moffatt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Tomek Stojecki
- [OAUTH-WG] draft-parecki-oauth-browser-based-apps… Daniel Fett
- [OAUTH-WG] draft-parecki-oauth-browser-based-apps… Daniel Fett
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Daniel Fett
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… n-sakimura
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Tomek Stojecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brian Campbell
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Vladimir Dzhuvinov
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Vladimir Dzhuvinov
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Hans Zandbelt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Jim Manico
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… George Fletcher
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Hans Zandbelt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brian Campbell
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Hannes Tschofenig
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… John Bradley
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Rob Otto
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Phil Hunt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Hans Zandbelt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… John Bradley
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brian Campbell
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki