Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
Steinar Noem <steinar@udelt.no> Tue, 26 March 2019 08:40 UTC
Return-Path: <steinar@udelt.no>
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 A02641202E2 for <oauth@ietfa.amsl.com>; Tue, 26 Mar 2019 01:40:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udelt-no.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 7Sm79w3gI63l for <oauth@ietfa.amsl.com>; Tue, 26 Mar 2019 01:40:24 -0700 (PDT)
Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 C5C2812029B for <oauth@ietf.org>; Tue, 26 Mar 2019 01:40:19 -0700 (PDT)
Received: by mail-oi1-x235.google.com with SMTP id e22so9262812oiy.0 for <oauth@ietf.org>; Tue, 26 Mar 2019 01:40:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=SIMvKCSSBv0VaxCb7Ce3m0/++3ZmUvDRPwTgcapn918=; b=B8gYbIMjPe/tidmwCKzEJIwTAlTNgkcV/0yeAFf2jBh+j4jNuzc+Qwbz9qRoDu4OsM zsqJKo7yj1sE32FQ3r+6T48ufDFRvVXK+rIfYWb5oMJTNzAWsWige7rpHy1nfNE3I54R GUpM5XWDkbxvkhrf4pGAxQQHQrB8Pq/bHoPBOSNOOfKplY2HOsFdgNoTiBUUHKnGe7qG 1QwtptkILamWndRkiY9syoFZXY9I/QpZ2uVs2wYRqu66BZjAEI0H5QQo5HF9hfVoy0C8 oQEaHj6aSSzj8PduI7wx+7Wt/Sb5LSE9rfmZd2nyHzkNOgB8YOoyiOzfjvliHyJ2PLKu k2EA==
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=SIMvKCSSBv0VaxCb7Ce3m0/++3ZmUvDRPwTgcapn918=; b=XkX4aa5EGHygmr0Aiz+nTWxvDV8TwV+QEWDAB0U3oFdlY7iTI2fzcys9MaI6oyTpuy +GHCXJGp7LE9Yde68/BWBr7hAjPsN6o6qqvkSHBujSseeZR6S6JlVPapo1ynAjiYTJ9p aD3W5niXVA9hjpEPPpaSTf26AMi9rdtnwy1gtS8uQiFRnsI9Nwi/sjR+V5jfRD43AoHy gU+/g8OlqUYyjfdnXcj/1q/geZPUMB1KQ14VJ5YxM3hHhKfi7Z8D5p7PEqAZZeW4PPnZ 6Lvg1e67kTtcbSbxDq/ziH/9g9ev/gkpHuEz/h3lUrSZD6xt25uqlv6WWBL6lDtYywK0 9mwA==
X-Gm-Message-State: APjAAAUy0dCSqwbXnDxkoTBaoDyTjFG5QQ9KBsQQF0uKicVx1BAe7YlP AwdGaojBCXL7qjitvEHTZy/fAiI9u6a4QQjuCCGSbw==
X-Google-Smtp-Source: APXvYqx3seRrkWJp6/ZOUReacbRBdkZRcQ08+AtYPGE94ZXxTSyDVsf7vMwDf8XENxLkaEFmsBPS0slOKfYt5S4CTO0=
X-Received: by 2002:aca:5f03:: with SMTP id t3mr14546517oib.113.1553589618564; Tue, 26 Mar 2019 01:40:18 -0700 (PDT)
MIME-Version: 1.0
References: <CAO_FVe6eWy3zppQAij7qxD+ycYL8ebqGJKG0y-A7GhN+0=kb4g@mail.gmail.com> <B755AE4D-2D10-4380-AC12-4B7A8F53B812@gmail.com> <CAO7Ng+siADYHEhr8gryPZ_6c50uQ3XxDM5inAFwgG+Xa0bnwfg@mail.gmail.com> <CA+iA6uhHOSmiSG_vxvad_g2ufi57OS4TxdvoO20g+7vm7rNZiA@mail.gmail.com> <CAO7Ng+vGC5ByU1wZrbNWvaZ+QuDByhJ8huw8UXVxfOCWQpaH1w@mail.gmail.com> <CA+iA6ujkEMdHPMn7JQLts7OAusV3ieKKMon572vTACtFvTGnrA@mail.gmail.com> <CAO_FVe73L7B-_7gu1W0N-mqLXHQExef4QKDeaWHrUmJnCCxCRg@mail.gmail.com> <D610AAEA-892F-4AAD-915D-A0C068F5BFD3@gmail.com> <CAO7Ng+sqzw4O2vt+iCWegBWBGg+-oyqV1j8dF7ADK2TbPec_CQ@mail.gmail.com>
In-Reply-To: <CAO7Ng+sqzw4O2vt+iCWegBWBGg+-oyqV1j8dF7ADK2TbPec_CQ@mail.gmail.com>
From: Steinar Noem <steinar@udelt.no>
Date: Tue, 26 Mar 2019 09:40:04 +0100
Message-ID: <CAHsNOKewL9xCFt6SsP4dz+W0CN_NUZaGMJahF7mSgos_Xbnhhw@mail.gmail.com>
To: Vittorio Bertocci <vittorio@auth0.com>, IETF oauth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000057772d0584fb45f0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/tp-ActdYSZUlLN6girN9H37uqBE>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-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: Tue, 26 Mar 2019 08:40:34 -0000
Hi Vittorio, we (the national federation-gateway for the health services in norway - "HelseID") think his is a really valuable initiative! We also agree with Dominick concerning definition of the "sub" claim. <mvh>Steinar</mvh> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <dbaier@leastprivilege.com >: > From an access token consumer (aka API) developer point of view, I prefer > this logic > > "If sub is present - client acts on behalf of a user, if not - not." > > Anything more complicated has a potential of going wrong. > > > On 26. March 2019 at 01:34:53, Nov Matake (matake@gmail.com) wrote: > > Hi Vittorio, > > Yeah, I’m concerning user & client ids collision. > I haven’t seen such implementations, but user-select username as sub, or > incremental integer as sub & client_id will be easily collide. > > If you can enforce collision resistant IDs between user & client > instances, it’ll works fine. I feel its overkill though. > > Sent from my iPhone > > On Mar 26, 2019, at 8:51, Vittorio Bertocci <Vittorio@auth0.com> wrote: > > Hey Nov, Dominick, Hans- > thanks for the comments. That was an area I was expecting to cause more > discussion, and I am glad we are having this opportunity to clarify. > The current language in the draft traces the etymology of sub to OpenID > Connect core, hence Dominick observation is on point. However in the > description I express something in line with 7519, which was in fact my > intent. > > The idea was to provide an identifier of the calling subject that is > guaranteed to be present in all cases- this would allow an SDK developer to > use the same code for things like lookups and membership checks regardless > of the nature of the caller (user in a delegated case, app in app-only > grants). The information to discriminate between user and app callers is > always available in the token (say, the caller is a user if sub!=client_id, > where client_id is always guaranteed to be present as well) hence there's > no loss in expressive power, should that difference be relevant for the > resource server. > > Dominick, Hans- I probably missed the security issue you guys are thinking > of in this case. Of course, if this would introduce a risk I completely > agree it should be changed- I'd just like to understand better the problem. > Could you expand it in a scenario/use case to clarify the risk? > Nov- playing this back: is the concern that a user and a client might have > the same identifier within an IDP? When using collision resistant IDs, as > it is usually the case, that seems to be a remote possibility- did you > stumble in such scenario in production? > > Thanks > V. > > > On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu> > wrote: > >> I believe there are plenty of OAuth 2.0 only use cases out there... but >> nevertheless I agree with the potential confusion and thus security >> problems arising from that (though one may argue the semantics are the >> same). >> >> Hans. >> >> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dbaier@leastprivilege.com> >> wrote: >> >>> Yes I know - and I think in hindsight it was a mistake to use the same >>> claim type for multiple semantics. >>> >>> All the “this is OIDC not OAuth” arguments are making things more >>> complicated than they need to be - in my experience almost no-one (that I >>> know) does OIDC only - nor OAuth only. They always combine it. >>> >>> In reality this leads to potential security problems - this spec has the >>> potential to rectify the situation. >>> >>> Dominick >>> >>> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandbelt@zmartzone.eu) >>> wrote: >>> >>> Without agreeing or disagreeing: OIDC does not apply here since it is >>> not OAuth and an access token is not an id_token. >>> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2: >>> >>> "The "sub" (subject) claim identifies the principal that is the >>> subject of the JWT. The claims in a JWT are normally statements >>> about the subject. The subject value MUST either be scoped to be >>> locally unique in the context of the issuer or be globally unique. >>> The processing of this claim is generally application specific" >>> >>> which kind of spells "client" in case of the client credentials grant >>> but I also do worry about Resource Servers thinking/acting only in terms of >>> users >>> >>> Hans. >>> >>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier < >>> dbaier@leastprivilege.com> wrote: >>> >>>> IMHO the sub claim should always refer to the user - and nothing else. >>>> >>>> OIDC says: >>>> >>>> "Subject - Identifier for the End-User at the Issuer." >>>> >>>> client_id should be used to identify clients. >>>> >>>> cheers >>>> Dominick >>>> >>>> On 25.. March 2019 at 05:13:03, Nov Matake (matake@gmail.com) wrote: >>>> >>>> Hi Vittorio, >>>> >>>> Thanks for the good starting point of standardizing JWT-ized AT. >>>> >>>> One feedback. >>>> The “sub” claim can include 2 types of identifier, end-user and client, >>>> in this spec. >>>> It requires those 2 types of identifiers to be unique each other in the >>>> IdP context. >>>> >>>> I prefer omitting “sub” claim in 2-legged context, so that no such >>>> constraint needed. >>>> >>>> thanks >>>> >>>> nov >>>> >>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci < >>>> vittorio.bertocci=40auth0.com@dmarc.ietf.org> wrote: >>>> >>>> Dear all, >>>> I just submitted a draft describing a JWT profile for OAuth 2.0 access >>>> tokens. You can find it in >>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/ >>>> . >>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >>>> remotely). I look forward for your comments! >>>> >>>> Here's just a bit of backstory, in case you are interested in how this >>>> doc came to be. The trajectory it followed is somewhat unusual. >>>> >>>> - Despite OAuth2 not requiring any specific format for ATs, through >>>> the years I have come across multiple proprietary solution using JWT for >>>> their access token. The intent and scenarios addressed by those solutions >>>> are mostly the same across vendors, but the syntax and interpretations in >>>> the implementations are different enough to prevent developers from reusing >>>> code and skills when moving from product to product. >>>> - I asked several individuals from key products and services to >>>> share with me concrete examples of their JWT access tokens (THANK YOU >>>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), >>>> Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and >>>> explanations!). >>>> I studied and compared all those instances, identifying >>>> commonalities and differences. >>>> - I put together a presentation summarizing my findings and >>>> suggesting a rough interoperable profile (slides: >>>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx >>>> <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx> >>>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>>> - The presentation was followed up by 1.5 hours of unconference >>>> discussion, which was incredibly valuable to get tight-loop feedback and >>>> incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, >>>> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there >>>> and contributed generously to the discussion. Thank you!!! >>>> Note: if you were at OSW2019, participated in the discussion and >>>> didn't get credited in the draft, my apologies: please send me a note and >>>> I'll make things right at the next update. >>>> - On my flight back I did my best to incorporate all the ideas and >>>> feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, >>>> Hannes and above all Brian were all super helpful in negotiating the >>>> mysterious syntax of the RFC format and submission process. >>>> >>>> I was blown away by the availability, involvement and willingness to >>>> invest time to get things right that everyone demonstrated in the process. >>>> This is an amazing community. >>>> V. >>>> _______________________________________________ >>>> 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 >>>> >>> >>> >>> -- >>> hans.zandbelt@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu >>> >>> >> >> -- >> hans.zandbelt@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no |
- [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Nov Matake
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Dominick Baier
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Hans Zandbelt
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Pedro Igor Silva
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Dominick Baier
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Hans Zandbelt
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… CARLIER Bertrand
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… donald.coffin
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Nov Matake
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Dominick Baier
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Schanzenbach, Martin
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Dave Tonge
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Rob Otto
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Steinar Noem
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Hans Zandbelt
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Dave Tonge
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Schanzenbach, Martin
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Binningsbø
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Benjamin Kaduk
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… George Fletcher
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… David Waite
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Brian Campbell
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… George Fletcher
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Hans Zandbelt
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Dominick Baier
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… George Fletcher
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… George Fletcher
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Brian Campbell
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Brian Campbell
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Hans Zandbelt
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… George Fletcher
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Brian Campbell
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… George Fletcher
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Schanzenbach, Martin
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Hans Zandbelt
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Brian Campbell
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Schanzenbach, Martin
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Schanzenbach, Martin
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… George Fletcher
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Mike Jones
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Hans Zandbelt
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Mike Jones
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Hans Zandbelt
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Binningsbø
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Brian Campbell
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vladimir Dzhuvinov
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vladimir Dzhuvinov
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vladimir Dzhuvinov
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vladimir Dzhuvinov
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Karl McGuinness
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… George Fletcher
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Hans Zandbelt
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Hans Zandbelt
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Hans Zandbelt
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Hans Zandbelt
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Hans Zandbelt
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Neil Madden
- [OAUTH-WG] OAuth security topics Neil Madden
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Neil Madden
- Re: [OAUTH-WG] OAuth security topics Hannes Tschofenig
- [OAUTH-WG] Off Topic: oauth-bounces Neil Madden
- Re: [OAUTH-WG] OAuth security topics Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth security topics Neil Madden
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Hans Zandbelt
- Re: [OAUTH-WG] Off Topic: oauth-bounces Benjamin Kaduk
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vladimir Dzhuvinov
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vladimir Dzhuvinov
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vladimir Dzhuvinov
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Neil Madden
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth security topics Torsten Lodderstedt
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… George Fletcher
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vladimir Dzhuvinov
- Re: [OAUTH-WG] draft-bertocci-oauth-access-token-… Vittorio Bertocci
- Re: [OAUTH-WG] OAuth security topics Neil Madden