Re: [OAUTH-WG] PAR and client metadata

Vladimir Dzhuvinov <> Sun, 19 April 2020 08:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8C993A074B for <>; Sun, 19 Apr 2020 01:09:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.211
X-Spam-Level: *
X-Spam-Status: No, score=1.211 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MISSING_HEADERS=1.207, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OXV6NC6guWYD for <>; Sun, 19 Apr 2020 01:09:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC0A93A0747 for <>; Sun, 19 Apr 2020 01:09:21 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPSA id Q50xjBTawnYyoQ50yjg0Y6; Sun, 19 Apr 2020 01:09:21 -0700
X-CMAE-Analysis: v=2.3 cv=d86LNirE c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=9cW_t1CCXrUA:10 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=__SxRlIrAAAA:8 a=4kG_aAeuAw_d-pNtDboA:9 a=hVy5dM5bJJFa2tYy:21 a=QymQuDMcWa3YDhTZ:21 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=DVh3MC2FUoLFXO0QobUA:9 a=OBK4qm-CHOFXXD4I:21 a=F02Jg16fTNAJCQ-b:21 a=HKBuKgiWF3ZbqhlZ:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=H5r4HjhRfVyZ-DhAOYba:22
Cc: oauth <>
References: <> <>
From: Vladimir Dzhuvinov <>
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <>
Date: Sun, 19 Apr 2020 11:09:18 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060206000806060900080801"
X-CMAE-Envelope: MS4wfNtkJvTZCkVkqBgGPvzQdFSWwohwHSsztUFLup0W400G3f6VHa6k4hiq07VQRGP1/L6r/wyf/0QxIalPo/tUfyPOvtD6JdriPxrSn2gOCpHPFMauOEZS Jl3mTIcLVtQBuJQx8V0iNYZT65TxTu6mG1i+QFOySXQU1v0T7Dg9rOvD
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: Sun, 19 Apr 2020 08:09:24 -0000

In a off-list conversation Torsten floated the idea of letting
confidential PAR-only clients register without a redirect_uris and
having this "PAR only" parameter will enable that.

A "PAR only" parameter will also prevent client developers from
accidentally making plain authz requests (for clients that rely on PAR
for the extra security).


On 16/04/2020 18:39, Brian Campbell wrote:
> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle
> <
> <>> wrote:
>     As I think through this, I’m struggling to identify the threats
>     this actually helps mitigate.
>     A client metadata parameter implies that the value may be
>     different for different clients, and that any given client won’t
>     already know via other means whether or not it needs to use PAR.
>     That means we’re only talking about dynamic clients since
>     statically registered clients already have some proprietary
>     out-of-band registration mechanism (e.g., a developer console).
> As I tried to articulate in the original email and Filip also
> mentioned in a different fork of this email thread, defining metadata
> can be beneficial even when it's not used dynamically at runtime. So
> we're not only talking about dynamic clients.
>     A client metadata parameter also implies that the AS allows some
>     clients to make non-PAR requests (otherwise it would be an AS
>     metadata parameter).
> A per client setting seems necessary for existing ASs to roll out PAR
> support over time or just generally in support of diverse client
> capabilities and requirements.
>     If that’s the case then presumably a malicious party could
>     register their own client that doesn’t use PAR.
>     So it seems to me that the only scenario that this parameter would
>     protect against is a malicious party impersonating a dynamically
>     registered client that uses PAR. That wouldn’t apply to Mix-Up,
>     since in that attack the attacker uses its own client.
> This client metadata parameter is meant to be something that would
> prevent a malicious actor from controlling the content of the authz
> request parameters, which could be done by crafting the link and
> tricking a user into following it. I mentioned mix-up as an example
> because the first variant of it desribed at
> does something along those lines.
>     If a client can do PAR, then it can do authorization code grant
>     and PKCE, so we’re further limited to scenarios where the attacker
>     does not need to be able to redeem the authorization code
>     themselves. What threats fall into this category?
>     —
>     Annabelle Backman (she/her)
>     AWS Identity
>>     On Apr 14, 2020, at 2:44 PM, Brian Campbell
>>     <
>>     <>> wrote:
>>     *CAUTION*: This email originated from outside of the
>>     organization. Do not click links or open attachments unless you
>>     can confirm the sender and know the content is safe.
>>     I was hoping to get to a rough consensus in support of the idea
>>     before coming up with a name that everyone will hate :)
>>     In the meantime, however, name suggestions are of course welcome.
>>     On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov
>>     < <>> wrote:
>>         I'm all for that.
>>         I suppose you have already thought of a suitable name? :)
>>         Vladimir
>>         On 14/04/2020 23:08, 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
>> <>
>>     /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
>> <>