Re: [OAUTH-WG] PAR: pushed requests must become JWTs

[John Bradley <[e-mail]>]

It may be a challenge to change text saying that the contents of the
resource could be something other than a request object.

If not a request object then what and how is that interoperable are likely
AD questions.

I could perhaps see changing it to must be a request object, or other
format defined by a profile.

John B.


On Fri, Jan 10, 2020, 3:45 PM Brian Campbell <[e-mail]>
wrote:

> Agree and agree. But given that the change suggested by Annabelle has no
> impact on the client or interoperability, perhaps Nat or John could work
> the change into the draft during the edits that happen during the final
> stages of things?
>
> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt <torsten=
> [e-mail]> wrote:
>
>> I would assume given the status of JAR, we don’t want to change it. And
>> as I said, this difference does not impact interoperability from client
>> perspective.
>>
>> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle <richanna=
>> [e-mail]>:
>>
>> 
>>
>> It would be more appropriate to add the text to JAR rather than PAR. It
>> doesn't seem right for PAR to retcon rules in JAR. Moving the text to JAR
>> also highlights the weirdness of giving PAR special treatment.
>>
>>
>>
>> What if we changed this sentence in Section 5.2 of JAR:
>>
>> The contents of the resource referenced by the URI MUST be a Request
>>
>> Object.
>>
>>
>>
>> To:
>>
>> The contents of the resource referenced by the URI MUST be a Request
>>
>> Object, unless the URI was provided to the client by the Authorization
>>
>> Server.
>>
>>
>>
>> This would allow for use cases such as an AS that provides pre-defined
>> request URIs, or vends request URIs via a client management console, or
>> bakes them into their client apps.
>>
>>
>>
>> –
>>
>> Annabelle Richard Backman
>>
>> AWS Identity
>>
>>
>>
>> On 1/8/20, 2:50 PM, "Torsten Lodderstedt" <torsten=
>> [e-mail]> wrote:
>>
>>
>>
>>     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=
>> [e-mail]> 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
>>
>>     > [e-mail]
>>
>>     > https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*