Re: [OAUTH-WG] PAR and client metadata

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

Re: [OAUTH-WG] PAR and client metadata

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

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

I'll +1 that On Thu, Apr 16, 2020 at 2:14 PM Aaron Parecki wrote: > My mistake! In that case, my request is editorial, to mention that in > section 2.1 where it first talks about signing algorithms. > > > Aaron Parecki > aaronparecki.com > @aaronpk > > > > On

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

My mistake! In that case, my request is editorial, to mention that in section 2.1 where it first talks about signing algorithms. Aaron Parecki aaronparecki.com @aaronpk On Thu, Apr 16, 2020 at 1:12 PM Brian Campbell wrote: > sec 4 does have "The resource

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

sec 4 does have "The resource server MUST reject any JWT in which the value of "alg" is "none".' On Thu, Apr 16, 2020 at 1:09 PM Aaron Parecki wrote: > Section 2.1 says: > > > Although JWT access tokens can use any signing algorithm, use of > > asymmetric algorithms is RECOMMENDED > > Can this

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Section 2.1 says: > Although JWT access tokens can use any signing algorithm, use of > asymmetric algorithms is RECOMMENDED Can this be strengthened to disallow the `none` algorithm? Something like adding "... and MUST NOT use the "none" algorithm". Given that the JWT BCP doesn't disallow the

Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

Thanks Filip for the replies. I'll add this to the growing list of todos for a coming revision of the draft. On Thu, Apr 16, 2020 at 2:06 AM Filip Skokan wrote: > I'm still somewhat on the fence as to the pros and cons of using a new >> token type and authorization scheme. But the draft has

Re: [OAUTH-WG] PAR and client metadata

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

Re: [OAUTH-WG] PAR and client metadata

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

Re: [OAUTH-WG] PAR and client metadata

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

Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

> > I'm still somewhat on the fence as to the pros and cons of using a new > token type and authorization scheme. But the draft has gone with a new one. > Would it have really helped this situation, if it'd stuck with "bearer"? Or > would it just be less obvious? > If we had stuck "bearer" than i

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Since this is the last call, I thought I bring up some of thoughts / concerns. Some of them have been discussed before. *client_id vs sub* I am still not entirely happy with the “re-purposing” of the claim types based on flow. If the intention is, that sub expresses the entity against which the