wfm - thanks.
Brian Campbell schrieb am Mo.
27. Apr. 2020 um 21:06:
> require_pushed_authorization_requests works for me and is maybe/arguably a
> bit better by being more consistent with other names.
>
> On Mon, Apr 27, 2020 at 12:58 PM Filip Skokan wrote:
>
>> Alternatively, `require_pushed_
require_pushed_authorization_requests works for me and is maybe/arguably a
bit better by being more consistent with other names.
On Mon, Apr 27, 2020 at 12:58 PM Filip Skokan wrote:
> Alternatively, `require_pushed_authorization_requests`. Since we already
> have the `*require_*request_uri_regis
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 wrote:
> Hi all,
>
> I think
I think your proposal hits the right level of granularity and usefulness.
And I'm thrilled that you went ahead and offered up a name.
On Sun, Apr 26, 2020 at 8:58 AM Torsten Lodderstedt wrote:
> Hi all,
>
> I think this topic has several aspects:
> - Is the client required to use PAR only? Doesn
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?
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
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
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 PA
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
On Thu, Apr 16, 2020 at 2:15 AM Filip Skokan wrote:
> I would support defining a client level property. I would also support an
> AS discovery property for an AS-wide policy that is signalled to all
> clients (and maybe that one would be enough).
>
I do think there needs to be something at the c
On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle 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 alre
I am also in favour of such metadata.
I just implemented the draft and I used a client, which had multiple
redirect_uris, for testing purposes. That in mind, one of my thoughts
is that it could also be an advantage to not only bind a client to use
PAR but in combination with a specific redirect_ur
I would support defining a client level property. I would also support an
AS discovery property for an AS-wide policy that is signalled to all
clients (and maybe that one would be enough).
FWIW (and this touches my earlier responses about the dpop scheme) defining
metadata (both AS and Client) is
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
wrote:
> I'm all for that.
>
> I suppose you have already
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 cl
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
16 matches
Mail list logo
