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

John Bradley <ve7jtb@ve7jtb.com> Fri, 10 January 2020 15:53 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 1DBBD12092A for <oauth@ietfa.amsl.com>; Fri, 10 Jan 2020 07:53:49 -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 2VIwgwwLwurD for <oauth@ietfa.amsl.com>; Fri, 10 Jan 2020 07:53:43 -0800 (PST)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 43EEB1208EF for <oauth@ietf.org>; Fri, 10 Jan 2020 07:53:43 -0800 (PST)
Received: by mail-wr1-x42f.google.com with SMTP id g17so2298412wro.2 for <oauth@ietf.org>; Fri, 10 Jan 2020 07:53:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LGx5Na09JK8/oYd4Ig7tWgHn+S8yC3zVvLTqx3DPVAI=; b=PUAvQsfkGau1nsY8IloVGyFl/sdNKYcWUltr5p6+Ipwi+I7eCQP0f1XCH9lGvVqMKb kUONfKgyP584T1nmuS9cG4DlDbxJtmTOyxXGYYKS304SJtF6yzsXtr5v02T6pAhu/GDR p8Tawx80wzVaWrPp4xc6cNWCmR+lFDZWpyhIK/OfcvrArbZYsPNB7iPFgRHqhXRDeIOB ZT3Ojv2k6eetbUm4/xTzr3obSytLupmEs98xsdrGJUX9OtEJQmgeFxTXQFNpkPhbSmNQ BtBstkxiktEWC07KaD3DRxsWm2eU/OIPiQ2LxX1jwkYduzJ1cVtPMIfY4FXLLhDVBZQT 4i8Q==
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=LGx5Na09JK8/oYd4Ig7tWgHn+S8yC3zVvLTqx3DPVAI=; b=fmOyRls4fYGe21ZGFU2/4YWwvkIePITWsnXIV9D7JEE/S+iloYc7SF8dW7J0lkvLpK QaWzIyecLItO8UdrORybSJbTE9NwB0/dcNGRPOg5mjUVbWzv2SjtTaD0uQAZsFsO1M4H EdFLynSZmPzq9BLaN4TCVLy+FxxH0E4+zS4DbiI0RHC5ljJvf5yoMFPM0nBhlp3oTT8+ i7n3kd2BJQQWHm01erCNx+7CIZI9jCaFI1NTkoyJdML0/prG4QkEfno3eSMJ5D2i9Dkq coOoOj3rY0fDDpl2wFDDPjM2JzS86uIlLQaYYJSZH9qwqdootbN7UEO7koj5zVpHDTKp aI9w==
X-Gm-Message-State: APjAAAUm3fuPzRekcKcbyOenkkwEp7KFtWYZfE2wmD6XCdHXadruveMQ AG8Yops/Zyh+2xtRXFR61P8romPqpE+xMTfJtXRgYw==
X-Google-Smtp-Source: APXvYqwExe3H3lRVKTwGPBx28F9iZ3H9PiZkx9bgPk8op9JjYz+z1XDWFKWxykcPBEGOlwfAoaoCh1wmKpyk8jC9FM8=
X-Received: by 2002:a5d:480b:: with SMTP id l11mr4331425wrq.129.1578671621648; Fri, 10 Jan 2020 07:53:41 -0800 (PST)
MIME-Version: 1.0
References: <88b53953-620d-6bbb-403f-1c36bfd0d63c@ve7jtb.com> <8CF35A0F-F18A-4858-8A46-0713D205FAC8@lodderstedt.net> <CAANoGhJ8kW+waoOmAOAiN5T90J_Pp5NytcY3mS-dg8PysCvGXA@mail.gmail.com> <4CEE27B7-9B64-4302-A21D-3938CB231239@mit.edu>
In-Reply-To: <4CEE27B7-9B64-4302-A21D-3938CB231239@mit.edu>
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Fri, 10 Jan 2020 12:53:31 -0300
Message-ID: <CAANoGh+T1=krOtqLXfa45_wjwobfnUpDX0z5eXVYgV9xPqKD5w@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, IETF oauth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000039d2ce059bcb21b9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/h-j-FVERHMNV6lZ9DGaHc0ujuVI>
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: Fri, 10 Jan 2020 15:53:54 -0000

Yes that is what it comes down to.

Is that a feature having a fixed set of parameters in the signed JAR and
some number of OAuth parameters unsigned outside the JAR, that people want
badly enough for us to pull the spec back and restart IESG review.

I think Torsten is speculating that is not a feature people use.

It was a feature that people on the IESG objected to.

If we can get concensus in the WG to pull it back, we can do it.

That is the decision we should make.

John B.

On Fri, Jan 10, 2020, 12:01 PM Justin Richer <jricher@mit.edu> wrote:

> But merge gives us the ability, which has been stated here before, to have
> a fixed core set of parameters inside the JAR and a mixed set of variable
> parameters outside the JAR.
>
> What if by “merge” we really mean “you can’t repeat things in both places
> but you can have fields in either”.
>
> — Justin
>
> On Jan 10, 2020, at 9:49 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
> I haven't seen any real use of merge.   It happens with Connect as a side
> effect of OAuths current requirement to have some of the parameters outside
> the JAR.
>
> Nothing stops servers from ignoring parameters outside JAR or acting on
> query parameters outside the JAR if they are not in the OAuth registry.   A
> server can merge but that would not be JAR compliant if they care.
>
> If the AS returned an error for parameters values that differ between the
> JAR and the query that is not required but I don't think that is
> prohibited.  I need to look at that.
>
> JAR dosen't say your server can't do something else, but that is not JAR.
>
> Clients should be updated to have all the parameters in the JAR.  That
> should be the case for most of not all clients now.
>
> For older servers they need to continue to include the required OAuth
> parameters outside.
>
> Servers need to migrate and eventually move to returning a warning or
> error when a registry parameter is outside the JAR if JAR is used.
>
> Especially if PAR is used (I suspect that will become the prefers pattern)
> then merging won't really make sense.
>
> John B.
>
> On Tue, Jan 7, 2020, 6:19 AM Torsten Lodderstedt <torsten@lodderstedt.net>
> wrote:
>
>>
>>
>> Am 06.01.2020 um 23:50 schrieb John Bradley <ve7jtb@ve7jtb.com>om>:
>>
>> A client could duplicate those outside the request object for some sort
>> of backwards compatability but they will be ignored.
>>
>> Is this used for backward compatibility with the OIDC servers?
>>
>> 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.
>>
>>
>> Is this option used in the wild? As far as I understand the main use case
>> is a 3rd party signing the request object that way entitling the client for
>> something. I‘m asking since in my experience any kind of entitlement by a
>> 3rd party is handled behind the scene using registries.
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>