Hello Denis,
The most recent version of the DPoP draft is not draft-fett-oauth-dpop-04
but rather draft-ietf-oauth-dpop-01, which doesn't expire until November. I
realize that the naming and versioning conventions of IETF documents are a
bit esoteric and can lend themselves to such mistakes. But
In my opinion, all parameters should be able to be passed inside the request
object, including `scope`.
We couldn’t do that kind of thing in OIDC because that would be a breaking
change to existing requirements in OAuth 2. JAR is taking the step of
overriding those requirements, and so it
Hi Vladimir,
Thank you for your reply. It sounds that your opinion is "`scope` request
parameter must exist outside the request object even if JAR applies if the
authorization request is an OIDC request". I'm on the fence on this topic
and just wondered whether those who had wanted to remove
Hello Vittorio,
I have three comments numbered 1, 2 and 3.
*Comment 1:**
*
Section 3 states:
3. Requesting a JWT Access Token
An authorization server can issue a JWT access token in response
to any authorization grant defined by [RFC6749] and subsequent
extensions meant
Hello Brian and Vittorio,
I have two observations:
* draft-fett-oauth-dpop-04 which is the last version expired on 5
September 2020,
* the podcast as well as draft-fett-oauth-dpop-04 omit to mention the
client/user collaborative attack against which
draft-fett-oauth-dpop-04 is
Thanks Brian, Logan.
On clarity. I tweaked that section and produced a new draft (-10).
Details:
* Formally, the fact that we are referring to the User entity should be
unambiguous. 4.1.2 is a subsection of 4.1, which is titled "User Resource
Schema”.
However as a frequent critic of the
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
