Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
Eric Rescorla <ekr@rtfm.com> Sun, 22 July 2018 22:02 UTC
Return-Path: <ekr@rtfm.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 9E072131030 for <oauth@ietfa.amsl.com>; Sun, 22 Jul 2018 15:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 LDofixxpaE-L for <oauth@ietfa.amsl.com>; Sun, 22 Jul 2018 15:02:36 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 8DEE313104C for <oauth@ietf.org>; Sun, 22 Jul 2018 15:02:35 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id a134-v6so5064211lfe.6 for <oauth@ietf.org>; Sun, 22 Jul 2018 15:02:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3WNjvG/kgFdLrwWLnW3xOKC36mY3Fjkn4lflLZtfwao=; b=AkxwgUfKKMExGTplVQERsXXIrHPnx8kPuV1f2bklgDoJ63/fgAUcW2qPGFKlNgmIBU cB/hTJXi+9DwM8Gvia4zBTXO/K3QMS3wFrNP7dldRgM5F2mJlSEBAhzWkVkusVnV3Vd0 Ol+V5KmpzojKqWmwqClSf+PoOH2mvcPnFrzsVR1rWHQg4dpilqgu0HUqODnBC/26vaV5 PXOJT9vR6Gzn93SNV1Exu3TqIILD4NlivAIetTZVQSY6qTWMQeGxDOAsBCM2bvFzsVeI nKj4SO3GiRNLW8eisWfEFydn7Hfu3//aHD0TKAJsCdWqEi6YGyqHft1kKQS9elnCF1r0 xpgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3WNjvG/kgFdLrwWLnW3xOKC36mY3Fjkn4lflLZtfwao=; b=ZQ0mIPtc8VY6ZraLRg9h0xVLkAaeUOLV6KoJwVRvw8xBz/8MnaKD3HJX+dT6mHa256 9hZnHe1YKwflFBA2QsIwDRavUkogNJXkfPEE4P2sJBhfG/gVEttAnGO9NatTuUGthVVb RCcVevgfzNhmzx3p2l2Ej357w8+g52ICgGALCWgdLMQ+GgEHnxEKFMY+c09iCPXUx47G 8/oSjHmbF37B/wZ9DSKRApbnKsX4ZOo3q9+aXPAWZm3kZQXngF2hByPtGkMHLekLdNaX U+JizdnqOO0OLva0sRucKwXmdHwEk7EZnLW0vkBdjszczXgIa3kKgHWtBM9Y114ut5Em 674g==
X-Gm-Message-State: AOUpUlHPJx6HaZBixZq4JMtNXcFuqU1GwOpcAVC7L1BEdp63JYan0smn P0uNVNRlSjKOIqUkS6kIuDZYAA0CsxwejwCGjrXvJA==
X-Google-Smtp-Source: AAOMgpfawHP6sHN5Tfg+kqvt96EVXBiI0UBMfd10+GTgYbzx4smVbb3eQp/+hpvtlPO8OUGr8TFo8qvoui8mql1Vnxk=
X-Received: by 2002:a19:c403:: with SMTP id u3-v6mr5654883lff.87.1532296953675; Sun, 22 Jul 2018 15:02:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Sun, 22 Jul 2018 15:01:52 -0700 (PDT)
In-Reply-To: <CA+k3eCTn_5KHF6CT=9OeEiUmU-HENqee3jQ89OscTO9vgMuJfw@mail.gmail.com>
References: <CABcZeBNQaqg3wFuo=w3h4k+bB44pEPnoR-zZYM+AR7YDA=O8Gg@mail.gmail.com> <CA+k3eCRDyn7-1KEVYai8b-G_bLQZGTgiS2VFG9W3NWy2Ttu-nw@mail.gmail.com> <ef06d115-b178-16c3-76ca-4693d273ae41@free.fr> <CA+k3eCTeBqPHTs_vUrFOcEOT3CHJptJN8m3_M3LDYyL=WrL5BA@mail.gmail.com> <CABRXCmxSY75_tSA6uE4jtMMeX4aXOGEzWBLhkKXOOgg9ZUNNuA@mail.gmail.com> <SN6PR00MB03015D1AAF670587060EE199F5910@SN6PR00MB0301.namprd00.prod.outlook.com> <CABRXCmy8WnhSYGSz+wu2NQvz1E2Jr_Jx-=cH=tM_xVT0UaQp6g@mail.gmail.com> <CA+k3eCQdyuFA6FKUg4onMPhQ6VxfcOQ6vLSW_GijLsF+NOBaSg@mail.gmail.com> <CABcZeBNReOvd-FFiEwf-M_zXoiKYTT2pcSGfyjVEYe4E6adMCw@mail.gmail.com> <CA+k3eCRBahGR2N6rUNtZrYASQhjNUU4-_HVCZp_XAKv70zkpTA@mail.gmail.com> <CABcZeBOk4haUG_omN-ED_WwpAmY2G5jW2O6MPfhGLojw9bQ2kQ@mail.gmail.com> <CA+k3eCSzRHuNsb=kDTLk1Y_o0NYRMgu5XxN+Ow1xjS9mMBm+NQ@mail.gmail.com> <CABcZeBMLAoMNLhSEoXRAvJVLcYajueL+zfLtNz+cAzk+EtoHCQ@mail.gmail.com> <CA+k3eCTn_5KHF6CT=9OeEiUmU-HENqee3jQ89OscTO9vgMuJfw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 22 Jul 2018 15:01:52 -0700
Message-ID: <CABcZeBPaK0zXBxfXF9zWdp3TMY-r9nuWQbOpE3KzS=n8=kY=Yg@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009d52f305719dafbe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/zMyXo_cFuI4XMi2RxhhKRnXgDCw>
Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.27
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: Sun, 22 Jul 2018 22:02:42 -0000
This text is fine. I have issued IETF-LC. On Mon, Jun 4, 2018 at 1:45 PM, Brian Campbell <bcampbell@pingidentity.com> wrote: > Thanks Eric, I've added text in the just submitted -14 saying that only > the two ends of the chain are to be considered in access control policy > decisions. > > diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-14 > > htmlized: > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-14 > > > On Fri, Jun 1, 2018 at 10:02 PM, Eric Rescorla <ekr@rtfm.com> wrote: > >> OK, well, it seems like it ought to say that that generator of the token >> can expect that the RP will apply an access control policy that s the union >> of the capabilities of the two ends of the chain -- and that while it might >> be less it won't be more. >> >> -Ekr >> >> >> On Fri, Jun 1, 2018 at 3:15 PM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> I suspect that the vast majority of time C's permissions won't matter at >>> all. But I do think there are legitimate cases where they might be >>> considered in the policy decision. One general example I can think of is a >>> customer service rep or administrator taking override type corrective >>> action on an end-user's account or transaction information (A is the >>> end-user and C is the customer service rep) that the user on their own >>> wouldn't have permission to change. >>> >>> On Fri, Jun 1, 2018 at 3:47 PM, Eric Rescorla <ekr@rtfm.com> wrote: >>> >>>> That would go a long way, I think. Do you think that C's permissions >>>> matter at all? So, say that the resource is accessible to C but not A? >>>> >>>> -Ekr >>>> >>>> >>>> >>>> >>>> On Fri, Jun 1, 2018 at 11:47 AM, Brian Campbell < >>>> bcampbell@pingidentity.com> wrote: >>>> >>>>> Hi Eric, >>>>> >>>>> Apologies for my somewhat slow response. I've honestly been unsure of >>>>> how else to try and address the comment/question. But will continue >>>>> trying... >>>>> >>>>> My expectation would be that access control decisions would be made >>>>> based on the subject of the token itself or on the current actor. And maybe >>>>> a combination of both in some situations (like, for example, the actor is >>>>> an administrator and the token allows admin level access to the stuff the >>>>> token subject would normally have access to). However, I don't believe >>>>> that nested prior actors would or should be considered in access control >>>>> decisions. The nesting is more just to express what has happened for >>>>> auditing or tracking or the like. To be honest, the nesting was added in >>>>> the draft largely because the structure naturally and easily allowed for it >>>>> and it seemed like it might be useful information to convey in some cases. >>>>> >>>>> So in that A->B->C case (the claims of such a token would, I think, >>>>> look like the JSON below), B *is not* giving C his authority. B is >>>>> just noted in the token as having been involved previously. While A is >>>>> identified as the subject of the token and C is the current actor. >>>>> >>>>> { >>>>> "aud":"... ,"iss":... , "exp":..., etc. etc. ... >>>>> "sub":"A", >>>>> "act": >>>>> { >>>>> "sub":"C", >>>>> "act": >>>>> { >>>>> "sub":"B" >>>>> } >>>>> } >>>>> } >>>>> >>>>> >>>>> Would some text explicitly saying that only the token subject (top >>>>> level sub and claims) and the party identified by the outermost "act" claim >>>>> (the current actor) are to be considered in access control decisions >>>>> address your concern? >>>>> >>>>> >>>>> On Tue, May 29, 2018 at 4:19 PM, Eric Rescorla <ekr@rtfm.com> wrote: >>>>> >>>>>> Hi Brian, >>>>>> >>>>>> To be clear, I'm not opposing Delegation. My concern here is that we >>>>>> have a chain of signed assertions and I'm trying to understand how I as a >>>>>> consumer of those assertions am supposed to evaluate it. >>>>>> >>>>>> I don't think it's sufficient to just say that that the access >>>>>> control rules are local policy, because then the entity generating the >>>>>> signature has no way of knowing how its signature will be used. >>>>>> >>>>>> To go back to the case I gave in my initial e-mail, say we have a >>>>>> chain A->B->C and a resource that A and C could ordinarily not access, but >>>>>> B can. If C has this delegation, can C access the resource? I.e., is B >>>>>> giving C his authority or just passing on A's authority? It seems pretty >>>>>> important for B to know that before he gives the token to C. >>>>>> >>>>>> -Ekr >>>>>> >>>>>> >>>>>> On Thu, May 17, 2018 at 11:06 AM, Brian Campbell < >>>>>> bcampbell@pingidentity.com> wrote: >>>>>> >>>>>>> Delegation has been in the document since its inception and >>>>>>> throughout the three and a half years as a working group document. >>>>>>> >>>>>>> From a process point of view, the document is now in AD Evaluation. >>>>>>> I worked through a number of questions and clarifications with Eric (said >>>>>>> AD), however he raised the particular questions that started this thread on >>>>>>> the WG list. And I responded with an attempt at addressing those questions. >>>>>>> That was about a month ago. >>>>>>> >>>>>>> Eric, was my explanation helpful in clarify anything for you? Is >>>>>>> there some text that you'd like to see added? Something else? I'm unsure >>>>>>> how to proceed but would like to move things forward. >>>>>>> >>>>>>> >>>>>>> On Thu, May 17, 2018 at 8:03 AM, Bill Burke <bburke@redhat.com> >>>>>>> wrote: >>>>>>> >>>>>>>> This is an honest question: How important is the actor stuff to the >>>>>>>> players involved? Are people going to use it? IMO, its an edge >>>>>>>> case >>>>>>>> and I think more important areas, like external token exchange >>>>>>>> (realm >>>>>>>> to realm, domain to domain) are being neglected. I'm quite >>>>>>>> unfamiliar >>>>>>>> how consensus is reached in this WG or the IETF, so I hope I'm not >>>>>>>> sounding rude. Just trying to provide some constructive feedback. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, May 17, 2018 at 9:26 AM, Mike Jones < >>>>>>>> Michael.Jones@microsoft.com> wrote: >>>>>>>> > Moving the actor claim to a separate specification would only >>>>>>>> make things more complicated for developers. There already plenty of OAuth >>>>>>>> specs. Needlessly adding another one will only make related things harder >>>>>>>> to find. >>>>>>>> > >>>>>>>> > Just like in the JWT [RFC 7519] spec itself in which use of all >>>>>>>> the claims is optional, use of the actor claim in this spec. If you don't >>>>>>>> need it, don't use it. Just because some won't use it is no better an >>>>>>>> argument for moving it to a different spec than the argument that JWT >>>>>>>> should have defined each of its claims in different specs. That would have >>>>>>>> made things harder, not easier. >>>>>>>> > >>>>>>>> > -- Mike >>>>>>>> > >>>>>>>> > -----Original Message----- >>>>>>>> > From: OAuth <oauth-bounces@ietf.org> On Behalf Of Bill Burke >>>>>>>> > Sent: Thursday, May 17, 2018 2:11 PM >>>>>>>> > To: Brian Campbell <bcampbell@pingidentity.com> >>>>>>>> > Cc: oauth <oauth@ietf.org> >>>>>>>> > Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchang >>>>>>>> e-12.txt >>>>>>>> > >>>>>>>> > My personal opinion is that I'm glad this actor stuff is optional. >>>>>>>> > For one, none of our users have asked for it and really only do >>>>>>>> simple exchanges. Secondly, the rules for who can exchange what for what >>>>>>>> is controlled and defined within our AS. Makes things a lot simpler on the >>>>>>>> client. I kind of wish the actor stuff would be defined in a separate >>>>>>>> specification. I don't see us implementing it unless users start asking us >>>>>>>> to. >>>>>>>> > >>>>>>>> > On Wed, May 16, 2018 at 6:11 PM, Brian Campbell < >>>>>>>> bcampbell@pingidentity.com> wrote: >>>>>>>> >> Well, it's already called the "actor claim" so the claimed part >>>>>>>> is >>>>>>>> >> kind of implied. And "claimed actor claim" is a rather awkward. >>>>>>>> >> Really, all JWT claims are "claimed something" but they don't >>>>>>>> include >>>>>>>> >> the "claimed" bit in the name. RFC 7519, for example, defines the >>>>>>>> >> subject claim but not the claimed subject claim. >>>>>>>> >> >>>>>>>> >> On Fri, Apr 20, 2018 at 11:38 AM, Denis <denis.ietf@free.fr> >>>>>>>> wrote: >>>>>>>> >>> >>>>>>>> >>> Brian, >>>>>>>> >>> >>>>>>>> >>> Eric said: "what is the RP supposed to do when they encounter >>>>>>>> it? >>>>>>>> >>> This seems kind of under specified". >>>>>>>> >>> >>>>>>>> >>> After reading your explanations below, it looks like the RP can >>>>>>>> do >>>>>>>> >>> anything he wants with the "actor". >>>>>>>> >>> It is a "claimed actor" and, if we keep the concept, it should >>>>>>>> be >>>>>>>> >>> called as such. Such a claim cannot be verified. >>>>>>>> >>> A RP could copy and paste that claim in an audit log. No >>>>>>>> standard >>>>>>>> >>> action related to the content of such a claim can be specified >>>>>>>> in the >>>>>>>> >>> spec. If the content of a "claimed actor" is used by the RP, it >>>>>>>> >>> should be only used as an hint and thus be subject to other >>>>>>>> >>> verifications which are not specified in this specification. >>>>>>>> >>> >>>>>>>> >>> Denis >>>>>>>> >>> >>>>>>>> >>> Eric, I realize you weren't particularly impressed by my prior >>>>>>>> >>> statements about the actor claim but, for lack of knowing what >>>>>>>> else >>>>>>>> >>> to say, I'm going to kind of repeat what I said about it over >>>>>>>> in the >>>>>>>> >>> Phabricator tool and add a little color. >>>>>>>> >>> >>>>>>>> >>> The actor claim is intended as a way to express that delegation >>>>>>>> has >>>>>>>> >>> happened and identify the entities involved. Access control or >>>>>>>> other >>>>>>>> >>> decisions based on it are at the discretion of the consumer of >>>>>>>> the >>>>>>>> >>> token based on whatever policy might be in place. >>>>>>>> >>> >>>>>>>> >>> There are JWT claims that have concise processing rules with >>>>>>>> respect >>>>>>>> >>> to whether or not the JWT can be accepted as valid. Some >>>>>>>> examples are "aud" >>>>>>>> >>> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) >>>>>>>> from RFC 7519. >>>>>>>> >>> E.g. if the token is expired or was intended for someone or >>>>>>>> something >>>>>>>> >>> else, reject it. >>>>>>>> >>> >>>>>>>> >>> And there are JWT claims that appropriately don't specify such >>>>>>>> >>> processing rules and are solely statements of fact or >>>>>>>> circumstance. >>>>>>>> >>> Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At) >>>>>>>> claims are good examples of such. >>>>>>>> >>> There might be application or policy specific rules applied to >>>>>>>> the >>>>>>>> >>> content of those kinds of claims (e.g. only subjects from a >>>>>>>> >>> particular organization are able to access tenant specific data >>>>>>>> or, >>>>>>>> >>> less realistic but still possible, disallow access for tokens >>>>>>>> issued >>>>>>>> >>> outside of regular business >>>>>>>> >>> hours) but that's all outside the scope of a specification's >>>>>>>> >>> definition of the claim. >>>>>>>> >>> >>>>>>>> >>> The actor claim falls into the latter category. It's a way for >>>>>>>> the >>>>>>>> >>> issuer of the token to tell the consumer of the token what is >>>>>>>> going >>>>>>>> >>> on. But any action to take (or not) based on that information >>>>>>>> is at >>>>>>>> >>> the discretion of the token consumer. I honestly don't know it >>>>>>>> could >>>>>>>> >>> be anything more. And don't think it should be. >>>>>>>> >>> >>>>>>>> >>> There are two main expected uses of the actor claim (that I'm >>>>>>>> aware >>>>>>>> >>> of >>>>>>>> >>> anyway) that describing here might help. Maybe. One is a human >>>>>>>> to >>>>>>>> >>> human delegation case like a customer service rep doing >>>>>>>> something on >>>>>>>> >>> behalf of an end user. The subject would be that user and the >>>>>>>> actor >>>>>>>> >>> would be the customer service rep. And there wouldn't be any >>>>>>>> chaining >>>>>>>> >>> or nesting of the actor. The other case is so called service >>>>>>>> chaining >>>>>>>> >>> where a system might exchange a token it receives for a new >>>>>>>> token >>>>>>>> >>> that it can use to call a downstream service. And that service >>>>>>>> in >>>>>>>> >>> turn might do another exchange to get a new token suitable to >>>>>>>> call >>>>>>>> >>> yet another downstream service. And again and so on and turtles >>>>>>>> all >>>>>>>> >>> the way. I'm not necessarily endorsing that level of >>>>>>>> granularity in >>>>>>>> >>> chaining but it's bound to happen somewhere/sometime. The nested >>>>>>>> >>> actor claim is able to express that all that has happened with >>>>>>>> the >>>>>>>> >>> top level or outermost one being the system currently using the >>>>>>>> token >>>>>>>> >>> and prior systems being nested.. What actually gets done with >>>>>>>> that >>>>>>>> >>> information is up to the respective systems involved. There >>>>>>>> might be >>>>>>>> >>> policy about what system is allowed to call what other system >>>>>>>> that is >>>>>>>> >>> enforced. Or maybe the info is just written to an audit log >>>>>>>> >>> somewhere. Or something else. I don't know. But whatever it is >>>>>>>> application/deployment/policy dependent and not specifiable by a spec. >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla <ekr@rtfm.com> >>>>>>>> wrote: >>>>>>>> >>>> >>>>>>>> >>>> Hi folks, >>>>>>>> >>>> >>>>>>>> >>>> I've gone over draft-ietf-oauth-token-exchange-12 and things >>>>>>>> seem >>>>>>>> >>>> generally OK. I do still have one remaining concern, which is >>>>>>>> about >>>>>>>> >>>> the actor claim. Specifically, what is the RP supposed to do >>>>>>>> when >>>>>>>> >>>> they encounter it? This seems kind of underspecified. >>>>>>>> >>>> >>>>>>>> >>>> In particular: >>>>>>>> >>>> >>>>>>>> >>>> 1. What facts am I supposed to know here? Merely that everyone >>>>>>>> in >>>>>>>> >>>> the chain signed off on the next person in the chain acting >>>>>>>> as them? >>>>>>>> >>>> >>>>>>>> >>>> 2. Am I just supposed to pretend that the person presenting >>>>>>>> the token >>>>>>>> >>>> is the identity at the top of the chain? Say I have the >>>>>>>> >>>> delegation A -> B -> C, and there is some resource which >>>>>>>> >>>> B can access but A and C cannot, should I give access? >>>>>>>> >>>> >>>>>>>> >>>> I think the first question definitely needs an answer. The >>>>>>>> second >>>>>>>> >>>> question I guess we could make not answer, but it's pretty >>>>>>>> hard to >>>>>>>> >>>> know how to make a system with this left open.. >>>>>>>> >>>> >>>>>>>> >>>> -Ekr >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> _______________________________________________ >>>>>>>> >>>> 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 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 >>>>>>>> >> >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > -- >>>>>>>> > Bill Burke >>>>>>>> > Red Hat >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > OAuth mailing list >>>>>>>> > OAuth@ietf.org >>>>>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Bill Burke >>>>>>>> Red Hat >>>>>>>> >>>>>>> >>>>>>> >>>>>>> *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.* >>>>> >>>> >>>> >>> >>> *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-WG] Followup on draft-ietf-oauth-token-exc… Eric Rescorla
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Brian Campbell
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Denis
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Brian Campbell
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Bill Burke
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Rob Otto
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Mike Jones
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Bill Burke
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Brian Campbell
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Bill Burke
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Brian Campbell
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Eric Rescorla
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… George Fletcher
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Brian Campbell
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Eric Rescorla
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Brian Campbell
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Eric Rescorla
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Brian Campbell
- Re: [OAUTH-WG] Followup on draft-ietf-oauth-token… Eric Rescorla