Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

Nat Sakimura <sakimura@gmail.com> Mon, 16 March 2020 14:20 UTC

Return-Path: <sakimura@gmail.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 2126D3A0909 for <oauth@ietfa.amsl.com>; Mon, 16 Mar 2020 07:20:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 aoFf0acx5AZj for <oauth@ietfa.amsl.com>; Mon, 16 Mar 2020 07:20:43 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 B95233A0902 for <oauth@ietf.org>; Mon, 16 Mar 2020 07:20:42 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id s5so21513787wrg.3 for <oauth@ietf.org>; Mon, 16 Mar 2020 07:20:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pTr126Jr+e7aRXeAEyDJf80QUKZuKc5PWUGlHMRi4Xg=; b=SEOolHYL16T/iiOlb+WZ3yCnnyLwOtGB8jDsPGzL5aiWJtEdzsKrlKd+QHrMgXEU8W xq3R5aV+CesHyY7TbJw0XNcrAHWvOPz/7E4W8RtJ9KW21eKeHG++hlC69z2I0pjrjRYo RsxhJlscxmweQVfuXf1iRVaB07uY0qy+TIRXDJA1+X+XmtZfZF7+gQ5/2eoGUsoAfxL/ Y7N9WGz133g+XpwcBuvsl8aHq38UVK8C3CncG+KTznaZ1dkaxpg7GP/7m0DOPJ2wtV69 B5llu9kSFbQUw0iLU7ELoy72fxYuHMlyz1QTI+0nDmyU6PBGymPz2mUAdMeBsAaH/pHg OlEA==
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=pTr126Jr+e7aRXeAEyDJf80QUKZuKc5PWUGlHMRi4Xg=; b=iob+MR/oTfvuuuJWnjPmnYGMy/Sdwhqr8mqgT2kxcSg1poHspNU0qc2WIJgtTc3IT9 8I2QVfpe340TkPUEfzKU3Qyv4nZLacQTzgCw8gAleoR19AjA0HJhLdQrfsxc85gB4rgU rLeWlrfQEbXGOo2gA7MeV4/p8oTE4TrEpuLDRKtmzFZ1iPz+8f9CZDmGAvFYIjG3IYib A7zcIVWqogfJHSFKGnJYPCpaLcUvhVDY0ThSiYhSIBuvYPlpYS5tNAmWPFhUcvbpruDn KA9+HoLZcemMRX0j+1lNj9OPdJ1EFPED0T0LF63w6qSuznzBvhv+sDK7Mu7nM+qUdxU8 7oBQ==
X-Gm-Message-State: ANhLgQ0KGc4rYHEHeEtmEv3jWkG5/BtwD2Uys1AOAEarc5vcTpwAPNep El97IxOSizCrwaE9o0gRuM2bGaj8qXNKKAJDlbGdMIXI
X-Google-Smtp-Source: =?utf-8?q?ADFU+vs83ozHBrYQgFXjZapoImQQuVsfH9T5l55YglKp?= =?utf-8?q?eHcVfRba9HHjnWtw5YRdczGI134Uo7KZ3SyUCp774E7ZLhc=3D?=
X-Received: by 2002:a05:6000:4a:: with SMTP id k10mr34593974wrx.381.1584368440725; Mon, 16 Mar 2020 07:20:40 -0700 (PDT)
MIME-Version: 1.0
References: =?utf-8?q?=3CBY5PR00MB0676CAEA2D875E8150A6444FF5FD0=40BY5PR00MB0?= =?utf-8?q?676=2Enamprd00=2Eprod=2Eoutlook=2Ecom=3E?= <34877359-D7BD-44F6-B97C-95457F7D4542@authlete.com> <CA+k3eCQP_RAhHn2rGXiVp9r7SS2vdoBay7Ls1mp=jyTkTA5gNQ@mail.gmail.com> <014d3b9b-494a-1a1c-8482-075a957bc15d@aol.com>
In-Reply-To: <014d3b9b-494a-1a1c-8482-075a957bc15d@aol.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Mon, 16 Mar 2020 23:20:28 +0900
Message-ID: <CABzCy2D1hYuFRUWy0SWxB=cus6K9Um=4_wdG44jetDUoTCOonA@mail.gmail.com>
To: George Fletcher <gffletch=40aol.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001a55e305a0f98607"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/dbD-OaOnFkvQS6hmgte_HTKcG3I>
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object
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: Mon, 16 Mar 2020 14:20:46 -0000

So, I am getting overwhelming approval on getting client_id back.
In the next few days, I will create another draft that has it back.

Best,

Nat Sakimura

On Fri, Mar 13, 2020 at 1:25 AM George Fletcher <gffletch=
40aol.com@dmarc.ietf.org> wrote:

> I'm a +1 for adding client_id back as well
>
> On 3/12/20 11:31 AM, Brian Campbell wrote:
>
> +1 (again) that `client_id` should be allowed/required as a query parameter
> outside the request object JWT or URI and that its value has to be the same
> as within the request object.
>
> On Thu, Mar 12, 2020 at 8:20 AM Joseph Heenan <joseph@authlete.com> <joseph@authlete.com> wrote:
>
>
> I agree with that too.
>
> Joseph
>
> On 12 Mar 2020, at 14:18, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:
>
> I agree that we should restore the client_id functionality.  Thanks for
> moving this forward!
>
>                                                        -- Mike
>
> *From:* OAuth <oauth-bounces@ietf.org> <oauth-bounces@ietf.org> *On Behalf Of *Nat Sakimura
> *Sent:* Monday, February 24, 2020 6:18 PM
> *To:* John Bradley <ve7jtb@ve7jtb.com> <ve7jtb@ve7jtb.com>
> *Cc:* oauth <oauth@ietf.org> <oauth@ietf.org>
> *Subject:* Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Authorization
> Request (JAR) vs OIDC request object
>
> So, where should we take it to?
> Just add back client_id as it used to be?
>
> On Fri, Jan 24, 2020 at 6:55 AM John Bradley <ve7jtb@ve7jtb.com> <ve7jtb@ve7jtb.com> wrote:
>
>
> ---------- Forwarded message ---------
> From: *John Bradley* <ve7jtb@ve7jtb.com> <ve7jtb@ve7jtb.com>
> Date: Sat, Jan 18, 2020, 9:31 PM
> Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request
> (JAR) vs OIDC request object
> To: Benjamin Kaduk <kaduk@mit.edu> <kaduk@mit.edu>
>
>
> If you put the iss in the JWE header it is integrity protected, as JWE
> only supports AAD encryption algs.
>
> It is more of a problem when the client is sending a requestURI in that
> case having the clientID in the GET to the Authorization endpoint is useful.
>
> I think there is a argument for explicitly allowing the clientID as long
> as it exactly matches the clientID in the JAR.
>
> John B.
>
> On Fri, Jan 17, 2020 at 11:53 PM Benjamin Kaduk <kaduk@mit.edu> <kaduk@mit.edu> wrote:
>
> On Fri, Jan 17, 2020 at 08:44:18AM -0500, Justin Richer wrote:
>
> I don’t agree with this stance from a security or implementation
>
> perspective.
>
> If there’s a clear order of precedence for the information, it’s not
>
> particularly problematic. Everything inside the request object is to be
> taken over things outside the request object. We have the exact same
> semantics and process with dynamic registration, where the software
> statement is carried alongside plain JSON claims, and the two are mixed
> with a very simple algorithm:
>
>  - If a field is inside the signed payload, use that value and ignore
>
> any copy of it on the outside
>
>  - If a field is not inside the signed payload and is outside the signed
>
> payload, use the outside value
>
> Can someone please point out a concrete security issue with this
>
> algorithm? This is the extent of the “merge” semantics that we need here,
> and it would solve not only the ability to use this for use cases that call
> for a more static request object (perhaps signed by a third party and not
> the client) along side the plain parameters that can vary, but also the
> backwards compatibility issue that’s been discussed. With this algorithm in
> place, you could have OIDC clients actually be compliant with the spec,
> since OIDC requires replication of the values inside the request object on
> the outside with exact matches. An OIDC server wouldn’t be fully compliant
> with the new spec since it would reject some compliant JAR requests that
> are missing the external parameters, but that’s fairly easy logic to add on
> the OIDC side. And in that case you get a matrix of compatibility like:
>
> I agree that the merge algorithm is simple and fairly straightforward to
> implement.  But, as Joseph has been alluding, it's only simple if you've
> already made the decision to use all the parameters, both from inside and
> from outside the signed payload.  The security risk lies about having to
> make the trust decision twice, more than the mundane details of actually
> doing the merge.  (Though there is still some latent risk, given that we've
> seen some really crazy quality of implementation out there.)
>
> It's certainly *possible* that things end up fine in many well-deliniated
> cases where merging can be used.  But it's more complicated to reason
> about, and I don't remmber seeing much previous discussion about the
> specifics of the double trust decision.
>
> -Ben
>
>
>               JAR Server | OIDC Server  |
> ------------+------------+--------------+
> JAR Client  |     YES    |      NO      |
> OIDC Client |     YES    |     YES      |
>
> Breaking one out of the four possible combinations in a very predictable
>
> way is, I think, the best way to handle backwards compatibility here.
>
> But between this issue and JAR’s problematic call for the value of a
>
> request_uri to always be a JWT and be fetchable by the AS (neither of which
> are true in the case of PAR) makes me think we need to pull this back and
> rework those things, in a push back to the IESG’s comments.
>
>  — Justin
>
>
>
> On Jan 16, 2020, at 7:38 PM, Joseph Heenan <joseph@authlete.com> <joseph@authlete.com>
>
> wrote:
>
> I agree with this, particularly the security concerns of merging. If
>
> we merge, we can much guarantee there will eventually be a security issue
> where an attacker is able to gain an advantage by adding a parameter to the
> url query (which the server would then happily process if that parameter
> isn’t found inside the request object). Ruling out that case makes security
> analysis (particularly when creating new OAuth2 parameters) significantly
> simpler.
>
> Putting the iss in the JWE header and having the client_id duplicated
>
> outside the request object seem to address all the concerns I’ve seen
> raised.
>
> (It seems like it may be unnecessary to have the client_id duplicated
>
> outside if the request_uri is a PAR one though.)
>
> Joseph
>
>
>
>
> On 16 Jan 2020, at 22:40, John Bradley <ve7jtb@ve7jtb.com> <ve7jtb@ve7jtb.com> wrote:
>
> I agree with the IESG reasoning that merging is problimatic.  Once we
> allow that given a unknown list of possible paramaters with diffrent
> security properties it would be quite difficult to specify safely.
>
> Query paramaters can still be sent outside the JAR, but if they are in
> the OAuth registry the AS MUST ignore them.
>
> Puting the iss in the JWE headder addresses the encryption issue
>
> without
>
> merging.
>
> I understand that some existing servers have dependencys on getting
>
> the
>
> clientID as a query paramater.
>
> Is that the only paramater that people have a issue with as oposed to
>
> a
>
> nice to have?
>
> Would allowing the AS to not ignore the clientID as a query paramater
>
> as
>
> long as it matches the one inside the JAR, basicly the same as Connect
> request object but for just the one paramater make life easier for the
> servers?
>
> I am not promising a change but gathering info before proposing
>
> something.
>
> John B.
>
>
> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:
>
> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote:
>
> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
>
> Well, embedding a client_id claim in the JWE header in order to
> achieve "request parameters outside the request object should not
>
> be
>
> referred to" is like "putting the cart before the horse". Why do we
> have to avoid using the traditional client_id request parameter so
> stubbornly?
>
> The last paragraph of Section 3.2.1
> <https://tools.ietf.org/html/rfc6749#section-3.2.1
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6749%23section-3.2.1&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986096572&sdata=m6%2BaTTp1bBtLcoJ883HIFFg5OPqcqW9Mo%2B8ennoFgaM%3D&reserved=0> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6749%23section-3.2.1&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986096572&sdata=m6%2BaTTp1bBtLcoJ883HIFFg5OPqcqW9Mo%2B8ennoFgaM%3D&reserved=0>>
> of RFC 6749 says
>
> as follows.
>
>   /A client MAY use the "client_id" request parameter to identify
>   itself when sending requests to the token endpoint.  In the
>   "authorization_code" "grant_type" request to the token endpoint,
>   *an unauthenticated client MUST send its "client_id" to prevent
>   itself from inadvertently accepting a code intended for a client
>   with a different "client_id".*  This protects the client from
>   substitution of the authentication code.  (It provides no
>   additional security for the protected resource.)/
>
>
> If the same reasoning applies, a client_id must always be sent with
> request / request_uri because client authentication is not
>
> performed
>
> at the authorization endpoint. In other words, */an unauthenticated
> client (every client is unauthenticated at the authorization
>
> endpoint)
>
> MUST send its "client_id" to prevent itself from inadvertently
> accepting a request object for a client with a different
>
> "client_id"./*
>
> Identifying the client in JAR request_uri requests can be really
>
> useful
>
> so that an AS which requires request_uri registration to prevent
>
> DDoS
>
> attacks and other checks can do those without having to index all
> request_uris individually. I mentioned this before.
>
> I really wonder what the reasoning of the IESG reviewers was to
>
> insist
>
> on no params outside the JAR JWT / request_uri.
>
> I'm beginning to realise this step of the review process isn't
> particularly transparent to WG members.
>
> Could you expand on that a bit more?  My understanding is that the
>
> IESG
>
> ballot mail gets copied to the WG precisely so that there is
>
> transparency,
>
> e.g., the thread starting at
>
>
> https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FlkOhwiDj_hCI55BQRdiR9R0JwgI&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986106566&sdata=lkS8YioL8fTeiuLU%2F2MzebzCB%2FA%2FPPy%2Fl1Wi%2BLFKCFE%3D&reserved=0> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FlkOhwiDj_hCI55BQRdiR9R0JwgI&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986106566&sdata=lkS8YioL8fTeiuLU%2F2MzebzCB%2FA%2FPPy%2Fl1Wi%2BLFKCFE%3D&reserved=0>
>
> Which admittely is from almost three years ago, but that's the
>
> earliest
>
> that I found that could be seen as the source of this behavior.
>
> -Ben
>
> P.S. some other discussion at
>
>
> https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2F-tUrNY1X9eI_tQGI8T-IGx4xHy8&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986106566&sdata=QNpyHqv10Dfu9MQzkhVs%2By23ShloRw9GIbn8%2B6pvigo%3D&reserved=0> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2F-tUrNY1X9eI_tQGI8T-IGx4xHy8&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986106566&sdata=QNpyHqv10Dfu9MQzkhVs%2By23ShloRw9GIbn8%2B6pvigo%3D&reserved=0>
>  and
>
> https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FUke1nxRlgx62EJLevZgpWCz_UwY&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986116568&sdata=JTvXisbbmnXSpNRFJQkEKvO%2BkXiLdtEr%2FoH8obLtlo8%3D&reserved=0> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FUke1nxRlgx62EJLevZgpWCz_UwY&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986116568&sdata=JTvXisbbmnXSpNRFJQkEKvO%2BkXiLdtEr%2FoH8obLtlo8%3D&reserved=0>
>  and
>
> so on.
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986126557&sdata=I5KDQT%2BdT0lapMOr71odsiCRrZ7csVZMuaYnMzsWwhM%3D&reserved=0> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986126557&sdata=I5KDQT%2BdT0lapMOr71odsiCRrZ7csVZMuaYnMzsWwhM%3D&reserved=0>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986136551&sdata=8nJdrY3H98I39l5KXVkokwGw9sVzQGTJRfoxYwjtLhs%3D&reserved=0> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986136551&sdata=8nJdrY3H98I39l5KXVkokwGw9sVzQGTJRfoxYwjtLhs%3D&reserved=0>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986136551&sdata=8nJdrY3H98I39l5KXVkokwGw9sVzQGTJRfoxYwjtLhs%3D&reserved=0> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986136551&sdata=8nJdrY3H98I39l5KXVkokwGw9sVzQGTJRfoxYwjtLhs%3D&reserved=0>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986146548&sdata=%2B1PGj7U2CLMlh6HWf8BuGIvqtcGkz0hLMJYlktmkLc4%3D&reserved=0> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986146548&sdata=%2B1PGj7U2CLMlh6HWf8BuGIvqtcGkz0hLMJYlktmkLc4%3D&reserved=0>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986156545&sdata=2lgFg7%2F%2BLZ%2FgoabHcpK1ggg1FgNaArMIUKojGxJ%2BdLk%3D&reserved=0> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986156545&sdata=2lgFg7%2F%2BLZ%2FgoabHcpK1ggg1FgNaArMIUKojGxJ%2BdLk%3D&reserved=0>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986166540&sdata=Ex9kDYE8r4E0Y2KxMdDpwtZVWdNrq1Uqm6eYFf1LcsI%3D&reserved=0> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986166540&sdata=Ex9kDYE8r4E0Y2KxMdDpwtZVWdNrq1Uqm6eYFf1LcsI%3D&reserved=0>
>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundationhttp://nat.sakimura.org/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnat.sakimura.org%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986166540&sdata=%2FEt7X7DH8psh0JPtSnZGyk6qtliZUySH4z9%2BbLAEeTs%3D&reserved=0> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnat.sakimura.org%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7C35a13327b6124e254aa708d7b998f935%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637181938986166540&sdata=%2FEt7X7DH8psh0JPtSnZGyk6qtliZUySH4z9%2BbLAEeTs%3D&reserved=0>
> @_nat_en
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en