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 > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
