Alternatively, `require_pushed_authorization_requests`. Since we already have the `*require_*request_uri_registration` server and `*require_* auth_time` client metadata properties.
WDYT? S pozdravem, *Filip Skokan* On Sun, 26 Apr 2020 at 16:58, Torsten Lodderstedt <torsten= 40lodderstedt....@dmarc.ietf.org> wrote: > Hi all, > > I think this topic has several aspects: > - Is the client required to use PAR only? Doesn’t this also mean it is > required to use request_uri only? > - Is there a need to separate those to questions or shall we treat this as > the same? > - Who decides whether PAR and request_uri are required? The client for its > instances or the AS for the whole deployment? > > I’m in favour of coupling enforced PAR use with enforced request_uri use > even though it means the setting is useful with PAR only, not with all > JAR-based clients. > I think both the client as well as the AS should be able to declare forced > PAR. If the AS is able to basically turn of traditional authorization > requests, it can consequently utilize the changed protocol properties in > terms of security and robustness in its deployment. This means, for > example, the AS no longer needs to require pre-registered redirect URIs for > confidential clients. It also means, the AS can use voluminous > claims/authorization details objects without worrying about fragile long > request URLs. > > So here is my proposal: > > 1) Add server metadata parameter “pushed_authorization_requests_only” of > type boolean - It requires any client to use PAR, the AS will refuse to > process any authorization request containing parameters other than > request_uri + client_id (as required by > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension > request parameters need to be passed via PAR. > 2) Add client registration parameter “pushed_authorization_requests_only” > - It requires this client to use PAR only. The AS won’t accept any > authorization request containing more than request_uri + client_id for that > particular client. > > What are your thoughts? > > best regards, > Torsten. > > > On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov <vladi...@connect2id.com> > wrote: > > > > 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> 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> 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> 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 > 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 > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> 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 > >>> 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
