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

John Bradley <ve7jtb@ve7jtb.com> Mon, 06 January 2020 22:50 UTC

Return-Path: <ve7jtb@ve7jtb.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 B089C12004F for <oauth@ietfa.amsl.com>; Mon, 6 Jan 2020 14:50:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, 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=ve7jtb-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 TgsVTAWb73lW for <oauth@ietfa.amsl.com>; Mon, 6 Jan 2020 14:50:29 -0800 (PST)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 EA89B120041 for <oauth@ietf.org>; Mon, 6 Jan 2020 14:50:28 -0800 (PST)
Received: by mail-qk1-x72f.google.com with SMTP id x1so40970297qkl.12 for <oauth@ietf.org>; Mon, 06 Jan 2020 14:50:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=HKyLT7jQzZ7F1829FDIt29PiYqHzbwy0KQVZBs8Nb64=; b=MN+/zPknYjkA6nonBZYPkikwKnovHzeSlvy+UidHms2wnpQChhmfAxPdRlH7RJMnZy Gw3TjdvUKQMzPloBod03/PPyZg8YzPpG1UnvBi7NgHaFdTvoUloP/TnDKeyLsU59zLsM TkI6Mk2p4GQKhIxQaHBpfFGg2ri3c+/Rl8zj0xnqALqfiKvOjWqgg4SePdCgkK5oxy/s Lc7qqGohFrMDKwEFIJEqyT0sOF2HxIW6nfTGfi06GzeK61uwoHzVQhUn5DOBMsEYz5mB odsyLwcQiY9Ga+rh5HDoZAy+i/Y6QTrpjLJ9ORG952Vuu8VwLqyxQAcI5758QfjK8A+C CulA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=HKyLT7jQzZ7F1829FDIt29PiYqHzbwy0KQVZBs8Nb64=; b=GCzFPuMmTCmWtzgAuwRaR9c2d1NLPeAZcq1Fgu0AULjErp7zQ4EOLTyg3zKt/oBTSk 6YxX7WKIqNE6tNrLpM9Sh4XmiTtwpFVYpUXy+Bm12wnPTxcypF2cTbEYtDXUnRWzMlPM Gd12w+3J+M+5Lt/DL31M6xaD42UTgyF6yQiRE6DoiKyAdUGrWD9gMroBykX9icRIgpdj vAheE0+UL+0ZVnRH4hU3kHWfKLauVLcjq4Tnj7WUz4NexZ4/dXeyyxOnxBOLmmrxygic MrxEBpAW4UoO0M8MZuGdB3SobCOHpXUC4thIEJwbCa1SNx/peS1kd/A71d71BXMQCfpj 5gVQ==
X-Gm-Message-State: APjAAAUzATouWK202CeMXejFfeMomJpULiPvanlNHtAzIeTooxI4oMtR NnZxPdNMM5X2eocw9vjiRAFyLsHWhgCbDS+9
X-Google-Smtp-Source: APXvYqzq4xFYj9yjeKcj6Brwrrbx5TehWdM0DCp1JZvBi4EwpABzdLPO7N0S6OUqwSvCPQRb+hbPNA==
X-Received: by 2002:ae9:e306:: with SMTP id v6mr84073777qkf.162.1578351027225; Mon, 06 Jan 2020 14:50:27 -0800 (PST)
Received: from [192.168.8.103] ([181.203.103.238]) by smtp.gmail.com with ESMTPSA id s20sm21466593qkj.100.2020.01.06.14.50.24 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jan 2020 14:50:26 -0800 (PST)
To: oauth@ietf.org
References: <CALAqi_-Ku6Hh3DQDXGR+83Q8jofMzVBcW=7GUnFFzsoG+Ka_1g@mail.gmail.com> <CA+k3eCRRW9oLfdmBXsccc_BVd-Ne8qOR5A4HftpSMkMt2JZLRg@mail.gmail.com> <CALAqi_9s+jXDwfb-HK+sguijR6=R6cPgJMwXhSkU52YQcEkX2A@mail.gmail.com> <CA+k3eCQZdX_DTDzcVaDJ=xaKSa0msjJh2UQvA+ZvhTeEBkTDkw@mail.gmail.com> <CABzCy2BVoutsLiwTDxpOKxOOtiNv59-TKAq=V9498m4OT=79+w@mail.gmail.com> <CAANoGhJnHnrN2aMtgpyTs02bA8v7d5a_M5PgSVcUx1xxHo4CmA@mail.gmail.com> <CABzCy2DM7OwUfOiYK2P6vWttpZm+Y=EWf_NwCvih==gSfXA=dw@mail.gmail.com> <CAHdPCmPjHkrfJvTJaMbqn7es=R1GPUGO8M+ASbUiODLUuWEEGw@mail.gmail.com> <244AF461-F289-44E2-8777-CA6DF307155D@mit.edu> <CAHdPCmOae363AncjfF99yYLZJxN4VWAsDOr7uULbG_jdjEJzRw@mail.gmail.com> <475DB9C9-08AB-44AE-91FA-A5062B99E02B@mit.edu> <OSAPR01MB4948142CA3D6677B5D34E4CEF93C0@OSAPR01MB4948.jpnprd01.prod.outlook.com>
From: John Bradley <ve7jtb@ve7jtb.com>
Autocrypt: addr=ve7jtb@ve7jtb.com; keydata= mQINBF1708MBEAC+aR8GCZVXEdrPOaYORjPzZCi5nvoWd2t5+xKHCalCgnz8ORFcREM38tZI yQNQ6cfB1METyr+9dVqKrBm8x00QWIlZ4hrcW87pOBek3hrsvvbmagoxzlOCLYHQ+7ESjfUe QVV5O9mESU2s3Zm+c0kLAUYtsuo7neeeiYaAkiCHo9WkpybA5o9tzeg9fK8e+bygPFYD1u8B X1Uy3GYbO9iCQIUXjgVya0117J7XgN/2QwGUbQtYKAFOIyDZfz/WXce2nthRP0nfFczLKozA 0KgSu70CEWZedRqotqzXorSbWIStjqf5WlD2g+Yf2+pbHt19xKQKplfy11qM0tJSd4UhcPu3 CWXfTVEzecQAee72A9U9yy4H3DimSxbkee/K8/f8ZkddzkUC5RxNEp3iYVThzVKbbScFU+6n JW7vwmihP1V3eBpbxpOGDF36h4CLssG1sTQFDHAstSJwQPFsUYzly6tEtLCVt1S8XIqzbTu9 /sHaBJBORmq8z1D7AWh7q9whjp0j+xcDITmIQq31Bkftxq3ru4Ow9b7cBb86bhotvDoXTQJL dEcfcB/YvobVSsy0W06GrKTf218N8+lHHL3z3GXxxoQUUU9yD45UxGSOe3rA7MQruoE+sa6O 1voGFcTDrGyYdjJ+KFsvK+GWHtMkLpHH/ArQsnTEhXXK+MfdAQARAQABtCNKb2huIFQuIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPokCVAQTAQgAPhYhBEiwG6+1WqDAVWlaHtAUSk/j /S+vBQJde9RyAhsDBQkDw6G9BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJENAUSk/j/S+v G6EQAIn7W2JGIaLRJhlHmA901QTwkEc/0Nj1qkJLDLKJuIB7P2/2go7/qEMngTZyZhoglM0w 9EuQie/9UXz7HtyORS+AsmDityDeUr5XkTunyTFLPiiv9E2SwJwAQVJYS6V0NbesJDnkqpTt 4UwUa+Asqw2NaCxT1THHvnFJkDYhPrCGvtOEXBFHpEzYwLoEjx2wfqU1byZsjoxYMCrNokaY J4SUw+bVZaFa+M5WNRwn7ySgEpCv1egSvUydXhFBJTbdwVmCZL7m4WJbECs/ofIYcBGtUJFV nIZ+g34iRqJUPnd4xI/F27u9ydvw+Ml8bldmMnIwhsFkkDnZb8ecBo2P4FQS3h0nB+uNYIl+ SFGLb9B17Kvhy8HtGWrn+KTUn2C96DTuJkwYwS/vUs43HhWUsCx6SLYmQpIUq1CoUOLCP5pJ VB0Q8e/zwrjkB4yMKLPdl3yFbj/bSXSvCG0LcjAAc4Thbngm+xoh5v+nZMxkL8AI9XDE3+Mi M869EDITGKQTmIIB6fKtuLJQYbhAG8uDZ0zOHAJoxArVE9ZwdYiHNGimFa04uBjtobDCz//n k1jaEd3dkjh6kVuQt3sSvf7icen27OXoBB4/HPlH/WNCaeIB13+YyfdYTcdiIB9s7W+R3Kan ANoCAT9pS/ogP5M8Tr8dvZkBPrflkXBspLBOLmc2uQINBF1708MBEADwwZM3OKVJQluPNTJf Jw0XjTJtt0dTMfXG4alx0pF1SHndJweFKtlkp0u5OJZ+YsaZtqspFe++LzBscL3sz2FPsWwP g2OS3Kg1il1QAjZSFoR7fDj5lmxQ9VQws9BSDAr1W1E5YAAnmJFDpJ2DQokYSx1B9MhgG6br UurLR0rZXGvNdNeMUCBMg6vMkvAmwR5yrwBZ8FFLTGk8zN8CUM8EFtGW7/m9r/iwsoUpdsq9 UghvVvIte1xTK+79g6IrNB14O7QUmAaV1FUA4lWqz3pHsPRLIoFS/C5F/d0fLLQ68En/nN2x Tk1totgEqO7gXJa0n48907ALvk5zubZ95lpCNb4gE8FK+hPXLLoYJ+aC2ILjsyD2sMCSEbVK 2QuGL+CmsLVRZCfy/NOhyeCC9IzUxES/Y/a9Zp1ZPdHpiZ7Bjm7O3QoaZ1Jm5vSJ9g7r4T3A fGt7hHGTk6E0jlCaKdt3aB8R4HiIZO/TgUc+tpqAaZBIWELzsqZXAdRhpNYKBAwSU80Oe7GZ zwly5454oKXZe9d7jyjEY19MEEHzWtYgbcygyLXbrUEMpwa+OlFRxuvfQyWYCY0aU7eh6qpP rSbxyj4TtJ3aetaEvNehjttSpNUSWEhsy3AGHqPMjgd5Otio0eP61quJNZdBgkqq2Xop1Lnq l48RAb5xUI1NE33CcwARAQABiQI8BBgBCAAmFiEESLAbr7VaoMBVaVoe0BRKT+P9L68FAl17 08MCGwwFCQPDob0ACgkQ0BRKT+P9L688mxAAj2d6uNsbnQ5937w5N3dWgUZNGaZOOY5XwjZy kbFzXEyOGTbWDevuE2fkkrDFZISvLwfJs5Q1fxF7hP72sSYjNFso+ngFGpF9o8QPkxn9c1vs d9W94HjZN0c4gdmLtdGWr4zZAbnWIjmuEhDxd8CFDLlhCT7L6Iii9UMbJ1trsCvp8d8vbIK+ 2pJhrCy6eIZy9ceoCH2XLaLDxoCtnMhWeSLrwA16qnXEpddtK5pXauvBkdv9bLy9z+SMvSn2 ZFSAI8nv0Ck3FfFBe3rHd16vOn//jmwwMzAb9mNDV8e7/KarWA/YmZJ4YiJ1KbuSu9mS89fG c4mug1igE9DYThB42OvD/8QGdUbkZFcr7E0QJflwrtaZ5j8wIoAUvf0IUsh/6Y6p23hYqxZy dUg43w5tEUtnBR3r/9jE4+RkQtVm8DplNTZUVkA3AVSRp23k4zsU7ioa8hzUasDf3jJMZfSd Xsiuo4Y1Eq6IddJL063Uh6jouXASjwynRW0W7CWlR1/D9z9v+I+0zK/px1vEgNRSQzqtKkMV wUDKMby9BNuIURIj6TBpKk5jBrp3kMP6Yt+Ke9Fs0pPoFX6e+LbOhBvNNGusWIadZfMpL8Ur ZWafyadOQJtqa+xpicVY+ui83oXmGajjOnbIieYlWoskl00HNzppfyBtqOMcxRa7yBIooQE=
Message-ID: <88b53953-620d-6bbb-403f-1c36bfd0d63c@ve7jtb.com>
Date: Mon, 6 Jan 2020 19:50:21 -0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
MIME-Version: 1.0
In-Reply-To: <OSAPR01MB4948142CA3D6677B5D34E4CEF93C0@OSAPR01MB4948.jpnprd01.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------5F52908AD45BE247A4282108"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/6ozwcvRetoraQPRnmSqSoub1sBU>
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, 06 Jan 2020 22:50:34 -0000

My take would be that any paramater in the OAuth registy is a OAuth
paramater.

A client could duplicate those outside the request object for some sort
of backwards compatability but they will be ignored.

What we have lost is the merge capability.  There are some use cases
that could use that to have a presigned object that some paramaters like
state are outside.  

That was not popular with the IESG. 

John B.

On 1/6/2020 3:04 AM, n-sakimura wrote:
>
> Up until -12 (Feb 13, 2017), it was using merge + JAR precedence if
> duplicated.
>
> As of -13 (Mar 30, 2017), it was changed that the server does not have
> to do the merge, at least for OAuth Authorization request parameters.
> It says nothing about other parameters.
>
> As of -14 (Jul 21, 2017), the wording was further strengthened by adding
>
>  
>
> The Authorization Server MUST only use the parameters in the Request
> Object even if the same parameter is provided in the query parameter.
>
>  
>
> So, the entire 6.3 now became
>
>
>       6.3<https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-6.3>.3>. 
>       Request Parameter Assembly and Validation
>
>    The Authorization Server MUST extract the set of Authorization
>    Request parameters from the Request Object value.  The Authorization
>    Server MUST only use the parameters in the Request Object even if the
>    same parameter is provided in the query parameter.  The Authorization
>    Server then validates the request as specified in OAuth 2.0
>    [RFC6749 <https://tools.ietf.org/html/rfc6749>].
>
>  
>
> It says nothing on the non-OAuth parameters that came with the
> authorization request.
>
> My take on the text is that all OAuth Authorization Request parameters
> MUST be in the request object.
>
> Behaviors towards other parameters that happens to have come together
> with the authorization request outside of request object will be
> treated as non-OAuth parameters.
>
>  
>
> Nat Sakimura
>
> Research Fellow, Nomura Research Institute
>
> E: n-sakimura@nri.co.jp
>
> T: +81(90)60136276
>
> ---------------------------------------------------------
>
> PLEASE READ:This e-mail is confidential and intended for the named
> recipient only.
>
> If you are not an intended recipient, please notify the sender and
> delete this e-mail.
>
>  
>
> *From:*OAuth <oauth-bounces@ietf.org> *On Behalf Of *Justin Richer
> *Sent:* Friday, January 3, 2020 2:35 AM
> *To:* Takahiko Kawasaki <taka@authlete.com>
> *Cc:* Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>rg>;
> oauth <oauth@ietf.org>rg>; Nat Sakimura <nat.sakimura@oidf.org>
> *Subject:* Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs
> OIDC request object
>
>  
>
> For solution [2], this is the behavior that’s required for OIDC today,
> so I would say that’s the New Client behaving like an Old Client in
> order to talk to an Old Server. So in reality, (2) causes the request
> to be rejected, and that’s OK.
>
>  
>
> I don’t think it’s viable to require parameters to exist inside the
> request object at all times. Nor should we try to enumerate which
> parameters go inside and outside at all times — at least from the
> JAR/OAuth level of things. I think there are too many things that are
> application and deployment specific for us to make this call. The very
> nature of the request object changes for people — some have a static
> object that’s deployed with clients and some have something that the
> client creates at runtime for each request. 
>
>  
>
> If the instead the New Server requires that any parameters duplicated
> between the two places have to match (the OIDC method) or that in a
> conflict the request object values take precedence (the merge method),
> then problems 3-1 and 3-2 go away. 
>
>  
>
> With the merge-and-precedence behavior, which is what I thought that
> JAR had during WGLC, [3-1] is well-defined. The request is processed
> the same way every time because this is a New Server. The client is
> going to do OIDC’s “duplicate” method, so “merge with precedence” is
> effectively a no-op.
>
>  
>
> With the merge-and-precedence behavior, [3-2] doesn’t happen because
> the required parameters aren’t required to be in the request object
> itself. As long as the request object is valid, it protects all
> parameters within it. I don’t think it’s up to us to determine what
> makes sense to put in that object. Security guidance is probably a
> good idea here.
>
>  
>
> Solution [3] is what Old Clients already do in OIDC today, so that’s
> what already happens and why problem space (3) isn’t a problem.
>
>  
>
>  — Justin
>
>
>
>     On Jan 2, 2020, at 12:24 PM, Takahiko Kawasaki <taka@authlete.com
>     <mailto:taka@authlete.com>> wrote:
>
>      
>
>     Thank you, Justin. Actually, I wanted to see someone write a
>     summary about what happens in each combination from a viewpoint of
>     both RP and AS with regard to backward compatibility (as I told
>     you in other channel just before you posted your email ^_^).
>
>     So,
>
>     *(1) New Client + New Server*
>     No problem will happen.
>
>     *(2) New Client + Old Server*
>     *[Problem 2-1]* If an authorization request contains 'request' or
>     'request_uri' but doesn't have old mandatory request parameters
>     ('client_id' and 'response_type') outside the request object, the
>     request is rejected.
>
>     *[Solution 2]* New Client should include the old mandatory request
>     parameters duplicately outside the request object. This means that
>     New Client should always send old mandatory request parameters
>     duplicately outside the request object if it wants to get maximum
>     compatibility.
>
>     *(3) Old Client + New Server*
>     *[Problem 3-1]* If an authorization request contains 'request' or
>     'request_uri' and some "optional" request parameters are not
>     included in the request object, AS will interpret the request
>     differently. Imagine what happens when optional parameters such as
>     'scope', 'state', 'nonce', 'redirect_uri', 'response_mode',
>     'max_age', 'acr_values', 'code_challenge', 'code_challenge_method'
>     and 'prompt' are not included in the request object but present
>     outside the request object.
>
>     *[Problem 3-2]* If an authorization request contains 'request' or
>     'request_uri' and some "mandatory" request parameters ('client_id'
>     and 'response_type') are not included in the request object, the
>     request is rejected.
>
>     *[Solution 3]* Old Client should include all request parameters
>     duplicately in the request object. This means that Old Client
>     should always include all request parameters duplicately in the
>     request object if it wants to get maximum compatibility.
>
>     *(4) Old Client + Old Server*
>     No problem will happen.
>
>     - - -
>
>
>     From a Client's point of view, for maximum compatibility, both Old
>     and New Clients should put mandatory request parameters outside
>     the request object and put all request parameters duplicately
>     inside the request object.
>
>     [Problem 3-1] is difficult to detect because the authorization
>     request is not rejected. But, if New Server requires that all
>     request parameters outside the request object be put inside the
>     request object duplicately, [Problem 3-1] is handled as an error
>     and thus client developers can detect the problem.
>
>     Consequently, introducing the following requirement in "FAPI Part
>     2, 5.2.2
>     <https://openid.net/specs/openid-financial-api-part-2-ID2.html#authorization-server>,
>     10" to JAR seems a good compromise (as I told before)
>
>         shall require that all parameters are present inside the
>         signed request object passed in the request or request_uri
>         parameter;
>
>
>     instead of just saying "the authorization server supporting this
>     specification MUST only use the parameters included in the request
>     object." which will bring about [Problem 3-1]. That is, how about
>     adding a rule like "if request parameters exist outside the
>     request object, they must exist inside the request object, too."?
>
>     Any thoughts?
>
>      
>
>     Best,
>
>     Taka
>
>      
>
>      
>
>     On Fri, Jan 3, 2020 at 12:48 AM Justin Richer <jricher@mit.edu
>     <mailto:jricher@mit.edu>> wrote:
>
>         I think the nature of the backwards incompatibility is
>         important here. The way that things are now, using
>         merge-with-precedence, you have the following matrix of
>         compatibility:
>
>          
>
>          
>
>                      New Server  |  Old Server  |
>
>         -----------+-------------+--------------+
>
>         New Client |      YES    |      NO      |
>
>         Old Client |      YES    |     YES      |
>
>          
>
>          
>
>         If you ask me, this is the right balance for a breaking
>         change. Old clients, where the vast majority of the code is,
>         don’t have to change. New clients can only talk to servers
>         with the new features, which is the ability to drop parameters
>         from the external request. This would apply to both OIDC and
>         plain OAuth.
>
>          
>
>         I think we should follow this kind of pattern in the
>         discussions on OAuth 2.1, which I think JAR should be a part of/
>
>          
>
>          — Justin
>
>          
>
>          
>
>
>
>             On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki
>             <taka@authlete.com <mailto:taka@authlete.com>> wrote:
>
>              
>
>             Breaking backward compatibility in this part would mean
>             that OpenID Certification given to AS implementations with
>             request_uri support will be invalidated once they support
>             JAR. It also would mean that test cases in the official
>             conformance suite need to be changed in a
>             backward-incompatible manner, which would implicitly
>             encourage that all certified implementations should re-try
>             to get certification.
>
>             Changing the spec now might need more three to six months,
>             but it would be worth considering what we get and lose by
>             saving the months and breaking backward compatibility.
>
>             Best Regards,
>             Taka
>
>              
>
>             On Wed, Dec 18, 2019 at 4:14 PM Nat Sakimura
>             <sakimura@gmail.com <mailto:sakimura@gmail.com>> wrote:
>
>                 So, no change is OK? 
>
>                  
>
>                 On Wed, Dec 11, 2019 at 10:01 PM John Bradley
>                 <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>> wrote:
>
>                     I also slightly prefer the merge approach. 
>
>                      
>
>                     There are plusses and minuses to both. 
>
>                      
>
>                     Changing again now that it is past ISEG review and
>                     backing out a Discuss will add another three to
>                     six months at this point, if we can get them to
>                     agree to the change. 
>
>                      
>
>                     John B. 
>
>                      
>
>                     On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura
>                     <sakimura@gmail.com <mailto:sakimura@gmail.com>>
>                     wrote:
>
>                         Correct. The WG supported the precedence
>                         approach and even merge just like OIDC as it
>                         is very useful from the implementation point
>                         of view and helps with a bunch of deployment
>                         patter. 
>
>                          
>
>                         The push back came in from the Ben Campbell’s
>                         DISCUSS. 
>
>                         See 
>
>                         https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-actually-specifies-the
>
>                          
>
>                         I am willing to go either way as long as
>                         people agree. My slight preference is to the
>                         original approach. 
>
>                          
>
>                         Best, 
>
>                          
>
>                         Nat Sakimura
>
>                          
>
>                         2019年8月29日(木) 6:56 Brian Campbell
>                         <bcampbell=40pingidentity..com@dmarc.ietf.org
>                         <mailto:40pingidentity.com@dmarc.ietf.org>>:
>
>                             FWIW, as best I can remember the change in
>                             question came as I result of
>                             directorate/IESG review rather than a WG
>                             decision/discussion. Which is likely why
>                             you can't find the "why" anywhere in the
>                             mailing list archive.
>
>                              
>
>                             On Wed, Aug 28, 2019 at 3:23 PM Filip
>                             Skokan <panva.ip@gmail.com
>                             <mailto:panva.ip@gmail.com>> wrote:
>
>                                 Well it kind of blows, doesn't it? I
>                                 wasn't able to find the "why" anywhere
>                                 in the mailing list archive around the
>                                 time this was changed.
>
>                                  
>
>                                 My take on satisfying both worlds
>                                 looks like this
>
>                                  
>
>                                 - allow just JAR - no other params
>                                 when possible.
>
>                                     (which btw isn't possible to do
>                                 with request_uri when enforcing client
>                                 based uri whitelist and the jwsreq
>                                 5.2.2 shows as much)
>
>                                 - enforce the "dupe behaviours"
>                                 defined in OIDC (if response_type or
>                                 client_id is in request object it must
>                                 either be missing or the same in
>                                 regular request).
>
>                                 - allows merging request object and
>                                 regular parameters with request object
>                                 taking precedence since it is a very
>                                 useful feature when having pre-signed
>                                 request object that's not one time use
>                                 and clients using it wish to vary
>                                 state/nonce per-request.
>
>                                  
>
>                                 I wish the group reconsidered making
>                                 this breaking change from OIDC's take
>                                 on request objects - allow combination
>                                 of parameters from the request object
>                                 with ones from regular parameters (if
>                                 not present in request object).
>
>
>                                 S pozdravem,
>                                 *Filip Skokan*
>
>                                  
>
>                                  
>
>                                 On Wed, 28 Aug 2019 at 23:02, Brian
>                                 Campbell <bcampbell@pingidentity.com
>                                 <mailto:bcampbell@pingidentity.com>>
>                                 wrote:
>
>                                     Filip, for better or worse, I
>                                     believe your assessment of the
>                                     situation is correct. I know of
>                                     one AS that didn't choose which of
>                                     the two to follow but rather
>                                     implemented a bit of a hybrid
>                                     where it basically ignores
>                                     everything outside of the request
>                                     object per JAR but also checks for
>                                     and enforces the presence and
>                                     value of the few regular
>                                     parameters (client_id,
>                                     response_type) that OIDC mandates.
>
>                                      
>
>                                     On Tue, Aug 27, 2019 at 5:47 AM
>                                     Filip Skokan <panva.ip@gmail.com
>                                     <mailto:panva.ip@gmail.com>> wrote:
>
>                                         Hello everyone,
>
>                                          
>
>                                         in an earlier thread I've
>                                         posed the following question
>                                         that might have gotten missed,
>                                         this might have consequences
>                                         for the existing
>                                         implementations of Request
>                                         Objects in OIDC
>                                         implementations - its making
>                                         pure JAR requests incompatible
>                                         with OIDC Core implementations.
>
>                                          
>
>                                         draft 14 of jwsreq (JAR)
>                                         introduced this language
>
>                                          
>
>                                             The client MAY send the
>                                             parameters included in the
>                                             request object
>                                             duplicated in the query
>                                             parameters as well for the
>                                             backward
>                                             compatibility etc.
>                                              *However, the
>                                             authorization server
>                                             supporting this
>                                             specification MUST only
>                                             use the parameters
>                                             included in the request
>                                             object. *
>
>                                          
>
>                                             Server MUST only use the
>                                             parameters in the Request
>                                             Object even if the
>                                             same parameter is provided
>                                             in the query parameter. 
>                                             The Authorization
>
>                                          
>
>                                             The client MAY send the
>                                             parameters included in the
>                                             request object
>                                             duplicated in the query
>                                             parameters as well for the
>                                             backward
>                                             compatibility etc.
>                                              *However, the
>                                             authorization server
>                                             supporting this
>                                             specification MUST only
>                                             use the parameters
>                                             included in the request
>                                             object.. *
>
>                                          
>
>                                         Nat, John, everyone - *does
>                                         this mean a JAR compliant AS
>                                         ignores everything outside of
>                                         the request object while OIDC
>                                         Request Object one merges the
>                                         two with the ones in the
>                                         request object being used over
>                                         ones that are sent in
>                                         clear?* The OIDC language also
>                                         includes sections which make
>                                         sure that some required
>                                         arguments are still passed
>                                         outside of the request object
>                                         with the same value to make
>                                         sure the request is "valid"
>                                         OAuth 2.0 request (client_id,
>                                         response_type), something
>                                         which an example in the JAR
>                                         spec does not do. Not having
>                                         this language means that
>                                         existing authorization request
>                                         pipelines can't simply be
>                                         extended with e.g. a
>                                         middleware, they need to
>                                         branch their codepaths.
>
>                                          
>
>                                         Is an AS required to choose
>                                         which of the two it follows?
>
>                                          
>
>                                         Thank you for clarifying this
>                                         in advance. I think if either
>                                         the behaviour is the same as
>                                         in OIDC or different this
>                                         should be called out in the
>                                         language to avoid confusion,
>                                         especially since this already
>                                         exists in OIDC and likely
>                                         isn't going to be read in
>                                         isolation, especially because
>                                         the Request Object is even
>                                         called out to be already in
>                                         place in OIDC in the JAR draft.
>
>                                          
>
>                                         Best,
>
>                                         *Filip*
>
>                                         _______________________________________________
>                                         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./*
>
>
>                             */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 <mailto:OAuth@ietf.org>
>                             https://www.ietf.org/mailman/listinfo/oauth
>
>                         -- 
>
>                         Nat Sakimura (=nat)
>
>                         Chairman, OpenID Foundation
>                         http://nat.sakimura.org/
>                         @_nat_en
>
>                         _______________________________________________
>                         OAuth mailing list
>                         OAuth@ietf.org <mailto:OAuth@ietf.org>
>                         https://www.ietf.org/mailman/listinfo/oauth
>
>
>                  
>
>                 -- 
>
>                 Nat Sakimura (=nat)
>
>                 Chairman, OpenID Foundation
>                 http://nat.sakimura.org/
>                 @_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
>
>          
>
>  
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth