Hi, you are right, PAR does not require the AS to represent the request as a JWT-based request object. The URI is used as internal reference only. That why the draft states
"There is no need to make the
authorization request data available to other parties via this
URI.”
This difference matters from an AS implementation perspective, it doesn't
matter from a client's (interop) perspective.
We may add a statement to PAR saying that request_uris issued by the PAR
mechanism (MAY) deviate from the JAR definition.
best regards,
Torsten.
> On 8. Jan 2020, at 23:42, Richard Backman, Annabelle
> <richanna=40amazon....@dmarc.ietf.org> wrote:
>
> Hi all,
>
> The current drafts of PAR (-00) and JAR (-20) require that the AS transform
> all pushed requests into JWTs. This requirement arises from the following:
> • PAR uses the request_uri parameter defined in JAR to communicate the
> pushed request to the authorization endpoint.
> • According to JAR, the resource referenced by request_uri MUST be a
> Request Object. (Section 5.2)
> • Request Object is defined to be a JWT containing all the
> authorization request parameters. (Section 2.1)
>
> There is no need for this requirement to support interoperability, as this is
> internal to the AS. It is also inconsistent with the rest of JAR, which
> avoids attempting to define the internal communications between the two AS
> endpoints. Worse, this restriction makes it harder for the authorization
> endpoint to leverage validation and other work performed at the PAR endpoint,
> as the state or outcome of that work must be forced into the JWT format (or
> retrieved via a subsequent service call or database lookup).
>
> –
> Annabelle Richard Backman
> AWS Identity
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
