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

Vladimir Dzhuvinov <vladimir@connect2id.com> Tue, 17 March 2020 12:39 UTC

Return-Path: <vladimir@connect2id.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 31A883A1E2A for <oauth@ietfa.amsl.com>; Tue, 17 Mar 2020 05:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 jrOmpdHoWoy6 for <oauth@ietfa.amsl.com>; Tue, 17 Mar 2020 05:39:43 -0700 (PDT)
Received: from p3plsmtpa07-05.prod.phx3.secureserver.net (p3plsmtpa07-05.prod.phx3.secureserver.net [173.201.192.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4353A1E30 for <oauth@ietf.org>; Tue, 17 Mar 2020 05:39:42 -0700 (PDT)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id EBVUj3JyTVFE6EBVVjPHnk; Tue, 17 Mar 2020 05:39:42 -0700
X-CMAE-Analysis: v=2.3 cv=aJiOVo1m c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=ddEIn7SpAAAA:8 a=48vgC7mUAAAA:8 a=Mhp_Scw7AAAA:8 a=UqCG9HQmAAAA:8 a=DVqm7IH0AAAA:8 a=yMhMjlubAAAA:8 a=2V9cX1JTLGS0VGowF9IA:9 a=kOzfvTpMDikEuSKB:21 a=YddrdvYCjsD9KNdy:21 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=v81dPFujXwDpEvnPQeAA:9 a=bPFot_M6njuH2tyz:21 a=ATP9WQo_4cx5ERde:21 a=qW6C3UGxcYf5N5PJ:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=0LcYgHMQs7_kImmFrmno:22 a=w1C3t2QeGrPiZgrLijVG:22 a=rCfoGGe4EEIQCwLoKFZE:22 a=M6wP_kGduNurgptF5PJY:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
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>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Organization: Connect2id Ltd.
Message-ID: <fe7f4d16-5f06-5823-7bb4-66286174e3b1@connect2id.com>
Date: Tue, 17 Mar 2020 14:39:39 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CA+k3eCQP_RAhHn2rGXiVp9r7SS2vdoBay7Ls1mp=jyTkTA5gNQ@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000602060401050500070801"
X-CMAE-Envelope: =?utf-8?q?MS4wfCPWTG+YhtLW9BudfF9bNH91/EOrZSgmWk3MQNnqVCEq2?= =?utf-8?q?4abHjyWAouLmTcvDHj0NL0eh3LqWmBmz2Be16jse/+Jr5pPej6P8ybMAlinsIi911?= =?utf-8?q?QTAsEj?= DVHmXSN6mXn6QijVp8qBbRQxTbJiZNrNiiVhAJVZ6GO73lIiqUKFD49T
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/DzBDlDR65c5iMtdBk1bSPKHiraQ>
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: Tue, 17 Mar 2020 12:39:49 -0000

+1

Thanks!

Vladimir

On 12/03/2020 17:31, 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
> <mailto: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
>>     <mailto: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
>>     <mailto:oauth-bounces@ietf.org>> *On Behalf Of *Nat Sakimura
>>     *Sent:* Monday, February 24, 2020 6:18 PM
>>     *To:* John Bradley <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>>
>>     *Cc:* oauth <oauth@ietf.org <mailto: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
>>     <mailto:ve7jtb@ve7jtb.com>> wrote:
>>
>>          
>>         ---------- Forwarded message ---------
>>         From: *John Bradley* <ve7jtb@ve7jtb.com
>>         <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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>>
>>             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>
>>             > >>> 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> 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> and
>>             > >>> so on.
>>             > >>> 
>>             > >>> _______________________________________________
>>             > >>> OAuth mailing list
>>             > >>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>             > >>> https://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>
>>             > >> 
>>             > >> _______________________________________________
>>             > >> OAuth mailing list
>>             > >> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>             > >> https://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>
>>             > > 
>>             > > _______________________________________________
>>             > > OAuth mailing list
>>             > > OAuth@ietf.org <mailto:OAuth@ietf.org>
>>             > > https://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>
>>             > 
>>
>>             > _______________________________________________
>>             > OAuth mailing list
>>             > OAuth@ietf.org <mailto:OAuth@ietf.org>
>>             > https://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>
>>
>>             _______________________________________________
>>             OAuth mailing list
>>             OAuth@ietf.org <mailto:OAuth@ietf.org>
>>             https://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>
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         OAuth@ietf.org <mailto:OAuth@ietf.org>
>>         https://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>
>>
>>
>>      
>>     -- 
>>     Nat Sakimura (=nat)
>>     Chairman, OpenID Foundation
>>     http://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>
>>     @_nat_en
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/oauth
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto: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

-- 
Vladimir Dzhuvinov