Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

Brian Campbell <bcampbell@pingidentity.com> Fri, 01 February 2019 21:43 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 78409130EBE for <oauth@ietfa.amsl.com>; Fri, 1 Feb 2019 13:43:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 aFezrUiQHc4F for <oauth@ietfa.amsl.com>; Fri, 1 Feb 2019 13:43:35 -0800 (PST)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 B5F8B130EC2 for <oauth@ietf.org>; Fri, 1 Feb 2019 13:43:34 -0800 (PST)
Received: by mail-io1-xd34.google.com with SMTP id k7so6957224iob.6 for <oauth@ietf.org>; Fri, 01 Feb 2019 13:43:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j8qqDleC4G9O94XHdNN7liw4qu0LW/HOm+JuH0PcsOM=; b=PsWI4xa6BkTkmWbCtAlTcS5zba/4Ug2KQg1UMFg7PDbp1HqjrZP4fgxWxmD4E16eUB lXNSLEgxMsrME4ZgLfZHD7QCqBece/PiT/LGpz7bo0Ixx1mOYhHPAE5Xn7ThOIjkrcZI sVpVe3oQbQA1B8BOHpCV7WB8JD9BDYOrKoLew=
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=j8qqDleC4G9O94XHdNN7liw4qu0LW/HOm+JuH0PcsOM=; b=KRGVcoyN3ewImzoU1CNCMXHrBL0EKrP41m6i2u8g5fTg4IEgaegOkXGZInTsp2BIVX Zjl5UiM+zGWGn0aF1qDl32RVqhRcWMl6/xicqw9jIA9Alr+VlElEd2JUJKk0lrckwNdv B5AjamSkO1z8Lfz+kOe+UlyQVOJeflRajAuc+YQQhwH8NGIHtho5+vwL43CrpZ09dHAo yOkxUeGmWlrOhKuDdfZ96/cnd1P8OjPg8q2TrQdGkaLWHXYrHKK/yIdcy0oZlkWR+Xzc HmkIW1LZRoRUz+yisQou2xVluDzMxUA/3L4aMZdiaBmLD5YbGnQMtEsaUb1gCF3LV9zo kUXA==
X-Gm-Message-State: AHQUAubGswIsdKtpkmtmTLOvsNEnlvaYciKMVw5pqjRLcOlaRPQGYCvB oRuBuGieI8y+5bxjfpVIGt+si5U3ogNmNCP2N+dzUYTb7mM3/FqVNlP/dshSVJ42WHmNn8G5Kq2 RyrmuKQqvUN4BjQ==
X-Google-Smtp-Source: AHgI3IaK6hAzKADz2QKZdCqVbJF0we33PjbEi9pjN1PxFoJqo+c1ldMTCBQmLpVn1UiodYKCiVu8zMHhY0gGLRkTd+c=
X-Received: by 2002:a5d:8597:: with SMTP id f23mr127540ioj.238.1549057413671; Fri, 01 Feb 2019 13:43:33 -0800 (PST)
MIME-Version: 1.0
References: <CA+k3eCTKSFiiTw8--qBS0R2YVQ0MY0eKrMBvBNE4pauSr1rHcA@mail.gmail.com> <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <CA+k3eCSoNRGrsxeLYd6DEqU+U6TB_aXV2aPUa07Um2X0ZH_ZEw@mail.gmail.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <CA+k3eCQi1sz2bDOMEATpN9ZvXd+VJydQXG03WKuLczG5kz2z+Q@mail.gmail.com> <CAP-T6TTD-nLGoPHqJ042SzotLorb2mzoWgLxsausWHhRPZr8xA@mail.gmail.com> <CALAqi_8CoYiy04eEKnWD=mjhRoB+y8nN8qeKre3Zcp5rAHxpMA@mail.gmail.com> <CA+k3eCQ_p5rQQ_1vR3NKXAYTaTJ7Rk=Ck-ZqDSFcjDHvTXUXzA@mail.gmail.com> <CALAqi_9h=Vczk4a4x-4590n2ep-v8vKJ2V8ufBbQFQ_dfrB5sA@mail.gmail.com> <CA+k3eCRumt5Eu8DxMSz20nQkmx5+cU8uA0fVifA+h9zoLMUb9w@mail.gmail.com> <CA+k3eCStivD8qywQ0c-SJovbCWDokYJcZhsPrfdu-=ZrnMqBZQ@mail.gmail.com> <372BB591-41AB-478B-9ADF-BE1A9ACCFF15@oracle.com> <CA+k3eCQ+L3uXdT2b61k0KP76U29bB96QCFhUwviaAA0eFgZURQ@mail.gmail.com> <A191AB8A-E3FA-4C1E-90C4-90155806DC5A@oracle.com> <CA+k3eCQnXVU8kJ4f0K2ppkeZr+R+Li9LBy7LTdc+BAa05w2gxQ@mail.gmail.com> <1F553EBD-DB43-40DB-85AB-BCA783E23F02@oracle.com>
In-Reply-To: <1F553EBD-DB43-40DB-85AB-BCA783E23F02@oracle.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 01 Feb 2019 14:43:07 -0700
Message-ID: <CA+k3eCQBMq+dKRu_-SxHXRb6bcRzgzcrjQgF+Wp8fg-TrCvwvw@mail.gmail.com>
To: Phil Hunt <phil.hunt@oracle.com>
Cc: Filip Skokan <panva.ip@gmail.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e116160580dc087b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/5NwXd3VUQxqyPhpDCLZ2WHuqb-Y>
Subject: Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint
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: Fri, 01 Feb 2019 21:43:41 -0000

I guess I'm not clear what you are driving at.

On Fri, Feb 1, 2019 at 2:32 PM Phil Hunt <phil.hunt@oracle.com> wrote:

> That way works. But one of the modes on most tls terminators is client
> cert optional.
>
> This works ok when you want dual mode to support bearer and mtls for apps
> (e.g. mobile) because the client will decide to use MTLS.  With browsers,
> they only use it if forced.
>
> Phil
>
> Oracle Corporation, Cloud Security and Identity Architect
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
> On Feb 1, 2019, at 1:14 PM, Brian Campbell <bcampbell@pingidentity.com>
> wrote:
>
> The server has to ask during the handshake for a client to send a cert.
>
> On Fri, Feb 1, 2019 at 2:12 PM Phil Hunt <phil.hunt@oracle.com> wrote:
>
>> If a client attempts to force mtls would typical tls terminators accept
>> it enough to redirect?
>>
>> My worry is how optionality works in browsers. It seems like they have to
>> hit an mtls required endpoint before they reliably use a client cert.
>>
>> Phil
>>
>> On Feb 1, 2019, at 12:56 PM, Brian Campbell <bcampbell@pingidentity.com>
>> wrote:
>>
>> It would be more a client having reached a non-MTLS endpoint and is 307'd
>> to an MTLS enabled endpoint.
>>
>> On Fri, Feb 1, 2019 at 1:40 PM Phil Hunt <phil.hunt@oracle.com> wrote:
>>
>>> I was a bit confused by how the 307 would work.
>>>
>>> To confirm, Is the client having reached an MTLS optional endpoint being
>>> redirected to an MTLS mandatory endpoint if the AT (or a cookie) is
>>> detected to have a “cnf” claim in order to make the browser invoke MTLS?
>>>
>>> Phil
>>>
>>> Oracle Corporation, Cloud Security and Identity Architect
>>> @independentid
>>> www.independentid.com
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=phUYsLIDYY7XNgWGCUgJ7N9VhrrCNFXff2qqJiEF2rc&s=XMz5UneDiol_fVUSqQrKTYmt9CaOqeHjRwMvPx3szZc&e=>
>>> phil.hunt@oracle.com
>>>
>>> On Feb 1, 2019, at 11:56 AM, Brian Campbell <
>>> bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:
>>>
>>> I'm finally getting around to working on the document updates (there's
>>> quite a few things that came out of AD review too). As far as the issue in
>>> this thread goes though, I'm leaning towards adding "mtls_endpoints" as a
>>> new metadata parameter. Maybe mention that a 307 might happen but it'd be
>>> more of a considerations type text.
>>>
>>> On Wed, Jan 16, 2019 at 5:52 AM Brian Campbell <
>>> bcampbell@pingidentity.com> wrote:
>>>
>>>> I guess I should have also said or been more straightforward in saying
>>>> that I don't particularly want to try and discuss/define the use of a 307
>>>> in the document.
>>>>
>>>> On Tue, Jan 15, 2019 at 6:59 AM Filip Skokan <panva.ip@gmail.com>
>>>> wrote:
>>>>
>>>>> I don't know that the use of 307 would need to be discussed in the
>>>>>> document itself.
>>>>>
>>>>>
>>>>> If the clients are supposed to be ready for this, yeah. For instance,
>>>>> my client software by default doesn't follow redirects, in order for it to
>>>>> be ready for mtls client authentication i'd have to know 307 is a
>>>>> possibility and whitelist 307 as a valid code to be followed.
>>>>>
>>>>> S pozdravem,
>>>>> *Filip Skokan*
>>>>>
>>>>>
>>>>> On Tue, Jan 15, 2019 at 2:54 PM Brian Campbell <
>>>>> bcampbell@pingidentity.com> wrote:
>>>>>
>>>>>> I don't know that the use of 307 would need to be discussed in the
>>>>>> document itself.
>>>>>>
>>>>>> On Tue, Jan 15, 2019 at 2:30 AM Filip Skokan <panva.ip@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I'm in favour of both 307 and metadata.
>>>>>>>
>>>>>>>    - case 307 - I don't recall ever encountering an http client
>>>>>>>    software that wouldn't have an option for following redirects, same for a
>>>>>>>    server side frameworks not having the option to do a 307 response with a
>>>>>>>    location header.
>>>>>>>    - case 307 - Relying purely on a new metadata doesn't help in
>>>>>>>    the scenario David put forth earlier about clients not being aware of using
>>>>>>>    mtls, a device policy of sorts.
>>>>>>>    - case metadata - no second request if the client knows there's
>>>>>>>    an mtls endpoint it should use.
>>>>>>>
>>>>>>> Maybe we should specify both as optional for an AS to deploy and a
>>>>>>> client to be ready for?
>>>>>>>
>>>>>>> S pozdravem,
>>>>>>> *Filip Skokan*
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jan 15, 2019 at 10:05 AM Dave Tonge <
>>>>>>> dave.tonge@momentumft.co.uk> wrote:
>>>>>>>
>>>>>>>> I'm in favour of the `mtls_endpoints` metadata parameter - although
>>>>>>>> it should be optional.
>>>>>>>> While a 307 redirect seems kind of elegant I worry, like you,  that
>>>>>>>> not all clients would handle it appropriately.
>>>>>>>> There would probably need to be an error defined for clients who
>>>>>>>> attempt to use `tls_client_auth` at the regular endpoint.
>>>>>>>>
>>>>>>>> Dave
>>>>>>>>
>>>>>>>> On Mon, 14 Jan 2019 at 22:29, Brian Campbell <bcampbell=
>>>>>>>> 40pingidentity.com@dmarc.ietf.org> wrote:
>>>>>>>>
>>>>>>>>> Trying to summarize things somewhat here and focus in hopefully
>>>>>>>>> towards some decision. There's basically an idea on the table to add an AS
>>>>>>>>> metadata parameter to the draft-ietf-oauth-mtls doc that would be a JSON
>>>>>>>>> object which contains endpoints that a client doing MTLS would use rather
>>>>>>>>> than the regular endpoints. A straw-man example might look like this (with
>>>>>>>>> mtls_endpoints being that new parameter).
>>>>>>>>>
>>>>>>>>> {
>>>>>>>>>   "issuer":"https://server.example.com",
>>>>>>>>>   "authorization_endpoint":"https://server.example.com/authz",
>>>>>>>>>   "token_endpoint":"https://server.example.com/token",
>>>>>>>>>   "token_endpoint_auth_methods_supported":[
>>>>>>>>> "client_secret_basic","tls_client_auth", "none"],
>>>>>>>>>   "userinfo_endpoint":"https://server..example.com/userinfo
>>>>>>>>> <https://server.example.com/userinfo>",
>>>>>>>>>   "revocation_endpoint":"https://server.example.com/revo",
>>>>>>>>>   "jwks_uri":"https://server.example.com/jwks.json",
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *  "mtls_endpoints":{      "token_endpoint":"https://mtls.example.com/token
>>>>>>>>> <https://mtls.example.com/token>",    "userinfo_endpoint":"https://mtls
>>>>>>>>> <https://server.example.com/token>.example.com/userinfo
>>>>>>>>> <http://example.com/userinfo>",    "revocation_endpoint":"https://mtls
>>>>>>>>> <https://server.example.com/token>..example.com/revo
>>>>>>>>> <http://example.com/revo>"  }*
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> The idea behind this is that "regular" clients (those not doing
>>>>>>>>> MTLS) will use the regular endpoints. And only the host/port of the
>>>>>>>>> endpoints listed in mtls_endpoints will be set up to request TLS client
>>>>>>>>> certificates during handshake.. Thus any potential impact of the
>>>>>>>>> CertificateRequest message being sent in the TLS handshake can be avoided
>>>>>>>>> for all the other regular clients that are not going to do MTLS - including
>>>>>>>>> and most importantly in-browser javascript clients where there can be less
>>>>>>>>> than desirable UI presented to the end-user.
>>>>>>>>>
>>>>>>>>> The arguments in favor of that seem to be basically that it allows
>>>>>>>>> for AS deployments to support MTLS while still allowing for a "not broken"
>>>>>>>>> UX for end-users of clients (in-browser javascript clients) that aren't
>>>>>>>>> doing MTLS. And that it's not much in terms of adding to the spec and
>>>>>>>>> complexity of implementations.
>>>>>>>>>
>>>>>>>>> The arguments against it seem to be 1) the bad UX isn't really
>>>>>>>>> that bad and/or will only happen to a subset of users 2) there are other
>>>>>>>>> things that can be done, such as 307ing or renegotiation/post-handshake
>>>>>>>>> client auth, to avoid the bad UX.
>>>>>>>>>
>>>>>>>>> Speaking for myself, I'm kinda torn on it.
>>>>>>>>>
>>>>>>>>> I will say that, in addition to the folks that have pointed out
>>>>>>>>> that renegotiation just isn't possible in some cases, my experience trying
>>>>>>>>> to do something like that in the past was not particularly successful or
>>>>>>>>> encouraging. That could have been my fault, of course, but still seems a
>>>>>>>>> relevant data point. I also have my doubts about the actual difficulty of
>>>>>>>>> getting an AS to issue a 307 like response for requests based on the
>>>>>>>>> calling client and the likelihood that some/all OAuth client software would
>>>>>>>>> handle it appropriately.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Jan 11, 2019 at 12:32 PM David Waite <
>>>>>>>>> david@alkaline-solutions.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> > On Jan 11, 2019, at 3:32 AM, Neil Madden <
>>>>>>>>>> neil.madden@forgerock.com> wrote:
>>>>>>>>>> >
>>>>>>>>>> > On 9 Jan 2019, at 05:54, David Waite <
>>>>>>>>>> david@alkaline-solutions.com> wrote:
>>>>>>>>>> >>
>>>>>>>>>> >>> On Dec 28, 2018, at 3:55 PM, Brian Campbell <bcampbell=
>>>>>>>>>> 40pingidentity.com@dmarc.ietf.org> wrote:
>>>>>>>>>> >>>
>>>>>>>>>> >> <snip>
>>>>>>>>>> >>
>>>>>>>>>> >>> All of that is meant as an explanation of sorts to say that I
>>>>>>>>>> think that things are actually okay enough as is and that I'd like to
>>>>>>>>>> retract the proposal I'd previously made about the MTLS draft introducing a
>>>>>>>>>> new AS metadata parameter. It is admittedly interesting (ironic?) that Neil
>>>>>>>>>> sent a message in support of the proposal as I was writing this. It did
>>>>>>>>>> give me pause but ultimately didn't change my opinion that it's not worth
>>>>>>>>>> it to add this new AS metadata parameter.
>>>>>>>>>> >>
>>>>>>>>>> >> Note that the AS could make a decision based on the token
>>>>>>>>>> endpoint request - such as a policy associated with the “client_id”, or via
>>>>>>>>>> a parameter in the ilk of “client_assertion_type” indicating MTLS was
>>>>>>>>>> desired by this public client installation. The AS could then to TLS 1.2
>>>>>>>>>> renegotiation, 1.3 post-handshake client authentication, or even use 307
>>>>>>>>>> temporary redirects to another token endpoint to perform mutual
>>>>>>>>>> authentication.
>>>>>>>>>> >
>>>>>>>>>> > Renegotiation is an intriguing option, but it has some
>>>>>>>>>> practical difficulties. Our AS product runs in a Java servlet container,
>>>>>>>>>> where it is pretty much impossible to dynamically trigger renegotiation
>>>>>>>>>> without accessing private internal APIs of the container. I also don’t know
>>>>>>>>>> how you could coordinate this in the common scenario where TLS is
>>>>>>>>>> terminated at a load balancer/reverse proxy?
>>>>>>>>>> >
>>>>>>>>>> > A 307 redirect could work though as the server will know if the
>>>>>>>>>> client either uses mTLS for client authentication or has indicated that it
>>>>>>>>>> wants certificate-bound access tokens, so it can redirect to a
>>>>>>>>>> mTLS-specific endpoint in those cases.
>>>>>>>>>>
>>>>>>>>>> Agreed. There are trade-offs for both. As you say, I don’t know a
>>>>>>>>>> way to have say a custom error code or WWW-Authenticate challenge to
>>>>>>>>>> trigger renegotiation on the reverse proxy - usually this is just a static,
>>>>>>>>>> location-based directive.
>>>>>>>>>>
>>>>>>>>>> >
>>>>>>>>>> >> Both the separate metadata url and a
>>>>>>>>>> “client_assertion_type”-like indicator imply that the client has multiple
>>>>>>>>>> forms of authentication and is choosing to use MTLS. The URL in particular
>>>>>>>>>> I’m reluctant to add support for, because I see it more likely a client
>>>>>>>>>> would use MTLS without knowing it (via a device-level policy being applied
>>>>>>>>>> to a public web or native app) than the reverse, where a single client
>>>>>>>>>> (represented by a single client_id) is dynamically picking between forms of
>>>>>>>>>> authentication.
>>>>>>>>>> >
>>>>>>>>>> > That’s an interesting observation. Can you elaborate on the
>>>>>>>>>> sorts of device policy you are talking about? I am aware of e.g. mobile
>>>>>>>>>> device management being used to push client certificates to iOS devices,
>>>>>>>>>> but I think these are only available in Safari.
>>>>>>>>>>
>>>>>>>>>> The primary use is to set policy to rely on device level
>>>>>>>>>> management in controlled environments like enterprises when available. So
>>>>>>>>>> an AS may try to detect a client certificate as an indicator of a managed
>>>>>>>>>> device, use that to assume a device with certain device-level
>>>>>>>>>> authentication, single user usage, remote wipe, etc. characteristics, and
>>>>>>>>>> decide that it can reduce user authentication requirements and/or expose
>>>>>>>>>> additional scopes.
>>>>>>>>>>
>>>>>>>>>> On more thought, this is typically done as part of the user agent
>>>>>>>>>> hitting the authorization endpoint, as a separate native application may be
>>>>>>>>>> interacting with the token endpoint, and in some operating systems the
>>>>>>>>>> application’s network connections do not utilize (and may not have access
>>>>>>>>>> to) the system certificate store.
>>>>>>>>>>
>>>>>>>>>> In terms of user agents, I believe you can perform similar
>>>>>>>>>> behavior (managed systems using client certificates on user agents
>>>>>>>>>> transparently) on macOS, Windows, Chrome, and Android devices, Chrome
>>>>>>>>>> (outside iOS) typically inherits device level policy. Firefox on desktop I
>>>>>>>>>> assume you can do that in limited fashion as well.
>>>>>>>>>>
>>>>>>>>>> -DW
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *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
>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=phUYsLIDYY7XNgWGCUgJ7N9VhrrCNFXff2qqJiEF2rc&s=U24_047OeCiktLwRQs8xiahNU72QuHsnJ2k6R-Zuk0w&e=>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=phUYsLIDYY7XNgWGCUgJ7N9VhrrCNFXff2qqJiEF2rc&s=U24_047OeCiktLwRQs8xiahNU72QuHsnJ2k6R-Zuk0w&e=>
>>>>>>>>
>>>>>>>
>>>>>> *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 mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=phUYsLIDYY7XNgWGCUgJ7N9VhrrCNFXff2qqJiEF2rc&s=U24_047OeCiktLwRQs8xiahNU72QuHsnJ2k6R-Zuk0w&e=>
>>>
>>>
>>>
>> *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._