Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
Vittorio Bertocci <Vittorio@auth0.com> Tue, 07 May 2019 07:50 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 697861200A2 for <oauth@ietfa.amsl.com>; Tue, 7 May 2019 00:50:45 -0700 (PDT)
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=unavailable 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 PhKVuXEFfnBC for <oauth@ietfa.amsl.com>; Tue, 7 May 2019 00:50:41 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 04D6912001E for <oauth@ietf.org>; Tue, 7 May 2019 00:50:41 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id d8so11061049lfb.8 for <oauth@ietf.org>; Tue, 07 May 2019 00:50:40 -0700 (PDT)
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=6jYx1uFs9dpf9rj/ehIbusxbTLIcZC4/6hjDXAQDoaw=; b=UYGfXLPfWT8GVbetPWltHQe2Z1FzewdgMqNQwC+F43DuiRmoJRs9VtL9Hd/DfyZxfw /+JYnLEQR+6YROI/wlkjphhUL+Pzo6BZAUENuScSga5e9MCH3nPm9XXnuGNahAT/WUYh t02+s3cQeg0Zq7xMIZkZ1zPcI42uR4nIiHZmYiNmDcxY+CnNnPRzG8dLA3UlreOo3JUh 3Rt151PaB57e/fFGiks1Z5KYVkPCmp7tkiPdRjWf1R+aSctf1wLxPOiZiOJtu1th3eCF wUzVtAuWZDKjnMyqxoncgRNxGjBAdm2gtRpsdzzrBd+5iIaY9qXfSE8ZDMFBzr/MbZdy nPdg==
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=6jYx1uFs9dpf9rj/ehIbusxbTLIcZC4/6hjDXAQDoaw=; b=m9oVTt8RMKWJjCvModCyueu+pLZzaHtoKzqBWHGvYW5iya+ZbmWRj5wfwNxoBL/4rX K+dFf2bSG2qVNmMh4PtTPQjQOoEQ5GgVoumNa4tTCs6mdfKj04Wzx1fAI1PL1l0JXUCN icCu7RMT6ObBEgzwomdIQwmWI9saVtEnRXXFYpXqd/MrRx0u9/ifTrYgUrDJoLVLYAl5 AxcgYRZG7Sr76G5UqfIeG7gY6WTM4j0fKva1xVeuIWUR1uPRCUw0U5b+AKXbN72o75dd cPJ1WO/jfAPz2dApI4UWJnM1zKvePVd4H3PwsTITi7j6+aMqYmQmu6G0RD5BqMHoWV16 Um5w==
X-Gm-Message-State: APjAAAWjglxUqRXgylHABhBo15w25/vUuL1Gp8FH7AQzvW4v3qlQhAhf vRGgKTjcmXuozgQv9AeVlQADJucDcSbxOTkkEKs2DA==
X-Google-Smtp-Source: APXvYqyvkK2NC8Xu5Y5BwGCeFxpJfaVJZuVV+u28sUJXAfZz4aT3QSpdAqNQy9UJkiHzigc+lfyzFth0GlYloobrWM0=
X-Received: by 2002:ac2:51a1:: with SMTP id f1mr14259429lfk.129.1557215439044; Tue, 07 May 2019 00:50:39 -0700 (PDT)
MIME-Version: 1.0
References: <CAO_FVe6eWy3zppQAij7qxD+ycYL8ebqGJKG0y-A7GhN+0=kb4g@mail.gmail.com> <CAHsNOKewL9xCFt6SsP4dz+W0CN_NUZaGMJahF7mSgos_Xbnhhw@mail.gmail.com> <CAO_FVe7c6jLRJ8mD7gw=a6NY3oZcgCh_b5dR8uRXa6Q2c2gmGg@mail.gmail.com> <CA+iA6uje229zrAos3c1TCuJEM+2vmVifNQ2FnKDuj2T4ET2SYA@mail.gmail.com> <a34edf0e-012a-ecc9-e547-3cdc61dca5a4@aol.com> <CA+iA6uh6Q901wEaqGSK7An0z0_iJTjCfvPVN44Qwpb=M_rDONg@mail.gmail.com> <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <SN6PR00MB0304BC3C7D438F8A5715B36DF5500@SN6PR00MB0304.namprd00.prod.outlook.com> <CA+iA6ugr+xPfeTFXK2gGBFX8Yw+zGArGfav=Ci5A3qNYUqB7rw@mail.gmail.com> <SN6PR00MB030459810B40D98370728BBAF5500@SN6PR00MB0304.namprd00.prod.outlook.com> <CA+iA6ug1NOpMcPsSr8o24CM3xWy-3z_pxiZhiyPeKxvScMACmg@mail.gmail.com> <CAO_FVe4AP5aWgXAAGj1QxPDFPjyfeaZGWd-b5azrz=ajuHuJdQ@mail.gmail.com> <3ec04cf7-e0ed-2b9a-20f7-a94dea4d559b@connect2id.com> <CAO_FVe6sLxbkk0tEjH5sb8k36q4_sJLU6HAgU05fAqOGaqo8MA@mail.gmail.com> <61adde0e-8709-5b88-8b64-ac8cc4549f51@connect2id.com> <CAO_FVe4HQKPvL5bdbAerHRU0TCiZKLJS9JgDrYkXNokri9oBaA@mail.gmail.com> <2C153797-C5AD-410D-A52E-B87DBA19DF99@okta.com> <CA+iA6uig=Pud6h8T=n9rY7vvkc97=80K-0JQOXhgv2mQBt3kPQ@mail.gmail.com> <CAO_FVe67X4mwCAUv=GHkBByaGKyb2JcMtna+UKNatxjfiGw5OQ@mail.gmail.com> <CA+iA6uiTzLRG6S-OGVyBk2TCGsf4mjktTMn=vxcODNOq3=Jxig@mail.gmail.com> <CAO_FVe7OSB_5vhFQ8Fxhf0a7nZ2SpDpKCHiqdjGxRpDTkA+q4w@mail.gmail.com> <CA+iA6ujVwsXCVM3D5ySUa2p9RFheFStub2C29-ThYDAHQBvFdg@mail.gmail.com> <CAO_FVe4TPtMdrvTvRfJZ9tXr9jyUDZaHUcGN8cj833WeTeUmvw@mail.gmail.com> <CA+iA6ujgiVKwzqSu5BLiv2UTj4FGosDFRF=DOgO51TDB__yEZQ@mail.gmail.com> <CAO_FVe5tZr4a+7Y_3udTHrgt+wH7z0Mof7wHGQ8M-zC59aq=Uw@mail.gmail.com> <CA+iA6ujOxCB2Kbe7Mh-T0kUKZmK1vkH2R9=PwG1Tp3ueAMPDAQ@mail.gmail.com>
In-Reply-To: <CA+iA6ujOxCB2Kbe7Mh-T0kUKZmK1vkH2R9=PwG1Tp3ueAMPDAQ@mail.gmail.com>
From: Vittorio Bertocci <Vittorio@auth0.com>
Date: Tue, 07 May 2019 00:50:30 -0700
Message-ID: <CAO_FVe42b6h0D9Ztis2cU_VGkJFuAKssB=ZuD+LOxFiK4q27Wg@mail.gmail.com>
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Cc: IETF oauth WG <oauth@ietf.org>, Karl McGuinness <kmcguinness=40okta.com@dmarc.ietf.org>, Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000155a7105884779a9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/bCedb-PZNhe02dZH-VvitWNZgXI>
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, 07 May 2019 07:50:46 -0000
It looks like we'll have to agree to disagree on this one :) to me we aren't using 3 claims to say that the token is about the client. Sub and client_id have their independent reasons to be in the token. Expressing the fact that a token is about an app should not have the side effect of forbidding a sub to be RS-specific, for example. On Tue, May 7, 2019 at 12:30 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote: > using 2 existing + 1 new (=3) claims to say the token is about the client > to me suggests something went sideways in the past and were unable to fix > it in a clean way > > Hans. > > On Tue, May 7, 2019 at 8:25 AM Vittorio Bertocci <Vittorio@auth0.com> > wrote: > >> For many of the products I have been and I am working on, sub and >> client_id can't be arbitrarily changed - the examples I provided aren't >> hypothetical: in my research *all *the providers adding sub in their app >> only ATs (Azure AD, Auth0, Ping Identity) had different values in sub and >> in the claim they used to indicate the client identifier. For at least >> Auth0 and AAD you can't use arbitrary client_ids/formats, you get them >> assigned by the system. >> That's not really legacy, it's current practice - with no counter >> indications, really. It's not that we are being soft, handling sub and >> client_id differently isn't some kind of bad practice nor has any security >> implications. It's an internal implementation detail. >> >> I am not sure I see how having a specialized claim would paint us in a >> corner more than imposing the constraint you are suggesting. That seems to >> do the exact opposite: it helps ASes to provide the desired functionality >> without imposing changes that will ripple across their codebase well beyond >> this particular use case. >> >> On Tue, May 7, 2019 at 12:07 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu> >> wrote: >> >>> I understand your legacy-breaking point (and do see a name spacing >>> hurdle) but: >>> a. I feel we're now painting ourselves into a corner ("soft doctors make >>> stinking wounds"). >>> b. putting the client_id into the sub value would be something that any >>> product should be able to do, just like putting an extra claim in; I don't >>> think that is fundamental stuff >>> >>> Hans. >>> >>> On Mon, May 6, 2019 at 11:22 PM Vittorio Bertocci <Vittorio@auth0.com> >>> wrote: >>> >>>> Let me try a different angle. An AS might generate sub claims and >>>> client_id identifiers using a different format/template. That means that >>>> there might be a client with client_id X that gets assigned a sub value Y, >>>> despite the client being the same, hence the check “sub==client_id” would >>>> fail. >>>> The logic producing this might be hard for an AS to change as there has >>>> never been any requirement on client_id or sub formats hence everyone was >>>> free until now to use whatever logic they chose, including name spacing one >>>> but not the other and any other variation, and changes might have ripple >>>> effects downstream on systems that have nothing to do w this spec (eg >>>> sharing of where clients are stored might depend on the internal structure >>>> of the client_id). So in other words, an AS might have to touch pretty >>>> fundamental stuff in its logic and potentially impact scenarios that have >>>> no direct bearing with the JWT AT profile just for making that condition >>>> true. On the other plate of the scale, there’s adding a new claim- which I >>>> can literally already do in various commercial ASes via extensibility >>>> points, without changing their code. >>>> >>>> >>>> On Mon, May 6, 2019 at 15:11 Hans Zandbelt <hans.zandbelt@zmartzone.eu> >>>> wrote: >>>> >>>>> I'm suggesting that whichever "sub" and "client_id" the RS is >>>>> receiving and however it was generated, it must mean something to it in >>>>> alignment with the JWT/OAuth2/OIDC specs, otherwise it wouldn't be there at >>>>> all; moreover, if the "sub" has the same value as "client_id" it must be a >>>>> client talking to the RS on behalf of its own and the claims are associated >>>>> with the client; if the "sub" has a different value than the "client_id" it >>>>> must be a scenario where the client presents a token delegated by a >>>>> Resource Owner and the claims are about the Resource Owner. Problem solved? >>>>> >>>>> Hans. >>>>> >>>>> On Mon, May 6, 2019 at 11:06 PM Vittorio Bertocci <Vittorio@auth0.com> >>>>> wrote: >>>>> >>>>>> I am not following. We want this to be adopted, right? :) if we >>>>>> provide guidance that is sound but hard to implement we are going to fail. >>>>>> Considerations on whether the guidance requires a big effort to be applied >>>>>> are very much in scope for me. >>>>>> >>>>>> On Mon, May 6, 2019 at 14:54 Hans Zandbelt < >>>>>> hans.zandbelt@zmartzone.eu> wrote: >>>>>> >>>>>>> the scope and way of generating sub/client_id is orthogonal to the >>>>>>> semantics IMHO but if I'm the only one who thinks so, I'll rest my case >>>>>>> >>>>>>> Hans. >>>>>>> >>>>>>> On Mon, May 6, 2019 at 10:49 PM Vittorio Bertocci < >>>>>>> Vittorio@auth0.com> wrote: >>>>>>> >>>>>>>> See below, Hans- the sub doesn’t have to be global, it could be >>>>>>>> something generated just for this particular RS. Or the AS might have its >>>>>>>> own recipe for generating sub values that different from the recipe used to >>>>>>>> generate client_ids. It would be much easier for an AS to emit a claim >>>>>>>> making this explicit statement than to change sub and client_id assignment >>>>>>>> logic. >>>>>>>> >>>>>>>> On Mon, May 6, 2019 at 13:49 Hans Zandbelt < >>>>>>>> hans.zandbelt@zmartzone.eu> wrote: >>>>>>>> >>>>>>>>> I may be missing something but I'd argue that by requiring and >>>>>>>>> comparing both "sub" and "client_id" we achieve the same semantics without >>>>>>>>> a new/additional claim (barring name spacing) >>>>>>>>> >>>>>>>>> Hans. >>>>>>>>> >>>>>>>>> On Mon, May 6, 2019 at 8:58 PM Karl McGuinness <kmcguinness= >>>>>>>>> 40okta.com@dmarc.ietf.org> wrote: >>>>>>>>> >>>>>>>>>> Makes sense that we don’t want to further couple AS and RS with >>>>>>>>>> grant types. I’m OK if we want a dedicated claim to establish whether the >>>>>>>>>> token is resource owner delegated vs client acting as itself. >>>>>>>>>> >>>>>>>>>> Subject Type is already a concept in RISC. Just making folks are >>>>>>>>>> aware of prior art. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section.2.2 >>>>>>>>>> >>>>>>>>>> https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2.1 >>>>>>>>>> >>>>>>>>>> -Karl >>>>>>>>>> >>>>>>>>>> On May 6, 2019, at 12:42 PM, Vittorio Bertocci < >>>>>>>>>> Vittorio=40auth0.com@dmarc.ietf.org> wrote: >>>>>>>>>> >>>>>>>>>> *This message originated outside your organization.* >>>>>>>>>> ------------------------------ >>>>>>>>>> Fair enough! What others think about it? >>>>>>>>>> Exploring the approach: would we want a bool claim or an >>>>>>>>>> enumeration, e.g. sub_type = [ resource_owner | client ] ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov < >>>>>>>>>> vladimir@connect2id.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Vittorio, >>>>>>>>>>> >>>>>>>>>>> On 06/05/2019 22:22, Vittorio Bertocci wrote: >>>>>>>>>>> > It is true that the grant_type is a client side consideration. >>>>>>>>>>> I did think >>>>>>>>>>> > about the "client_id==sub" heuristic, but that's not always >>>>>>>>>>> applicable: >>>>>>>>>>> > many systems have their own rules for generating sub, and in >>>>>>>>>>> case they want >>>>>>>>>>> > to prevent tracking across RSes the sub might be generated >>>>>>>>>>> ad-hoc for that >>>>>>>>>>> > particular RS. >>>>>>>>>>> > Would you prefer to have a dedicated claim that distinguish >>>>>>>>>>> between user >>>>>>>>>>> > and app tokens rather than reusing grant_type? >>>>>>>>>>> >>>>>>>>>>> A dedicated claim to flag client_id effectively == sub would be >>>>>>>>>>> preferable, and much easier for RS developers to process. >>>>>>>>>>> >>>>>>>>>>> The AS is the authority and has all the knowledge to set / >>>>>>>>>>> indicate this. >>>>>>>>>>> >>>>>>>>>>> I want to keep RS developers away from having to deal with grant >>>>>>>>>>> types >>>>>>>>>>> and having to make decisions whether client_id effectively == >>>>>>>>>>> sub. >>>>>>>>>>> >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov < >>>>>>>>>>> vladimir@connect2id.com> >>>>>>>>>>> > wrote: >>>>>>>>>>> > >>>>>>>>>>> >> On 06/05/2019 20:32, Vittorio Bertocci wrote: >>>>>>>>>>> >>> To that end, *Karl MCGuinness suggested that we include >>>>>>>>>>> >>> grant_type as a return claim, which the RS could use to the >>>>>>>>>>> same >>>>>>>>>>> >> effect*. I >>>>>>>>>>> >>> find the proposal very clever, and the people at IIW thought >>>>>>>>>>> so as well. >>>>>>>>>>> >>> What you think? >>>>>>>>>>> >> The grant type is not something that the RS is really >>>>>>>>>>> concerned with, or >>>>>>>>>>> >> should be. Introducing this parameter in the access token >>>>>>>>>>> will create an >>>>>>>>>>> >> additional logical dependency, plus complexity - in the >>>>>>>>>>> system of >>>>>>>>>>> >> client, AS and RS as a whole, as well as for RS developers. >>>>>>>>>>> The grant >>>>>>>>>>> >> type, as a concept, is a matter between the client and AS, >>>>>>>>>>> and IMO >>>>>>>>>>> >> should stay that way. >>>>>>>>>>> >> >>>>>>>>>>> >> Clear language in the spec should suffice. For instance: "If >>>>>>>>>>> the sub >>>>>>>>>>> >> value matches the client_id value, then the subject is the >>>>>>>>>>> client >>>>>>>>>>> >> application". >>>>>>>>>>> >> >>>>>>>>>>> >> Vladimir >>>>>>>>>>> >> >>>>>>>>>>> >> -- >>>>>>>>>>> >> Vladimir Dzhuvinov >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> _______________________________________________ >>>>>>>>>>> >> OAuth mailing list >>>>>>>>>>> >> OAuth@ietf.org >>>>>>>>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> >> >>>>>>>>>>> -- >>>>>>>>>>> Vladimir Dzhuvinov >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>> >>>> >>> >>> -- >>> hans.zandbelt@zmartzone.eu >>> ZmartZone IAM - www.zmartzone.eu >>> >> > > -- > hans.zandbelt@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu >
- [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