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 > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
