Re: [OAUTH-WG] PAR and client metadata

Filip Skokan <panva.ip@gmail.com> Thu, 16 April 2020 08:15 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 1A9F23A117D for <oauth@ietfa.amsl.com>; Thu, 16 Apr 2020 01:15:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, 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=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 UxI7lhmRVF4C for <oauth@ietfa.amsl.com>; Thu, 16 Apr 2020 01:15:54 -0700 (PDT)
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 1191B3A1179 for <oauth@ietf.org>; Thu, 16 Apr 2020 01:15:53 -0700 (PDT)
Received: by mail-yb1-xb31.google.com with SMTP id i2so1579238ybk.2 for <oauth@ietf.org>; Thu, 16 Apr 2020 01:15:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QnNmpYIKmfBjlWjprJ8s/phGnEkbu1sTNaHpodCuVpY=; b=cTK4m2H5QdGquq6P1AkgzPwI5KJOkwsKvewltw38ArdoTTdRNJ+lvYGZ+h6IgQra9Y n3/lTZyWKJR3VG8c/5JzW48PA6ayeRHFUMD9GbSAZnuYds+PNA+lUxDmhrZAQx2yvmAW E5OmKFkThYpeJpfcJBYDVwiiPlj35B8tc69vxte4gRial6q9kw34SHuGsHV6wMjInX3n vJJaI4TYGYMCIbWGvfnrnwN8XPzonYRXtKS591qoG9NYGUS8dK29LqMp4wcqtJgnYHAW PLkCtUCar1xHh/8s7XrB0E3d98F7A6aGHsQv7DrPwXCvv9pbnBLjMR+vqEt3z4mcX16g z7Pw==
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=QnNmpYIKmfBjlWjprJ8s/phGnEkbu1sTNaHpodCuVpY=; b=U092ZLCS/YXSowJaugFjb2pWvD2Vs1n9qpWnATZZH55pIJ1sb/0jNRpNdBeWGyX1Ad sx5QemRFdaPezNbTCXf5LRv8lh3joUCsJSYuUyK8v5kuejK59qjaZbQA4IsFJEk48V9K 3Gonbi//CKMl74oOU76TOmJKSZ1AkeCkNU4fccFyEJ0c3iDrfc5rCDJ3aZ1IaHoZlkAi n0ESXC88UdpY03HRyC77NtCDoDB+wuqANRdMWdtEpIqaSegkpHXlUnKvD35IwJBCrkzR /EUtmUInwdQV9yZo/jOimEAf+M1gH9akTFpUgYu0peGAajmiTFC3YzLCNhr3ElfY0mnX N/aQ==
X-Gm-Message-State: AGi0PuZ/WeXLKWvRadQZreWL13ZdF7ItboD4MvAELFEVej+WsQKGC5Hu 0INtuDVmvAtUPmhc1usSjp1yfRAXVfxinVFsEsS8W/I=
X-Google-Smtp-Source: APiQypJe3ffbGnSLrsb4eQiUTL2HzxdvSMNHSsddtqDCA307+77X4cBWun4q9rNKUnamTXO5+fLC/UkHwLYsexYvsxc=
X-Received: by 2002:a25:6607:: with SMTP id a7mr13753519ybc.351.1587024953078; Thu, 16 Apr 2020 01:15:53 -0700 (PDT)
MIME-Version: 1.0
References: <CA+k3eCTHtpBD-=hZPuCwjcjc_55f-J6=RKe_OGuRW38Wnhm2Cg@mail.gmail.com>
In-Reply-To: <CA+k3eCTHtpBD-=hZPuCwjcjc_55f-J6=RKe_OGuRW38Wnhm2Cg@mail.gmail.com>
From: Filip Skokan <panva.ip@gmail.com>
Date: Thu, 16 Apr 2020 10:15:17 +0200
Message-ID: <CALAqi_9cXOiEN-i1xoQSrtBP=A8QdUYi4upjL2s4kAE0fG1p3w@mail.gmail.com>
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000093f7ea05a3640a92"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/AiwBCiPYE8vqPLe0OGjcjSp0GTc>
Subject: Re: [OAUTH-WG] PAR and client metadata
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 Apr 2020 08:15:56 -0000

I would support defining a client level property. I would also support an
AS discovery property for an AS-wide policy that is signalled to all
clients (and maybe that one would be enough).

FWIW (and this touches my earlier responses about the dpop scheme) defining
metadata (both AS and Client) is beneficial not only for runtime (DCR,
discovery) but in general supports developers using these specs, when they
read about a possible behaviour in the document and there's a mentioned
metadata property, they know what to look for in readmes, API
documentation, UI etc. It saves time, theirs, and mine when i develop those
behaviour toggles - i don't have to start mixing configuration objects so
far composed entirely of IANA registered properties with proprietary ones,
i don't need to come up with property names (and we know what a PITA that
is) and it also saves time in the long run because it's less likely someone
will open an issue about it.

Best,
*Filip*


On Tue, 14 Apr 2020 at 22:09, Brian Campbell <bcampbell=
40pingidentity.com@dmarc.ietf.org> wrote:

> Using PAR can facilitate improved security by giving clients a
> (relatively) simple means for sending a confidential, integrity protected,
> and (for confidential clients anyway) authenticated authorization request.
>
> It seems like some of that improved security could be undermined by a
> malicious actor somehow getting a user to navigate to a URL of a regular
> old parameterized authorization request. One variation of the Mix-Up Attack
> does this
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
> for example and email, social media, online forums, etc., are other ways a
> user might be tricked into following a maliciously crafted link.
>
> Following from that it seems logical that an authorization server might
> want to restrict some clients from sending a regular parameterized
> authorization request and instead require use of the PAR endpoint to
> initiate an authorization request. Something like this could, of course, be
> implemented as custom policy or configuration in any AS. But I'm thinking
> it might be common enough to warrant adding a client metadata parameter to
> the PAR draft specifically for it. The metadata (and registered extensions)
> defined by Dynamic Client Registration [RFC7591] has come to imply a
> general data model and expected associated behaviors for clients that is
> useful for authorization server implementations, even when the Dynamic
> Client Registration Protocol isn't directly in play. This particular
> situation seems like a good potential candidate for a new such client
> metadata parameter that would indicate that the given client can only use a
> request_uri value obtained from the PAR endpoint to initiate an
> authorization request. And that a regular old fashioned authorization
> request from the given client would result in an error.
>
> Do the folks of this fine WG think something like this would be a
> worthwhile addition to the PAR draft?
>
>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>