On Mon, Apr 27, 2020 at 12:58:09PM -0400, Justin Richer wrote:
> I agree that any URI could be used but that it MUST be understood by the AS
> to be local to the AS (and not something that can be impersonated by an
> attacker). I wouldn’t even go so far as RECOMMENDED, but it’s certainly an
>
Yeah, I hadn't really been thinking of going so far as making it
RECOMMENDED either but more of just providing an easy option for those that
would choose to use it.
On Mon, Apr 27, 2020 at 10:58 AM Justin Richer wrote:
> I agree that any URI could be used but that it MUST be understood by the
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
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
While there are certainly different permutations and contexts of use that
could be imagine, I tend to agree with Filip here in not seeing a strong
need to define new PAR specific metadata around signing/encryption of the
request object.
On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan wrote:
>
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?
Dear all,
Thanks for all the feedback at the last round. Here’s a new version of the
draft incorporating your suggestions. Main changes:
-Added the None prohibition in section 2.1 as well
-Incorporated language suggestions from Dominick (and fixed the spelling of his
last name ;))
-Clarified
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.
Title : JSON Web Token (JWT) Profile for OAuth 2.0 Access
Tokens
Author : Vittorio Bertocci
Thanks Brian, that appears to have worked!
From: OAuth on behalf of Brian Campbell
Date: Monday, April 27, 2020 at 06:26
To: Vittorio Bertocci
Cc: oauth
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth
2.0 Access Tokens"
This old thread
In section 1.5, step 8 in the flow says:
The authorization server authenticates the client and validates the refresh
token, and if valid, issues a new access token (and, optionally, a new
refresh token).
Also, Figure 2, step 8 says:
Access Token & Optional Refresh Token
Whether or not the
I agree that any URI could be used but that it MUST be understood by the AS to
be local to the AS (and not something that can be impersonated by an attacker).
I wouldn’t even go so far as RECOMMENDED, but it’s certainly an option.
— Justin
> On Apr 27, 2020, at 4:41 AM, Filip Skokan wrote:
>
+1
On Mon, 27 Apr 2020 at 01:42, Filip Skokan wrote:
>
> I believe implementers should be free to devise their own URIs and not be
> locked down to one by the spec, at the same time, and RFC6755 subnamespace
> would be good for guidance.
>
> So, I would suggest it be RECOMMENDED to use e.g.
>
On Fri, Apr 24, 2020 at 5:48 PM Aaron Parecki wrote:
> Thanks for the detailed review Brian! I've made many of these edits to the
> draft, but there are still a few things that need some discussion on the
> list. My notes are inline below.
>
Thanks Aaron. I realize there was a lot there. I've
This old thread
https://mailarchive.ietf.org/arch/msg/oauth/1ajE-d3nVOFRGLbwMmPViDhEdqw/
has some discussion of working with/around that particular quirk of the
htmlizing tool.
On Mon, Apr 27, 2020 at 2:34 AM Vittorio Bertocci wrote:
> Thank you for bringing this up Benjamin, you saved me from
I believe implementers should be free to devise their own URIs and not be
locked down to one by the spec, at the same time,
and RFC6755 subnamespace would be good for guidance.
So, I would suggest it be RECOMMENDED to use e.g.
`urn:ietf:params:oauth:request_uri:` (Brian's proposal) but also
that
Considering there's going to be a setting that forces clients to use PAR
(other mailinglist thread), then we should rely on the existing
`request_object_signing_alg` presence to indicate a Request Object must be
used (as suggested by this upcoming OIDC Core errata
Thank you for bringing this up Benjamin, you saved me from a long wild goose
chase!
It' good to know that there's a new rfc format version, but I am a bit worried
about venturing there given that I am barely managing the v2 as it is __ v3
still feels pretty experimental, and other than this
17 matches
Mail list logo
