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). Vladimir On 16/04/2020 18:39, Brian Campbell wrote: > > > On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle > <richanna=40amazon....@dmarc.ietf.org > <mailto:40amazon....@dmarc.ietf.org>> 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 > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1 > 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 >> <bcampbell=40pingidentity....@dmarc.ietf.org >> <mailto:40pingidentity....@dmarc.ietf.org>> 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 >> <vladi...@connect2id.com <mailto:vladi...@connect2id.com>> 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 >>> >>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1 >>> >>> <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 <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> /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 <mailto: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
