Subject: [OAUTH-WG] PAR and client metadata

From: Brian Campbell <[email-masked]>
Date: Tue, 14 Apr 2020 14:08:54 -0600

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

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 14 Apr 2020 23:21:55 +0300

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.
>
> 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
> metadata parameter that would indicate that the given client can only
> use a request_uri value obtained from the PAR endpoint to initiate an
> /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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Tue, 14 Apr 2020 15:43:24 -0600

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 <[email-masked]>
wrote:

> (relatively) simple means for sending a confidential, integrity protected,
> and (for confidential clients anyway) authenticated authorization request.
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> 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 [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Filip Skokan <[email-masked]>
Date: Thu, 16 Apr 2020 10:15:17 +0200

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=
[email-masked]> wrote:

> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Sascha Preibisch <[email-masked]>
Date: Thu, 16 Apr 2020 08:10:42 -0700

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.

Regards,
Sascha

On Thu, 16 Apr 2020 at 01:16, Filip Skokan <[email-masked]> 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 <bcampbell=[email-masked]> 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
>> [email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Thu, 16 Apr 2020 14:50:20 -0600

> 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

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

Best,
>> 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.*

---

From: George Fletcher <[email-masked]>
Date: Thu, 16 Apr 2020 17:05:13 -0400

Maybe if we make it an array of authorization "flows" supported? A bit 
like the AS can describe whether it supports "pairwise", "public" or both?

Not sure what to name it though:) Possible values could be "redirect" 
and "par" (redirect not being quite right:) which allows for expansion 
in the future. That way the AS could easily signal whether it supports 
both or just one. It does mean the discovery doc is redundant in 
specifying that the AS supports PAR but that's probably ok.

On 4/16/20 4:50 PM, Brian Campbell wrote:
> But do you think that an AS-wide policy

---

From: George Fletcher <[email-masked]>
Date: Thu, 16 Apr 2020 17:05:13 -0400

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 17 Apr 2020 09:22:32 +0200

Is this really a PAR requirement? I’m asking since the client in the end is required to use an authorization request in the fron channel but with a PAR request_uri. So one could see this as a constrained on the authorisation request itself. Another question is whether this request_uri must be PAR based or whether it could be any other request_uri.

> On 16. Apr 2020, at 23:05, George Fletcher <gffletch=[email-masked]> wrote:
> 
> Maybe if we make it an array of authorization "flows" supported? A bit like the AS can describe whether it supports "pairwise", "public" or both?
> 
> Not sure what to name it though:) Possible values could be "redirect" and "par" (redirect not being quite right:) which allows for expansion in the future. That way the AS could easily signal whether it supports both or just one. It does mean the discovery doc is redundant in specifying that the AS supports PAR but that's probably ok.
>

---

From: George Fletcher <[email-masked]>
Date: Fri, 17 Apr 2020 10:33:30 -0400

I don't know about a PAR "requirement", but it feels like the PAR spec 
is the right place to put this. My understanding of what's being asked 
is... how does the AS advertise to it's clients that it will ONLY accept 
PAR based request_uris and other authn/authz request methods will fail.

---

From: George Fletcher <[email-masked]>
Date: Fri, 17 Apr 2020 10:33:30 -0400