Re: [OAUTH-WG] PAR and client metadata

Brian Campbell <> Thu, 16 April 2020 20:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 622D23A1091 for <>; Thu, 16 Apr 2020 13:50:51 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M4UdqJIgpNRI for <>; Thu, 16 Apr 2020 13:50:49 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 17E2A3A108B for <>; Thu, 16 Apr 2020 13:50:48 -0700 (PDT)
Received: by with SMTP id u6so7759634ljl.6 for <>; Thu, 16 Apr 2020 13:50:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BVmn2cYpZe/vLi4WCB1rkp0StnqZ1A1Hy9RSuLdf9KE=; b=c9Szm3Trc/Uu51qliJ8YAmSXbL3GGIF7coC1f6mbOIEJ5Up4TD7dwVOhk8+xlmT8TU DeXhU/IUh7nTzl9BBhYkmvkNCYmPMmj9Q2A30xiknjdQnfNCPaC7VMyRgXOr5vepk2WO 8a/otjfbwaphwrJiiKXNYBeeQSmdjS46JkC7E0i+oD3GLLRP/lZf2SywhKDvljU3xkMH 9c9gLVLfS6jgIojV7CAN9yvqRc8gtcrj2xaDvdTAwTV5KS4MhtFN5tSd0HXJGKudMOCD b6DFi44tfZkfz1D4koIVk/L3Zt4QvxgCUmgL6LiboHGfmG9vCanUJwYjuU/odBirO1t1 H56A==
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; bh=BVmn2cYpZe/vLi4WCB1rkp0StnqZ1A1Hy9RSuLdf9KE=; b=XrCGjYsJ26fJtrFoRqD+QN7AfmZc6ieIA7sDwqWCpSxCQI0In/rUxqw+mZAjZbe6HJ os0u81bgLWI8WOcEQIui+lOoKN1QCYB46g236sWgxFZ5Wj6cY6befzzQDeiEOg61AXH+ AuMpPklFdC55cj4mOy/Q9thUM1T44XDxk0raBtlvs9Hz6dsphuwGjEd5h4BEsGt1IZQK TWGH3PSDhPF6/vcu+KJT5c5f+bSdqvT+2AF+QQYL4oECupWZWdJOp1czb7G1C2J3bAAQ dVy6nK1i8YtAd1/jd11RlcWNKLqZZwGrUhQulwqWdDwu77B7Oc+bxuhWJnSSCeHPS8ZZ RZzQ==
X-Gm-Message-State: AGi0PuaMb5wB0or/06SV92DqstXoT7qOeiaA/ZB6klMq9uZsrJOBmq3e 7RG05WhkhTdMgNhfVzt/bRgnVwND2bSO55+V7k6jOOA8l4vbMhL4tXyXrVjDO8JTc74M6lrLWiu VKQtapWYBS/LynA==
X-Google-Smtp-Source: APiQypIDCY5qqgMi2a5J6Bd80uKBGQxt0IZWBPnqFZrwqxs78mM4IBYSExlRPWjFmz3UKaFYECcVLMFPKE9TnRNOPGo=
X-Received: by 2002:a2e:b8c1:: with SMTP id s1mr22532ljp.0.1587070247195; Thu, 16 Apr 2020 13:50:47 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Thu, 16 Apr 2020 14:50:20 -0600
Message-ID: <>
To: Filip Skokan <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="000000000000517eb505a36e96a7"
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 20:50:52 -0000

On Thu, Apr 16, 2020 at 2:15 AM 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).

I do think there needs to be something at the client level for it to be
useful. My thinking was that one AS-wide policy would be too broad to be of
much use. Many existing ASs will need to roll out PAR support over time or
more generally just support diverse clients with different capabilities and
requirements including PAR forever. The AS can advertise support for PAR by
including a "pushed_authorization_request_endpoint" parameter. Which is
roughly consistent with other AS metadata that's mostly about advertising
the set of supported capabilities. But do you think that an AS-wide policy
signal (i.e. all_yall_clients_gotta_do_par_every_darn_time : true) is
needed or sufficiently useful?

> 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.

That is good and useful perspective, thanks for sharing that.

> *Filip*
> On Tue, 14 Apr 2020 at 22:09, Brian Campbell <bcampbell=
>> 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

_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._