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 <panva...@gmail.com> 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=40pingidentity....@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 initia te 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
