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=40aol....@dmarc.ietf.org> 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. > > On 4/16/20 4:50 PM, Brian Campbell wrote: >> 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? > > _______________________________________________ > 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
