[OAUTH-WG] PAR - Can AS/client require request object?

Torsten Lodderstedt <torsten@lodderstedt.net> Sun, 26 April 2020 15:09 UTC

Return-Path: <torsten@lodderstedt.net>
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 B9EDA3A0864 for <oauth@ietfa.amsl.com>; Sun, 26 Apr 2020 08:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lodderstedt.net
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 s03mMocyvU5A for <oauth@ietfa.amsl.com>; Sun, 26 Apr 2020 08:09:08 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 5CA9B3A0863 for <oauth@ietf.org>; Sun, 26 Apr 2020 08:09:08 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id j2so17454777wrs.9 for <oauth@ietf.org>; Sun, 26 Apr 2020 08:09:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=XjbTlymDJssY3JO0ADXwXkq0QEcmC+CmFs0HHBmqPic=; b=X/Khy72qPYg5/l5eTZGg01vqgBOLjgpcrI15Qn9bCINTpIa4CZvutBGpWiMRBF1/Vq qowWRH0fEi1Rue3NxWmIF6xewMiFOJ+5HGh29ncs9ECbiZK58vzR6mPwkZsW8V44V6FW 0kIMY4c2U7zw0tnQyvOW9IuJO06vfuURqYFLYaRsYV4kGjSlCsyM4nGxhcQB9+GAPJvb AYXCAT0i92lmiGL2i8yJy41VIK42weM2pTsf5RAjmt4YxJpYpRXOhfy5ZWBE2tcq7O0J JRCCTAFihc+xr0b378WTqoeW1p7wUtSUgcDaEFaK4+P8tdcHbIyoq1/4ofqsDIeufql4 XjAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=XjbTlymDJssY3JO0ADXwXkq0QEcmC+CmFs0HHBmqPic=; b=Bkevv6eLyUU0qRejl2J1K3v2mxAwNZJAthU2MtjQmqFyEf07vZgPLblS/Z2Wzs9TRr mJUV0MClARHSfziG7H64SYdhmuXBQlTdwaTsgGm6yIQkuks0Y6QeUN8TUmgCUxwmYMSA VGjwq5HREuwk3Vx7CeOt6Tjx9rw1EGcq8TWjI7OHPKg9/ta5h37gsjELel7I0LgwlrWv CI564IH2H2vyzGKe5VuoIPLFNS6QX0k+VdTCms65X69INQ70biHbSeLqhb75VjozoAEk +z2G7mGmlD5dvZj6ZSgbr5f4bJbuVYr/OhuRE9j77nq71a3AVNZXQre7HQxcle4vqVq9 IUyQ==
X-Gm-Message-State: AGi0PubiM0reSbE46TdoL/NO3nxw3M6bQaIumTePBS0EYFkcNKBPIyvV mLGV7Hoz2jiYB1gXxo9HnNrwuJHclGw=
X-Google-Smtp-Source: APiQypJ7bsfwFIEQth1ougbm25IBM/u3xZXouHUX2kn+pgvoOvKSumTvJV08SwbDKserkEFB/JE7Sg==
X-Received: by 2002:adf:dfcd:: with SMTP id q13mr23850583wrn.423.1587913745872; Sun, 26 Apr 2020 08:09:05 -0700 (PDT)
Received: from p200300eb8f301fbe504ffe40cdc43adf.dip0.t-ipconnect.de (p200300EB8F301FBE504FFE40CDC43ADF.dip0.t-ipconnect.de. [2003:eb:8f30:1fbe:504f:fe40:cdc4:3adf]) by smtp.gmail.com with ESMTPSA id p190sm11680344wmp.38.2020.04.26.08.09.05 for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2020 08:09:05 -0700 (PDT)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: <7320379C-877F-4446-AB71-B4C70FEFA134@lodderstedt.net>
Date: Sun, 26 Apr 2020 17:09:04 +0200
To: oauth <oauth@ietf.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/1mzeKcb7I78AOGL8t-qNukkZyYc>
Subject: [OAUTH-WG] PAR - Can AS/client require 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: Sun, 26 Apr 2020 15:09:10 -0000

Hi all, 

this is one of the topics we quickly flipped through in the virtual meeting last week. 

I see the following open questions:
- Can the client require its instances to use request objects only.
- Are there further requirements on the properties of these objects? Signed only, Signed and encrypted, algorithms? 
- Can an AS require ALL clients to use request objects only? 
- Further requirements here as well? 
- Is this tied to PAR or relevant for JAR as well? 

In my opinion, client as well as AS should be able to control enforced use of request objects. 

I could imagine the setting for JAR request objects (“request" parameter) and request objects in the PAR context differ, as the first case goes through the user’s browser whereas the PAR case goes direct from client to AS via a TLS protected channel. I therefore feel the settings should be PAR specific. 

What do you think?

best regards,
Torsten.