Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

John Bradley <ve7jtb@ve7jtb.com> Mon, 03 December 2018 15:38 UTC

Return-Path: <ve7jtb@ve7jtb.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 136A3130E5F for <oauth@ietfa.amsl.com>; Mon, 3 Dec 2018 07:38:52 -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=ve7jtb-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 TwMxfsRqcW6u for <oauth@ietfa.amsl.com>; Mon, 3 Dec 2018 07:38:48 -0800 (PST)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 181B612D7EA for <oauth@ietf.org>; Mon, 3 Dec 2018 07:38:46 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id a18so6165978wmj.1 for <oauth@ietf.org>; Mon, 03 Dec 2018 07:38:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vuj662wPmjnJs7s7we5Yztp5g3419aBmALdBYahchpw=; b=F3iUN6OeXotToJZ/1OFFAg7lT2fRbMfYbjrnmb/f+8Rd/lyD3Io0HN6vF64nYcFVQv Z8Z2sd2EbtOWrkNVMvB/iYC1cU8YC7FkgGVFZI9iifzRutoOnCWj/u2nC1+Ky1XabeY6 4eHaFb05Q3RjIxg+8NWfj6yuc2q69CYvSDOVwP7uMCdNfpR/BCWLo6YjfihTF0DBUg/L qqCtD5Lr8/D2znkNCnGvpoOFhFAm4meS/ZFPPD4WGQQw/wP33Slufb6BHObb0lEWmFkd h8GmuJmobETacdd2d+xOR+CNBzSqRU+CCdKM+dJApK6VtF8Q9YAAYfe3O4S05KcZ5RSr 158w==
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=vuj662wPmjnJs7s7we5Yztp5g3419aBmALdBYahchpw=; b=nDuH8IwfnDmT6Yo6/ldzkgOgaxu6BLImEshiSpCA1XKho8zvkDY22nAFcGCrv81bYS XtscVTq9CcTOk54A0eXC4blwgKVu6K7eCEtdYXJeeJZ7wCiyld0YOI4tbMoI9iG9C5rA PqD+eKUUJ50yruQQlOW7ARyhDEKUvBc4+vCnCT7Hf6uttxZw3UIiksiZJ+mvy275S49l /Bs0hAZKGF9jNMhjqa+W8k4D+baIFccY3eFsUz4KKKbWDZhGz0xux8Rh2EWKj4O00W3c R/CMZHg03N+ab1Lbo0HUa2St07GNjdv0sySS7Eq+fD40NX9s0ho4Idju/FoBVTlcDWg5 MVDw==
X-Gm-Message-State: AA+aEWaIL1G5OMS/M7cy4ieIukiUuSJPyAcEJDu2M3hzqMDSJtGEmohj GGnp9hDT14AbOXM75hlmwhcgvMjFqNA1YVJHAzH9CQ==
X-Google-Smtp-Source: AFSGD/X3n3JUB8cgTy+gMv4MzzRSmhkL5LsQ0Lg4OpID9Ko9Bd1OOloC0DopWrP+Zqa1m3qbXHRfm/wlX26PbmVrVNc=
X-Received: by 2002:a1c:cc1:: with SMTP id 184-v6mr9275947wmm.102.1543851524594; Mon, 03 Dec 2018 07:38:44 -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> <CAGBSGjrzeeR5QQ=nA=gTj0q7sRvRVc0DDacbxB+ED87ymHSOuA@mail.gmail.com> <VI1PR0801MB21120AA6CC9437E237F481A2FAAC0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <EA38C666-2325-430A-91B0-C02AAC65FCC8@lodderstedt.net> <CAO_FVe7j_79sPrRSFXvQJax3vDjT_0=ZaWHW9aan9rJnLUftkA@mail.gmail.com> <CAO7Ng+vsQ2i4=V0nq+ymO6aNCvurb02+Zt7HHwp4=FnWCO4pUQ@mail.gmail.com> <CAANoGhLx42Noqw4WN-THXbGYvS3t1Z2_EmPs+z641-cNovFNvw@mail.gmail.com> <B857DECA-5457-4E62-A720-437832850680@lodderstedt.net>
In-Reply-To: <B857DECA-5457-4E62-A720-437832850680@lodderstedt.net>
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Mon, 03 Dec 2018 16:38:36 +0100
Message-ID: <CAANoGh+1wRzz5x7jJrMy-KzCpeK0KN3fK2Qo62KEhz+9SE83=g@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Dominick Baier <dbaier@leastprivilege.com>, Vittorio Bertocci <vittorio.bertocci=40auth0.com@dmarc.ietf.org>, Daniel Fett <fett@danielfett.de>, IETF oauth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b5b109057c1ff197"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/7mp5TnQQl9MKVRQvCM4fvatCnCE>
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: Mon, 03 Dec 2018 15:38:52 -0000

Not everyone loves OAuth.  Sometimes our discussions on how to make it more
secure can be taken out of context and used as reasons to move back to
proprietary solutions.

We just need to be sensitive to the spin on this.

John B.

On Mon, Dec 3, 2018, 3:43 PM Torsten Lodderstedt <torsten@lodderstedt.net
wrote:

>
>
> > Am 03.12.2018 um 12:59 schrieb John Bradley <ve7jtb@ve7jtb.com>:
> >
> > I agree that the hair on fire messaging is over stated.
> >
> > This is still a document in development and not yet a BCP.   No new
> vunerable have been found, but attackers are evolving.
>
> You are right. Basically, RFC 6749’s security consideration section
> already states the vulnerabilities:
>
> § 10.3
>
> „When using the implicit grant type, the access token is transmitted
>    in the URI fragment, which can expose it to unauthorized parties.“
>
> § 10.16
>
> „In the implicit flow (response_type=token), the attacker can easily
>    switch the token in the response from the authorization server,
>    replacing the real access token with the one previously issued to the
>    attacker."
>
> Retrospectively, I’m asking myself why we ever agreed to move the spec
> forward given these issues at hand.
>
> Why the change now?
>
> Not only attackers are evolving, also the use cases for OAuth and the
> dynamics of the respective deployments have changed significantly. Just to
> give some example, open banking was not a topic in 2012. The discovery of
> the mix up attack was kind of a wake up call in late 2015. We realized
> token leakage and replay is becoming a major issue.
>
> That are the reasons why we started working on the Security BCP as an
> update of RFC 6749/4750 security considerations and also RFC 6819.
>
> The BCP, by the way, deprecates several other practices: For example, it
> introduces exact URI matching, one time use CSRF tokens in state, and
> obliges implementors to use code in conjunction with PKCE or nonce,
> effectively deprecating the pure code flow. No one every complaint about
> this.
>
> We also recommend use of sender constraint access tokens simply because we
> came to the conclusion focussing on token leakage prevention only would be
> a rather thin defense.
>
> >
> > These are security best practices for new implimentations.   Not a
> recommendation to rip things out.    As applications are updated they need
> to consider the BCP recommendations.
>
> I would go one step further. Given the fact we pointed out the risk
> associated with implicit in RFC 6749, implementors should have conducted a
> risk assessment before they implemented implicit. If they haven’t, they
> should do now using the information we provide in the BCP. If they conclude
> by finding application specific mitigations or just assume the risk, that
> fine with me.
>
> But I don’t want to give implementors the „blessing“ (as Vittorio called
> it) of this working group to use a flow with such know security issues,
> especially since a simpler and more secure option is available.
>
> BTW: I would be ok with making the respective text a SHOULD NOT again
> since that would serve the purpose just fine.
>
> >
> > We do need to be careful about how our discussions are interpreted.
>
> That’s certainly true. On the other hand, most developers don’t know
> anything about the current state of OAuth. What I have seen in the wild
> makes me nervous. People think implicit is the „lightweight and easy to
> use“ version of OAuth and don’t ask for the security implications. That’s
> why I think we need to find ways to get developers and API designers
> educated on how to properly use OAuth.
>
> >
> > There are also worse things people could do than implicit if we scare
> them back to proprietary solutions.
>
> Why do you see that risk? We offer an alternative solution, which is
> simple to use, secure, and versatile.
>
> kind regards,
> Torsten.
>
> >
> > John B.
> >
> > On Mon, Dec 3, 2018, 12:50 PM Dominick Baier <dbaier@leastprivilege.com
> wrote:
> > I agree with Vittorio -
> >
> > While we all agree that implicit is outdated and we can do better (and
> it is indeed good that this discussion has finally started for real) - the
> communication around the (preliminary) results of the BCP was unfortunate
> and not very responsible - quoting:
> >
> > “Simply put, the implicit grant’s security is broken beyond repair. It
> is vulnerable to access token leakage, meaning an attacker can exfiltrate
> valid access tokens and use it to his own benefit. This might for example
> result in the attacker accessing the legit user’s health record or
> initiating a payment, from her bank account."
> >
> > This indeed, as Vittorio pointed out, sounds like a new vulnerability
> has been found. This spreads FUD ;)
> >
> > Also - simply saying “implicit is evil - switch to code” means for most
> people also using refresh token - so we are treating access tokens in the
> URL with refresh tokens in session storage (over simplified - but you get
> the idea).
> >
> > Again we all agree that implicit can be improved - but there are some
> issues to be sorted first to make this a smooth transition.
> >
> > My 2c
> >
> > ———
> > Dominick
> >
> > On 3. December 2018 at 11:59:44, Vittorio Bertocci (vittorio.bertocci=
> 40auth0.com@dmarc.ietf.org) wrote:
> >
> >> Hi all,
> >> Sorry for stepping a bit back from the level of detail the discussion
> already reached. I do have some specific comments on the document, but
> before bringing those up I wanted to raise a general problem I am
> experiencing with this initiative..
> >>
> >> I have a number of customers that are reacting to the news with
> distress. The language used in some of the communications associated with
> this initiative made them feel like some new vulnerability was discovered,
> calling for immediate action.
> >> The fact is that as far as I can tell, no new, previously unknown fact
> informed this decision: no new vulnerability, nor any new technology that
> wasn’t available before (the sender constrain is still not actionable for
> most customers). The risks of the implicit flow aren’t bigger now than they
> were in October.
> >> That doesn’t mean that we cannot improve guidance, of course- and now
> is as good as any other moment to do so: but at the same time, I think we
> need to be cognizant of the *immense* investment in existence today in form
> of SDKs and applications built on those SDKs that are predicated on
> implicit flow, with our blessing: until very recently the official position
> was “implicit is bad but it’s the best we have noawadays”.
> >> To me, being cognizant of that means that we should help people to
> formulate action proportionate to the risk. And if until yesterday we were
> ok with them using implicit, we cannot realistically expect anyone to start
> changing all of their apps today, but that’s the message many customers are
> getting.
> >> TL;DR, I think the community would be well served by clarifying in the
> security document that there is no new risk and their existing codebase
> didn’t suddenly become less secure and in *urgent* need to update.
> >> To attempt a metaphor. We discovered a new drug against headache with
> milder side effects than the one we were prescribing them until now, but
> that doesn’t mean that they should throw away all the stash they have of
> the older drug. The old drug will keep working as it worked until now. Once
> they run out of their stash, they should get the new one; or if the old
> side effects were particularly bad for them, perhaps they should consider
> switching today. But this isn’t a recall.
> >>
> >> And if in fact this group thinks it should be a recall and get everyone
> off the old one right now, I think we’ll need to make a much stronger case
> than we have done so far.
> >>
> >> Thoughts?
> >>
> >> Thanks
> >> V.
> >>
> >>
> >> On Sat, Dec 1, 2018 at 04:01 Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
> >> Hi Hannes,
> >>
> >> > Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig <
> Hannes.Tschofenig@arm.com>:
> >> >
> >> > I agree with Aaron here and I think Section 3.8.1.2 of
> draft-ietf-oauth-security-topics-10  already does a pretty good job.
> >>
> >> my proposal is to add the following definition (based on 3.8.1.2) to a
> new „Terminology" section or to section 2.1.2:
> >>
> >> A sender constrained access token scopes the applicability of an access
> token to a certain sender.  This sender is
> >> obliged to demonstrate knowledge of a certain secret as prerequisite
> for the acceptance of that token at the recipient (e.g. a resource server).
> >>
> >> >
> >> > I was, however, wondering about the subtle implication of the
> requirement for sender constrained tokens. My understanding of the token
> binding discussion, which is one of the ways to provide sender-constrained
> tokens, is that we don’t have good faith in seeing deployment anytime soon.
> Hence, we are essentially (reading in between the lines of Section 3.8.1.2)
> saying that you cannot use implicit grant in a practical setup for the
> web*..
> >>
> >> The text shall convey that implicit must not be used at all. The main
> reason being it is unprotected against token injection and additionally
> also cannot sender constrain tokens.
> >>
> >> The second part of the statement relates to other response types and
> conditionally opens the MUST NOT in case they are protected against
> injection (which is true for the listed response types) and can issue
> sender constrained tokens (which does not work today but might work in the
> future).
> >>
> >> kind regards,
> >> Torsten.
> >>
> >> >
> >> > Am I misunderstanding it?
> >>
> >> >
> >> > Ciao
> >> > Hannes
> >> >
> >> > PS: The IoT case is likely different.
> >> >
> >> > From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki
> >> > Sent: Saturday, December 1, 2018 3:18 AM
> >> > To: Torsten Lodderstedt <torsten@lodderstedt.net>
> >> > Cc: Daniel Fett <fett@danielfett.de>; IETF oauth WG <oauth@ietf.org>
> >> > Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend
> authorization code instead of implicit
> >> >
> >> > +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
> >> >
> >> > 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
>
>