Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

Brian Campbell <bcampbell@pingidentity.com> Mon, 04 June 2018 20:45 UTC

Return-Path: <bcampbell@pingidentity.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 7A1A1130DE1 for <oauth@ietfa.amsl.com>; Mon, 4 Jun 2018 13:45:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 S9eYLdEK-wA9 for <oauth@ietfa.amsl.com>; Mon, 4 Jun 2018 13:45:41 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 B8111130DC0 for <oauth@ietf.org>; Mon, 4 Jun 2018 13:45:40 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id l19-v6so615294ioj.5 for <oauth@ietf.org>; Mon, 04 Jun 2018 13:45:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yhDZ0vLPpJt2O9IvYA4YJ3apN9wTp+ApAcjNsVWUKcA=; b=nNo5Pz2qON5mCiPytfktzILlaGQUHquredKHd6qbF893VdF+4pC0fXOKIbBYP3S353 c0MBwRmRZFi20vW40R/iISCguKrj0Ma+RIhTN68slk3r+8a+tbMpGvQ8W0pnSPYJMPuW 5l1CltcRr9tPV0Dp3K1BfnpezDwKWtCN5xbRE=
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=yhDZ0vLPpJt2O9IvYA4YJ3apN9wTp+ApAcjNsVWUKcA=; b=IwT5NYhmGRj1teSfy6NLkrbHgOz04Vq2rftOFKWaPRFTtRPsOTNakL438wkP+eWKZq /IFuaRvmDbot8Hlr7iTF9f+pAg7SwQwzYpbmrd9pBdGnaxcPGALs2hLBoFx1NPh4VyF3 k7mea3FNvI2OWMoL8BQ6q0Mex46aabzOArGGJQGcK+4jD0FQg4GC1/Zwbunf5GTGQ5K+ kyzFCdmvKYqAGEY5xsYh7mJYsMqeZ04vvjEabiPKFC2Ta3FCwIfAEQFh0zNhG5eSfrDS VThZGr9WXv0FDFtYgqfRdrQfy2YVlJipYP2S9l91Ek0pddMk6qO00lXeDHL9DV95d1zu Qftg==
X-Gm-Message-State: APt69E2xptr5MaLRLhnH6tz8KFkVnuJ2WWQBwJhqXaz5XeRH/tC56b+5 tr0/bcVXa/oFZiVJyXBvlRNix7O4OLX4xFjFhJVKvpqP78vP+l1SABO/h0786y526G24c8ZW0j5 5ZRIZVC4TTfEkbNck
X-Google-Smtp-Source: ADUXVKIuZEFwhvfS/RfgQNfRrKv/XXRyzz5JHYIo76IbtYsaPM/zDi1TQzfRJ2ha0LxTgp7Osc+2sE4gbV9bd/Jt67E=
X-Received: by 2002:a6b:588:: with SMTP id 130-v6mr15616021iof.282.1528145139677; Mon, 04 Jun 2018 13:45:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Mon, 4 Jun 2018 13:45:08 -0700 (PDT)
In-Reply-To: <CABcZeBMLAoMNLhSEoXRAvJVLcYajueL+zfLtNz+cAzk+EtoHCQ@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>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 4 Jun 2018 14:45:08 -0600
Message-ID: <CA+k3eCTn_5KHF6CT=9OeEiUmU-HENqee3jQ89OscTO9vgMuJfw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000375c49056dd70451"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ZXR_KOYXqDRiyS5JPnfs7BEiKqw>
Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.26
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, 04 Jun 2018 20:45:46 -0000

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._