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

John Bradley <ve7jtb@ve7jtb.com> Fri, 10 January 2020 14:49 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 B7FAF1200FF for <oauth@ietfa.amsl.com>; Fri, 10 Jan 2020 06:49:25 -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 HKtIHeUA78oR for <oauth@ietfa.amsl.com>; Fri, 10 Jan 2020 06:49:23 -0800 (PST)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 0E2F81200F7 for <oauth@ietf.org>; Fri, 10 Jan 2020 06:49:23 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id a5so2305575wmb.0 for <oauth@ietf.org>; Fri, 10 Jan 2020 06:49:22 -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=osZNMqeF9rqMJ6b8Ulf2PpBQFAmnL6BPK4tQ6u85hHk=; b=XaLbNFUGVSpJwIjQqXDaQCeB6gzPoPTQ22pGO1PhqBA3hDQz3AEkOR6x1mV+ELfyFS rL08itd/8AkYbWnEfWQ09iIKYLVU0cJXEV3NYyMQt2TSt7QDfqeyeWPEc3+Ywlg3XkBV VjchB8PongBdb2ddWPVgEUCYZy7Q3+J6BUOS4puI1pkVrfRnzcCg/pZKd+rNOWFMLMLk EMhLd3PzRacM2ILCrq7jBkQKo8nRiiPxPw2bvADpUKnA5nHjo858e4Itda0Fr5Gp8cGn 6kxGay95s2L7Os46rsB9E5tN45nXe0JiobXn2I3cR+FnnJ2GyRbOnLDTZRIIURdgAX4e r8hw==
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=osZNMqeF9rqMJ6b8Ulf2PpBQFAmnL6BPK4tQ6u85hHk=; b=f2i5CYfR2XMsCSoSFt3Ydd3gE9j4rjxBZ8A10OUPBnjAPBX+Fj6jJl/YJUu4WSw3iI MlUrnrkleonvKcKeJ/+53cq4yXRgUo48xaMbxwkSxx/wohmH3PKWyd0d4RTQhURx/lFd BdMGAfghv2AaR6IlU8VL4xjJsFZVQFXBkLS8ZYBg3OVWlBnTMYyLxshTAV+2kaNdEbEc nQFePIOehqlrDQlu84MiXnxfzlOr1zlvXGLX8QLQjsrO5ZYIlseuL31mswSq1u8908Yl okOxizNvXtmSdyPyi/4Hud/Yh98YKpN9cgKmTIrjMmJ3p41zCVgKoJWmHxm+1V0DJpTs cYlw==
X-Gm-Message-State: APjAAAVj390ok+wFi8QUT0FMboHAuQzsBoQVyT3b7QVNkUMUviW6Oaji UevBNaDrdR+zQcAkzcGNEaPR0aXdgeRfiAb4FOzrXA==
X-Google-Smtp-Source: APXvYqx0pCzPWxlbDB/z8DTShD0XxPgFPUPx2Kx7VhLFvm2/HFdP0vFHdJ/witNfRmCul/fnakfWRoMxGyqqaUdcsAE=
X-Received: by 2002:a1c:61c1:: with SMTP id v184mr4755365wmb.160.1578667761312; Fri, 10 Jan 2020 06:49:21 -0800 (PST)
MIME-Version: 1.0
References: <88b53953-620d-6bbb-403f-1c36bfd0d63c@ve7jtb.com> <8CF35A0F-F18A-4858-8A46-0713D205FAC8@lodderstedt.net>
In-Reply-To: <8CF35A0F-F18A-4858-8A46-0713D205FAC8@lodderstedt.net>
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Fri, 10 Jan 2020 11:49:08 -0300
Message-ID: <CAANoGhJ8kW+waoOmAOAiN5T90J_Pp5NytcY3mS-dg8PysCvGXA@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: IETF oauth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000021bc09059bca3bff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/2thfHAuMdsCboYdp2IEMlmnm490>
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 14:49:26 -0000

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.
>