Re: [OAUTH-WG] PAR and client metadata

Sascha Preibisch <> Thu, 16 April 2020 15:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4BF73A0B24 for <>; Thu, 16 Apr 2020 08:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sJ1t2tDPdIqB for <>; Thu, 16 Apr 2020 08:11:14 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 460EF3A0B17 for <>; Thu, 16 Apr 2020 08:11:13 -0700 (PDT)
Received: by with SMTP id u13so5288783wrp.3 for <>; Thu, 16 Apr 2020 08:11:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=EUnSTXXnq06RIW0qc129+5aNQOuGntCpGrbLD0f0QR8=; b=lWmbhhtQzSCNFxM/8QT4Hwn9WUmoPVAZerTNYoVaGZzSD/ZM6QNHwHwBzzMadbEe0O ArWCPXGZQBEK/HlNbaFV8NBNC33qAUombakktXi3uKtNmn7/JQtjxPpH9JLe6fL/k/YJ 8vbPNv8gYvqZnJ1ewEdu7xDPMqmmWCPCQjOcoHVrCLt5l/pBI7ecJguLN1rrXLeTElPU VYxRampGstmwy+/gh5QA9iTHL1RzR6xKDI6Y1l9A5b2u5QoZYgB844LPQOfXuQ9nnHGb +dzttxsAjCJmD7FwuAVmIh+3T5XHdA0/oDLYRW3QK1VtQN4skuFrhX0ckN/V2Xcm3xGE g8zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EUnSTXXnq06RIW0qc129+5aNQOuGntCpGrbLD0f0QR8=; b=b5jf4i+HLC1cK01pDE3pPgrkoK76nL8nf+p+29U6WYmtTqbTsJOe1ew6/NDf3dQZSI h/LpLrNzKhFUIiyEZweKlS7JV1rJecnxxEurX3WCcC2thU08wK1pj/pbhR2BneXcW+z2 qSxuETsHbtl8eAeqKCw0U/c3vK6/RQqFT7jKSjSaEaMFduyH0r7UrYC/2USPioOFRBB1 rlnBwqBFv1G4lwgs1AxyYq9St9Dw+fkM22Hm+or63Xk0bsNUQwJI9nBAu2o/1CkV0e9z gFYaXGb8GzgZqiMUu1XTeuIGX5HHRThyp/hh8uzEh1FpW7ms8YETCs7Lfa0fzIpxT2F3 1fDg==
X-Gm-Message-State: AGi0PubpADlVAO/JnPaLFHstKgrR3Rymevft+dJ4EQSkThTyazztLM1F uNpLmmiVTjmH0YmyM2dIDABvkYcL/2s1a/mo2M9o+kVL
X-Google-Smtp-Source: APiQypIQWB1hQZeJsAdcP8NL78eRUCXegp9qAQfwCGcRJBf8EXKEeDjQYZV62J+o8Cg/3W3gROapYDpCDoSzMbc82Tg=
X-Received: by 2002:adf:b78b:: with SMTP id s11mr33825091wre.235.1587049871641; Thu, 16 Apr 2020 08:11:11 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Sascha Preibisch <>
Date: Thu, 16 Apr 2020 08:10:42 -0700
Message-ID: <>
To: Filip Skokan <>
Cc: Brian Campbell <>, oauth <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [OAUTH-WG] PAR and client metadata
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Apr 2020 15:11:17 -0000

I am also in favour of such metadata.

I just implemented the draft and I used a client, which had multiple
redirect_uris, for testing purposes. That in mind, one of my thoughts
is that it could also be an advantage to not only bind a client to use
PAR but in combination with a specific redirect_uri only. This may be
a implementation detail of the AS, just wanted to mention it.


On Thu, 16 Apr 2020 at 01:16, Filip Skokan <> wrote:
> 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 <> 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 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 mailing list