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

John Bradley <ve7jtb@ve7jtb.com> Thu, 16 January 2020 13:40 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 CBEC3120026 for <oauth@ietfa.amsl.com>; Thu, 16 Jan 2020 05:40:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 C3lhvFeGUFGw for <oauth@ietfa.amsl.com>; Thu, 16 Jan 2020 05:40:43 -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 3EDD0120018 for <oauth@ietf.org>; Thu, 16 Jan 2020 05:40:43 -0800 (PST)
Received: by mail-qk1-x72f.google.com with SMTP id k6so19084364qki.5 for <oauth@ietf.org>; Thu, 16 Jan 2020 05:40:43 -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-transfer-encoding:content-language; bh=y+68h/NwTMXzy82CLd2y9PuQRS3FH7dQvjswQbEIKVw=; b=eXhQdXlswDyxxDQrW17os2sr83F5lmcWiu9rOc5FGtPLW0+xvLr4xJHmoww9Fddl98 lWPa4XEEL4k/ScIktyw0RzkBF7wZ+hyNV/twZx8zn0W87YxPZhuB3Q8/ZO3Eui1zF6za GnzBE2mA9wbTBmsk8/RBppnd3KnzGTs4TakykM0MDbwgNMYFMEIKxHiUiARJcCq9l5vv /vSJhMN2jikoUBXzq1ByoNXfQ9DNOReEJgzeo/BP6grOt3QOTyLPNH14tFESqtTzQ8hw sDRg9DWCIRWcp/kRwSrvjqFZ0caXy5Ls/sZ+DV6GlunwdzyaOA3WzSW1mKyTctxEAw+Q GtWA==
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-transfer-encoding :content-language; bh=y+68h/NwTMXzy82CLd2y9PuQRS3FH7dQvjswQbEIKVw=; b=jrXpn4MbhiTNftFAavvwJGC1gqhCpVBA+TfbM8nJEbiUe64eWxiW5bATLB4oVQaFt6 G8bsXToUtaddXcUS1xue9OG4zDsK/jgODboruDr/viW2nnV4Qb3PKJOYamuS4Pcxp+NF stv5ve2tJIu9m6Xy4oXkeFPaU4eXIexiJkoYqphf9b0dcmSNWnzDS33Y2N11FTB3hmWd upanvCqfxFvvCH7EMy7c+A28KTT6QKo3EqibqdPv1+ZmnDHAG+o1uXO/x92GKQfBia2y buF6kwnWOYPzrXuim6ZrwVkLqDihWNYP19Hbw3YNvXaxbZLIbfyFZFoINY3CkVgviw3J GKvw==
X-Gm-Message-State: APjAAAXmsXw5PVSibsUdJ8AbUMWnvZXn6e/g/VFFOZKSEiJP8oo2KGn1 zDvAlLmFiPbEv+rPczlyBY4hWr5Pv2D+71MC
X-Google-Smtp-Source: APXvYqw+uchUiIG+DxudSCEyOprFzMd2JNMjE0PAKhQkrtN8Q8U3jwr+yEjYEITRfjTY9wVmS9DE/A==
X-Received: by 2002:a05:620a:1509:: with SMTP id i9mr26641769qkk.447.1579182041383; Thu, 16 Jan 2020 05:40:41 -0800 (PST)
Received: from [192.168.8.104] ([181.203.98.179]) by smtp.gmail.com with ESMTPSA id k9sm11209735qtq.75.2020.01.16.05.40.39 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jan 2020 05:40:40 -0800 (PST)
To: oauth@ietf.org
References: <79C4475C-FDEB-42C8-8A44-7BFE4DBF9453@gmail.com> <110a95d9-2981-6d2b-9cbf-9658be3585cc@connect2id.com> <CAANoGhK0-n6V_RogvVZ=8J8AQCEUUVJQn4_7wSWYixeQM8aZsw@mail.gmail.com> <CH2PR00MB0843D5044E11E0F4CE5F5D09F53B0@CH2PR00MB0843.namprd00.prod.outlook.com> <CAANoGhJB4mYSFiWKt3T=cObH7uCW0s3Zpv2m92+YaAY2Oy4mqw@mail.gmail.com> <2aca5c38-bb20-497e-14ed-f4a9245a9439@connect2id.com> <7baae999-47c1-f749-6c51-f45022ab1a3d@ve7jtb.com> <3d9ffc74-6c9c-48a1-0c98-65a7465e8dbc@connect2id.com> <CAHdPCmNHeUyDjrc32oQPZ5g3oars-XY3vq2p3qt2LzzkZMTw5w@mail.gmail.com> <89345e9b-8191-f01d-71a6-453ec197796f@connect2id.com> <20200116045302.GG80030@kduck.mit.edu>
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: <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com>
Date: Thu, 16 Jan 2020 10:40:39 -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: <20200116045302.GG80030@kduck.mit.edu>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/hVQuIoj_Qsa2fyu5iAHt2ygnHVY>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: 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: Thu, 16 Jan 2020 13:40:49 -0000

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> 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
> 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 and
> https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY and
> so on.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth