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

Neil Madden <neil.madden@forgerock.com> Thu, 16 January 2020 14:01 UTC

Return-Path: <neil.madden@forgerock.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 CC696120018 for <oauth@ietfa.amsl.com>; Thu, 16 Jan 2020 06:01:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (1024-bit key) header.d=forgerock.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 Am8BsyHEW-Xi for <oauth@ietfa.amsl.com>; Thu, 16 Jan 2020 06:01:22 -0800 (PST)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 622B212007C for <oauth@ietf.org>; Thu, 16 Jan 2020 06:01:22 -0800 (PST)
Received: by mail-wr1-x434.google.com with SMTP id b6so19293904wrq.0 for <oauth@ietf.org>; Thu, 16 Jan 2020 06:01:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/COalwJ6Vj2cYBcASX7/J/u3QuHGRixgyPFq2zuRN5k=; b=O5FCdxf5Ztjlfqe5yIgEXNERz9FImv5KomM4lglU7Mgyz/XSh7lRgUYV9I/oF9n8ZH 9IYblUF3UzbmqCfjuW+6NdLwwEXyLEp6rG5TY8NUT+x2D2FvraDmhV3XrNjHxi8s+S10 w+alScKJQJ5XdXwZbTKrtRAV5VT4bedz81it0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/COalwJ6Vj2cYBcASX7/J/u3QuHGRixgyPFq2zuRN5k=; b=tAzhJNFrRXzEFowgV/P/ZybET0eR6hNcrW2RcNeL3YSmOpD2qiRl8L757f/ONToEMC w8WjY22LmSMwOXJwp0g7QZLJblTL/qslUidbaQBj8nw3Qyzl4Vk0HA9eyHshxDsbeMJn Qi0gj9PQQz3DR1IzQoKuZUBqCqKdY94LH1/3Cp4dtbc7V/u5Y7lgrPXoVOlU/gJBl3S8 2GZ5hubT/+kjxBr/BJilqz+ShQTa2yM6/DDhMqNRZpfKs2SC6lEzXO7fFfpm1ZJJxmQh Z5p8U5Uks+34u0uRN9EnR3hSTYAYzSCjuLktkqKMpjLyfGO5P59FJxN+tIHYL0dSIyhc I2ow==
X-Gm-Message-State: APjAAAWAkyRZJJP49LvauCDjlZKsmOSOLGur88jrw9bnCooy2IwUHK+q Wr1gS4f1vizlcxStz32wLZawNQ4i54w=
X-Google-Smtp-Source: APXvYqzfr4a3Mq0gEYkxGmv4MMmz4hK2umcrITaiF7+AKgZgWgXhCl8ZltESr+KEGRiIjbFpdphyJw==
X-Received: by 2002:adf:fc0c:: with SMTP id i12mr3741456wrr.74.1579183280787; Thu, 16 Jan 2020 06:01:20 -0800 (PST)
Received: from [192.168.1.64] (24.248.90.146.dyn.plus.net. [146.90.248.24]) by smtp.gmail.com with ESMTPSA id y7sm49847wmd.1.2020.01.16.06.01.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jan 2020 06:01:20 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Neil Madden <neil.madden@forgerock.com>
In-Reply-To: <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com>
Date: Thu, 16 Jan 2020 14:01:18 +0000
Cc: oauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E514281-F4A5-48B1-940E-62315F46F6DB@forgerock.com>
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> <837c8db5-5200-29c6-5914-167b77bdc071@ve7jtb.com>
To: John Bradley <ve7jtb@ve7jtb.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/NaGZOBRZsaJU-v25g3D324pqC04>
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 14:01:28 -0000

I believe just client_id would be sufficient for us, so I'd support a compromise position in which that is the only additional query parameter allowed.

-- Neil

> On 16 Jan 2020, at 13:40, John Bradley <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> 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
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth