I don't know about a PAR "requirement", but it feels like the PAR spec
is the right place to put this. My understanding of what's being asked
is... how does the AS advertise to it's clients that it will ONLY accept
PAR based request_uris and other authn/authz request methods will fail.
On 4/17/20 3:22 AM, Torsten Lodderstedt wrote:
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
