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

Eric Rescorla <ekr@rtfm.com> Sat, 02 June 2018 04:03 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 6F64A1250B8 for <oauth@ietfa.amsl.com>; Fri, 1 Jun 2018 21:03:14 -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 oU3TJtJfyJjX for <oauth@ietfa.amsl.com>; Fri, 1 Jun 2018 21:03:10 -0700 (PDT)
Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (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 2F47D126B7E for <oauth@ietf.org>; Fri, 1 Jun 2018 21:03:10 -0700 (PDT)
Received: by mail-ot0-x234.google.com with SMTP id l13-v6so31582523otk.9 for <oauth@ietf.org>; Fri, 01 Jun 2018 21:03:10 -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=vgReGYszJrQoiPO6TGr6G0aCKE+3j3lCqE3w0LoAXyI=; b=2Fq9cKEOEazwxGLddaV6JNX0dIltXe3mfr6UD/itEznZecTC6aB7cDg0KfrI6r9BLL 3qOAcBSTFLlrQWBhkG4Mw2cU4ObShXa2j86Q5/sJ2/gMxVpNg1LmewuWzDwPdOsKHkia UOsNiXG7ZhcAAkDQeBw8PT3m72ns0LT1TLUcBl75xI/xz7n5Xl1WGQ35KFewJK36QF+e VBbZppCWbXkRVwRc4b+0mr+7ZQlbgqDK7rVjixzIYv1TKfJg22jag5WOMS6iQ+pb5+mV XJhB6xC3JEQn8hhh1AQuta67pTBWiQ0EksfStZbfYlWbFJBC3WaE08U5w0XqZ2iD7DRt yFHg==
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=vgReGYszJrQoiPO6TGr6G0aCKE+3j3lCqE3w0LoAXyI=; b=VZfzG1PjenIiABWv6/mBeDMO1T5TxaxtLHs4PFnwu+OpwZYw0YAjduPTfdx5tGlZPl Iey9aN88vRQ4jhZcFedGFSpUuduzM/B3CvR7JilHBmBpkp+RXdzyG5l79e8w+pu0VpfR NQxJPrikat7wyDnZl8TOSNFGd8CzxYvf70wmhdY9hHXQV44jFCggyGUPxKiPDrZoA0hv fmBLZO4SzLmcizAHWcf86b+VArSETkF2VHzSSL2P+n3TxwFH5JRilkFMiyqMeGec+fAb NM7CkwHF4dWlSlg6YC+Om3vVfHzEYidBK2vKe5lkXhYUVhbS+JyWhen/Sv9Jjq4GfghJ EWKw==
X-Gm-Message-State: ALKqPwdzY/1Xz1H7w7xV1PicTDzGMj5f6TLziZqo6b8/3VnGFwgeo8bF LWrxVNyyCs9cXEn4gWpGRjNaTQw7BPa4uzaPrB9Afg==
X-Google-Smtp-Source: ADUXVKKwiLYgN1r3fxLDunO6XRGjobrHAc4mcL2+691L4D3S2ViBweIFRYi21x3f8RX0qmx22PRvxiq+keG3S8G6uR0=
X-Received: by 2002:a9d:72c6:: with SMTP id d6-v6mr8794568otk.392.1527912189295; Fri, 01 Jun 2018 21:03:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Fri, 1 Jun 2018 21:02:28 -0700 (PDT)
In-Reply-To: <CA+k3eCSzRHuNsb=kDTLk1Y_o0NYRMgu5XxN+Ow1xjS9mMBm+NQ@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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 1 Jun 2018 21:02:28 -0700
Message-ID: <CABcZeBMLAoMNLhSEoXRAvJVLcYajueL+zfLtNz+cAzk+EtoHCQ@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004a908c056da0c74c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/gQ1qG-o_m-uba6iTz1-5l0QK5B8>
Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 02 Jun 2018 04:03:15 -0000

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