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

Filip Skokan <panva.ip@gmail.com> Wed, 28 August 2019 09:00 UTC

Return-Path: <panva.ip@gmail.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 19A9A12003E for <oauth@ietfa.amsl.com>; Wed, 28 Aug 2019 02:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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=gmail.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 S1JEyAsEOKNM for <oauth@ietfa.amsl.com>; Wed, 28 Aug 2019 02:00:33 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 D21BA120018 for <oauth@ietf.org>; Wed, 28 Aug 2019 02:00:32 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id z11so1656274wrt.4 for <oauth@ietf.org>; Wed, 28 Aug 2019 02:00:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=o08zIB/CxMNC9z2adp5BgYkmaPiGjs6OpqvfVdRIWAY=; b=djUQ6EEX8TJVNkvFia7BFIiL8zFWpJMXdaeju+xCxILOnhWW1eaqdSTHqHaUcpC7pJ GFsNw78/6i6Bda0+IDBp1APhI1p1u+XICnU/NO93mRFAcLoCLYNDTO4wANoMcPpaOR9p 8DM/VW90gAdUjwLYutmq5CNE+hyyqf1KMUBgZiVgUEHgRq7zOhf6br15qSDpjE3PXPha qFvICnqhcd8i4//iORcTgJ3Walw+E+w1xoBLcikillelruZ+7WjyTeEQq+hbEkF6pf3Z U6d2yToDpNu9XpbjUIh9yKdhur4arJlFWp3j6CeFTr2drlk8IsG0qtGu/pA4Zpy1xwEG V9qA==
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=o08zIB/CxMNC9z2adp5BgYkmaPiGjs6OpqvfVdRIWAY=; b=UbcEJ56iETBXnH38qspm0qUFB0nz84zSebyKo1NspkUR2bK7r6CBj8zkb8WSb0wybQ e+BIGJ7nPnBvHjdkxd2csoOPZHKaa3EgsEY6ZQADJ09aFfrmrvOx7L+Pq83/oJ+MpE6A 77yt9h4NodEvplEpU0qDqwP8TVx4zZx9xBO9mTknMC7faMPhIBK57XpqgwdeZn2uw82c hdZi/32/jJg2GQ4jBrSJIBMD3CRpuQKY9xEUtvALE5YWTsm6l7YTvLbV3WDyjF5T8vaV kZxdaUp0LwcWi8IZl2yvZvKpbuPPVFuSm6AxTCNT3ieK0Byt3aRJRf0/q16LrLdmN0rm 2q5g==
X-Gm-Message-State: APjAAAWFLnqx8PqO8SyNBIj3PSapDO3HSrKag/GxDrIm+huQYdVehrQP bhvd2jFax62/YC4/TARhNg==
X-Google-Smtp-Source: APXvYqxbRUotVlGk/yotKkiNc8lvfZ8AjmHAP0sYrsKtyXfd5eOxRUCbGQdIOEie+rR089F1OzRV0w==
X-Received: by 2002:adf:e30e:: with SMTP id b14mr3262084wrj.168.1566982831242; Wed, 28 Aug 2019 02:00:31 -0700 (PDT)
Received: from [100.96.66.97] (ip-37-188-253-244.eurotel.cz. [37.188.253.244]) by smtp.gmail.com with ESMTPSA id 20sm1977743wmk.34.2019.08.28.02.00.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Aug 2019 02:00:30 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Filip Skokan <panva.ip@gmail.com>
X-Mailer: iPhone Mail (16G77)
In-Reply-To: <674CC181-FE18-4BED-83DC-916EF86E7AA8@lodderstedt.net>
Date: Wed, 28 Aug 2019 11:00:29 +0200
Cc: oauth <oauth@ietf.org>, Nat Sakimura <nat.sakimura@oidf.org>, John Bradley <ve7jtb@ve7jtb.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <865F377D-46D7-4420-AB15-FD2B67E37B28@gmail.com>
References: <CALAqi_-Ku6Hh3DQDXGR+83Q8jofMzVBcW=7GUnFFzsoG+Ka_1g@mail.gmail.com> <674CC181-FE18-4BED-83DC-916EF86E7AA8@lodderstedt.net>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/4dpbO0jzqWrs-xfc9ycuWw4o5LE>
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: Wed, 28 Aug 2019 09:00:36 -0000

I can get by not having to have the minimum oauth request parameters, but the current language does not imply that one can use the parameters if they’re not present in the Request Object. 

That derails JAR from its OIDC variant. 

Odesláno z iPhonu

28. 8. 2019 v 10:48, Torsten Lodderstedt <torsten@lodderstedt.net>et>:

> Hi Filip,
> 
> In my understanding, duplication of request parameters outside of the request object was necessary in the OIDC variant in order to retain OAuth compliance. JAR as an OAuth extension will not require the client to duplicate OAuth request parameters outside of the request object.  
> 
> There might potentially be reasons for merging (different) URI request parameters with parameters passed in the request object in cases where long living request objects are used.  
> 
> kind regards,
> Torsten. 
> 
>> On 27. Aug 2019, at 13:46, Filip Skokan <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
>> https://www.ietf.org/mailman/listinfo/oauth
>