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 <bcampb...@pingidentity.com> 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= > 40lodderstedt....@dmarc.ietf.org> 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= >> 40amazon....@dmarc.ietf.org>: >> >> >> >> 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= >> 40lodderstedt....@dmarc.ietf.org> 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= >> 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 >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> 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.*
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
